Mark, It is possible to implement the SR architecture without perverting IPv6. That's what SRm6 is all about.
SR solves the following problems: * Traffic steering * Passing information to segment endpoints to support SFC * Passing information to the packet's ultimate destination to support VPNs * Fast Reroute All of these can be addressed without breaking the IPv6 architecture. See: * https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/ for traffic steering * https://datatracker.ietf.org/doc/draft-bonica-6man-seg-end-opt/ for delivering information to segment endpoints * https://datatracker.ietf.org/doc/draft-bonica-6man-vpn-dest-opt/ for delivering information to the packet's ultimate destination Fast reroute can be achieved with an IPv6-compliant variation of TI-LFA. Create the repair path by encapsulating the packet in another IPv6 header that has its own Routing header. Ron From: ipv6 <[email protected]> On Behalf Of Mark Smith Sent: Friday, February 28, 2020 8:13 PM To: Warren Kumari <[email protected]> Cc: James Guichard <[email protected]>; SPRING WG List <[email protected]>; 6man WG <[email protected]>; Robert Raszuk <[email protected]> Subject: Re: [spring] RFC8200 update? On Sat, 29 Feb 2020, 06:55 Warren Kumari, <[email protected]<mailto:[email protected]>> wrote: On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk <[email protected]<mailto:[email protected]>> wrote: > > > interestingly enough MPLS took the same approach > > Well not really. As you know, MPLS unicast and multicast have a new ethertype. And this is a critical distinction -- Brian Carpenter's limited domain document (draft-carpenter-limited-domains) says: "Domain boundaries that are defined administratively (e.g. by address filtering rules in routers) are prone to leakage caused by human error, especially if the limited domain traffic appears otherwise normal to the boundary routers. In this case, the network operator needs to take active steps to protect the boundary. This form of leakage is much less likely if nodes must be explicitly configured to handle a given limited domain protocol, for example by installing a specific protocol handler." Using IPv6 for SR is fundamentally using the wrong tool for the job. IPv6 is an internetworking protocol used to network networks and to internetwork all hosts attached to all of those networks. The SR problem space is typically limited to local network or sub-network, and usually only between network elements, rather than out to end hosts. It does make sense to try to use a internetworking protocol to solve a local sub-network problem when the internetworking protocol has become commodity. The benefits of the cheapness of the commodity protocol should outweigh the costs of the drawbacks and compromises that need to be made to use it. However, the moment customising the commodity to better suit the problem starts is the moment the benefits of using the existing commodity start being lost. Customise too much and all of the benefits of choosing a commodity in the first place disappear. That's why I fundamentally think changing IPv6 to suit SR should be avoided as much as possible. Compromising SR to suit and fit within existing IPv6 would retain the benefits of using existing commodity IPv6. Customising IPv6 to suit SR risks throwing the commodity benefits "baby out with the bathwater", with the more radical the customising, the greater risk. Regards, Mark. > > 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://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!RyNO7NdA0TVRLR5IWzQtztXYzSVXXmWf9C42QoCax9VkMMefqNhlkK6es2NheiOg$> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected]<mailto:[email protected]> > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RyNO7NdA0TVRLR5IWzQtztXYzSVXXmWf9C42QoCax9VkMMefqNhlkK6esxpQhIzK$> > -------------------------------------------------------------------- -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RyNO7NdA0TVRLR5IWzQtztXYzSVXXmWf9C42QoCax9VkMMefqNhlkK6esxpQhIzK$> -------------------------------------------------------------------- Juniper Business Use Only
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
