Of course, if it's allowed to make a minor change to the MPLS architecture (i.e., adding a protocol field immediately after the bottom of the label stack to indicate the MPLS payload type ), the first nibble issue imposed on those new encapsulations which may be transported over MPLS would disappear forever. Furthermore, the necessity of allocating local labels just for the purpose of indicating those new encapsulations (imagine how to transport NSH over MPLS) would disappear forever as well.
Best regards, Xiaohu > -----Original Message----- > From: Xuxiaohu > Sent: Wednesday, April 08, 2015 10:15 AM > To: 'Erik Nordmark'; [email protected] > Subject: Re: [nvo3] Encapsulation considerations > > Hi Erik, > > As it has said in the draft : "... We later expanded the scope somewhat to > consider how the encapsulations would play with MPLS "transport", which is > important because SFC and BIER seem to target being dependent of the > underlying "transport"...", it would be necessary to consider the first nibble > issue for those encapsulations which may be transported over MPLS. More > specifically, for those encapsulations which may be directly encapsulated > further > with an MPLS header, they must not start with the value 4 (IPv4) or the value > 6 > (IPv6) in the first nibble. Otherwise, they would be mistakenly interpreted > as IP > payloads by transit LSRs and therefore be subjected to ECMP and potential > packet misordering. > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
