Subject: [spring] CSID Question

From: Ron Bonica <[email-masked]>
Date: Fri, 1 Oct 2021 19:33:17 +0000

CSID Authors,

Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7 are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.

Please provide an example that shows us:

  *   What the SRH looks like as it arrives at the first segment endpoint
  *   What the IPv6 Destination Address looks like at each segment endpoint, including information required to parse the Destination Address

                                                                                                                   Ron

Juniper Business Use Only

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 1 Oct 2021 22:31:37 +0200

Hi Ron,

Have you read this draft ?

Quote from it:

   It is recommended for ease of operation that a single compressed
   encoding flavor be used in a given SRv6 domain.  However, in a multi-
   domain deployment, different flavors can be used in different
   domains.

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> CSID Authors,
>
>
>
> Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5,
> and 7 are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6
> are END SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.
>
>
>
>    - What the SRH looks like as it arrives at the first segment endpoint
>    - What the IPv6 Destination Address looks like at each segment
>    endpoint, including information required to parse the Destination Address
>
>
>
>
>                                                                        Ron
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 1 Oct 2021 20:58:34 +0000

Robert,

I do remember that quote. And that is exactly why I ask the question!

If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain:

  *   Can we say that they are a single behavior ?
  *   Can we justify both because each is optimized for a different kind of network?
  *   Can we justify another behavior either because it is optimized for yet another type of network or because it does relatively well in all network types?

However, if this is just an “ease of operation” thing, as stated in the draft, the authors are obliged to answer my question.

                                                                                                 Ron

P.S. Rest assured that I have read the draft. However, your concern is greatly appreciated 😉

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] CSID Question

[External Email. Be cautious of content]

Hi Ron,

Quote from it:

   domains.

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
CSID Authors,

                                                                                                                   Ron

Juniper Business Use Only
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UL_LsTEWuybtewcIHX2FwrqtwS3G97ki3tzHT8pGyGcx2hPWYZfriSmeG75uwP7l$>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 1 Oct 2021 23:08:28 +0200

Hi Ron,

   - Can we say that they are a single behavior ?

No. And neither RFC8986 defines a single behavior or single flavor. Yet the
bounds are clearly set what is the SRv6 data plane.

For some strange reason I am observing here an attempt to squeeze different
data plane into the room which is not compliant to [RFC8402], [RFC8754] and
[RFC8986]. Do you think anyone will be so naive to accept it ?

Now I am going to rest assured and enjoy the rest of this show.

Best,
Robert

On Fri, Oct 1, 2021 at 10:58 PM Ron Bonica <[email-masked]> wrote:

>    - Can we say that they are a single behavior ?
>    - Can we justify both because each is optimized for a different kind
>    of network?
>    - Can we justify another behavior either because it is optimized for
>    yet another type of network or because it does relatively well in all
>    network types?
>
>
>
> However, if this is just an “ease of operation” thing, as stated in the
> draft, the authors are obliged to answer my question.
>
>
>
>
>                                        Ron
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, October 1, 2021 4:32 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> *Subject:* Re: [spring] CSID Question
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Ron,
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UL_LsTEWuybtewcIHX2FwrqtwS3G97ki3tzHT8pGyGcx2hPWYZfriSmeG75uwP7l$>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 2 Oct 2021 13:39:14 +0000

Folks,

Now that Robert and I have provided some entertainment, could someone answer the technical question that initiated this thread?

Does the document recommend against using Next-C-SId and Replace-C-Sid in the same domain  for ease of operation or because they don’t work well together? If the former, please provide the example described below.

              Ron

Sent from my iPhone

On Oct 1, 2021, at 5:07 PM, Robert Raszuk <[email-masked]> wrote:

Hi Ron,

No. And neither RFC8986 defines a single behavior or single flavor. Yet the bounds are clearly set what is the SRv6 data plane.

For some strange reason I am observing here an attempt to squeeze different data plane into the room which is not compliant to [RFC8402], [RFC8754] and [RFC8986]. Do you think anyone will be so naive to accept it ?

Best,
Robert

On Fri, Oct 1, 2021 at 10:58 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                                                 Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] CSID Question

Hi Ron,

Quote from it:

   domains.

                                                                                                                   Ron

---

From: <[email-masked]>
Date: Sun, 3 Oct 2021 09:03:02 +0800 (CST)

Hi Ron,

You raised an interesting question, but I think it might be already discussed in the DT. In my understanding, this question is just more related the usecases and requirements but the solutions. In a SRv6 domain, the header compression effection depends on the SID informaion redundencies due to the reasonable SID planning with the SRv6 compatible solution. I think it's meanless to compress the SRv6 header in the case of random SID format. Besides other solution without engouth SRv6 compatible such as Unified SID could be used to resolve the usecase you mentioned. I believe that had been discussed and compared within the DT and the one solution compatible with SRv6 is preferred, that is the CSID draft.

Best Regards,

Aihua

原始邮件

发件人：RonBonica
收件人：Robert Raszuk;
抄送人：SPRING WG;
日 期 ：2021年10月02日 21:39
主 题 ：Re: [spring] CSID Question

 Folks,

               Ron

 
Sent from my iPhone

Hi Ron,

 Can we say that they are a single behavior ?

 Best,
Robert

Robert,

 

 

Can we say that they are a single behavior ?

Can we justify both because each is optimized for a different kind of network?

Can we justify another behavior either because it is optimized for yet another type of network or because it does relatively well in all network types?

 

                                                                                                 Ron

 

 

 

 

Hi Ron,

 

Quote from it: 

   It is recommended for ease of operation that a single compressed    encoding flavor be used in a given SRv6 domain.  However, in a multi-    domain deployment, different flavors can be used in different    domains. 

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica <rbonica=[email-masked]> wrote:

CSID Authors,

 

 

What the SRH looks like as it arrives at the first segment endpoint

What the IPv6 Destination Address looks like at each segment endpoint, including information required to parse the Destination Address

                                                                                                                   Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 4 Oct 2021 15:17:50 +0000

Aihua,

I don’t recall this being discussed in the design team, but my memory may be failing me. The design team kept meticulous minutes ( https://mailarchive.ietf.org/arch/browse/srcomp/ ) and it would be very helpful of you could point me the meeting where this was discussed.

I agree that it would be difficult to find a use-case where both G-SID and uSID are both required. However, I ask the question for the following reasons:

  *   To determine whether G-SID and uSID are different behaviors. If they don’t work well together in a single domain, it would be difficult to argue that they are a single behavior
  *   To determine whether they are both needed.
  *   To determine whether the C-SID encapsulation overhead reduction statistics reported in the analysis document reflect uSID only, G-SID only, or a combination of both

                                                                                         Ron

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Saturday, October 2, 2021 9:03 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re:[spring] CSID Question

Hi Ron,

Best Regards,

Aihua

原始邮件
发件人：RonBonica
收件人：Robert Raszuk;
抄送人：SPRING WG;
日 期 ：2021年10月02日 21:39

Folks,

              Ron

Sent from my iPhone

On Oct 1, 2021, at 5:07 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ron,

Best,
Robert

                                                                                                 Ron

Hi Ron,

Quote from it:

   domains.

                                                                                                                   Ron

---

From: <[email-masked]>
Date: Tue, 5 Oct 2021 19:26:34 +0800 (CST)

Hi Ron，

For your questions, from my point of view, might be a little deviation with purpose of the C-SID solution. As I understand, the SRv6 header compression depends on the redundencies of SID information, and the C-SID solution provides 2 flavors for compression, how to use them also depending on the SRv6 self, such as SID format, just like others flavors of SRv6 programming.

But I agree the WG might find out a better one based on the C-SID draft, I think it is a good start to adopt the C-SID draft.

Best regards,

Aihua

原始邮件

发件人：RonBonica
收件人：刘爱华10024999;
抄送人：[email-masked];[email-masked];
日 期 ：2021年10月04日 23:18
主 题 ：RE: Re:[spring] CSID Question

Aihua,

 

 

To determine whether G-SID and uSID are different behaviors. If they don’t work well together in a single domain, it would be difficult to argue that they are a single behavior

To determine whether they are both needed.

To determine whether the C-SID encapsulation overhead reduction statistics reported in the analysis document reflect uSID only, G-SID only, or a combination of both

                                                                                         Ron

 

 

 

Hi Ron,

Best Regards,

Aihua

原始邮件

发件人：RonBonica

收件人：Robert Raszuk;

抄送人：SPRING WG;

日 期 ：2021年10月02日 21:39

 
 Folks,

 

 

              Ron

                               

Sent from my iPhone

 

 

Hi Ron,

 

 

 

 

Best,

Robert

 

Robert,

 

 

 

 

                                                                                                 Ron

 

 

 

 

Hi Ron,

 

Quote from it: 

 

CSID Authors,

 

 

 

                                                                                                                   Ron