Limited Domains: (was: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt)

Folks,

If we redefine the flow label so that it has one semantic on the global Internet and another in Limited Domain A, do we still have a single IPv6 protocol? Or do we have IPv6 and IPv6.1, which are not compatible with one another?

If we go down that path, how many incompatible versions of IPv6 should we allow. One? Two? Forty-two? 

                                                Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ahmed Abdelsalam (ahabdels)
Sent: Monday, April 12, 2021 12:02 PM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>; 6man@ietf.org
Cc: draft-filsfils-6man-structured-flow-label@ietf.org
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

[External Email. Be cautious of content]

Hi Brian,

Many thanks for your time.

Indeed, the scope of this draft is within a limited domain. The deployment scenario for this draft is documented in Section 3. In short: service provider network, whereas all IPv6 nodes are under the administrative control of the operator. The ingress PE receives traffic from customers (eth, ipv4, ipv6) and encapsulates it in a new IPv6 header. The source node of the IPv6 packet traversing the SP network is the ingress PE. We can clarify this further in the next revision of the draft.

I believe this would address your point.

We will also fix the nit in the illustration.

Many thanks,
Ahmed.

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Thursday, 8 April 2021 at 04:19
To: "6man@ietf.org" <6man@ietf.org>
Cc: "draft-filsfils-6man-structured-flow-label@ietf.org" <draft-filsfils-6man-structured-flow-label@ietf.org>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
Resent from: <alias-bounces@ietf.org>
Resent to: <cf@cisco.com>, ahabdels <ahabdels@cisco.com>, <shay.zadok@broadcom.com>, <xiaohu.xu@capitalonline.net>, <chengweiqiang@chinamobile.com>, <daniel.voyer@bell.ca>, <pcamaril@cisco.com> Resent date: Thursday, 8 April 2021 at 04:18

    Hi,

    A few comments on this draft.

    As background, there have been numerous past proposals for semantics in the flow label; all the ones we could find in 2011 are discussed in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6294.html__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOgTZo7iN$ . The IETF has consistently declined to adopt any of them. There's also some rationale for the current standard in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6436.html__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOnCrSKIZ$ .

    My first comment on the present draft is that it doesn't state its target scenario (which might be LAG, because LAG is mentioned a few times). It also ignores the fact that most current operating systems follow RFC6437 by setting a 20-bit pseudorandom label for all TCP sessions. Of course this must not be changed en route across the Internet. One usage scenario is described in RFC7098, but it's clear that the draft isn't compatible with any scenario in which sources somewhere on the Internet do what RFC6437 tells them to do and downstream routers or load balancers assume that is the case.

    So is it correct that the draft is aimed only at sources (and routers and destinations) within some sort of limited domain? If so, that needs to be clearly stated at the beginning.

    There is a spec for using the flow label for ECMP/LAG tunnels in RFC6438. I'd be inclined to the view that 16 pseudorandom bits would be sufficient in that case. In any case, in that case the end-to-end flow label is not affected, just the tunnel, so the fact that four bits don't contribute to the hash is tolerable.

    However, just to be clear, you *cannot* declare that in a packet that goes out on the Internet, where the downstream routers support RFC6437, that 4 bits in the flow label are not part of the flow label. Such a thing would in no way be "seamless migration from RFC6437".

    Relying on specific statements by a couple of router vendors about what their current products do or don't do is invalid. Other vendors might be different, and as technology evolves those two vendors might change what they do. The argument in section 4 might work for an ECMP/LAG scenario but it *certainly* doesn't work for the server farm scenario (RFC7098), which it would simply break. So rather than "seamless migration" you get "broken user sessions".

    Again, you might be able to fix this by positioning the proposal for an ECMP/LAG scenario within a limited domain or a provider tunnel. But as a generic update to RFC6437, absolutely positively not.

    Nit:

    I'm not sure why in figs 1 and 2 you use little-endian bit numbering. It's confusing. I thought the issue was settled by RFC 791.

    Regards
       Brian Carpenter

    On 17-Mar-21 05:49, internet-drafts@ietf.org wrote:
    >
    > A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >
    >
    >         Title           : Structured Flow Label
    >         Authors         : Clarence Filsfils
    >                           Ahmed Abdelsalam
    >                           Shay Zadok
    >                           Xiaohu Xu
    >                           Weiqiang Cheng
    >                           Daniel Voyer
    >                           Pablo Camarillo Garvia
    >   Filename        : draft-filsfils-6man-structured-flow-label-00.txt
    >   Pages           : 12
    >   Date            : 2021-03-16
    >
    > Abstract:
    >    This document defines the IPv6 Structured Flow Label.  The seamless
    >    nature of the change to [RFC6437] is demonstrated.  Benefits of the
    >    solution are explained.  Use-cases are illustrated.
    >
    >
    > The IETF datatracker status page for this draft is:
    > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOnB_SDAh$
    >
    > There are also htmlized versions available at:
    > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-filsfils-6man-structured-flow-label-00__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOv2CiWS9$
    > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-filsfils-6man-structured-flow-label-00__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOrk-MX27$
    >
    >
    > Please note that it may take a couple of minutes from the time of submission
    > until the htmlized version and diff are available at tools.ietf.org.
    >
    > Internet-Drafts are also available by anonymous FTP at:
    > https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOhgc6EkY$
    >
    >
    > _______________________________________________
    > I-D-Announce mailing list
    > I-D-Announce@ietf.org
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOvvLmZUo$
    > Internet-Draft directories: https://urldefense.com/v3/__http://www.ietf.org/shadow.html__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOmQbYE53$
    > or https://urldefense.com/v3/__ftp://ftp.ietf.org/ietf/1shadow-sites.txt__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOskgTb1M$
    >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9ARUaOuTV9LL3$
--------------------------------------------------------------------