RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Thu, 27 February 2020 12:05 UTC

Return-Path: <xiejingrong@huawei.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 CF6A63A09E8; Thu, 27 Feb 2020 04:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 xdgDjFRGHT_i; Thu, 27 Feb 2020 04:05:14 -0800 (PST)
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 5AC753A0803; Thu, 27 Feb 2020 04:05:14 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 72B329E4861BDA6CED2A; Thu, 27 Feb 2020 12:05:12 +0000 (GMT)
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Feb 2020 12:05:12 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 27 Feb 2020 20:05:09 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Thu, 27 Feb 2020 20:05:09 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Fernando Gont <fernando@gont.com.ar>, Ted Lemon <mellon@fugue.com>, "Maojianwei (Mao)" <maojianwei@huawei.com>
CC: SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Topic: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AdXtUHCB1tqntXEdSECRXFRXLBEUff//igSAgAAMNwD//3SlsA==
Date: Thu, 27 Feb 2020 12:05:09 +0000
Message-ID: <7a93a4726f8641f0bf374dd8911b6c3b@huawei.com>
References: <6B803B308679F94FBD953ABEA5CCCCD701089509@dggema524-mbx.china.huawei.com> <6E7A3022-DEC7-4E35-9A56-0F708CD41180@fugue.com> <58c706f7-2370-2b63-37df-0b5daf1ad8a5@gont.com.ar>
In-Reply-To: <58c706f7-2370-2b63-37df-0b5daf1ad8a5@gont.com.ar>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BUYCyxFiBKBKoEOz9_HCW6x8EQs>
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, 27 Feb 2020 12:05:16 -0000

However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200.

What PSP does is that, given:

  ---- B ----- C


routers, when B realizes, after processing the SRH and setting the Dest Addr to the last segment, SegmentsLeft==0, it removes the SRH.

This case is not even covered by their fictional interpretation of RFC8200.


RFC8200:
   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.

Isn't the word 'reaches' clear? A packet with the destination address owing to node B 'reaches' the node B. 

How can this be claimed again violation 8200 after 2 months? 

I remember that, Bob, Joel and many others had clarified this very clearly 2 months before, which led to the errata, saying 'clarifying' 8200.

----look at the errata----
Section 4 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.
It should say:
   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast).

So do you think the RFC8200 had made so big a mistake without awareness of the distinction of 'destination' and 'final destination' for 25 years since 1883 ?
And the folks that had been participated in the meantime had been made the same mistake for 25 years since 1883?
I can find the word 'reaches', 'destination' and 'final destination' in RFC1883 clearly, and I assume this distinction had been well aware of since 1883.


Thanks
Jingrong