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

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:jmh@joelhalpern.com] 
Sent: Sunday, May 24, 2020 1:10 AM
To: Chengli (Cheng Li) <c.l@huawei.com>; 6man <6man@ietf.org>; spring@ietf.org
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:
> 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.t
> xt 
> <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:rbonica@juniper.net]
> *Sent:* Friday, May 22, 2020 10:17 PM
> *To:* Chengli (Cheng Li) <c.l@huawei.com>; 6man <6man@ietf.org>; 
> spring@ietf.org
> *Cc:* spring@ietf.org
> *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
> 
> Both of these can be used to deliver service function information to 
> service function instances.
> 
>                                                                                                                       
> Ron
> 
> Juniper Business Use Only
> 
> *From:*Chengli (Cheng Li) <c.l@huawei.com <mailto:c.l@huawei.com>>
> *Sent:* Friday, May 22, 2020 2:56 AM
> *To:* 6man <6man@ietf.org <mailto:6man@ietf.org>>; spring@ietf.org 
> <mailto:spring@ietf.org>; Ron Bonica <rbonica@juniper.net 
> <mailto:rbonica@juniper.net>>
> *Cc:* spring@ietf.org <mailto:spring@ietf.org>
> *Subject:* How CRH support SFC/Segment Endpoint option?
> 
> *[External Email. Be cautious of content]*
> 
> 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#secti
> on-4.1 
> <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]. 
> https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.t
> xt 
> <https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 