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

[Mark Smith <[e-mail]>]

Hi Ron,

On Tue, 13 Apr 2021 at 02:22, Ron Bonica
<rbonica=[e-mail]> 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?

No, no single IPv6 protocol anymore. There would now be multiple
variants or dialects, similar to spoken and written human languages
like English.

I fear that the worst case use of "limited domains" will be for a
vendor to define their own proprietary version of standard protocols,
and then trick customers into buying them by obscuring that, and then
the customer is locked into continuing to have to buy the proprietary
"limited domain" version only available from that vendor.

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

If multiple, semantically different versions, variants, or field
structures of IPv6 are going to be created, the version number or
sub-version needs to be encoded in the packet somehow so that
receivers can distinguish the version or variant it to know how it is
to be processed.

What draft-filsfils-6man-structured-flow-label is really doing is
taking 4 bits from the flow label field and defining a completely new
field in the 26 year old, now full Internet Standard, IPv6 fixed
header, without changing the protocol version to indicate a new header
structure.

You can tell it is a new and unrelated field because it is not
required to be set or processed as flow related information:

"FLC semantics (hence, per-packet marking, potentially not per-flow constant)"

and

"FLC: 4-bit "[19, 16]": per-packet Control not included in ECMP hash".

Including the term "Flow Label" in the FLC field name is
misrepresenting what its purpose is. If those bits were available
because they were reserved, then I'd guess the authors wouldn't have
included the term "Flow Label" in the field name at all, instead would
have called it something like the "Generic Application Mark" field.


Regards,
Mark.



>                                                 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-n29Pk9ARUaOuTV9LL3$
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------