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

From: John Scudder <[email-masked]>
Date: Wed, 13 Oct 2021 22:28:42 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Oct 2021 00:57:49 +0200

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 <[email-masked]> 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.
>

---

From: John Scudder <[email-masked]>
Date: Wed, 13 Oct 2021 23:24:58 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Folks,

Thanks,

—John

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 14 Oct 2021 01:53:28 +0200

Il 2021-10-14 01:24, John Scudder ha scritto:
> 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”.[*]

Hi John,

I agree that the statement "this solution does not require any SRH data 
plane change" needs to be clarified, also because there is no formal 
definition of a "data plane", hence it is even more vague the "SRH data 
plane".

My understanding of "SRH data plane" here is the combination of RFC 8754 
AND RFC 8986 (SRv6 Network Programming).

The second sentence in the draft says:
"SRv6 Network Programming [RFC8986] defines a framework to build a 
network program with topological and service segments carried in a 
Segment Routing header (SRH) [RFC8754]."

So I think the context of the draft is SRv6 Network programming... in 
this context the basic idea is that you can add new features (i.e. new 
instructions) in specific nodes and add the "network program" in the 
packet header so that you know in advance which nodes will execute which 
instructions.

In this way you can include in your network a mix of "legacy" RFC 8754 
nodes (that do not need to implement the new features) and nodes that 
support the new features (e.g. the CSID flavours).

I think this gives a reasonable interpretaion of "does not require any 
SRH data plane change"... though I agree it could be better explained

ciao
Stefano

> <https://en.wikipedia.org/wiki/Duck_test>
> 
>> 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.
>>
>>     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.
>>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Oct 2021 19:57:01 -0400

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=
[email-masked]> 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.
>
> 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
>
> On Oct 13, 2021, at 6:57 PM, Robert Raszuk <[email-masked]> wrote:
>
>
> Hi John,
>
> 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
>> 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
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Oct 2021 18:22:43 -0700

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Oct 2021 21:35:51 -0400

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

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: John Scudder <[email-masked]>
Date: Thu, 14 Oct 2021 14:54:29 +0000

Hi Stefano,

We agree on the overarching point, which is that the statement isn’t clear as written.

I take your point about reading it in the context of SRv6 Network Programming, and I would absolutely agree that it’s right to talk about “the Network Programming paradigm”, but right now I don’t see this paradigm as defining “a data plane” in a useful sense. I won’t go into greater detail on this right now since it may represent a serious tangent and might not end up being relevant depending on how the authors (and WG if the document is adopted) decide to address the concern.

Thanks for your helpful reply,

—John

On Oct 13, 2021, at 7:53 PM, Stefano Salsano <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

ciao
Stefano

---

From: John Scudder <[email-masked]>
Date: Tue, 26 Oct 2021 17:55:30 +0000

(For clarity: I’m not wearing any hats other than “WG contributor”.)

Hi All,

Since there hasn’t been any definitive answer from the authors, nor any update to the draft to address the issue, and given that the disputed statement seems to be an important premise for evaluation of the fitness of the draft for adoption (at least, the authors considered it fundamental enough to put in the abstract): I’m opposed to adoption of the draft until this question has been settled, or at least meaningfully addressed.

Regards,

—John

P.S.: I will also follow up to the main adoption thread to assist with issue tracking.

> On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=[email-masked]> wrote:
> 
> 
> Hi Folks,
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Oct 2021 21:41:14 +0200

Hello John,

May I inquire what was not definitive as part of my answer ?

Please observe that below documents which are product of this WG go in
depth to evaluate compression against the requirement not to change SRv6
data plane:

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression
-requirement

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression
-analysis

Would your enquiry be satisfied if the draft in question s/SRH data
plane/SRv6 data plane/ ?

Kind regards,

Robert

On Tue, Oct 26, 2021 at 7:55 PM John Scudder <[email-masked]> wrote:

> Since there hasn’t been any definitive answer from the authors, nor any
> update to the draft to address the issue, and given that the disputed
> statement seems to be an important premise for evaluation of the fitness of
> the draft for adoption (at least, the authors considered it fundamental
> enough to put in the abstract): I’m opposed to adoption of the draft until
> this question has been settled, or at least meaningfully addressed.
>
> Regards,
>
> —John
>
> > 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

---

From: Ron Bonica <[email-masked]>
Date: Tue, 26 Oct 2021 20:01:32 +0000

Robert,

Which requirement was that?

                                    Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Tuesday, October 26, 2021 3:41 PM
To: John Scudder <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]

Hello John,

Please observe that below documents which are product of this WG go in depth to evaluate compression against the requirement not to change SRv6 data plane:

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrQcnZRJk$>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrft1hBsN$>

Would your enquiry be satisfied if the draft in question s/SRH data plane/SRv6 data plane/ ?

Kind regards,
Robert

On Tue, Oct 26, 2021 at 7:55 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
(For clarity: I'm not wearing any hats other than "WG contributor".)

Hi All,

Since there hasn't been any definitive answer from the authors, nor any update to the draft to address the issue, and given that the disputed statement seems to be an important premise for evaluation of the fitness of the draft for adoption (at least, the authors considered it fundamental enough to put in the abstract): I'm opposed to adoption of the draft until this question has been settled, or at least meaningfully addressed.

Regards,

-John

> On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=[email-masked]<mailto:[email-masked]>> 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.)
>
> 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.
>
> -John
> [email-masked]<mailto:[email-masked]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Oct 2021 22:09:36 +0200

4.  SRv6 Specific Requirements

4.1.  SRv6 Based

*   Description: A solution to compress SRv6 SID Lists SHOULD be based on
 the SRv6 architecture, control plane and data plane. * The compression
   solution MAY be based on a different data plane and control plane,
   provided that it derives sufficient benefit.

It is clearly a requirement. It is not an exclusive requirement, but that
does not make it of any less importance as evaluation criteria. Analysis
draft provides comparison table in section 3.1

But please let's not derail this thread as I provided a specific question
to John.

Many thx,
R.

On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica <[email-masked]> wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, October 26, 2021 3:41 PM
> *To:* John Scudder <[email-masked]>
> *Cc:* [email-masked];
> [email-masked]
> *Subject:* Re: [spring] "This solution does not require any SRH data
> plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hello John,
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrQcnZRJk$>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrft1hBsN$>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Tue, 26 Oct 2021 20:55:47 +0000

Robert,

Please read the Metric for this requirement:

  *   Metric: The utilization metric (U) records whether a proposal utilizes the SRv6 specifications.
  *
A proposal can use 8404, 8986, etc and still change the SRv6 data plane.

                                                             Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Tuesday, October 26, 2021 4:10 PM
To: Ron Bonica <[email-masked]>
Cc: John Scudder <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

4.1.  SRv6 Based

   Description: A solution to compress SRv6 SID Lists SHOULD be based on
   the SRv6 architecture, control plane and data plane.  The compression
   solution MAY be based on a different data plane and control plane,
   provided that it derives sufficient benefit.

It is clearly a requirement. It is not an exclusive requirement, but that does not make it of any less importance as evaluation criteria. Analysis draft provides comparison table in section 3.1

But please let's not derail this thread as I provided a specific question to John.

On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Many thx,
R.
Robert,

                                    Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Tuesday, October 26, 2021 3:41 PM
To: John Scudder <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

Hello John,

Kind regards,
Robert

Hi All,

Regards,

-John

---

From: John Scudder <[email-masked]>
Date: Tue, 26 Oct 2021 21:21:48 +0000

Hi Robert,

> On Oct 26, 2021, at 3:41 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Hello John,
> 

I answered that in my response to your earlier message: https://mailarchive.ietf.org/arch/msg/spring/dtKC6Um6USs0Jf7-LssRVsZzwTw/

> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement

This one says (§4.1)

“Based on” is different from “does not change”. I don’t see any documentation or claim of the latter.

> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis

Similarly (§3.1)

   A solution to compress SRv6 SID Lists SHOULD be based on the SRv6
   architecture, control plane and data plane.  The compression solution
   MAY be based on a different data plane and control plane, provided
   that it derives sufficient benefit.
…
   Conclusion: CSID is SRv6 based, requiring no updates to existing SRv6
   standards, VSID and UIDSR require updates.  CRH is not strictly based
   on SRv6 but is able to provide equivalent functionality.

That does make the stronger claim “no updates to existing SRv6 standards”. It’s still the case that this is not the same as saying it doesn’t change the data plane, however, for the reasons I gave previously.

> Would your enquiry be satisfied if the draft in question s/SRH data plane/SRv6 data plane/ ? 

Using the more commonly-used term would be a good start. I think if the only change were that, though, it would still be problematic, for example the revised abstract would say “This solution does not require any SRv6 data plane change”. AFAICT, that still fails the test I proposed in my initial note.

Regards,

—John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Oct 2021 23:30:10 +0200

Hi John,

Many thx for your detailed clarification.

> CRH is not strictly based on SRv6 but is able to provide equivalent
functionality.

Now it is pretty obvious that all of those endless discussions are about
C-SID vs CRH.

It does sound like LDP vs CR-LDP many years ago :)

However the topic is IMO orthogonal
to draft-filsfilscheng-spring-srv6-srh-compression and the discussion
should return on the correct tracks of either revisiting single vs many
data plane solutions or question the results from design team analysis
draft.

Many thx,
R.

On Tue, Oct 26, 2021 at 11:21 PM John Scudder <[email-masked]> wrote:

> I answered that in my response to your earlier message:
> https://mailarchive.ietf.org/arch/msg/spring/dtKC6Um6USs0Jf7-LssRVsZzwTw/
>
> That does make the stronger claim “no updates to existing SRv6 standards”.
> It’s still the case that this is not the same as saying it doesn’t change
> the data plane, however, for the reasons I gave previously.
>
> Using the more commonly-used term would be a good start. I think if the
> only change were that, though, it would still be problematic, for example
> the revised abstract would say “This solution does not require any SRv6
> data plane change”. AFAICT, that still fails the test I proposed in my
> initial note.
>
> Regards,
>
> —John
>
> >
> >
> >
> > Kind regards,
> >
> > Robert
> >
> >
> >
> >
> >
> >
> > > 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.)
> > >
> 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.
> > >

---

From: John Scudder <[email-masked]>
Date: Tue, 26 Oct 2021 21:52:13 +0000

Hi Robert,

> On Oct 26, 2021, at 5:30 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi John,
> 

You are welcome.

> > CRH is not strictly based on SRv6 but is able to provide equivalent functionality.
> 
> Now it is pretty obvious that all of those endless discussions are about C-SID vs CRH. 

I wouldn’t say the topic I raised was “endless” [*], and it has nothing whatsoever to do with CRH, it relates solely to the document in question. If you have some specific reason to say otherwise, that involves things I wrote [**], please do share.

> However the topic is IMO orthogonal to draft-filsfilscheng-spring-srv6-srh-compression and the discussion should return on the correct tracks of either revisiting single vs many data plane solutions or question the results from design team analysis draft. 

I’m not making any attempt to derail such discussions; however, it’s still the case that the topic I raised hasn’t been closed and I would equally appreciate it if you’d refrain from trying to derail this line of discussion with distractions like bringing up CRH.

Regards,

—John

[*] I count fifteen messages not including this one.
[**] Obviously, beyond the fact that I quoted a paragraph from a document you cited, that included the letters C, R, and H.