RE: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Mon, 25 May 2020 04:56 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 2095E3A0B51 for <ipv6@ietfa.amsl.com>; Sun, 24 May 2020 21:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 obgZHNEU3e7j for <ipv6@ietfa.amsl.com>; Sun, 24 May 2020 21:56:11 -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 A15373A0B49 for <6man@ietf.org>; Sun, 24 May 2020 21:56:11 -0700 (PDT)
Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 51CFACCD7D3BDE7D6FF7; Mon, 25 May 2020 05:56:08 +0100 (IST)
Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 25 May 2020 05:56:07 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 25 May 2020 12:56:05 +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.1913.007; Mon, 25 May 2020 12:56:05 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6MAN <6man@ietf.org>
Subject: RE: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
Thread-Topic: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
Thread-Index: AQHWI0N8oI/8MsBlk0uecDFDr3XEgai3UJYAgAEJwPA=
Date: Mon, 25 May 2020 04:56:05 +0000
Message-ID: <69f92d989fca4a7bb3117d6afa84eade@huawei.com>
References: <CAJE_bqcR8gg6c4c=4sU8zfs5B0gaT4AFtKrbq9o2CFw_Yo4qvA@mail.gmail.com> <fd375263-2b3a-f20d-cf51-d5f39a62c5bf@gmail.com>
In-Reply-To: <fd375263-2b3a-f20d-cf51-d5f39a62c5bf@gmail.com>
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/8WMsRtWJjdojRKgJU7-XfDklCKE>
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, 25 May 2020 04:56:14 -0000
Hi Brian, Maybe the more you assume "Destination node" as "final/ultimate destination node", the more you will be confusing. To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field". Just think of the "destination node" as a node who is "listening" to an address, either a unicast address, or a multicast address. If a packet with the destination address being an address the "destination node" listening to, the "destination node" will <catch> it, and processing it either way, for example: (1) it could just simply forward it according to further (not very deep) information in any EH. (2) it could further dispatch it to the APP according to some (fairly deep) information. (3) it could discard the packet when it doesn't even be able to know how deep the information is. This way, the many text about EH (including the 4.6 DOH mentioned below) in RFC8200/2460/1883 is clear IMO. If there is need to describes "final/ultimate destination node", the further qualifying text will be added to the "Destination address". There *ARE* many examples in the RFC8200/2460/1883, and one could find those text "final/ultimate" in those RFCs. Thanks Jingrong -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, May 25, 2020 5:02 AM To: 6MAN <6man@ietf.org> Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 I believe there is one point that this draft still leaves unclear. RFC8200 says: "4.6. Destination Options Header The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s)." I believe we need to clarify whether this means the current destination node(s), or the final destination node(s), if a Routing Header is present. Regards Brian Carpenter On 06-May-20 13:12, 神明達哉 wrote: > I'd like to clarify a few things about > draft-bonica-6man-ext-hdr-update-03 based on the comments made in > today's interim meeting. I speak only for myself as a coauthor of the > draft, of course, but I believe I'm generally on the same page as Ron > for these points. > > First off, the purpose of this draft is NOT to prevent future > "innovations" on using extension headers (especially in terms of > insertions and deletions) forever. Protocols evolve over time, and > RFCs have been and will be continuously updated or obsoleted with new > requirements, changes in assumptions, or "innovations". Even if this > draft intended to prevent such changes it wouldn't be impossible in > practice. I thought that's too obvious to mention, but if we really > worry about this draft to act as an "innovation blocker", we could add > the obvious note. > > Secondly, in a sense this draft indeed clarifies an "obvious" point: > "the node identified in the Destination Address field of the IPv6 > header" in Section 4 of RFC8200 means the ultimate destination, not an > intermediate node specified in a routing header, regarding "not [...] > inserted, or deleted by any node". It was actually obvious to me and > so it's unfortunate that we have to clarify such a point. But the > recent discussion on draft-ietf-spring-srv6-network-programming proves > that it's not obvious for some others and can even be used as a reason > to pass a WGLC (and, in fact, I surprisingly realized that the RFC > text could literally read in a different way). So I believe we need > an explicit clarification. > > Third, several people suggested we should rather focus on conditions > where we can loosen the restrictions. That effort is certainly highly > appreciated and I'll support that, but I'd say that's a different > topic than this draft, nor can it substitute for this draft. RFC 8200 > specified the most generic principle and behavior of the IPv6 > protocol. If we leave the ambiguity (I'd rather say a "bug") in the > general protocol, we'll also leave it open for future protocols to > casually violate the intent without giving considerations on the > conditions that allow the exception. So IMO we need both: fixing the > "bug" of the general case, and work on detailing the conditions to > allow exceptions. > > I don't expect everyone agrees on all of my points, but at least I > hope it helps understand the motivation of the draft more accurately. > > -- > JINMEI, Tatuya > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- some feedback on feedback on draft-bonica-6man-ex… 神明達哉
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- Re: some feedback on feedback on draft-bonica-6ma… otroan
- Re: some feedback on feedback on draft-bonica-6ma… Philip Homburg
- Re: some feedback on feedback on draft-bonica-6ma… 神明達哉
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… 神明達哉
- Re: some feedback on feedback on draft-bonica-6ma… Ole Troan
- Re: some feedback on feedback on draft-bonica-6ma… 神明達哉
- Re: some feedback on feedback on draft-bonica-6ma… Gyan Mishra
- Re: some feedback on feedback on draft-bonica-6ma… Philip Homburg
- Re: some feedback on feedback on draft-bonica-6ma… Gyan Mishra
- RE: some feedback on feedback on draft-bonica-6ma… Ron Bonica
- Re: some feedback on feedback on draft-bonica-6ma… Philip Homburg
- Re: some feedback on feedback on draft-bonica-6ma… Robert Raszuk
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- Re: some feedback on feedback on draft-bonica-6ma… Philip Homburg
- Re: some feedback on feedback on draft-bonica-6ma… Robert Raszuk
- Re: some feedback on feedback on draft-bonica-6ma… Gyan Mishra
- Re: some feedback on feedback on draft-bonica-6ma… Joel M. Halpern
- Re: some feedback on feedback on draft-bonica-6ma… Robert Raszuk
- Re: some feedback on feedback on draft-bonica-6ma… Joel M. Halpern
- Re: some feedback on feedback on draft-bonica-6ma… Mark Smith
- Re: some feedback on feedback on draft-bonica-6ma… Robert Raszuk
- whether to grant exception for SRV6 (Re: some fee… 神明達哉
- Use/Modification/Extensibility and Reinvention (R… Mark Smith
- Re: some feedback on feedback on draft-bonica-6ma… Gyan Mishra
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Philip Homburg
- Role of IETF Robert Raszuk
- Re: whether to grant exception for SRV6 (Re: some… Andrew Alston
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Andrew Alston
- Re: Role of IETF Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Robert Raszuk
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: whether to grant exception for SRV6 (Re: some… Gyan Mishra
- Re: whether to grant exception for SRV6 (Re: some… JINMEI Tatuya / 神明達哉
- Re: Role of IETF Tony Przygienda
- springs network-programming (was Re: whether to g… Fernando Gont
- Re: whether to grant exception for SRV6 (Re: some… Gyan Mishra
- Re: some feedback on feedback on draft-bonica-6ma… S Moonesamy
- Re: springs network-programming (was Re: whether … Gyan Mishra
- Re: springs network-programming (was Re: whether … Fernando Gont
- Re: Role of IETF Tom Herbert
- Re: some feedback on feedback on draft-bonica-6ma… Sander Steffann
- Re: Role of IETF Robert Raszuk
- Re: Role of IETF Tom Herbert
- Re: Role of IETF Robert Raszuk
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- RE: some feedback on feedback on draft-bonica-6ma… Xiejingrong (Jingrong)
- Re: some feedback on feedback on draft-bonica-6ma… Brian E Carpenter
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- Re: some feedback on feedback on draft-bonica-6ma… Fernando Gont
- RE: some feedback on feedback on draft-bonica-6ma… Xiejingrong (Jingrong)
- RE: some feedback on feedback on draft-bonica-6ma… Xiejingrong (Jingrong)
- Re: some feedback on feedback on draft-bonica-6ma… 神明達哉