RE: Comments on draft-fz-6man-ipv6-alt-mark-09

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Thu, 21 May 2020 10:03 UTC

Return-Path: <giuseppe.fioccola@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 38DEB3A0B6A for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 03:03:39 -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 N2qdt1TS263w for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 03:03:37 -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 D87513A0B5B for <6man@ietf.org>; Thu, 21 May 2020 03:03:36 -0700 (PDT)
Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 98F155CF9B5D8A7F2CC7; Thu, 21 May 2020 11:03:35 +0100 (IST)
Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 21 May 2020 11:03:35 +0100
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 21 May 2020 12:03:35 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Thu, 21 May 2020 12:03:35 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6MAN <6man@ietf.org>
Subject: RE: Comments on draft-fz-6man-ipv6-alt-mark-09
Thread-Topic: Comments on draft-fz-6man-ipv6-alt-mark-09
Thread-Index: AQHWLV4B729lZpqY10m1a8Nz6iB756iukSqAgADPCgCAACoVIP//76qAgAEUqZCAAOH2AIAAyskA
Date: Thu, 21 May 2020 10:03:34 +0000
Message-ID: <9b6e321f202c48de90576e17787705da@huawei.com>
References: <CALx6S35bWVkTWcbdOt-HA-9XbH4WwRsTyaUdDA5q4rUNJvNNiw@mail.gmail.com> <da6e0d76-915b-a7da-8744-2f3761b43a98@gmail.com> <CALx6S37STTqFfFmOm9Rosmot5Dt2+YpQLoy4EPGzFn=6MTG_+A@mail.gmail.com> <0ab629e6d20e4943871446cc23a22ac8@huawei.com> <CALx6S36tyEbijjXybmadpiFt9RC59=ysgtqQyjz7TdxrwWM-rA@mail.gmail.com> <f9feee64d55848d59e9451fdf92c73d7@huawei.com> <CALx6S37L=5L66DOSw5bz8VHPEgke4BVSGrw5HiGiUL=q0CbaRg@mail.gmail.com>
In-Reply-To: <CALx6S37L=5L66DOSw5bz8VHPEgke4BVSGrw5HiGiUL=q0CbaRg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.2.74]
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/b0_oeQ9Gf_sCAn7QgBIXeGdQn0E>
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, 21 May 2020 10:03:40 -0000

Hi Tom,
Thanks a lot for the useful inputs.
My answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Tom Herbert [mailto:tom@herbertland.com] 
Sent: giovedì 21 maggio 2020 00:32
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; 6MAN <6man@ietf.org>
Subject: Re: Comments on draft-fz-6man-ipv6-alt-mark-09

On Wed, May 20, 2020 at 12:21 AM Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:
>
> Hi Tom,
> Please find my answers inline tagged as [GF]
>
> Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Tuesday, May 19, 2020 6:33 PM
> To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; 6MAN 
> <6man@ietf.org>
> Subject: Re: Comments on draft-fz-6man-ipv6-alt-mark-09
>
> On Tue, May 19, 2020 at 8:48 AM Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:
> >
> > Hi Tom,
> > Thanks for your support and for your comments.
> > I understand your point, but, in this regard, we should consider the following paragraph from RFC6437:
> >
> >    "There is no way to verify whether a flow label has been modified en
> >    route or whether it belongs to a uniform distribution.  Therefore, no
> >    Internet-wide mechanism can depend mathematically on unmodified and
> >    uniformly distributed flow labels; they have a "best effort" quality.
> >    Implementers should be aware that the flow label is an unprotected
> >    field that could have been accidentally or intentionally changed en
> >    route (see Section 6)"
>
> Hi Giuseppe,
>
> Unless AH is present (the common case) the whole IP header and extension headers, including any HBH and Destination Options, are also unprotected and best effort delivery. We even have to consider that IP addresses can change (for instance NAT can change addresses in the middle of UDP flow lifetime).
>
> >
> > This does not suggest to rely fully on the Flow Label.
> > Maybe we can mention in the next revision of the draft the possibility to use the Flow Label for identification, but we should also highlight this point.
> > In addition, as listed in Section 5.3 of draft-fz-6man-ipv6-alt-mark-09, FlowMonID adds additional advantages in terms of scalability, flexible flow definition granularity, counters handling simplification...
>
> I don't see any scalability for a 20 bit identifier that is supposed to be unique throughout the network. As I mentioned this can simply be combined with the source and destination IP addresses to form a 3-tuple. The 3-tuple can then be hashed to produce a single most unique flow identifier that is suitable lookups. In this manner the 20 bit field is sufficient and nodes can autonomously set it without any synchronization. This is how we commonly deal with the flow label today and other cases of flow classification using a flow hash.
>
> [GF]: I think we can mention the possibility to use the 3-tuple for identification: Flow Label with source and destination addresses. In addition, we could also consider the hashed 3-tuple to set the FlowMonID algorithmically generated by the source node.
> The only issues with the 3-tuple are:
> - in case the IP addresses or Flow Label change en route.

Giuseppe,

Again, they're not really supposed to change enroute. IP addresses can only change due to NAT and flow labels can only be changed for a strong security reason. Given that the marking is only meaningful in a limited domain which wouldn't have NAT and there is no security issue that would necessitate rewriting flow labels, for the purposes of this proposal they can't change in flight.

[GF]: Yes, agree, it is quite unlikely to happen but it is something to keep in mind.

> - it allows only layer3/layer4 granularity. We may not have flexible 
> flow identification in order to enable personalized selection rules or 
> multipoint paths monitoring (e.g. draft-ietf-ippm-multipoint-alt-mark)

The flow label does interact with ECMP, so there may be cases where they need to be different I suppose.

> For this reason we suggest to keep all the possibilities: 3-tuple and FlowMonID.
>
I suggest not keep all the possibilities open, pick one that should be implemented. The cost of sending the FlowMonID is negligible (the cost of the extension header has already been assumed), to me it's more of a question of whether it's sufficient for uniquely identifying flows.

[GF]: I understand your point. The two possibilities I have in mind are the centralized control and the auto generation of the FlowMonID. With regards to the auto set, the idea to use the FlowMonID together with the 3 tuple is a possible way to ensure the uniqueness.

> Even if the FlowMonID remains, the likely thing a host implementation would do is just to set the FlowMonID identically to the flow label.
> Do you see any reason why this won't work?
>
> [GF]: We did not specify the way to generate the FlowMonID, we just think that the FlowMonID can identify flows easily and flexibly. So we can surely mention that FlowMonID can be set identically to the Flow Label.
>

The draft mentions two ways to set the FlowMonID: "The FlowMonID can be uniformly assigned by the central controller or algorithmically generated by the source node.".

The use of a centralized control for this is a hard problem. The protocol and APIs that hosts use to interact with the controller have to be considered, as do various failure modes, redundancy model, coherency, etc. If this is suggested, I think there should be some detail and requirements or reference to a protocol specification for it.

[GF]: If we want to achieve the flexible monitoring like Multipoint Alt Mark, the centralized control is required to zoom in and zoom out. Of course, this requires interaction between controller and the nodes, but we can reuse and extend some existing protocol. Anyway we can further explore this part in a later version after the draft is adopted.

As the draft states for the automatic generation of flow identifiers cannot guarantee uniqueness. In this case, we want a mechanism that provides uniqueness with high probability. The probability of identifier uniqueness correlates to the amount of entropy of the inputs. For instance, if the 20 bit FlowMonID is set independently and pseudo randomly by each node without any additional input entropy, there is a 50% chance of collision is just 1207 flows. If there were a
32 bit hash with at least 32 bits of input entropy the 50% threshold jumps to 77,264 flows, for 64 bit hash it's 5.06 billion flows. So as defined FlowMonID really isn't sufficient for uniqueness. To get more entropy it can either be combined with other identifying flow information in a packet (like we do when hashing IP addresses and flow
label) or the FlowMonID size could be increased (presumably the sender would set the FlowMonID to some sort of pseudo hash with at least 32 bits of entropy for the connection anyway).

[GF]: Yes, fully agree on that. Note that draft-ietf-anima-grasp-15 describes a similar problem and is proposing a pseudo-random 32 bit Session ID that is generated by the initiator. However, because of the finite probability that two nodes might generate the same Session ID value, the receiving node also tags it with the initiator's IP address to allow disambiguation. In a similar way, FlowMonID can be combined with other identifying flow information in a packet (IP addresses together and Flow Label) or the FlowMonID size can also be increased by using the reserved bits.

One other question, does flow identification need to be symmetric. For instance, do we need to be able to match packets sent in either direction of a TCP connection as being part of the same flow?

[GF]: Since we consider the IP layer monitoring, we can focus on unidirectional flow and not bidirectional.

Tom


Tom



> Tom
>
>
>
>
>
>
>
> >
> > Regards,
> >
> > Giuseppe
> >
> >
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
> > Sent: Tuesday, May 19, 2020 5:00 PM
> > To: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > Cc: 6MAN <6man@ietf.org>
> > Subject: Re: Comments on draft-fz-6man-ipv6-alt-mark-09
> >
> > On Mon, May 18, 2020 at 7:39 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > >
> > > Tom,
> > >
> > > > It's unclear to me how the FlowMonID is set, how it's used, and 
> > > > why the Flow Label isn't sufficient for this purpose.
> > >
> > > That was proposed by the authors and discarded a long time ago, 
> > > because the usage was incompatible with RFC6437. I can't remember 
> > > the details without looking up long-expired drafts and old email. But generally:
> > > you can't encode semantics in conformant flow labels, because they 
> > > are pseudo-random.
> > >
> > Brian,
> >
> > AFAICT the FlowMonID is just another type of flow identifier in the packet. For the purposes of correlating flows in the network I believe it is redundant to the flow label and would otherwise add a lot of complexity to implement. I think what you might be referring to are earlier proposals to put the loss signal bits in the flow label and not use an EH-- that idea is indeed infeasible at this point. IMO, we should be able to eliminate FlowMonID from the option, but still need the two signaling bits in the option hence the alt marking option would contain one byte of data.
> >
> > Tom
> >
> > > Regards
> > >    Brian
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------