Indeed although I was commenting on the fact that MPLS does not leak MPLS packets outside of the administrative domain just like SRv6 MUST NOT ..
From: Robert Raszuk <[email protected]> Sent: Friday, February 28, 2020 9:02 AM To: James Guichard <[email protected]> Cc: Sander Steffann <[email protected]>; Wang, Weibin (NSB - CN/Shanghai) <[email protected]>; SPRING WG List <[email protected]>; 6man WG <[email protected]>; Andrew Alston <[email protected]> Subject: Re: [spring] RFC8200 update? > interestingly enough MPLS took the same approach Well not really. As you know, MPLS unicast and multicast have a new ethertype. SRv6 folks were just too nice and thought to leverage 0x86DD. I think that was a mistake. I further think we should fix it. Cheers, R. On Fri, Feb 28, 2020 at 2:44 PM James Guichard <[email protected]<mailto:[email protected]>> wrote: Hi Sander, RFC8402 explicitly says in section 8 security considerations that "by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain". The intent therefore seems clear that "global internet" does not apply; interestingly enough MPLS took the same approach and has been widely deployed for years. Respectfully, Jim -----Original Message----- From: spring <[email protected]<mailto:[email protected]>> On Behalf Of Sander Steffann Sent: Friday, February 28, 2020 8:25 AM To: Wang, Weibin (NSB - CN/Shanghai) <[email protected]<mailto:[email protected]>> Cc: SPRING WG List <[email protected]<mailto:[email protected]>>; 6man WG <[email protected]<mailto:[email protected]>>; Andrew Alston <[email protected]<mailto:[email protected]>> Subject: Re: [spring] RFC8200 update? Hi, > In the bearer of srv6 traffic, srv6 domain is only one part of the whole > packet journey. Because the srv6 domain is trusted by single operator, it is > no necessary for the outer IPv6 header (for performing SRH function) to > inherit all IPv6 extension headers specially designed for the initial > end-to-end IPv6 communication, for example, the AH is not must for outer IPv6 > header and its SRH. Therefore, the outer IPv6 processing of srv6 traffic can > appropriately relax the restrictions, that is to say, the outer IPv6 > encapsulation only inherits a part of IPv6 spec. No. It uses IPv6 and must therefore follow the rules of IPv6. What I propose is to update IPv6 to make this possible, but you can't break the rules in a standard without consensus that the rules can be changed. > For example, it is allowed to perform functions such as PSP within SRv6 > domain; Could we treat IPv6 headers function of internal and external layers > differently, after all, their purposes are different. Let's not use implicit definitions of "internal" and "external" layers. They don't make sense in a global protocol (and despite your claims that SRv6 is limited to a specific domain, it really isn't. It uses global IPv6 addresses and can traverse the global internet). Let's define global rules that apply to everybody instead, and standardise this behaviour. Cheers, Sander _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C855c414ffe774210ff8808d7bc56df71%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184953611018112&sdata=MN7hgUndA0GZdyfHJwN6iFGnFnP3jjXl%2BC94NX0DzNE%3D&reserved=0>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
