Re: Limited Domains:

[Toerless Eckert <[e-mail]>]

Can i get a standard RFC for another idea, in which
one does not overload the flow-ID, but instead source and destination
addresss ? In isolated limited domains, i do not need all those
long 128 bit addresses, but i appreciate the benefit of having the
IPv6 socket API in every OS, so i can read/write very easily those
addresses. And the basic IPv6 forwarding code in every router i want
tominimally modify.

For example, i could just use 32 bit IPv4 or even shorter
(16 bit) addresses and then use the rest of the IPv6 header address
bits for my isolated networks requirements and hosts and routers hop-by-hop
can use those bits, every isolated network could come up with
different desired semantics. I for once would love to put exactly
all those ethernet header fields required for TSN QoS into them,
so i have a 1:1 mapping of TSN into (abused) "IPv6" (TSN in IPv6).

Now, if you think this is too hilarious and the IMHO correct answer
should be "Great, toerless, but you are too late for Aprils Fools RFC",
lets remember that its not too far off from other address overload proposals
we did have in the IETF.

IMHO, i don't think you can just keep the encoding and overload
the semantic of a packet header in semantically incompatible fashions and NOT
call it a new protocol. 

Of course all the existing infra especially host stacks but also
router code creates a strong pressure to do just minimal changes in
places that are expensive/slow to change, but instead of sliding down 
this dangerous overload lane, why not recognize this generic problem and take the
hit once more of doing a larger change (new extensible, semantically
backward compatible base protocol header) to have clean options in
the future to do minimal enhancements where needed (aka: add new
TLV in my past example).

This is barly the only place. Just look at ECN semantics for L4S. Hard
trying to avoid semantic overload because all they can do is to fudge
around existing IPv6 header bits.


Cheers
    oerless

On Tue, Apr 13, 2021 at 09:46:46AM -0700, Tom Herbert wrote:
> On Tue, Apr 13, 2021 at 9:18 AM Ahmed Abdelsalam (ahabdels)
> <[e-mail]> wrote:
> >
> > Hi Nick,
> > Please find my answers inline [AA]
> >
> > ???-----Original Message-----
> > From: Nick Hilliard <[e-mail]>
> > Date: Tuesday, 13 April 2021 at 11:58
> > To: ahabdels <[e-mail]>
> > Cc: Tom Herbert <[e-mail]>, Brian E Carpenter <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> > Subject: Re: Limited Domains:
> >
> >     Ahmed Abdelsalam (ahabdels) wrote on 13/04/2021 09:59:
> >     > [AA] I don't think we need a new codepoint.
> >     > The operator explicitly configures the routers under his
> >     > administrative domain to support Structured Flow Label.
> >
> >     a codepoint is a marker to cause something to be interpreted in a
> >     specific and different way.  Moving this flag to the configuration
> >     domain is essentially admitting that the semantics of a codepoint are
> >     necessary, except that it removes the possibility of having these
> >     semantics interpreted automatically on a per-packet basis, and turns it
> >     into a per-router or possibly per-interface flag.  This is an unusual
> >     type of regression in terms of a protocol where so much work has been
> >     put into auto-configuration, and where the syntactic mechanism has been
> >     created for protocol extensions.
> > [AA] This is a domain wide config applied to all nodes of the domain. So either you decide to do on all routers or not. It doesn???t on per packet treatment.
> >
> Ahmed,
> 
> So this is all or nothing then, replete with a so-called "flag day".
> What is the protocol that guarantees that every router in the domain
> is properly configured, that no one ever inadvertently brings up a
> router without proper configuration? And if configuration fails, which
> even in a moderately sized domain will inevitably happen at some
> point, how will the user detect the issue and debug it?
> 
> Tom
> 
> >
> >     As a separate issue, if a regular ip packet from the outside
> >     accidentally enters into this administrative domain, how does a router
> >     on the inside of the domain know not to attempt to interpret the flow
> >     label as a SFL, as it could end up effectively parsing random junk?
> >
> > [AA] All packet coming from external interfaces will be encapsulated in outer IPv6 header as explained the in section 3. The outer IPv6 is what matters for forwarding inside the domain. If a packet from outside accidentally enters into this administrative domain, then that is a bigger problem than SFL.
> >
> >     Nick
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]