Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark

Bob Hinden <bob.hinden@gmail.com> Tue, 22 October 2019 15:33 UTC

Return-Path: <bob.hinden@gmail.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 AF6D012087A; Tue, 22 Oct 2019 08:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.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 T5ZWvXjfT0nR; Tue, 22 Oct 2019 08:33:21 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17431200DB; Tue, 22 Oct 2019 08:33:20 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id q70so10646184wme.1; Tue, 22 Oct 2019 08:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=R8EbQL8mm7bMNc71y2bFEygZFLGUI+EIrLflmZLNGFM=; b=E30+jQdP8tOHNSYmtxm198N9LEX14ZousQrO5eyoG35cdfFFBvQmrGSGBnPc5QFznV HkAzQWHorOFlhMZAyf9X+HBNccP0LBiWiihljy45Bm2oZcyybGuZbu8n58fff1oK9f5w 1mczAuaSAP9brcJtzhs2Hc3Rmj1wNZbbdP+K0OGKzBzRI09pyWVmEqB9rjMYtT5mQGy0 Nn1PP1LfULvCKYIMuMw8F5lAZGTcl7zeHC2PdfhH28tMKHMoQUn4UlE8KflD7Juzu4VQ XlCthSvrAgsclMkaE0EZilCItqF3W9BMLEBBvWfbfSxURTHrZhqKa3NhxYcmPhUk060p 6tGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=R8EbQL8mm7bMNc71y2bFEygZFLGUI+EIrLflmZLNGFM=; b=uFqjsqSfjEju4I9eSYaaX7I4i6LPNNNhU7visAr9c3p9Kl1zo/7IJoVFBQ+PEHYwVU CyJAoMattng5lEJOTlz8uxIrCjNjo+MZePvnFn78PfCZbu5KR9EdXYcbyuV0hRap8Wvz oY1bEuC44UZjtvPdA+MAwhXM1s6k5h9Ht0jRvqSriNWy1Y3CCCBm3ri9ELnwbAzanD3b v0mmt9VFUeGns7vyYnoopAPiIm05OOg7maKphdbY9AZHS2u+1P7PkQeD5v7C6iLbORlG 92UW1YzDqAzbkraBXC9YwGN1/zpVRdgcLd1H68EyRbE7w1X5bUVGTvBDVQEVEJpPR2Ji iisA==
X-Gm-Message-State: APjAAAUf0+hYCYg87I/DSIwDDnZ8AZ7B82HuJJnsw44GTI4GtQ5B/QDM +RbtHJ5J09oHvOuhBL7/A3s=
X-Google-Smtp-Source: APXvYqxznR8F0FWVqCnsFDjaFDl2aK2zqq0IxokzgkesZRbmIZXmtnK8L4yZ23YHT/Od2Of5fRntXQ==
X-Received: by 2002:a1c:1f14:: with SMTP id f20mr3306555wmf.147.1571758399109; Tue, 22 Oct 2019 08:33:19 -0700 (PDT)
Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id a17sm13680929wmb.8.2019.10.22.08.33.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Oct 2019 08:33:18 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <CF17F307-FFFD-4181-8C67-E82C5BECF1AE@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_9DD051FF-ADDE-4F5B-A527-83815EFF019C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
Date: Tue, 22 Oct 2019 08:33:12 -0700
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BF03EEF7@NKGEML515-MBX.china.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" <draft-fz-6man-ipv6-alt-mark@ietf.org>
To: Tianran Zhou <zhoutianran@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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vnSQMCq0R8mkFkXpNWaxtU7oY0E>
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: Tue, 22 Oct 2019 15:33:28 -0000

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
>> --------------------------------------------------------------------