Subject: How CRH support SFC/Segment Endpoint option?

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 22 May 2020 06:56:11 +0000

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this PSSI? At the beginning of the SRm6 design, this is described in [2]. But you deleted the containers [2].

Without that, I don't really understand how SFC can be supported.

Best,
Cheng

[1]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1
[2]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 May 2020 14:16:38 +0000

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified path to its destination. It shouldn't attempt to do any more than that.

The CRH does not attempt to deliver service function information to service function instances. However, it is compatible with:

  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service function instances.

                                                                                                                     Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <[email-masked]>; [email-masked]; Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

Best,
Cheng

[1]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 22 May 2020 16:23:39 +0200

Hi,

> The sole purpose of a Routing header is to steer a packet along a specified path to its destination. It shouldn’t attempt to do any more than that.
> 
> 	• The Network Service Header (NSH)
> 	• The Destination Options header that precedes the Routing header
> 

Clear separation of concerns in a SPRING architecture! I was afraid the hope for a clear architecture was lost, but this makes me so happy :)

Cheers,
Sander

And to be 100% clear: I'm not being sarcastic… The messy "architectures" I have seen in the past have driven me to despair. This work is finally something that makes sense.

---

From: James Guichard <[email-masked]>
Date: Fri, 22 May 2020 14:40:13 +0000

Hi Sander,

This separation of architecture is not new; see https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/ in the SPRING WG.

Jim

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Sander Steffann
Sent: Friday, May 22, 2020 10:24 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; [email-masked]; Chengli (Cheng Li) <[email-masked]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi,

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Fri, 22 May 2020 16:42:13 +0200

Hi James,

> This separation of architecture is not new; see https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/ in the SPRING WG.

My apologies, I didn't mean to imply that all SPRING drafts did not specify a good architecture. The ones that don't have gotten me frustrated, and that frustration came out.

Cheers,
Sander

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 22 May 2020 15:11:43 +0000

Hi Ron,

If using DOH, then we would have DOH (VPN) + DOH (SFC) + RH per packet in some circumstances, right? What if more (ever-emerging) services are required? Not sure about the forwarding efficiency.

Best regards,
Shuping

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

-        The Network Service Header (NSH)
-        The Destination Options header that precedes the Routing header

                                                                                                                     Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: How CRH support SFC/Segment Endpoint option?

Hi Ron,

Best,
Cheng

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2020 11:31:56 -0400

If you want to support IETF SFC, use the IETF Proposed Standard, NSH.

Yours,
Joel

On 5/22/2020 2:56 AM, Chengli (Cheng Li) wrote:
> For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC 
> related SID, how to indicate that? By PSSI? [1]
> 
> But how to know which segment endpoint node/egress node should process 
> this PSSI? At the beginning of the SRm6 design, this is described in 
> [2]. But you deleted the containers [2].
> 
> Without that, I don’t really understand how SFC can be supported.
> 
> Best,
> 
> Cheng
> 
> [1]. 
> https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1
> 
> [2]. 
> https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2020 12:15:59 -0400

SFC NSH is not a DOH.  SFC is a next-header.  And the preferred way to 
carry the VPN information for SFC is to use an SFC metadatum, since that 
is already supported.  The VPN destination option is for the non-SFC case.

Yours,
Joel

On 5/22/2020 11:11 AM, Pengshuping (Peng Shuping) wrote:
> Hi Ron,
> 
> If using DOH, then we would have DOH (VPN) + DOH (SFC) + RH per packet 
> in some circumstances, right? What if more (ever-emerging) services are 
> required? Not sure about the forwarding efficiency.
> 
> Best regards,
> 
> Shuping
> 
> *From:*ipv6 [mailto:[email-masked]] *On Behalf Of *Ron Bonica
> *Sent:* Friday, May 22, 2020 10:17 PM
> *To:* Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; 
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: How CRH support SFC/Segment Endpoint option?
> 
> Cheng,
> 
> The sole purpose of a Routing header is to steer a packet along a 
> specified path to its destination. It shouldn’t attempt to do any more 
> than that.
> 
> The CRH does not attempt to deliver service function information to 
> service function instances. However, it is compatible with:
> 
> -The Network Service Header (NSH)
> 
> -The Destination Options header that precedes the Routing header
> 
> *From:*Chengli (Cheng Li) <[email-masked] <mailto:[email-masked]>>
> *Sent:* Friday, May 22, 2020 2:56 AM
> *To:* 6man <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Ron Bonica <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* How CRH support SFC/Segment Endpoint option?
> 
> *[External Email. Be cautious of content]*
> 
> Hi Ron,
> 
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
> 
> [2]. 
> https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt 
> <https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.
> 
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 May 2020 17:32:33 +0000

Shuping,

The CRH can appear in a packet along with any valid combination of extension headers.

                                                             Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Pengshuping (Peng Shuping)
Sent: Friday, May 22, 2020 11:12 AM
To: Ron Bonica <rbonica=[email-masked]>; Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: How CRH support SFC/Segment Endpoint option?

Hi Ron,

Best regards,
Shuping

To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sat, 23 May 2020 16:59:03 +0000

Hi Ron,

Thanks for your reply.

Regarding NSH, are you saying to use CRH as a tunnel transport encapsulation between two SFF nodes?
Or we can use a single CRH for steering packet through all the SFF nodes that the NSH packet should visit?

Regarding using the first DOH, how to do that without the container design by your draft[1]?
Or the same option TLV will bind to different behaviors on different nodes according to the node local configuration?

Best,
Cheng

[1]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.

From: Ron Bonica [mailto:[email-masked]]
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 23 May 2020 13:10:25 -0400

there are a number of Internet Drafts describing a range of ways of 
using SFC NSH with MPLS.  The same choices appear to be available with 
CRH.  If folks are interested, once CRH progresses, it should be a 
simple task to document that.

Yours,
Joel

On 5/23/2020 12:59 PM, Chengli (Cheng Li) wrote:
> Or the same option TLV will bind to different behaviors on different 
> nodes according to the node local configuration?
> 
> Best,
> 
> Cheng
> 
> [1]. 
> *From:*Ron Bonica [mailto:[email-masked]]

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sat, 23 May 2020 17:27:29 +0000

Hi Joel,

Sure, you are right, we can use CRH and NSH, but personally, I don't think this is a good idea. 

CRH introduce the mapping table to the nodes, and NSH introduce per-SFC/flow mapping state again, it is not we want in source routing. 
We want to maintain the states on the edge nodes only instead of all the nodes. Not intent to say bad words to NSH, it is a good solution, but we just like sourcing routing more, because of the simplicity. 
Using CRH and NSH is too complicated. Why not use SRv6 for SFC?[1], a single SRH can solve the problem. Less states on nodes, even less overhead, and simpler processing for sure.

But my point is not about NSH, my point is about the second option proposed by Ron, how to use the first DOH to support SFC?

or how to support to trigger the specific (service/function) behavior on a specific node?

For example, I need to expose the packet to a firewall policy at node 3 ( 5 nodes for this path, 1,2,3,4,5), so I put a PSSI :expose a packet to a firewall policy into the first DOH.
According to RFC8200, all the segment endpoint nodes 1,2,3,4,5 will expose the packet to a firewall policy, correct?

Thanks,
Cheng

[1]. https://tools.ietf.org/html/draft-ietf-spring-sr-service-programming-02
[2]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1

======================
4.1.  PSSI

   The PSSI, if present, is executed on the segment egress node.
   Because the path egress node is also a segment egress node, it can
   execute a PSSI.

   The following are examples of PSSIs:

   o  Expose a packet to a firewall policy.

   o  Expose a packet to a sampling policy.

===============

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Sunday, May 24, 2020 1:10 AM
To: Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked]
Subject: Re: How CRH support SFC/Segment Endpoint option?

there are a number of Internet Drafts describing a range of ways of using SFC NSH with MPLS.  The same choices appear to be available with CRH.  If folks are interested, once CRH progresses, it should be a simple task to document that.

Yours,
Joel

On 5/23/2020 12:59 PM, Chengli (Cheng Li) wrote:
> specified path to its destination. It shouldn't attempt to do any more 
> than that.
> 
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-s
> pring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH
> 1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
> 
> [2].

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 23 May 2020 18:40:09 +0100

> Sure, you are right, we can use CRH and NSH, but personally, I don't think this is a good idea.

As an operator, I agree - this sounds like a foolish thing to do.

Fortunately, both CRH and NSH processing are disabled by default.  I.e. 
this is only an issue if the operator has explicitly enabled it.

It's also not a bug that if you aim a gun at your feet and pull the 
trigger, that injury will occur.

Nick

---

From: Ron Bonica <[email-masked]>
Date: Sun, 24 May 2020 01:24:34 +0000

Cheng,

The CRH is a building block. It has exactly one function. That is, to steer a packet along its delivery path.

The CRH does not attempt to deliver parameters or metadata to service function instances. It relies on other mechanisms. One possibility is a destination options header that precedes the CRH. I am sure that there are other mechanisms. CRH should be compatible with all of them.

Personally, I am not an NSH expert. Maybe someone who is can speak up.

                                                                                              Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Saturday, May 23, 2020 12:59 PM
To: Ron Bonica <[email-masked]>; 6man <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: How CRH support SFC/Segment Endpoint option?

Hi Ron,

Thanks for your reply.

Best,
Cheng

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sun, 24 May 2020 05:01:15 +0000

Hi Ron,

Thanks for your reply.

I finally get that CRH only support steering packet along a path.

But I am still curious that how to support a specific function/behavior at the specific node by using CRH. Can you please explain that?

Since this is a very basic function we want in the network. SFC needs that, all the services needs that if there is any function/service should be performed at the middle nodes along the path.

We want to provide an integrated service for our customers, because our customers want a integrated solution for providing service, like SFC, VPN, they don’t like us to provide a brick that still need to combine with other many bricks.

IMHO, when comparing solutions, we should compare the same functionality. So could you please provide more info of how CRH supporting services?  It will help people to evaluate the CRH, which can help CRH I think.

Thanks,
Cheng

________________________________

李呈 Cheng Li
Mobile: +86-15116983550<tel:+86-15116983550>
Email: [email-masked]<mailto:[email-masked]>

From: Ron Bonica<[email-masked]<mailto:[email-masked]>>
To: Chengli (Cheng Li)<[email-masked]<mailto:[email-masked]>>;6man<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>
Cc: spring<[email-masked]<mailto:[email-masked]>>
Subject: RE: How CRH support SFC/Segment Endpoint option?
Time: 2020-05-24 09:24:55

Cheng,

                                                                                              Ron

Hi Ron,

Thanks for your reply.

Best,
Cheng

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 24 May 2020 12:22:09 +0200

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.

Keep in mind that in number of networks P routers are also PE routers so
executing DOH even if CRH still contains many hops to go may result in very
unexpected behaviours. I am sure you recall that L3VPN labels are locally
significant and there is no mechanism in place to assure uniqueness of VPN
demux values across PEs.

Why is this important here - because CRH by design is decoupled from any
functions or network application handling.

Many thx,
Robert.

On Sun, May 24, 2020 at 3:24 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> The CRH does not attempt to deliver parameters or metadata to service
> function instances. It relies on other mechanisms. One possibility is a
> destination options header that precedes the CRH. I am sure that there are
> other mechanisms. CRH should be compatible with all of them.
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 08:54:05 +1200

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. 
> 
> 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 ? 
> 

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 24 May 2020 23:03:03 +0200

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 <
[email-masked]> wrote:

> 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
>
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 24 May 2020 14:08:55 -0700

> If you could please also provide reference to RFC8200 defining it.
Robert,

Look at Destination Options before the routing header in RFC8200.
These are intended to be processed at every intermediate destination
in the routing header and precede any fragment header.

Tom

> Keep in mind that in number of networks P routers are also PE routers so executing DOH even if CRH still contains many hops to go may result in very unexpected behaviours. I am sure you recall that L3VPN labels are locally significant and there is no mechanism in place to assure uniqueness of VPN demux values across PEs..
>
> Why is this important here - because CRH by design is decoupled from any functions or network application handling.
>
> Many thx,
> Robert.
>
>
> On Sun, May 24, 2020 at 3:24 AM Ron Bonica <rbonica=[email-masked]> wrote:
>>
>> Cheng,
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 24 May 2020 23:33:03 +0200

Hi Tom,

Thank you !

That confirms my understanding ie that DOH will be examined at each segment
endpoint hop if DOH is present.

So just like PSSI or TPF suggest a build in filtering (for example by
target ID) is required to avoid misuse.

Kind regards,
Robert.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 09:50:54 +1200

On 25-May-20 09:08, Tom Herbert wrote:
> in the routing header 

That intention is not specified in the text, and IMHO cannot be deduced from the text. Hence my comment on draft-bonica-6man-ext-hdr-update.

   Brian

> and precede any fragment header.
> 
> Tom
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 May 2020 19:47:54 -0400

There can be a destination options header before the routing header. 
And there can be one after the routing header.  The former is examined 
at every addressed destination.  The later is examined when the routing 
header reaches its final destination.
That is the RFC 8200 defined behavior.

Yours,
Joel

On 5/24/2020 5:33 PM, Robert Raszuk wrote:
> Hi Tom,
> 
> Thank you !
> 
> That confirms my understanding ie that DOH will be examined at each 
> segment endpoint hop if DOH is present.
>

---

From: James Guichard <[email-masked]>
Date: Sun, 24 May 2020 23:48:55 +0000

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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Sunday, May 24, 2020 5:03 PM
To: Brian E Carpenter <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi Brian,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

On 24-May-20 22:22, Robert Raszuk wrote:
> If you could please also provide reference to RFC8200 defining it..

Regards
    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 May 2020 19:53:21 -0400

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
> 
> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Sunday, May 24, 2020 5:03 PM
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* Ron Bonica <rbonica=[email-masked]>; 
> [email-masked]; 6man <[email-masked]>
> *Subject:* Re: [spring] How CRH support SFC/Segment Endpoint option?
> 
> Hi Brian,
> 
> curious for RbR - how to prevent midpoints to examine DOH if someone 
> would choose to carry VPN demux label there.
> 
> 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 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Robert,
> 
>      > I have one small question on the Destination Option Header you
>     keep referencing to carry for example VPN demux instructions.
>      >
>      > 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 ?
>      >
>     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 24 May 2020 16:55:33 -0700

> That intention is not specified in the text, and IMHO cannot be deduced from the text. Hence my comment on draft-bonica-6man-ext-hdr-update.
Brian,

I think it can be deduced. Extension headers need to be processed in
order, so destination options before the routing header must be
processed before the routing header. If the destination options before
the routing were only to be processed at the final destination, then
we would need to process the routing header before processing the
destination options in order to determine if the destination address
is indeed the final destination. More practically, if destination
options were only to be processed at the final destination then it
doesn't seem like there would be any material between destination
options before and those after the routing header (or maybe there was
some other intent to have two flavors of destination options?)..

I agree that the text could be clarified, It seems like another case
of potential ambiguity in RFC8200 among the terms destination,
destination address, final destination, an intermediate destination.
https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00 was
an attempt to calirfy this, at least to clarify the significance of a
modifiable destination option (before the routing header).

Tom

---

From: James Guichard <[email-masked]>
Date: Sun, 24 May 2020 23:58:37 +0000

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 <[email-masked]> 
Sent: Sunday, May 24, 2020 7:53 PM
To: James Guichard <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
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:
> 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
> 
> 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.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Cjames.n.guic
> hard%40futurewei.com%7C45543ce3c6e348e781e308d8003da5ff%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637259612082424038&amp;sdata=pPaP%2Byla
> xoDhRW%2BnseevQ0%2FCcVDkm0x6XukULxCtQDI%3D&amp;reserved=0
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Sun, 24 May 2020 20:03:34 -0400

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 02:31:07 +0000

Cheng,

IPv6 defines many Routing headers. The Routing header is designed to steer packets along a delivery path. Other headers are designed to deliver information to nodes along the delivery path.

The Routing header should not attempt to subsume the function of other IPv6 extension headers.

                                                                         Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Sunday, May 24, 2020 1:01 AM
To: Ron Bonica <[email-masked]>; 6man <[email-masked]>; spring <[email-masked]>
Cc: spring <[email-masked]>
Subject: Reply: RE: How CRH support SFC/Segment Endpoint option?

Hi Ron,

Thanks for your reply.

Thanks,
Cheng

李呈 Cheng Li

Cheng,

                                                                                              Ron

To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Ron,

Thanks for your reply.

Best,
Cheng

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 03:09:18 +0000

Folks,

I think that we are all talking past one another. RFC 8200 recommends specific ordering of extension headers for a reason.

IPv6 extension header are ordered as follows:

- Headers processed at every node along the delivery path
	- Hop-by-hop
- Headers processed at every segment endpoint
	- Destination options
	- Routing header
- Headers processed at the ultimate destination only
	- Fragment header
	- Authentication header
	- ESP header
	- Destination Options header

Note that the Destination Options header is the only extension header that can appear twice in a packet. The Destination Options header must immediately precede the Routing header or the upper-0layer header.

 If a packet contains a destination options header, a routing header, a fragment header, and another destination options header:

- the destination options header that precedes the routing header appears in each fragment
- the destination options header that precedes the routing header Is processed on each segment endpoint, before the packet is reassembled
- the destination options header that precedes the upper layer header appears in the first fragment only
- the destination options header that precedes the upper layer header Is processed on the ultimate destination node, after the packet has been reassembled

                                                                      ROn

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Brian,

I think it can be deduced. Extension headers need to be processed in order, so destination options before the routing header must be processed before the routing header. If the destination options before the routing were only to be processed at the final destination, then we would need to process the routing header before processing the destination options in order to determine if the destination address is indeed the final destination. More practically, if destination options were only to be processed at the final destination then it doesn't seem like there would be any material between destination options before and those after the routing header (or maybe there was some other intent to have two flavors of destination options?)..

I agree that the text could be clarified, It seems like another case of potential ambiguity in RFC8200 among the terms destination, destination address, final destination, an intermediate destination.
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCueDLaELLoTDx-wnEK6$  was an attempt to calirfy this, at least to clarify the significance of a modifiable destination option (before the routing header).

Tom

> >>> Personally, I am not an NSH expert. Maybe someone who is can speak up..
> >>>
> >>>
> >>>
> >>>                                                                                               
> >>> Ron
> >>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list [email-masked] Administrative 
> >> Requests: 
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i
> >> pv6__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCu
> >> eDLaELLoTD0hgsR60$
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > v6__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCueD
> > LaELLoTD0hgsR60$

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 25 May 2020 03:44:25 +0000

Hi Ron,

Thank you to share the facts of RFC8200.

Could you please explain how CRH supports SFC by the first Destination Options header as you mentioned in you previous email?

Or how to support performing a specific behavior at a specify node along the path by using CRH? 

You know, when we add an option in the first DOH, it will be processed by all the nodes listed in the RH. 

Best Regards,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, May 25, 2020 11:09 AM
To: Tom Herbert <[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

Folks,

                                                                      ROn

-----Original Message-----
From: Tom Herbert <[email-masked]>
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Brian,

Tom

> >> -

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 04:28:48 +0000

Cheng,

The CRH doesn't attempt the address SFC. That is beyond the scope or a routing header.

                                                                  Ron

-----Original Message-----
From: Chengli (Cheng Li) <[email-masked]> 
Sent: Sunday, May 24, 2020 11:44 PM
To: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

Hi Ron,

Best Regards,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Monday, May 25, 2020 11:09 AM
To: Tom Herbert <[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

Folks,

                                                                      ROn

-----Original Message-----
From: Tom Herbert <[email-masked]>
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Brian,

Tom

> >>> Personally, I am not an NSH expert. Maybe someone who is can speak up...
> >>>
> >>>
> >>>
> >>>
> >>> Ron
> >>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!XdMQFD54OnmS_ELU3qQMHcVZZnhEpDqi6DlUjZBbErP9_6b9aReoEWXxfz3ztST_$
--------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 25 May 2020 10:56:58 +0200

Hi Ron,

So what in your opinion would happen with the below if there is no Routing
Header at all and I still modify DA at each segment endpoint ?

Can I still put two Destination options ?

Or reading the RFC8200 verbatim first DOH must be placed before RH hence to
have more then one DOH in a packet RH is mandatory ?

If so can it contain only 4 octets and no type specific data (so called be
a NULL RH) ?

What exactly tells the router to process or not to process last 4 headers ?
Is there a rule anywhere that unless RH is present and segments left = 0
destination must not follow next header in RH ?

Thank you,
R.

IPv6 extension header are ordered as follows:
> Note that the Destination Options header is the only extension header that
> can appear twice in a packet. The Destination Options header must
> immediately precede the Routing header or the upper-0layer header.
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 25 May 2020 09:50:28 +0000

Hi Robert,

"What … would happen … if there is no Routing Header at all and I still modify DA at each segment endpoint"
----Good question. I saw no less than 2 existing drafts and no less than 2 potential proposals with this behavior, and IMO they are all reasonable.

Or reading the RFC8200 verbatim first DOH must be placed before RH hence to have more then one DOH in a packet RH is mandatory
----2nd good question. I saw no less than 2 RFCs that have 3 DOHs in it optionally.
----I believe there could be more than one DOH in a packet without mandatory of requiring DOH before RH,  per below [1] (a higher level observation of IPv6 design IMO, not just the “recommended” text).

What exactly tells the router to process or not to process last 4 headers ? Is there a rule anywhere that unless RH is present and segments left = 0 destination must not follow next header in RH ?
----3rd good question. A router does NOT check/assume/guarantee the “8200 recommended order” at all IMO (would you do that?). Once a packet with the DA being the IPv6 address of a node is received, the node just “catch” it to its local-process.
----I believe below [2]  is another higher level observation of IPv6 design IMO about “EH order” from implementation view, not just the “recommended order” text.

In summary, I believe the “recommended order” of RFC8200 does not make a proposal superior than others at all.

Thanks
Jingrong

[1] RFC8200
   Defining new IPv6 extension headers is not recommended, unless there
   are no existing IPv6 extension headers that can be used by specifying
   a new option for that IPv6 extension header.  A proposal to specify a
   new IPv6 extension header must include a detailed technical
   explanation of why an existing IPv6 extension header can not be used
   for the desired new function.  See [RFC6564] for additional
   background information.

   Instead of defining new extension headers, it is recommended that the
   Destination Options header is used to carry optional information that
   must be examined only by a packet's destination node(s), because they
   provide better handling and backward compatibility.

[2] RFC8200
   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

   If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers must be specified.

   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

From: ipv6 [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, May 25, 2020 4:57 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi Ron,

So what in your opinion would happen with the below if there is no Routing Header at all and I still modify DA at each segment endpoint ?

Or reading the RFC8200 verbatim first DOH must be placed before RH hence to have more then one DOH in a packet RH is mandatory ?

If so can it contain only 4 octets and no type specific data (so called be a NULL RH) ?

What exactly tells the router to process or not to process last 4 headers ? Is there a rule anywhere that unless RH is present and segments left = 0 destination must not follow next header in RH ?

Thank you,
R.