On Wed, Feb 26, 2020 at 6:55 PM Fernando Gont <ferna...@gont.com.ar> wrote:
> On 26/2/20 12:57, Dirk Steinberg wrote: > > Hi Fernando, > > > > adding to my own comment and to be more specific: > > > > The existing RFCs are very clear in their wording that > > the node identified in the Destination Address field of > > the IPv6 header is free to do whatever it desires with > > the packet it just received. After all, the packet was > > addressed specifically to that node. > > > > These nodes are called segment endpoint nodes in SRv6. > > > > Only nodes that are *NOT* identified in the DA are > > prohibited from making any changes. > > This should be very clear, even if you seem to > > wish that IPv6 had been defined differently. > > Are you saying that IPv6 allows for in the network header > insertion/removal? > No, not on a transit node. Yes, in SRv6 on a segment endpoint node. And that is not plain IPv6 anymore, that is the innovation the SRv6 brings along. > If so, please tell me how AH, Path-MTU Discovery, and ICMPv6 error > reporting works -- all very basic functions of IPv6. > > IPv6 is an end to end protocol. The IPv6 you are referring to (end-to-end user traffic) must not be confused with what SRv6 is. SRv6 will always encapsulate said user traffic and NOT modify it at all -- just like you demand. Therefore on that user plane all functions that you talk about will continue to function as before, AH, PMTU, and all. Managing MTU so as not to blow up within a carrier network has been done successfully with MPLS for more than 20 years. SRv6 should be understood for what it is -- a modern successor to MPLS to be used as both an underlay and service layer, managed within a well-defined network domain. SRv6 SRH should never occur directly within the user IPv6 header but only within the header added and owned by the carrier running SRv6. And within their own header the network operator, after receiving the packet at the IPv6 DA, can make changes. It's their own private header, just like the MPLS label stack in SR-MPLS. If you want to take a really orthodox and strict viewpoint maybe you should view the "end-to-end" IPv6 relation as being segment endpoint to segment endpoint only. Each new SRv6 segment opens up a new IPv6 end-to-end relation, whereas the "end-to-end" relation from the SRv6 point of view is at a higher layer. Then of course you could also adopt a more liberal viewpoint and just view the entire end-to-end SRv6 path as one end-to-end IPv6 entity as well without considering the underlying segment endpoints as IPv6 endpoints. With RH you change the DA on the flight, > No -- you do not change DA in flight -- only on segment endpoints which are the DA of the IPv6 packet. When IPv6 was defined decades ago nobody was thinking about SRv6. That notion was not present then -- otherwise one might have indeed clarified some of the points that are debated today. But just because the inventors of IPv6 did not think to include SRv6 capabilities from the start this should not be used as an excuse to block innovation. One could, of course, just say that SRv6 is a completely new animal to completely avoid the current type of discussion and just redefine everything from scratch. But why should we do such a thing? IMHO it is much better to take existing IPv6 and innovate by extending it -- not changing existing behavior -- in ways that had never been envisioned by the original authors of IPv6. That is what SRv6 is doing. > because routing only works based on the DA -- there's no other way to > specify waypoints. > If you claim otherwise, that can be, at best, a major misunderstanding > of how IPv6 works. > SRv6 is not the same as IPv6. Maybe there is a misunderstanding about SRv6 here. Cheers Dirk Thanks, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
