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.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: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#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$>.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 