Re: Re: [spring] Question about SRv6 Insert function

li zhenqiang <li_zhenqiang@hotmail.com> Thu, 05 September 2019 09:22 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 9809D120821; Thu, 5 Sep 2019 02:22:54 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Iu5np4U8sBoO; Thu, 5 Sep 2019 02:22:53 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253083.outbound.protection.outlook.com [40.92.253.83]) (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 CFD4812021C; Thu, 5 Sep 2019 02:22:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlBosckFiQC9XWPH3MzHk3+ljD0SLoY3kjb7PVpBElfPBoIUTWaYX2Y1CqJ1SHrLY+lA4OLttHiLK7cC2xknzVhxkPiKcMounFLZGmPnx0GZgM0En2aUD/BFpuPze1nikq3bwf7bn2sstzfjYKaR61csNZs97B6TY2lMkFrmCIEBhgwQfjvA3fpqTtefvbyPCufSGIx+wtGcVDg9RfR5ToTfHhW9BOELLmmlnMqD+w/lgG48URqHNQenTjU7xHJVgdGPUm4bXusaYBanVrFeAOUWZBErF/0H0R8zDaRJIaO5mYmgCJUjfmGsyxqYk1B7TNWKp6fjBexlYxu5xgQZbw==
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=7VKLaiYgtnAM8+lMWRLqNOLtYw8C+NPau3WN3oFUQLQ=; b=VVyGV2t04jImYGF/ryPtVvCdbMvDG1tm96VQWEjZTMublAHQF+ZqPGZ9gEUyWRhxuZFDUBXaKpU7qp1PTEKbpm1jnp4nvwwMSHjRQzisHh4IuJxTAygfNqhFOx2uOVDqAZCwAGXrThJUGTRq/FgkTyRdVLmJfdKW99dpszc7bzOipNWufNFikGQLpLd5lJ/mxNoRVdjO8j1nvjaupZ7OaR36cgft7Qx8mni65mola4vwHF6sDIDRI3kasY6CGaeGZTXQyDFmFUl/2QLlxE7ccuEVeUXXlOy92pvmX7XTRKbBqiOHyB1NQBnk+va2AH8cTIrXwHOlnOmAkQQm2r0TYw==
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=7VKLaiYgtnAM8+lMWRLqNOLtYw8C+NPau3WN3oFUQLQ=; b=iROXNLRyzwc/iU5W/rKN/TkxtO8AyN4JpNIf0AM5jA4R48gfOTj+U9e85y000la3wlqW9iSiwNYe0xLBJkKxht0YFlaFXk5WZS68PuxWdyOfSnq5ISpjdn3iuCcNM4jgQQOmxfFTvLp1U6ez1YMv04mESHK59XUZMUCEAJfUFaZIgCigPfNYhH7onOrbbA34G7R9+KyP/sqOAqUvGPL4twcNokVoG+m1yDcHzeDSXdeHAZHFh24yrPCmc9H+fb7bh90b6h1G/2CDu4GAEfVZjnbp3H52D2St7BynkESOBw8QsRpf+2c9hHJ7fsF4aMSOgvlCF6FZu+/SpIh/lAO2MQ==
Received: from SG2APC01FT005.eop-APC01.prod.protection.outlook.com (10.152.250.59) by SG2APC01HT166.eop-APC01.prod.protection.outlook.com (10.152.251.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2241.14; Thu, 5 Sep 2019 09:22:48 +0000
Received: from HK0PR03MB3970.apcprd03.prod.outlook.com (10.152.250.52) by SG2APC01FT005.mail.protection.outlook.com (10.152.250.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2241.14 via Frontend Transport; Thu, 5 Sep 2019 09:22:48 +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.014; Thu, 5 Sep 2019 09:22:48 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: Robert Raszuk <robert@raszuk.net>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
CC: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, Fernando Gont <fgont@si6networks.com>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: Re: Re: [spring] Question about SRv6 Insert function
Thread-Topic: Re: [spring] Question about SRv6 Insert function
Thread-Index: AQHVXxis/gF6F9KunkOxVqkDbflgtQ==
Date: Thu, 05 Sep 2019 09:22:48 +0000
Message-ID: <HK0PR03MB3970B55C202EBD4B17A4F1C0FCBB0@HK0PR03MB3970.apcprd03.prod.outlook.com>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com>, <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com>, <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar>, <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com>, <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar>, <18D85493-5FD4-4D26-B1A1-0931513DC847@gmail.com>, <05b6474b-ecc2-fbf9-ac5e-d81157be8b90@gont.com.ar>, <537C92D5-7355-45B5-8974-C74ED08B0E0F@employees.org>, <a7b5255b-8570-0e4b-da17-7557e7ca18c1@si6networks.com>, <CAOj+MMGbu5DhZ+igBLnU5M3QA5wFqzg=fiZG_Mhgnt-d0MG7yA@mail.gmail.com>, <AM0PR03MB3828138B0D728AA6FC4FA4139DBB0@AM0PR03MB3828.eurprd03.prod.outlook.com>, <CAOj+MMG=JLBb6X7HSYkhdPStCxvONUu6DJeCfW1dYVvZqSRKhA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HK0PR03CA0051.apcprd03.prod.outlook.com (2603:1096:203:52::15) To HK0PR03MB3970.apcprd03.prod.outlook.com (2603:1096:203:97::17)
x-incomingtopheadermarker: OriginalChecksum:FAE9379E1F02EA9A080C1B02436D4A7932674F6F1EA5EBE7BE614856C47B2F67; UpperCasedChecksum:F88D644AC4CC74EBC8A43A4FCEFB0DFD65887DF824EF99EFB007C930FC64E14C; SizeAsReceived:8573; Count:51
x-ms-exchange-messagesentrepresentingtype: 1
x-has-attach: no
x-mailer: Foxmail 7.2.9.156[cn]
x-tmn: [CfaHHlr65ZD8t/PDWxKnYbOymY3zceZlaEjHS0ld3Uc=]
x-microsoft-original-message-id: <201909051722461863176@hotmail.com>
x-ms-publictraffictype: Email
x-incomingheadercount: 51
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:SG2APC01HT166;
x-ms-traffictypediagnostic: SG2APC01HT166:
x-microsoft-antispam-message-info: 5/TJ332sDJgTs0VlSK675Fq/6L2wM9w5xEPdhMZssKOyEurtJ8q5FoIGUf0pGiJ0J9Fmr3TKCagKTZaJZk8ZWNQJT854M5DhRzYue/bj9V7FwkrZqBhkqSLMWPZYJKk20LQINt8IfrxjcpeQyolXWdLjYZgRbPuz/5pMv/MTZEtdCI/umsGiAgqYSIy3DmOO
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HK0PR03MB3970B55C202EBD4B17A4F1C0FCBB0HK0PR03MB3970apcp_"
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: 6cbbdd55-4aff-4c29-2394-08d731e29e08
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2019 09:22:48.3565 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT166
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oBA5C1U3FqAXh0UKFXucqbUcn-k>
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: Thu, 05 Sep 2019 09:22:55 -0000

Dear Robert,

Yes, SRH is TLV based. But the two documents want to insert one more SRH in a packet, not more segments in one SRH.

I recommend nothing. Just post the question.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com

From: Robert Raszuk<mailto:robert@raszuk.net>
Date: 2019-09-05 17:06
To: Alexander Vainshtein<mailto:Alexander.Vainshtein@ecitele.com>
CC: Ron Bonica<mailto:rbonica=40juniper.net@dmarc.ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; draft-voyer-6man-extension-header-insertion<mailto:draft-voyer-6man-extension-header-insertion@ietf.org>; Suresh Krishnan<mailto:suresh.krishnan@gmail.com>; Fernando Gont<mailto:fgont@si6networks.com>; draft-ietf-spring-srv6-network-programming<mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: Re: [spring] Question about SRv6 Insert function
Dear Alexander,

On Thu, Sep 5, 2019 at 10:38 AM Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:
Robert,
I fully agree with you that RFC 8200 does not prevent a node that owns the destination address of the IPv6 header to insert EH.

Great - Are we done with this "EH insertion" debate now ? :)

However, RFCV 8200 recommends (?) not to have more than one EH header of any type (excluding the Destination Options header that can occur no more than twice
– once before the Routing header and once again – before the upper layer header). I.e., two Routing Headers (of any type) in the same packet are, if not prohibited, then, at least, not recommended.

SRH is TLV based could be as long as needed.

However sometimes it could be useful from processing pov to decouple some functions to be placed in separate SRHs for example to clearly filter/boost processing just by looking at the flags field. But it is just optimization.

Sure one could ask for new type (or bunch of types) if this makes any technical merit.

Btw since you point out that Destination Options also only allow to be present twice we have the same problem there.

Dear Zhenqiang,

Would you recommend to define new type of EH for FRR protection ? Say PRH (Protection Routing Header) extension header with type say 5 ?

Does it make really sense to define a new type just from bureaucracy pov for each possible application - even if all functionality would still be identical if we would have the same type 4 carry the data ? Does it make any sense to do that from hardware processing point of view - to modify it to recognize bunch of types and still do exact same processing on them ?

Cheers,
R.