IETF Logo Mail Archive

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

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Fri, 22 May 2020 15:11 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A43A0BB1; Fri, 22 May 2020 08:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvYMKSDl6lfl; Fri, 22 May 2020 08:11:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FBD3A0B9C; Fri, 22 May 2020 08:11:57 -0700 (PDT)
Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B64B896C58F29CCB645A; Fri, 22 May 2020 16:11:55 +0100 (IST)
Received: from lhreml734-chm.china.huawei.com (10.201.108.85) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 22 May 2020 16:11:55 +0100
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 22 May 2020 16:11:55 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.202]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0487.000; Fri, 22 May 2020 23:11:43 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Chengli (Cheng Li)" <c.l@huawei.com>, 6man <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: How CRH support SFC/Segment Endpoint option?
Thread-Index: AdYwBYkgTau2vInrR6WP+x+iqlpN9gAPJDmwAAHblAA=
Date: Fri, 22 May 2020 15:11:43 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE18F3D928@DGGEML532-MBX.china.huawei.com>
References: <C7C2E1C43D652C4E9E49FE7517C236CB02A2CD12@dggeml529-mbx.china.huawei.com> <DM6PR05MB63482CFA4D5AB938D5A4B818AEB40@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB63482CFA4D5AB938D5A4B818AEB40@DM6PR05MB6348.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.218.16]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE18F3D928DGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/D_vr7KEXKdyh99tyYTkFwypxl5E>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2020 15:11:59 -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:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
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$>.

v2.23.0 | Report a Bug | By Email