RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
Tianran Zhou <zhoutianran@huawei.com> Wed, 23 October 2019 01:20 UTC
Return-Path: <zhoutianran@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 A6D4C120219; Tue, 22 Oct 2019 18:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2_sZPb55pKfz; Tue, 22 Oct 2019 18:20:01 -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 755E41200CD; Tue, 22 Oct 2019 18:20:01 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 47ED8D167733186D4821; Wed, 23 Oct 2019 02:19:57 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 23 Oct 2019 02:19:57 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 23 Oct 2019 02:19:56 +0100
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 23 Oct 2019 02:19:56 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Wed, 23 Oct 2019 09:19:44 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, IPv6 List <ipv6@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Tom Herbert <tom@quantonium.net>, Haoyu Song <haoyu.song@futurewei.com>, "draft-fz-6man-ipv6-alt-mark@ietf.org" <draft-fz-6man-ipv6-alt-mark@ietf.org>
Subject: RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
Thread-Topic: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
Thread-Index: AdWFiuts9lClw3kCQaWaKSoqvpT0FwAxICWAAANOY4AAXP6xgAAumKVAAAf8nwAAJSUVUA==
Date: Wed, 23 Oct 2019 01:19:43 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BF040161@NKGEML515-MBX.china.huawei.com>
References: <MN2PR13MB35820D0A6A5E73CBB5D9DD129A6C0@MN2PR13MB3582.namprd13.prod.outlook.com> <CAPDqMeqANRZPxEswcp+=TdwgGQztgr3YS8bHH_wW4Ftfqj8YyQ@mail.gmail.com> <58F2AEA0-BC60-4629-85E4-3DA217ECF2AF@gmail.com> <0089a5343ba2440195146a36314f3aad@huawei.com> <BBA82579FD347748BEADC4C445EA0F21BF03EEF7@NKGEML515-MBX.china.huawei.com> <CF17F307-FFFD-4181-8C67-E82C5BECF1AE@gmail.com>
In-Reply-To: <CF17F307-FFFD-4181-8C67-E82C5BECF1AE@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
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/TMhAUNFyRoYsExtioo88JaFJdWk>
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: Wed, 23 Oct 2019 01:20:05 -0000
Hi Bob, Thank you very much for your suggestion. I agree. We will update this in the next revision. BR, Tianran > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Tuesday, October 22, 2019 11:33 PM > To: Tianran Zhou <zhoutianran@huawei.com> > Cc: Bob Hinden <bob.hinden@gmail.com>; Giuseppe Fioccola > <giuseppe.fioccola@huawei.com>; IPv6 List <ipv6@ietf.org>; IETF IPPM WG > <ippm@ietf.org>; Tom Herbert <tom@quantonium.net>; Haoyu Song > <haoyu.song@futurewei.com>; draft-fz-6man-ipv6-alt-mark@ietf.org > Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark > > Tianran, > > > > On Oct 21, 2019, at 9:04 PM, Tianran Zhou <zhoutianran@huawei.com> wrote: > > > > Hi Bob, > > > > Thanks for your comments. > > On this: > > " In the EH definition in Section 3.1.1 there is a field called "Flow ID". > I can’t tell if this is the same or different from the IPv6 flow label defined > in RFC8200 and RFC6437. This should be clarified and justified." > > > > Here are my thoughts: > > 1. The flow label in rfc8200 is used for application service, like LB/ECMP, > QoS. The flow ID used in the EH is to identify the monitored flow, and may > be assigned by a controller. That is to say, flow label and flow ID within > the same packet will have different scope, identify different flows, > different usage. So it's better to separate the two. > > 2. The flow ID is used for monitoring and measurement. The reuse of flow > label field may change the application intent(e.g.ECMP) and forwarding > behavior. So that the measurement does not align with the original traffic. > > 3. The flow label may be changed en route. The reuse of the flow label field > for the flow ID may violate the measurement task. > > The issue I raised is that because the names are similar, it is easy to confuse > the two. If this is different, the draft needs to be much clearer on its > definition. For example, the draft doesn’t include most of the text you wrote > above. > > I would also suggest a different name so it won’t be confused. For example, > “measurement ID”, or similar. > > Bob > > > > > > Any thoughts? > > > > Best, > > Tianran > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Giuseppe > >> Fioccola > >> Sent: Monday, October 21, 2019 9:30 PM > >> To: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>; > >> IETF IPPM WG <ippm@ietf.org>; Tom Herbert <tom@quantonium.net> > >> Cc: Haoyu Song <haoyu.song@futurewei.com>; > >> draft-fz-6man-ipv6-alt-mark@ietf.org > >> Subject: RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark > >> > >> Dear Bob, Tom, > >> Thanks a lot for your review of the draft. Much appreciate. > >> Please find my answers inline tagged as [GF]. > >> > >> Best Regards, > >> > >> Giuseppe > >> > >> -----Original Message----- > >> From: Bob Hinden [mailto:bob.hinden@gmail.com] > >> Sent: Saturday, October 19, 2019 7:08 PM > >> To: IPv6 List <ipv6@ietf.org>; IETF IPPM WG <ippm@ietf.org> > >> Cc: Bob Hinden <bob.hinden@gmail.com>; Haoyu Song > >> <haoyu.song@futurewei.com>; draft-fz-6man-ipv6-alt-mark@ietf.org; Tom > >> Herbert <tom@quantonium.net> > >> Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark > >> > >> Hi, > >> > >> I did a quick read of this draft and have a few comments. > >> > >> It appears to be defining a new IPv6 extension header. It should say > that > >> in the title and be described in the abstract. > >> > >> [GF]: I will do. > >> > >> This document defines how the alternate marking method can be used to > >> measure packet loss and delay metrics of IPv6 and SRv6. > >> > >> As Tom mentioned, SRv6 is part of IPv6, they are not separate things. > >> > >> [GF]: Sure, we meant that it can be applicable to IPv6 and, as a > >> consequence, also to SRv6. We will specify it better in the next revision. > >> > >> The IPv6 Header Format defined in [RFC8200] introduces the format of > >> the IPv6 addresses, the Extension Headers in the base IPv6 Header and > >> the availability of a 20-bit flow label, that can be considered for > >> the application of the Alternate Marking methodology. In this > >> > >> RFC8200 does not define the format of IPv6 addresses. That is done > >> in RFC4291. > >> > >> [GF]: Yes, we will add the reference to RFC4291. > >> > >> This draft appears to depend on a number of IPPM documents, but none > >> are listed as normative references. > >> > >> [GF]: We will review the dependencies. In particular we may need to > >> cut the reference to draft-zhou-ippm-enhanced-alternate-marking and > >> leave only RFC > >> 8321 and draft-ietf-ippm-multipoint-alt-mark. > >> > >> One of these is RFC 8321, but that has status of Experimental. I > >> don’t think this document can be Standards track if it depends on an > Experimental RFC. > >> > >> [GF]: Consider that RFC 8321 was classified as Experimental since it > >> describes a methodology that came from lab experience. In particular, > >> the first example of application was with IP packets where there is > >> no space for marking and we reused the DSCP field for our scope. > >> However the applicability of the method is general and, in this > >> draft, the new IPv6 extension header introduces an appropriate > >> marking field that would be dedicated only for the alternate marking > >> method and not for other purposes. So we refer to RFC 8321 just for > >> information and this does not necessarily imply that the draft should be > experimental, therefore it could be discussed. > >> > >> In the EH definition in Section 3.1.1 there is a field called "Flow > >> ID". I can’t tell if this is the same or different from the IPv6 flow > label defined > >> in RFC8200 and RFC6437. This should be clarified and justified. > >> > >> [GF]: Of course, it is a separate field and we will make it clearer > >> in the next version. > >> > >> Bob > >> > >> > >> > >>> On Oct 19, 2019, at 8:32 AM, Tom Herbert <tom@quantonium.net> wrote: > >>> > >>> On Fri, Oct 18, 2019 at 1:30 AM Haoyu Song <haoyu.song@futurewei.com> > wrote: > >>>> > >>>> I just read this draft and I think it’s an implementation of the > >>>> draft > >> [I-D.zhou-ippm-enhanced-alternate-marking], which discusses the > >> method of encapsulating the enhanced alternate marking header in > >> IPv6. I have several comments. > >>>> > >>>> > >>>> > >>>> It doesn’t cover the encapsulation on SRv6 yet and I think a > >>>> solution for > >> SRv6 would be more useful. > >>> > >>> SRv6 _is_ a subset IPv6. It is one type of routing header. Like any > >>> other use case of IPv6, HBH and destination options are useable when > >>> SRv6 header is present. Because SRv6 is a routing header destination > >>> options before the routing header are processed by each destination > >>> in the route list. > >>> > >>>> More deployment consideration discussion should be given when it’s > >>>> encapsulated in HBH EH > >>> > >>> In what regard? > >>> > >>>> The document mentioned two PBT modes discussed in > >> [I-D.song-ippm-postcard-based-telemetry]. Since the PBT-I variation > >> has been merged in another draft > >> [I-D.ioamteam-ippm-ioam-direct-export], this draft may need to be updated > accordingly. > >>>> > >>>> > >>>> > >>>> Thanks! > >>>> > >>>> > >>>> > >>>> Haoyu > >>>> > >>>> _______________________________________________ > >>>> ippm mailing list > >>>> ippm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ippm > >>> > >>> -------------------------------------------------------------------- > >>> 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 > >> --------------------------------------------------------------------
- Mail regarding draft-fz-6man-ipv6-alt-mark Haoyu Song
- RE: Mail regarding draft-fz-6man-ipv6-alt-mark Giuseppe Fioccola
- Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Tom Herbert
- Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Bob Hinden
- RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Haoyu Song
- RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Giuseppe Fioccola
- RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Tianran Zhou
- Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Bob Hinden
- RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Tianran Zhou
- Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Ole Troan
- RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-… Tianran Zhou