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

[Ron Bonica <[e-mail]>]

Toerless,

You 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)."

The idea is intriguing, but it leads to the following questions:

- How do you make this new base header backwards compatible with IPv6-classic?
- Is draft-filsfils-6man-structured-flow-label an example of this new base header?

                                                                      Ron



Juniper Business Use Only

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Toerless Eckert
Sent: Monday, April 12, 2021 1:10 PM
To: Ron Bonica <rbonica=[e-mail]>
Cc: Ahmed Abdelsalam (ahabdels) <ahabdels=[e-mail]>; [e-mail]; [e-mail]
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 <[e-mail]> On Behalf Of Ahmed Abdelsalam 
> (ahabdels)
> Sent: Monday, April 12, 2021 12:02 PM
> To: Brian E Carpenter <[e-mail]>; [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]>
> Date: Thursday, 8 April 2021 at 04:19
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" 
> <[e-mail]>
> Subject: Re: I-D Action: 
> draft-filsfils-6man-structured-flow-label-00.txt
> Resent from: <[e-mail]>
> Resent to: <[e-mail]>, ahabdels <[e-mail]>, 
> <[e-mail]>, <[e-mail]>, 
> <[e-mail]>, <[e-mail]>, 
> <[e-mail]> 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, [e-mail] 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
>     > [e-mail]
>     > 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
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!UKtsY4bMjBYvdfHQZ3fbIfkDpi1BjJTpG15KUpg06Bgvp-n29Pk9A
> RUaOuTV9LL3$
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!R8KfrY_-UU1OFDv1r7zr1dkRVmyApILeyhDlijeT8hQjBvn8FFSlb
> J6d7wJj-Si3$
> --------------------------------------------------------------------

--
---
[e-mail]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R8KfrY_-UU1OFDv1r7zr1dkRVmyApILeyhDlijeT8hQjBvn8FFSlbJ6d7wJj-Si3$
--------------------------------------------------------------------