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=40cisco....@dmarc.ietf.org>
Sent: Tuesday, November 16, 2021 8:31 AM
To: Ron Bonica <rbon...@juniper.net>; spring@ietf.org; 6...@ietf.org
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 <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on
behalf of Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>>
Sent: Monday, November 15, 2021 2:12 PM
To: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
