Re: [IPv6] 6MAN: looking for feedback to draft-eckert-6man-qos-exthdr-discuss (Re: New Version Notification for ...)

[Toerless Eckert <[e-mail]>]

On Wed, Mar 06, 2024 at 01:10:06PM -0800, Tom Herbert wrote:
> > If my packet has e.g.: my new QoS HBH header mandatory, a router not
> > supporting that HBH header
> > will discaard it.
> 
> I don't believe that's feasible, with RFC8200 even HBH Options is not
> mandatory to process. A router can forward a packet just by inspecting IPv6
> header with no regard as to what the next header is.

The Option Type identifiers are internally encoded such that their
highest-order 2 bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.
      01 - discard the packet.
      10 - discard the packet and ..
      11 - discard the packet and ..

What am i overlooking ?

Cheers
    Toerless
> 
> Tom
> 
> 
> 
> 
> So it does not matter what tht router would have done with the flow label.
> > And when the router adds support for that QoS HBH header, then the spec
> > for that HBH header
> > could say: ROUTER MUST NOT PERFORM WHATEVER  FLOW-LABEL PROCESSING IT
> > THOUGHT WAS RIGHT, but only
> > what the spec for that HBH header says.
> >
> > Stds wise this would mean the HBH header is an update to RFC8200 given how
> > i don't think we have
> > a more current spec for it.
> >
> > True/False/Thoughts ?
> >
> > > > > > The goal of the extension header i am proposing does include the
> > feature to allow failure of
> > > > > > QoS experiments, even those we may have worked to standardize (as
> > opposed to experimental, informational etc..).
> > > > >
> > > > > Why limit it to QoS?  Why not make it a general “host to network
> > signalling” capability?
> > > >
> > > > Divide and conquer.
> > >
> > > I think of host to network signaling as being a signal carrier and
> > > signal content. Logically, what we want is one common carrier that can
> > > carry different types of signals for different purposes. FAST is a
> > > proposal for such a common carrier. It defines one new HBH option type
> > > and has a base header format that includes a type field that describes
> > > the format of the rest of the option contents (i.e. the signal
> > > content).
> >
> > Sure, but that point does not address the issue i mentioned in that i
> > would not want to enable
> > FAST processing on P nodes, because its for example to complex, so enable
> > it only on PE nodes, but
> > the QoS functions i do want to enable on P nodes. Hence it seems i'd have
> > a lot more complexity
> > to manage if both where in the same HBH.
> >
> > > > But one of the results of having gained gaining experience is that
> > some options may have been burned now,
> > > > and may need to be redefined to serve their purpose best. Such as for
> > example if we want to add flow label
> > > > to IPv4, i think we're not at the stage of knowing a single target
> > semantic, but we know that multiple
> > > > semantics would conflict. So at best IMHO if we where to introduce
> > flow label into IPv4, then it should
> > > > have an additional multiplexer. But that would then create a better
> > IPv4 solution than IPv6. Aka: i'd rather
> > > > only do that after we have an IPv6 extension header for QoS that
> > provides the same or superset function.
> > >
> > > Agreed. This is the point of draft-herbert-ipv4-eh. The goal is to
> > > backport features like EH and flow label into IPv4, not to improve
> > > upon them. If we make such features work better in IPv4 than IPv6 then
> > > that makes transitioning to IPv6 more difficult which is really the
> > > ultimate goal.
> >
> > Its just that we don't have a working interoperable Internet scope
> > solution for Flow Label in IPv6,
> > but at best working experiements in well controlled networks such as this
> > CERN experiment. And that
> > should mean something for what we write about it in your IPv4 extension
> > header doc.
> >
> > > > Not 100% sure, but i think the risk of functional collision for Flow
> > Label is smaller for packets with
> > > > a new mandatory to support extension header. Therefore it might be
> > possible to assign new semantics
> > > > to the Flow Label for packets with such extension headers without
> > creating deployment clasehes
> > > > (to avoid wasting the 20 bits).
> > >
> > > That would be really difficult, there are two many devices that have
> > > already burned in semantics of flow label. Besides, if interpreting
> >
> > Well... how would those devices work in a network using the CERN method ?
> > Aka: any hard-burned
> > semantics is a problem anyhow, especially because we as IETF wouldn't know
> > for a standards track
> > document like yous (AFAIK) be able to specify that functionality.
> >
> > But we can always override semantic for "new packets". Thats for example
> > what we did for IPv4 Multicast. Those where packets with previously
> > unassigned addresses, and
> > when those are used, the whole semantic of forwarding changes for the
> > packet and the
> > interpretation of destination address. Likewise do i see no reason to now
> > think along the same
> > ways when i add a HBH header and hence change the meaning of flow-label
> > for those fields.
> >
> > > the flow label correctly requires an EH, why not just put the
> > > information in the EH and avoid touching the flow label?
> >
> > Sure. Is it worth the trouble saving 20 bits... ?
> > But i see it differently: I always liked the idea of flow-label, so i'd
> > hate for an unusable
> > header to lay around in our base header in IPv6, and should your work
> > progress equally in IPv4.
> > It's ugly! ;-) So lets figure out how we could make best use of it...
> >
> > Cheers
> >     Toerless
> >
> > > Tom
> > >
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > >
> > > > > Tim
> > > > >
> > > > > > Cheers
> > > > > >    Toerless
> > > > > >
> > > > > > On Tue, Mar 05, 2024 at 10:31:09AM -0800, Tom Herbert wrote:
> > > > > >> On Tue, Mar 5, 2024 at 6:41 AM Tim Chown
> > > > > >> <Tim.Chown=[e-mail]> wrote:
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> On 4 Mar 2024, at 23:02, Tom Herbert <tom=
> > [e-mail]> wrote:
> > > > > >>>
> > > > > >>> On Mon, Mar 4, 2024 at 12:37 PM Toerless Eckert <[e-mail]>
> > wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Dear 6MAN-WG:
> > > > > >>>
> > > > > >>> I have just posted an extremely rough draft
> > draft-eckert-6man-qos-exthdr-discuss, to help start a discussion
> > > > > >>> about common IPv6 extension headers for (mostly) stateless QoS
> > beyond what we can do with just DSCP.
> > > > > >>>
> > > > > >>>
> > > > > >>> Hi Toerless,
> > > > > >>>
> > > > > >>> You might want to look at draft-herbert-fast and
> > > > > >>> draft-herbert-host2netsig. It looks like these have similar
> > goals.
> > > > > >>>
> > > > > >>>
> > > > > >>> And that is similar in spirit to what the CERN experiments are
> > doing with flow label semantics, which would/could be HbH header
> > information if then insertion penalty were not so high.
> > > > > >>
> > > > > >> Hi Tim,
> > > > > >>
> > > > > >> The CERN experiment might be okay as an experiment, but
> > overloading
> > > > > >> the twenty bit information of flow label is neither scalable nor
> > > > > >> standardizable. This is especially true for those proposals that
> > want
> > > > > >> to set some bits differently within the same flow and expect that
> > > > > >> routers will ignore those bits for ECMP hash.
> > > > > >>
> > > > > >> I am interested in what you mean by " if then insertion penalty
> > were
> > > > > >> not so high".
> > > > > >>
> > > > > >> Tom
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>>
> > https://www.ietf.org/archive/id/draft-cc-v6ops-wlcg-flow-label-marking-02.html
> > > > > >>>
> > > > > >>> And there are others, each doing something slightly different,
> > when we’d ideally have one EH to rule them all.
> > > > > >>>
> > > > > >>> Tim
> > > > > >>>
> > > > > >>>
> > > > > >>> Right now this is a discussion draft not intended to become RFC
> > because it's my impression that the
> > > > > >>> 6MAN community might benefit from some useful summary of how
> > DetNet (and potentially other WGs) might
> > > > > >>> use this work, but this would not be part of a final spec draft,
> > and likewise i have a wide range of
> > > > > >>> open questions instead of answers, and i included those
> > questions into the draft seeking for feedback from
> > > > > >>> 6MAN.
> > > > > >>>
> > > > > >>> Overall, i didn't want to go down a possible rabbit hole of
> > working on details of the spec if it just
> > > > > >>> turns out to involve insurmountable IETF process obtacles to go
> > this route. For example, we could continue to
> > > > > >>> standardize all advanced forwarding functions only into MPLS and
> > ignore IPv6 as DetNet has done so far
> > > > > >>> (*mumble ;-).
> > > > > >>>
> > > > > >>> The lack of such extension headers has IMHO held back innovation
> > into better (stateless) QoS, especially
> > > > > >>> in many controlled networks since at least 25 years, for example
> > when draft-stoica-diffserv-dps
> > > > > >>> was abandomed because it was too painfull trying to get to
> > through all the IETF IPv6 bureaucracy -
> > > > > >>> for just one algorithm, when there are so many that would
> > deserve experimentation in specific
> > > > > >>> networks. But given the good recent/ongoing work for example
> > into  I-D.ietf-6man-hbh-processing,
> > > > > >>> i would hope that we're closer now to actually wanting our
> > extensibility of IPv6 actually be used
> > > > > >>> by the industry (instead of all this happening only in MPLS).
> > > > > >>>
> > > > > >>> With DetNet we are too in the situation that we have multiple
> > candidates on the table and IMHO
> > > > > >>> it will not be very useufl trying to run a lottery for a single
> > "winner" and standardize just that.
> > > > > >>>
> > > > > >>> I have seen a lot more success in the industry by just letting
> > different algorithms compete with
> > > > > >>> each othrer in products and let the market decide. That was
> > quite a lot happening in e.g.: packet
> > > > > >>> scheduling in routers at least since the end of the 90th when in
> > my impression every new
> > > > > >>> hardware forwarding router implemented it's own new packet
> > scheduler based on the just hired lead
> > > > > >>> engineers PhD thesis. And over a period of 20 years, a lot of
> > commonality and industry
> > > > > >>> knowledge evolved in that space. For this type of scheduling,
> > this innovation was possible because it did not
> > > > > >>> require new packet headers, but just a lot of (ab)use of DSCP
> > and/or more or less horrenduous
> > > > > >>> QoS configurations. But for those solutions that do require
> > additional in-packet-QoS metadata,
> > > > > >>> we never created a viable method where it was easy for the
> > innovators/implementers to concentrate
> > > > > >>> on the novelties of the algorithm in question and get all the
> > knucklehead "how to packetize and what generic
> > > > > >>> requirements/functionalities" be provided as much as possible by
> > an existing framework/RFC.
> > > > > >>>
> > > > > >>> So, i'd be very happy to find interest to help progress this
> > work, aka: writing something
> > > > > >>> that ultimately would become a draft-ietf-6man-common-qos-exthr
> > or the like. I have tentatively
> > > > > >>> asked for a slot for IETF119 6MAN to present and get feedback,
> > if you think that would be time well
> > > > > >>> spent, pls. chime in.
> > > > > >>>
> > > > > >>> Cheers
> > > > > >>>   Toerless, for the authors
> > > > > >>>
> > > > > >>> On Mon, Mar 04, 2024 at 12:30:53PM -0800,
> > [e-mail] wrote:
> > > > > >>>
> > > > > >>> A new version of Internet-Draft
> > draft-eckert-6man-qos-exthdr-discuss-00.txt
> > > > > >>> has been successfully submitted by Toerless Eckert and posted to
> > the
> > > > > >>> IETF repository.
> > > > > >>>
> > > > > >>> Name:     draft-eckert-6man-qos-exthdr-discuss
> > > > > >>> Revision: 00
> > > > > >>> Title:    Considerations for common QoS IPv6 extension header(s)
> > > > > >>> Date:     2024-03-04
> > > > > >>> Group:    Individual Submission
> > > > > >>> Pages:    27
> > > > > >>> URL:
> > https://www.ietf.org/archive/id/draft-eckert-6man-qos-exthdr-discuss-00.txt
> > > > > >>> Status:
> > https://datatracker.ietf.org/doc/draft-eckert-6man-qos-exthdr-discuss/
> > > > > >>> HTMLized:
> > https://datatracker.ietf.org/doc/html/draft-eckert-6man-qos-exthdr-discuss
> > > > > >>>
> > > > > >>>
> > > > > >>> Abstract:
> > > > > >>>
> > > > > >>>  This document is written to start a discussion and collect
> > opinions
> > > > > >>>  and ansers to questions raised in this document on the issue of
> > > > > >>>  defining IPv6 extension headers for DETNET-WG functionality with
> > > > > >>>  IPv6.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> The IETF Secretariat
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > --------------------------------------------------------------------
> > > > > >>> IETF IPv6 working group mailing list
> > > > > >>> [e-mail]
> > > > > >>> Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > > > > >>>
> > --------------------------------------------------------------------
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > --------------------------------------------------------------------
> > > > > >>> IETF IPv6 working group mailing list
> > > > > >>> [e-mail]
> > > > > >>> Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > > > > >>>
> > --------------------------------------------------------------------
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > ---
> > > > > > [e-mail]
> > > > >
> > > >
> > > > --
> > > > ---
> > > > [e-mail]
> > >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]