IETF Logo Mail Archive

Re: RE: Question about SRv6 Insert function

li zhenqiang <li_zhenqiang@hotmail.com> Mon, 02 September 2019 01:15 UTC

Return-Path: <li_zhenqiang@hotmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDA61200E9; Sun, 1 Sep 2019 18:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.125
X-Spam-Level:
X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 IYQNr1aT-4rH; Sun, 1 Sep 2019 18:15:48 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254066.outbound.protection.outlook.com [40.92.254.66]) (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 B6A3512003F; Sun, 1 Sep 2019 18:15:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fIYd3OkbcRYwqaouHMkYoiGKcg2R0fKSZolR7X9XIiMyXqJeN/NJKLaS6N2lQdF+WUdejMdJ5MXcbtspT/cfYHpF5Bt+pnia3Aeq1V6DT3EBfhoBYNDUXfolwiosPOfK1wuV3gSaiNijZyyv3AreZc6gcdK/hjhydPWIQEcVRzzg+Qz/lcT9vKxq3InnHLm2QEjYRJsSoLyus1nLaWdMXgQu1pLi+p9P9WbnDJPRjrVzlPpoxLMoM2Kl27jZ74jBGEhbzJ2Nh9Us6vEB7wlp3tFNGe1sKIhz0IgmOJuWA2zEuhRukSlFgC2ke697UfDJzUWCV7lsUzWS/6L29LYd3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bizTtOEtBdkSstWKlLQHlGKsylriPuTQThAvtD+XiGo=; b=immBNqvEqkrJBQc4tpWOa/0x9XdyEOmbgOpfMrQuCWW01aOZfPGdP3b154gMzrn0yNTLoaa3cOndmr0YjJ5tQmD+G0C2ibz1Sf3K7TEQ+iEeZWdqzaqc21+5J3aYShQqeeEy9i71kIiS6p2cFN8NvGZ2FZvTNxjBITFhYmUjvAUtkQNCM4EKPPQ8IrML8XYtdRlZXbWWNCjMmYo4xGl+Mwbd96Ath0O3LiaQEMVvm10QX5tpfo7u8W5qCUPranQwrY8am3HW+JyexDXKAnVAEJsfYAQYBws094pb2U1UNkdtAos5Jeb/2oMF/obdXtoMZPSniMQBPqVQwEVqB+oj8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bizTtOEtBdkSstWKlLQHlGKsylriPuTQThAvtD+XiGo=; b=C+IqO4SjydO8l3Rtr93JVRU1J2sgbzxVxlnfnTpKV3sl2KgvqCwkEHNn5UJ2pCzFyZYmQWMCPbvt94qzSoNAbmrV4Dro7X5U8dlZBLSrH5RJyV/u4JjG8O028z0+xRCr7Jej4jcz47314RJFJpYYGn7d8gSqyPIbNeKPM7vbjTLb28cUoWGsFQ8NcIP3huh7La4MfhlKnN4/8z73qfCquBt6RDn5ccctV0lWXqbrLjwc9qEeYQOuRvCu7E/rTJPoUkqM2KlobrNH/+OIIOQM/jAS4xrN4E/IJ5esG9Fwp+rqtojm4sE9pP4nNFfjiluPHXWzAk7trZ80twpsJBpSyg==
Received: from HK2APC01FT048.eop-APC01.prod.protection.outlook.com (10.152.248.51) by HK2APC01HT068.eop-APC01.prod.protection.outlook.com (10.152.249.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2220.16; Mon, 2 Sep 2019 01:15:44 +0000
Received: from HK0PR03MB3970.apcprd03.prod.outlook.com (10.152.248.59) by HK2APC01FT048.mail.protection.outlook.com (10.152.249.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.16 via Frontend Transport; Mon, 2 Sep 2019 01:15:44 +0000
Received: from HK0PR03MB3970.apcprd03.prod.outlook.com ([fe80::58ab:9421:d860:7c34]) by HK0PR03MB3970.apcprd03.prod.outlook.com ([fe80::58ab:9421:d860:7c34%6]) with mapi id 15.20.2241.006; Mon, 2 Sep 2019 01:15:44 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: Ron Bonica <rbonica@juniper.net>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: RE: Question about SRv6 Insert function
Thread-Topic: RE: Question about SRv6 Insert function
Thread-Index: AQHVXxis/gF6F9KunkOxVqkDbflgtQ==
Date: Mon, 02 Sep 2019 01:15:44 +0000
Message-ID: <HK0PR03MB39700007E730C0CDB9D9F579FCBE0@HK0PR03MB3970.apcprd03.prod.outlook.com>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com>, <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HK0PR01CA0067.apcprd01.prod.exchangelabs.com (2603:1096:203:a6::31) To HK0PR03MB3970.apcprd03.prod.outlook.com (2603:1096:203:97::17)
x-incomingtopheadermarker: OriginalChecksum:31BDD976FFD0675151F9085076102A1231ACF020E0E0080DF0464FE2AF182749; UpperCasedChecksum:15BC97A2DC315026F4877DB2F53236A891DC77BE3F7D9D30B51E1D842E2E5600; SizeAsReceived:7729; Count:50
x-ms-exchange-messagesentrepresentingtype: 1
x-has-attach: no
x-mailer: Foxmail 7.2.9.156[cn]
x-tmn: [4aaeXchAVfJs3g0euc8i6ouy3DKA0329]
x-microsoft-original-message-id: <2019090209154309421520@hotmail.com>
x-ms-publictraffictype: Email
x-incomingheadercount: 50
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:HK2APC01HT068;
x-ms-traffictypediagnostic: HK2APC01HT068:
x-microsoft-antispam-message-info: 7UWjeNGiSku23TFLszlBqtQKmUMJpGQ/MubZ2+lE8gqkQ5S6hF366kS/kpBp7AuxfeowxheksSilO9KA0cix++DFMqk1YXjalUk91Z6FYxlY6+qWyVllBPu9pi2kBJIe26IFIUtPXhMH0r5RRyw6PYVk/lAosxGPG/vyz4IPuk9CLc17N5JZPn3D3f1HrX7B
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HK0PR03MB39700007E730C0CDB9D9F579FCBE0HK0PR03MB3970apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 74feff4b-92e6-4717-9bd6-08d72f43140c
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 01:15:44.5937 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT068
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/s7dsjxRoXgjDBAZMkuBE_vRBZuY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 01:15:51 -0000

Hi Ron,

Thank you for your discussion.
I think the texts of the two documents only describe the option 2 you mentioned, which is contradict with RFC 8200.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com

From: Ron Bonica<mailto:rbonica@juniper.net>
Date: 2019-08-31 01:24
To: li zhenqiang<mailto:li_zhenqiang@hotmail.com>; draft-voyer-6man-extension-header-insertion<mailto:draft-voyer-6man-extension-header-insertion@ietf.org>; draft-ietf-spring-srv6-network-programming<mailto:draft-ietf-spring-srv6-network-programming@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: Question about SRv6 Insert function
Li,

In the scenarios that you mention, below, SRv6 nodes have the following options:


  1.  To prepend and IPv6 header, with its own SRH
  2.  To insert an SRH, as described below

Option 1 is in keeping with the word and spirit of RFC 8200. As you point out, Option 2 contradicts RFC 8200.

So, we should probably explore the motivation for Option 2). If the motivation is not sufficient, we should probably standardize on Option 1.

                                                                                                               Ron




Juniper Business Use Only
From: spring <spring-bounces@ietf.org> On Behalf Of li zhenqiang
Sent: Friday, August 30, 2019 5:53 AM
To: draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>; 6man@ietf.org; spring@ietf.org
Subject: [spring] Question about SRv6 Insert function

Hello all,

End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will insert a new SRH in the received IPv6 packet, which results in two SRHs in one IPv6 packet. It is contradict with RFC8200 that says Each extension header should occur at most once, except for the Destination Options header.

In draft-voyer-6man-extension-header-insertion-06, an intermediate node executes the insert function to implement a sub-50 milliseconds FRR operation upon link failure. It is contradict with RFC8200 that says Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet’s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

v2.23.0 | Report a Bug | By Email