IMO it is simply a restriction on the first four bits of anything that can be directly encapsulated in MPLS
Otherwise, designing (for example) a version field for which IANA will have to punch holes in the assignment range does not seem like a good idea. And I’ve not been able to convince myself that this requirement has completely gone away. Cheers Dave From: BIER [mailto:[email protected]] On Behalf Of Tony Przygienda Sent: Thursday, April 09, 2015 11:18 AM To: Alia Atlas Cc: [email protected]; BIER; [email protected]; [email protected]; Erik Nordmark; Xuxiaohu Subject: Re: [Bier] [sfc] [nvo3] Encapsulation considerations I would venture to say that a. BIER misordering would be a bad thing for many applications but I do not think that the encapsulation per se misorders or not as property, it’s the way the intermediate routers are allowed to play shannigans (or seen differently, ‘heuristically’ come up with things given unclear semantics of the encaps) that causes misordering. So it is up to the encaps to give enough info so the routers in the middle do the ‘right thing’. Modulo historical problems with CW support and so on … b. This flavor of discussion is repeating, e.g. eVPN RFC with the CW/no CW debate which I could restore only partially and other groups now … OK, lemme stick my (naïve ;-) head far out: why do encaps guidelines for everything that can go over PSN not mandate CW from now on? Existing gear and historical RFCs supported until they peter out and entropy labels being an orthogonal mechanism … Or do we think the ‘heuristical DPI' is a bottomless box of band-aids ? --- tony On Thu, Apr 9, 2015 at 11:01 AM, Alia Atlas <[email protected]<mailto:[email protected]>> wrote: On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <[email protected]<mailto:[email protected]>> wrote: On 4/8/15 7:20 PM, Xuxiaohu wrote: Hi Erik, But I couldn't tell from the emails on the BIER list whether the constraints on the first nibble value is a strict requirement in all cases, or whether it is conditional on something (and if so, what is the condition). The conditions that I have thought of include: 1) the encapsulation is sensitive to packet misordering; 2) the encapsulation may be transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS payload to select the ECMP path. Those are conditions when the misordering would happen. But are you saying that any LSR is free to use the MPLS payload (including looking for 4 and 6 in the first nibble) to determine whether the packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes? Take a quick look at RFC 4385 - which is the control word for pseudo-wires. The short form is that a number of routers at the time peeked beneath the label stack to figure out whether what was inside as IPv4 or IPv6 based solely upon the first nibble. A recommendation was made that the checksum should also be verified, but the only equipment that I'm certain of that did that isn't around anymore. Also look at Section 2.4 of RFC 7325. Alia Thanks, Erik Best regards, Xiaohu Once I know that answer we can definitely add some text pointing out the issue. Thanks, Erik Best regards, Xiaohu -----Original Message----- From: Erik Nordmark [mailto:[email protected]<mailto:[email protected]>] Sent: 2015年3月26日 5:01 To: [email protected]<mailto:[email protected]> Subject: [nvo3] Encapsulation considerations I presented part of this at the most recent NVO3 interim meeting.The full 12 areas of considerations where presented at RTGWG earlier this week. The draft is http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ and the slides are at http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf There is probably additional things in there to consider for NVO3, and advice that can be reused to make it easier to move NVO3 forward. Regards, Erik _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ sfc mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ BIER mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bier
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
