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-boun...@ietf.org> *On Behalf Of *Robert Raszuk
*Sent:* Sunday, May 24, 2020 5:03 PM
*To:* Brian E Carpenter <brian.e.carpen...@gmail.com>
*Cc:* Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>;
spring@ietf.org; 6man <6...@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.carpen...@gmail.com <mailto:brian.e.carpen...@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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
