Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

"li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com> Wed, 04 March 2020 07:16 UTC

Return-Path: <li_zhenqiang@hotmail.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 ADD0A3A1087; Tue, 3 Mar 2020 23:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 VFXCIYbZbY4a; Tue, 3 Mar 2020 23:15:58 -0800 (PST)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255015.outbound.protection.outlook.com [40.92.255.15]) (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 8FEEB3A1081; Tue, 3 Mar 2020 23:15:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y0Yvqbb7TA2P5Ob1sBjy1I5Fq1aV7srvweJe+VTVF4HBYeBCkHgbmS3941+gQ6HKdnk9mIad5tXEO/voH6I//qllDdjAKaKrLRUHGLYLA7HSQhCNKdj6DbFeQ6TAgV0hxdQe4FSkjybK7X3Pa+l2w+jk/Qg00S22LyHIqFJpV87h50owOBDXwsUgSsnOAfLnlIx9sd3FuNwYPB7WRoZkJM8Ehju6bO30fEmhxwBoL45Zd5cCcv12pI4leTAE/jN9y5NF+//pn4meC093+4E1VgJwg6F2dS/KWeKCxb35BXYmve3CH7sbeix6iiQe2mnO9LBvGqOXT2UH17pioRdUUA==
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=eJZkrZZyXODNUWIahvzmWsuPD+0DU1SjnbnyRRmNf3k=; b=eNkuEfJ6SpZp0Uy/TeypIABx2Hc2zvnDnTyLoFVBMSzwmOq2BtuaG4WGA48HQJj49LHFQdRu2lByrI7Bo0js1LYgU5CbU70vPJkzpB31O2F3UJBVvRP9aWfKO0bkxiGzhWGKfh/ZEQQutnwMskggnV3Pd/x1xNplbWYenQE1jIZ2Yr+iHwPFB59SjPscPCJLytI2iKpA7iPy18FngKKySlRYocHcmDtq3jHKHDXbeWigMCwJztS6y6w1++idQZh3cfGp56BTGDJHidCa0JD8xrVAaTy193OiPjUOIQsoUyfh4XMeZ0ihVPtkvXAt+QMaHVtx9YJVxA4TtTAEQAE3OQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hotmail.com; dmarc=pass action=none header.from=hotmail.com; dkim=pass header.d=hotmail.com; 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=eJZkrZZyXODNUWIahvzmWsuPD+0DU1SjnbnyRRmNf3k=; b=QXaHhFqWoBFF7J9YYHa2ihe4Cxyx2oGEf8e/RlCB4MnS/MZWyHVYZZ3PfjgohXjY78EFLOEQbNgRSxYFLpgYr9C1q56WuH/AVW9YaLZrmTgjzIYbDrE2RK/HgdUcLcv1+AV4eS0V6Ah+dARqlBtwaaeYDvC9cEdVpmEZqrLQHJNzgxrjhFi/aeOhKKRnZ4pmQFyPIdscTxIYb26aUXi4BPJMIj67M4io5S9qV6tkowmtzrVE3wFLQQdGkRVGBdegN0xy6q7TFXIFiAGX8T8bw8ACCGnq3lwVZ4EIlQ0cuwZRbCfJ/v8K/zcL6YR7dRqtvVyiipWkMveASss3ezEwbw==
Received: from HK2APC01FT017.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::33) by HK2APC01HT155.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Wed, 4 Mar 2020 07:15:52 +0000
Received: from HK0PR03MB4066.apcprd03.prod.outlook.com (10.152.248.53) by HK2APC01FT017.mail.protection.outlook.com (10.152.248.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11 via Frontend Transport; Wed, 4 Mar 2020 07:15:52 +0000
X-IncomingTopHeaderMarker: OriginalChecksum:24D61E71ABB73F5DDED3701A3F0BF63AB24437A154E18D45E2AAE36751DDB467; UpperCasedChecksum:9F160F66CD3ECBBFDD52105FA85603CBD84879BF8168C4656CB8FC3F286EAD66; SizeAsReceived:9299; Count:51
Received: from HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::d4dc:f28f:1d27:e586]) by HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::d4dc:f28f:1d27:e586%7]) with mapi id 15.20.2793.011; Wed, 4 Mar 2020 07:15:51 +0000
Date: Wed, 04 Mar 2020 15:16:17 +0800
From: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, 神明達哉 <jinmei@wide.ad.jp>
References: <965ff6bbf1cb4c2f8d48b7b535a0cf5b@huawei.com>, <CAJE_bqcTNWt==mtYKeNVXOBAzBNLG=+_mXQQ9xMHYOCDRqCb_Q@mail.gmail.com>, <8ef02a5465104d1996546bc4cbea7ebb@huawei.com>, <CABNhwV1MZgvVTDH+32Q0DViwP43U=XUHD61DVeLbnA4_3-oq8g@mail.gmail.com>, <cc81dc2fbd4c4e3db3c1d2259386bf00@huawei.com>, <CABNhwV1RvwpOt_r-N8bs2oz0Fdc1xK5WTF=YcXALYBC3JfJ2cg@mail.gmail.com>
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.156[cn]
Message-ID: <HK0PR03MB40665212537EABC63C1BB859FCE50@HK0PR03MB4066.apcprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart230877141442_=----"
X-ClientProxiedBy: HK0PR01CA0054.apcprd01.prod.exchangelabs.com (2603:1096:203:a6::18) To HK0PR03MB4066.apcprd03.prod.outlook.com (2603:1096:203:9d::21)
X-Microsoft-Original-Message-ID: <2020030314401298895816@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from cmcc-PC (223.72.82.29) by HK0PR01CA0054.apcprd01.prod.exchangelabs.com (2603:1096:203:a6::18) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.2772.19 via Frontend Transport; Wed, 4 Mar 2020 07:15:49 +0000
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.156[cn]
X-Microsoft-Original-Message-ID: <2020030314401298895816@hotmail.com>
X-TMN: [PrQ+T+w58Aj+BoQ1cjUvpPZf5x6jlY8R]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 51
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: 8b679ad1-ae99-4a54-ac2c-08d7c00bde28
X-MS-TrafficTypeDiagnostic: HK2APC01HT155:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ZfmSbvFhfc2DtQ4jG7RQEx1E0qTnsQdIdb2Gl0izyqUEWpZfGOfMzN1AFiv0wI9lE36SAELwvj3mg55XMQ5LmekF2T++TQ66zg5ZYVmym5Ftbe8bOI5EBBcJvibvrLRLdwuAbYYFNCn1zf4vKUD7VfQ4n8pI8zUi7sCBYVYItzdtPgJwmUShbaWyfcoZACw8a6UQm/mA7mu7veCq9eFZqVALxKlozqx+tHHw3igJIn8=
X-MS-Exchange-AntiSpam-MessageData: lRIY8VjpdMLzwvFthk2Ys4NWHhj96iQwBcPuv9kCcbA9ZpjxkfLYpMEVGlEwM2fEyJu1u43P74UbpyID2D5/zRzB/avAD709hMJ1XEjq9OFKIEhlU2liALQx0+M1P6UL4plWws9fRE6RL1LtwD74FQ==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b679ad1-ae99-4a54-ac2c-08d7c00bde28
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2020 07:15:51.8934 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT155
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/QyWYw0ioOHUaStvBuIRof9MfHBc>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
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: Wed, 04 Mar 2020 07:16:01 -0000

Please use the text in the latest version as the start piont to generate the proper and acceptable text. Version 07 is too old.

Again to speed the standard process, I suggest the flavor part be removed from the srv6-network-programming doc. Since flavor is optional to srv6, we can disscuss it in a separate doc as an optional enhancement feature to SRv6.

Best Regards,
Zhenqiang Li


li_zhenqiang@hotmail.com
 
From: Gyan Mishra
Date: 2020-03-03 12:51
To: Xiejingrong (Jingrong)
CC: spring@ietf.org; 6man@ietf.org; Bob Hinden; 神明達哉
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong 

I am following what you displayed and it makes sense. In section 4.21.1 for the PSP flavor what was confusing was it said that the End.X with PSP flavor can pop the SRH.  The way it’s written,  to me it reads that any P router can pop the SRH when the last SID is written to the DA. So if the SRH SID list happens to not steer to the egress PE and ended a few hops early,  and If PSP is true then the SRH could be popped early on any P node.  Maybe I am reading to far into the verbiage.  I think since End.X could be any P transit router what I am saying could happen.  

4.21.1.  PSP: Penultimate Segment Pop of the SRH

   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
   the following instructions must be added:
 1.   IF updated SL = 0 & PSP is TRUE
 2.      pop the top SRH                                         ;; Ref1
   Ref1: The received SRH had SL=1.  When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but
   are not processed as part of the function.

At each hop each node copies the SID to DA and updates the SL = SL -1

I am depicting an incoming SL value to each node and then each node updates the SL pointer along the path hop by hop.

PSP mode

CE1----[PE1----{SL=2} - P2--{SL=1} -P3--pop--PE4]----CE2

PSP disabled (USP)

CE1----[PE1----{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 pop]----CE2

USD  (USD) - Decapsulation & forward native packet payload to customer CE

CE1----[PE1----{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 dencap]----CE2

Thanks 

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) <xiejingrong@huawei.com> wrote:
Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and End.X ( I haven’t known End.T very well yet).
 
Suppose:
CE1----[PE1----P2----P3----PE4]----CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the packet arriving P2 will be:
(SA=PE1, DA=P2<End>) (SL=2, PE4<End.DT4>, P3<End.X>, P2<End>)  (customer-packet)
 
Then, the packet arriving P3 will be:
(SA=PE1, DA=P3<End.X>) (SL=1, PE4<End.DT4>, P3<End.X>, P2<End>)  (customer-packet)
 
In Non-PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4<End.DT4>) (SL=0, PE4<End.DT4>, P3<End.X>, P2<End>)  (customer-packet)
 
In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4<End.DT4>) (customer-packet)
 
For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS identical to MPLS would be both a SR source node and final destination node of an LSP.”
I don’t think that’s always true, you can find an example I was recently thinking about in another mail: VM----TOR----Spine----Superspine----[PE1----P2----P3----PE4]----subscribers.
Even if it is true for some network, the capability to handle the SRH on a receiving packet is different than the encapsulation of an outer IPv6 header with an SRH header.
Sending (with encapsulation) and receiving (with recognizing/processing/demultiplexing),  they are not necessarily the same ---- like the things to fragment and assembly.
A PE may be well capable of encapsulation everything (like BFD template), but may fail to process a little thing that it is unrecognized.
It may just drop any packet with Next Header value other than 4/41/47/etc. 
It may send such packet with any routing header to its slow-path for the compliance but lose the necessary performance.
 
Thanks
Jingrong
 
From: Gyan Mishra [mailto:hayabusagsm@gmail.com] 
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
Cc: 6man@ietf.org; Bob Hinden <bob.hinden@gmail.com>; spring@ietf.org; 神明達哉 <jinmei@wide.ad.jp>
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
 
 
Hi Jingrong,
 
 
Can you help provide some clarification on the use cases for PSP flavor with end.X and end.T functions.
 
Under Ref1 where it mentions end.X and end.T functions to use PSP knob  as well if desired.
 
How would that work with any P node using the PSP function?
 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21
 
 
4.21.1.  PSP: Penultimate Segment Pop of the SRH
     After the instruction 'update the IPv6 DA with SRH[SL]' is executed,   the following instructions must be added:  1.   IF updated SL = 0 & PSP is TRUE 2.      pop the top SRH                                         ;; Ref1
 
Ref1: The received SRH had SL=1.  When the last SID is written in the   DA, the End, End.X and End.T functions with the PSP flavour pop the   first (top-most) SRH.  Subsequent stacked SRH's may be present but   are not processed as part of the function.
 
Also trying to understand the reason given for PSP function for legacy final destination egress PE not being SRv6 capable.
 
Since every PE in an SR domain both SRv6 or SR-MPLS identical to MPLS would be both a SR source node and final destination node of an LSP.  I am using the MPLS term LSP with SR as the concept of FEC destination which now is a prefix SID still exists that all traffic to egress final destination  PE is forwarded to.  
 
Since LSPs built to FEC destination are uni directional as they are with MPLS  and that would be the case as well for SR paths - the idea that the final destination PE would lack hardware capability for SRH processing does not make sense as the source and final destination node are one and the same.
 
Am I missing something?
 
Kind Regards 
 
Gyan
 
On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) <xiejingrong@huawei.com> wrote:
Got it.
Thanks for your clarification of your point. 

Jingrong

-----Original Message-----
From: 神明達哉 [mailto:jinmei@wide.ad.jp] 
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
Cc: Ted Lemon <mellon@fugue.com>; Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; Bob Hinden <bob.hinden@gmail.com>; Joel M. Halpern <jmh@joelhalpern.com>; spring@ietf.org; 6man@ietf.org
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

At Fri, 28 Feb 2020 07:54:28 +0000,
"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> wrote:

> The design of PSP for the benefits of deployment is based on the 
> understanding that it does not violate section 4 of RFC8200. In case 
> the RFC8200 text may be modified in the future, the PSP may also need to change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to discuss it at this level due to the poor editorial work then (I was also responsible for that as one of those reviewing the bis draft), but anyone who involved the discussion should know the intent of this text intended to say (borrowing from Ron's text) "Extension headers cannot be added to a packet after it has left the its source node and extension headers cannot be removed from a packet until it has arrived at its ultimate destination".  It might look "an attempt of blocking an innovation by a small group of vocal fundamentalists", but if you see the responses without a bias, you'd notice that even some of those who seem neutral about the underlying SRv6 matter interpret the text that way.

I'd also note that simply because PSP violates RFC8200 doesn't immediately mean it (PSP) "needs to change".  It can update RFC8200 with explaining why it's necessary and justified.  That's what I requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's justified.

And, since PSP at least wouldn't break PMTUD, I guess the update proposal will have much more chance to be accepted than a proposal including EH insertion.  On the other hand, pretending there's no violation will certainly trigger many appeals and objections at the IETF last call (I'll certainly object to it).  In the end, it can easily take much longer, or even fail, than formally claiming an update to RFC8200.

--
JINMEI, Tatuya
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-- 
Gyan  Mishra
Network Engineering & Technology 
Verizon 
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com
 
 
-- 
Gyan  Mishra
Network Engineering & Technology 
Verizon 
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com