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

Toerless Eckert <tte@cs.fau.de> Mon, 12 April 2021 19:33 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 CDC193A13EA; Mon, 12 Apr 2021 12:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 Ad_XWHXkENXc; Mon, 12 Apr 2021 12:33:36 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D643A13EC; Mon, 12 Apr 2021 12:33:36 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2452854804D; Mon, 12 Apr 2021 21:33:28 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 16FF84400B2; Mon, 12 Apr 2021 21:33:28 +0200 (CEST)
Date: Mon, 12 Apr 2021 21:33:28 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Tom Herbert <tom@herbertland.com>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Ahmed Abdelsalam (ahabdels)" <ahabdels=40cisco.com@dmarc.ietf.org>, "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" <draft-filsfils-6man-structured-flow-label@ietf.org>
Subject: Re: Limited Domains: (was: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt)
Message-ID: <20210412193328.GK34032@faui48f.informatik.uni-erlangen.de>
References: <BL0PR05MB5316991D4124AD85BC69392AAE709@BL0PR05MB5316.namprd05.prod.outlook.com> <20210412170938.GB34032@faui48f.informatik.uni-erlangen.de> <BL0PR05MB53163BB3383E1DE6CA98D4C3AE709@BL0PR05MB5316.namprd05.prod.outlook.com> <CALx6S35JhJ_+WNpQ10JHB6L2E8MTEaCRO9c6g7rT-2BK3ZnsuA@mail.gmail.com> <20210412184030.GG34032@faui48f.informatik.uni-erlangen.de> <CALx6S34STnDNG0h+nBQXVGgiCsPJmg4=PAy2H-oiHXPncOkJ=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALx6S34STnDNG0h+nBQXVGgiCsPJmg4=PAy2H-oiHXPncOkJ=g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Kp-1qmGo02kgoNnhFkiJAgYI1Js>
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, 12 Apr 2021 19:33:42 -0000

On Mon, Apr 12, 2021 at 12:07:49PM -0700, Tom Herbert wrote:
> Right, SRH is an extension header that works with the existing
> extensibility constructs for IPv6. Fundamentally, I don't understand
> what problem a new encoding would address, perhaps you could
> articulate that (personally, I wouldn't consider a use case where only
> one bit of extensible information is needed as justification to create
> a new version of IP).

See my last email reply with the TLV header encoding example. Of course
this is not justified by a single featurette. See for example also
draft-bryant-arch-fwd-layer-ps. In that one we actually missed out to
discuss the flow ID issues, have to add.

Cheers
    Toerless

> Tom
> 
> 
> 
> > And note that those have been arguably slow because they where/are tied very much to a
> > very HW-centric model and limited flexibility in those forwarders. But this is constantly
> > evolving and improving. The timing and adoption stories are quite different for other
> > technologies such as IP Multicast. But we have all these stories and should have learned from
> > them.
> >
> > But yes, it would be IMHO a lot more prudent to start looking into evolutions that are
> > not solely ad-hoc one-off extensions. If we had a clearer strategy how to evolve long term,
> > the pain of short term workaround would also become more manageable IMHO (and from experience
> > in such past stories).
> >
> > Cheers
> >     Toerless
> >
> > > I suppose the idea might be to have special
> > > value in the next protocol that indicates an extension to the base IP
> > > header, but then doesn't that just degenerate to to be another
> > > extension header?
> > >
> > > Tom
> > >
> > > >                                                                       Ron
> > > >
> > > >
> > > >
> > > > Juniper Business Use Only
> > > >
> > > > -----Original Message-----
> > > > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Toerless Eckert
> > > > Sent: Monday, April 12, 2021 1:10 PM
> > > > To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> > > > Cc: Ahmed Abdelsalam (ahabdels) <ahabdels=40cisco.com@dmarc.ietf.org>; 6man@ietf.org; draft-filsfils-6man-structured-flow-label@ietf.org
> > > > Subject: Re: Limited Domains: (was: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt)
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > On Mon, Apr 12, 2021 at 04:20:22PM +0000, Ron Bonica wrote:
> > > > > 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?
> > > >
> > > > AFAIK, this is not a new issue for this draft, this has been going on forever.
> > > >
> > > > https://urldefense.com/v3/__https://bapk-videos.mamadrum.net/old/IETF-099-Prague-videos/03-joel-jaeggli-8.mp4__;!!NEt6yMaO-gk!R8KfrY_-UU1OFDv1r7zr1dkRVmyApILeyhDlijeT8hQjBvn8FFSlbJ6d77MKy9Os$
> > > >
> > > > IMHO, attempting to harvest more bits from the IPv6 base header for improved functionality is just another wave of this problem space. At some point in time you have to give up on fields/functions that have been burned by bad specs and/or bad implementions and unforeseeable interop issues in uncontrolled network paths. I had the very same experience with router alert, but in that case one could solve the problem by just using a new code point. With flow label being in the base header, this is not possible. Even more so, the IPv6 base header has no notion to support limited domain scoping of functionality.
> > > >
> > > > I can just repeat myself and say that we simply should look into new, more flexible, extensible base header, backward compatible to IPv6/Internet (but with code points assigned to functionality, as we do with extension headers for example). Would be great if more people would be willing to even start collecting issues with the base header so that we could even prepare longer term for something like that. We also overlooked for example this flow-label  issue in draft-bryant-arch-fwd-layer-ps-02
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > > >                                                 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-n29Pk9A
> > > > > RUaOuTV9LL3$
> > > > > --------------------------------------------------------------------
> > > > > --------------------------------------------------------------------
> > > > > IETF IPv6 working group mailing list
> > > > > ipv6@ietf.org
> > > > > Administrative Requests:
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > > > > __;!!NEt6yMaO-gk!R8KfrY_-UU1OFDv1r7zr1dkRVmyApILeyhDlijeT8hQjBvn8FFSlb
> > > > > J6d7wJj-Si3$
> > > > > --------------------------------------------------------------------
> > > >
> > > > --
> > > > ---
> > > > tte@cs.fau.de
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R8KfrY_-UU1OFDv1r7zr1dkRVmyApILeyhDlijeT8hQjBvn8FFSlbJ6d7wJj-Si3$
> > > > --------------------------------------------------------------------
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> >
> > --
> > ---
> > tte@cs.fau.de

-- 
---
tte@cs.fau.de