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
Juniper Business Use Only
From: Darren Dukes (ddukes) <[email protected]>
Sent: Wednesday, November 17, 2021 3:27 PM
To: Ron Bonica <[email protected]>; [email protected]; [email protected]
Subject: Re: uSID and destination options
[External Email. Be cautious of content]
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"
<[email protected]<mailto:[email protected]>>
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
Juniper Business Use Only
From: Darren Dukes (ddukes)
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 16, 2021 8:31 AM
To: Ron Bonica <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: uSID and destination options
[External Email. Be cautious of content]
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 protected]<mailto:[email protected]>> on
behalf of Ron Bonica
<[email protected]<mailto:[email protected]>>
Sent: Monday, November 15, 2021 2:12 PM
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: [spring] uSID and destination options
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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
