Hi John Greg made an excellent point that as SRv6 uses the IPv6 data plane and as IPv6 extended header routing header SRH RH type 4 is in fact part of the “data plane”.
So as CSID containerization of the 128 bit SID entry in the SRH header RFC 8754, CSID is in fact a change of not only the SRV6 forwarding plane RFC 8986 as well as IPv6 data plane SRH RFC 8754. Many Thanks Gyan On Wed, Oct 13, 2021 at 9:23 PM Greg Mirsky <[email protected]> wrote: > Hi John, > thank you for equipping your question with the definition of the data > plane. That helps a lot. I agree with Gyan that as the local function > processing the SID encoding in an SRH container must change, so the only > conclusion we can make is that the data plane that supports C-SID is > different from the one that only supports RFC 8754. > > Regards, > Greg > > On Wed, Oct 13, 2021 at 3:29 PM John Scudder <jgs= > [email protected]> wrote: > >> Hi Folks, >> >> I’m struggling with the claim repeated throughout the beginning of >> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, §3) that >> “this solution does not require any SRH data plane change”. >> >> I’m not aware of a standardized formal definition of “data plane”, it >> seems to follow Justice Stewart’s maxim of “I know it when I see it”. >> However, here’s an attempt, cribbed from some Washington University course >> slides: a “local, per-router function that determines how a datagram >> arriving on a router input port is forwarded to a router output port”. >> Seems reasonable. >> >> I also am not aware of a standardized formal definition of the term “SRH >> data plane”, in fact this draft, its predecessors, some associated blog >> posts, and Clarence’s dissertation, are the only places a search finds the >> phrase (but it’s not formally defined in any of them). So I’m just going to >> assume it means the data plane, as applied to packets that include an SRH. >> (I’m not sure why we should disregard packets that are encoded using >> NEXT-C-SID that omit the SRH, but let’s overlook that for now.) >> >> If this solution does not require any SRH data plane change, presumably >> it would be true that if I take a packet that includes an SRH and place >> within it a series of SIDs encoded with (for example) the REPLACE-C-SID >> flavor, then that packet would be able to successfully traverse a network >> of routers that support plain vanilla RFC 8754. That is, it would arrive at >> its first hop router which according to a local, per-router function, would >> determine how to take the datagram arriving on the router input port and >> forward it to (the correct) router output port. Then that process would be >> repeated across the rest of the network. >> >> But that is patently incorrect: when it’s delivered to the first hop, the >> plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID >> behavior, and forwarding to the next hop will fail. It seems that a >> different local, per-router function is required (in fact, the local, >> per-router function defined in the draft) in order for the forwarding to >> succeed. By the definitions I’m using here, that is exactly a data plane >> change. >> >> What, precisely, is then being claimed? >> >> Thanks, >> >> —John >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
