Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[Gyan Mishra <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*