Subject: uSID and destination options

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Nov 2021 19:11:51 +0000

C-SID authors,

Consider an SRv6 packet that contains:

  *   An outer IPv6 header
  *   A Destination Options Header
  *   IPv4 payload

The packet does not contain an SRH. However, the Destination Address field  in the outer IPv6 header contains a C-SID container and the C-SID container contains two or more C-SIDs.

Where are the destination options processed? The following are possible answers to this question:

  *   At every segment endpoint node
  *   At the SR path egress node

                                                     Ron

Juniper Business Use Only

---

From: Andrew Alston <[email-masked]>
Date: Tue, 16 Nov 2021 06:58:18 +0000

I am curious about this as well - since the drafts are silent on it, and this does have a material impact on destination option processing, which if not clarified could lead to some interesting inter-op issues.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: Monday, November 15, 2021 10:12 PM
To: [email-masked]; [email-masked]
Subject: [spring] uSID and destination options

C-SID authors,

  *   An outer IPv6 header

                                                     Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 16 Nov 2021 13:31:20 +0000

Hi Ron, my read of section 4.1.1 of the draft is the dest opt in your example packet would be processed at every segment endpoint.

Darren
________________________________
From: spring <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Monday, November 15, 2021 2:12 PM
To: [email-masked]; [email-masked]
Subject: [spring] uSID and destination options

C-SID authors,

  *   An outer IPv6 header

                                                     Ron

---

From: Sander Steffann <[email-masked]>
Date: Tue, 16 Nov 2021 15:24:46 +0100

Hi,

> Hi Ron, my read of section 4.1.1 of the draft is the dest opt in your example packet would be processed at every segment endpoint.

That seems very counter-intuitive…
Sander

---

From: Ron Bonica <[email-masked]>
Date: Tue, 16 Nov 2021 18:14:03 +0000

Hi Darren,

That's my reading, too. But this leads us to additional questions:

  *   How do we encode destination options that need to be processed at the SR Path egress node only?
  *   How do we encode the Fragment Option?
  *   How do we encode the ESP option?
In these cases, do we need an SRH to indicate that the extension headers that follow it are to be processed by the SR path egress node only? Would that SRH carry any routing information at all?

                                                                                        Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Tuesday, November 16, 2021 8:31 AM
To: Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: uSID and destination options

[External Email. Be cautious of content]

Darren
________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: Monday, November 15, 2021 2:12 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [spring] uSID and destination options

C-SID authors,

  *   An outer IPv6 header

                                                     Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 17 Nov 2021 20:27:08 +0000

Hi Ron, I’m glad we read that the same.

As usual for SRv6, the SR source needs to decide how to build the IPv6 extension header chain. With current text, when extension headers are required to be processed at the ultimate segment, the SR source would need to add an SRH.

Would you agree?

The pseudocode could be modified such that the SR source adds an SRH only when it wants a dest-opt header to be processed at each segment endpoint. Section 4.1.1 would state the pseudocode is invoked when processing any header type other than HBH or dest-opt (vs just upper layer header).

Darren

On 2021-11-16, 1:14 PM, "Ron Bonica" <rbonica=[email-masked]> wrote:

Hi Darren,

That’s my reading, too. But this leads us to additional questions:

-         How do we encode destination options that need to be processed at the SR Path egress node only?

-         How do we encode the Fragment Option?

-         How do we encode the ESP option?
In these cases, do we need an SRH to indicate that the extension headers that follow it are to be processed by the SR path egress node only? Would that SRH carry any routing information at all?

                                                                                        Ron

Darren

C-SID authors,

·         An outer IPv6 header

·         A Destination Options Header

·         IPv4 payload

·         At every segment endpoint node

·         At the SR path egress node

                                                     Ron

---

From: Ron Bonica <[email-masked]>
Date: Wed, 17 Nov 2021 20:58:26 +0000

Darren,

Yes, the SR ingress node would need to add an SRH whenever the packet includes an extension header that needs to be processed at the packet's ultimate destination only.

This would be an odd routing header as it would include no routing information whatsoever.

You might want to document this along with the other case in which you need an SRH that contains no routing information. This is the case where:

  *   The entire SR Path is represented in the IPv6 Destination Address by a single C-SID container
  *   The SRH does not contain any SIDs
  *   The SRH is required to carry the flag, tag and TLV fields

                                                    Ron

Sent: Wednesday, November 17, 2021 3:27 PM

Hi Ron, I'm glad we read that the same.

Would you agree?

Darren

On 2021-11-16, 1:14 PM, "Ron Bonica" <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Hi Darren,

                                                                                        Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Sent: Tuesday, November 16, 2021 8:31 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: uSID and destination options

Darren

C-SID authors,

*         An outer IPv6 header

*         IPv4 payload

                                                     Ron