Hi John CSID as it does supports SRv6 forwarding plane, it does require a change to the existing SRv6 PGM RFC 8986 to support the CSID draft new flavors.
So yes definitely a software upgrade would be required. Kind Regards Gyan On Wed, Oct 13, 2021 at 7:25 PM John Scudder <jgs= 40juniper....@dmarc.ietf.org> wrote: > Hi Robert, > > My question doesn’t have anything to do with “classic ASIC design”. Indeed > if you look at the definitions I supplied they don’t say anything at all > about how the router is implemented, the nature of the control plane > including whether there is one, and indeed are very broad. I would say they > are general enough to encompass everything you described. > > As best I can tell, “adding new flavo[u]rs” or “adding new behaviors” is > just a different way of saying “making a change to the local, per-router > function that determines how a datagram arriving on a router input port is > forwarded to a router output port”. That is to say, by definition it is a > change to the forwarding plane. > > I tried to motivate this with the for-instance in my fourth paragraph: can > my plain-vanilla RFC 8754 network successfully forward a packet that uses > cSIDs? Or does it need new software, at the nodes identified by the SIDs > contained in the cSID, in order to supply support for the “new flavor” or > “new behavior”? If it needs new software, then it seems self-evident to me > that it’s a change to the forwarding plane — it “looks like a duck, swims > like a duck, and quacks like a duck”.[*] > > Thanks, > > —John > > [*] https://en.wikipedia.org/wiki/Duck_test > > On Oct 13, 2021, at 6:57 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
