On 4/9/15 3:50 PM, Ian Cox wrote: > MPLS has no indication in the label stack for intermediate nodes what > the underlying payload is. To achieve better load balancing of MPLS > traffic most hardware today looks to see if the first nibble is 4 or > 6 then parse into the payload under the belief that it is a IPv4 or > v6 packet and parse the address fields out to use in the ECMP hash.
Some of them also use the TOS or DSCP bits as part of the hashkey with the additional ensuing entertainment value that provides. > If your defining something new please put a "next protocol" or type > field in the preceding header so it clear what the next protocol is. > The 4 or 6 guess for the underlying MPLS payload being an IP packet > was fine until IEEE allocated MAC addresses starting with 6. This > issue is specific PWE3 packets that do not contain the control word. > > > Ian > > -----Original Message----- From: BIER [mailto:[email protected]] > On Behalf Of Erik Nordmark Sent: Thursday, April 09, 2015 10:50 AM > To: Xuxiaohu; Erik Nordmark; [email protected] Cc: [email protected]; BIER; > [email protected] Subject: Re: [Bier] [nvo3] Encapsulation considerations > > 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? > > 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]] Sent: 2015年3月26日 5:01 To: >>>>> [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] https://www.ietf.org/mailman/listinfo/nvo3 >>>> >> > > _______________________________________________ BIER mailing list > [email protected] https://www.ietf.org/mailman/listinfo/bier > _______________________________________________ nvo3 mailing list > [email protected] https://www.ietf.org/mailman/listinfo/nvo3 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
