that is only a problem if one needs different options aimed at different
service functions. Even NSH does not actually do that.
So define a destination option to carry service parameters. Put it in a
destination option before the CRH. then every addressed entity examines
it. It is marked as "ignore if irrelevant". So only the things that
are SFs pay any attention.
Personally, I would rather use NSH. CRH clearly can provide the same
functionality with a destination option if desired.
Yours,
Joel
On 5/24/2020 7:58 PM, James Guichard wrote:
Hi Joel,
I have a vague recollection of that and will do some digging. However, it seems
fair to say that CRH in its current form can only support complex service
chaining by utilizing NSH unlike SRv6 that has the capability to encode as many
services as you want in the SRH, or if you prefer integrate with NSH.
Jim
-----Original Message-----
From: Joel M. Halpern <j...@joelhalpern.com>
Sent: Sunday, May 24, 2020 7:53 PM
To: James Guichard <james.n.guich...@futurewei.com>
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: 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-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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Cjames.n.guic
hard%40futurewei.com%7C45543ce3c6e348e781e308d8003da5ff%7C0fee8ff2a3b2
40189c753a1d5591fedc%7C1%7C0%7C637259612082424038&sdata=pPaP%2Byla
xoDhRW%2BnseevQ0%2FCcVDkm0x6XukULxCtQDI%3D&reserved=0
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
