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

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 <gregimirsky@gmail.com> 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=
> 40juniper.net@dmarc.ietf.org> 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
>>
> _______________________________________________
> 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.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*