On Tue, May 16, 2017 at 10:29 PM, Brian E Carpenter <[email protected]> wrote: > On 14/05/2017 05:42, Tom Herbert wrote: >> Hello, >> >> At the Chicago WG meeting I made a request that ILA be taken up as a >> WG item in int-area. The WG chairs and AD requested that we raise a >> discussion on the list about what else is needed to be done for ILA >> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The >> question was also raised if int-area is the right WG for ILA or if it >> should have a BOF. > > I think it's fine for int-area to take this up, as long as 6man > is alerted. > > A few somewhat random comments: > > Is there any particular reason you chose a /64 routing prefix, > rather than say /72 or /80? I don't see any dependency on SLAAC, > so there's no reason to care about /64, right? I assume you would > use DHCPv6 or some other method of assigning addresses to VMs. > The 64 bit was for convenience since that is what ILNP had and in the DC we wanted enough identifier bits to be able to do identifier assignment based on a timestamp as described in appendix B. There's no hard requirement for it. I think we could just say an ILA domain can define lengths of identifier and locators as they see fit-- as long as its consistent and unambiguous within the domain there shouldn't be an issue.
> If you used /72 or /80 you'd have flexibility with a ULA prefix to > insert a subnet field. > >> The format of an ILA address with a global unicast locator is: >> >> |<--------------- Locator --------------->| >> |3 bits| N bits | M bits | 61-N-M | 64 bits | >> +------+-------------+---------+---------------------------------+ >> | 001 | Global prefix | Subnet | Host | Identifier | >> +------+---------------+---------+--------+----------------------+ > > Why is this restricted to 2000::/3? Probably shouldn't be. If locator length isn't fixed like above, then probably should just describe it by properties of being routable to physical hosts. > >> The format of an ILA address with a unique local IPv6 unicast locator >> is: >> >> |<--------------- Locator --------->| >> | 7 bits |1| 40 bits | 16 bits | 64 bits | >> +--------+-+------------+-----------+----------------------------+ >> | FC00 |L| Global ID | Host | Identifier | >> +--------+-+------------+-----------+----------------------------+ > > The first byte is confusing; presumably you're trying to express > fd00::/8 so why not put 11111101 ? > > I agree that the flow label would be tricky to use for this sort of > purpose, but I have a couple of comments anyway: > >> o The flow label is only twenty bits, this is too small to be a >> discriminator in forwarding a virtual packet to a specific >> destination. Conceptually, the flow label might be used in a >> type of label switching to solve that. > > Perhaps, but 6man fairly comprehensively rejected that type of usage. > In practice it's excluded by section 4 of RFC6437. > > o The flow label is not considered immutable in transit, > intermediate devices may change it. > > That's not phrased quite right. RFC6437 section 2 says: > > " Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change it > only for compelling operational security reasons as described in > Section 6.1. > > There is no way to verify whether a flow label has been modified en > route..." > > You could in fact have an operational guarantee that within an > administrative domain, no middleboxes will change the flow label. > So something like this is more accurate: > > o The flow label is not protected against changes in transit. > Yes, the flow label concept came up in some early dicussions. >> o Intermediate devices must not insert extension headers >> [RFC2460bis]. > > I think you could say: > > o Current specifications do not allow intermediate devices to > insert extension headers [RFC2460bis]. > Good point. > Regards > Brian _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
