Re: [spring] How CRH support SFC/Segment Endpoint option?

We did construct (and describe in an I-D) a version of the PSSI that 
carried multiple instructions, with marking as to which SL values 
applied to which instructions.  Tom Herbert constructed a different 
workable encoding for this functionality.  No one seemed interested.

So rather than worry about perfect equivalence with other things, we 
worried about getting what we needed to have for what was being requested.

Yours,
Joel

On 5/24/2020 7:48 PM, James Guichard wrote:
> It seems to me that RFC8200 could not be clearer when it states that 
> there is an order to how extension headers are processed (see [1]) and 
> if a DOH precedes a routing header then **every** node in the routing 
> header must process the DOH; which leads me to wonder how a service 
> chain could be supported unless only a single service is needed in a 
> chain and that service be placed as the last node in the routing header 
> so that a DOH could be added **after** the routing header and therefore 
> only be processed by the last node.
> 
> [1] RFC8200 section 4.1
> 
>        note 1: for options to be processed by the first destination that
> 
>                appears in the IPv6 Destination Address field plus
> 
>                subsequent destinations listed in the Routing header.
> 
>        note 3: for options to be processed only by the final destination
> 
>                of the packet.
> 
> ** note 1 is for DOH preceding routing header and note 3 is for DOH 
> after routing header.
> 
> Jim
> 
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* Sunday, May 24, 2020 5:03 PM
> *To:* Brian E Carpenter <brian.e.carpenter@gmail.com>
> *Cc:* Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; 
> spring@ietf.org; 6man <6man@ietf.org>
> *Subject:* Re: [spring] How CRH support SFC/Segment Endpoint option?
> 
> Hi Brian,
> 
> No playing with words intended at all.
> 
> But as you very well know half of the room read RFC8200 verbatim to what 
> the definition of destination node is. Clearly segment endpoint address 
> would be the "local" destination of the packet when it receives it.
> 
> It seems very clear that RFC8200 authors did not expect that packet may 
> have more then one destination in a domain :)  That seems to be a crux.
> 
> *Let's please do not restart that topic.* I asked this question as I am 
> curious for RbR - how to prevent midpoints to examine DOH if someone 
> would choose to carry VPN demux label there.
> 
> What is there in the packet when packet is received by a segment 
> endpoint (transit point) to tell - STOP ... this is not a packet for you 
> - skip DOH - but go and examine other RHs ?
> 
> Thank you,
> 
> R,
> 
> On Sun, May 24, 2020 at 10:54 PM Brian E Carpenter 
> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 
>     Hi Robert,
> 
>     On 24-May-20 22:22, Robert Raszuk wrote:
>      > Hi Ron,
>      >
>      > I have one small question on the Destination Option Header you
>     keep referencing to carry for example VPN demux instructions.
>      >
>      > As DOH follows Fragment Header it is indeed inspected before CRH.
>      >
>      > So please kindly clarify what is there in the IPv6 packet header
>     which would stop each segment endpoint (during the transit over SR
>     anchors)  which destination is obviously in DA of the arriving
>     packet not to inspect DOH and not trying to execute it ?
>      >
>      > If you could please also provide reference to RFC8200 defining it..
> 
>     I think you are playing with words a bit here. 8200 says:
>     "The Destination Options header is used to carry optional information
>     that need be examined only by a packet's destination node(s)."
> 
>     That clearly means that other nodes *do not need* to examine the
>     DOH, so they can simply skip over it. Because it isn't encrypted, of
>     course they physically can examine it if they want to waste CPU
>     cycles, but they *do not need* to do so. Since they are not the
>     destination node, obviously the information in the DOH is not
>     intended for them. If it isn't obvious that they are not intended to
>     act on that information, I don't know why we bother to write RFCs at
>     all.
> 
>     Regards
>          Brian
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 