Hi John, I think the crux of the matter is indeed in definition of "SRH data plane". So let me present my own personal understanding of it.
Clearly SRH external format does not change so hardware's ability to read SRH remains intact. IPv6 packet's header also can be read and processed by network elements which have no idea about cSIDs so that as well is not questionable. Now your definition of data plane is sound if you consider traditional data planes of network elements when control plane input set's forwarding behaviour. Well in SRH as you know we have SIDs which inside may contain functions. So forwarding behavior is not pre programmed from control plane, but can and often is embedded in the actual packets. That is what real network programming is all about. And each function can have zoo of also nested arguments all resulting in different forwarding outcome. With such definition of SRH data plane I do not see anything new in adding few new flavours to existing behaviours or even adding new behaviours. Now the question is do we all see SRH data plane in the same way. Maybe it is way ahead of our times and classic ASIC design ? And I am in no way judging here if this is good or bad - I am just observing the facts and already published RFCs. Many thx, Robert PS. And I do agree with your inline comment that cSIDs should be possible to be used without SRH if no special functions are needed at each segment endpoint. On Thu, Oct 14, 2021 at 12:28 AM John Scudder <j...@juniper.net> 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
