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

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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
>
>