Re: [Apn] Using IPv6 Flow Label for APN [was Re: Fwd: [IAB] IETF 111 reports: APN BOF]

[Toerless Eckert <[e-mail]>]

Some IMHO useful operator opinion about IPv6 flow labels,
and if not, then at least great, subtle entertainment:

   https://bapk-videos.mamadrum.net/old/IETF-099-Prague-videos/03-joel-jaeggli-8.mp4

The humor may be a bit lost on you if you cannot imagine what amount
of pain and time in troubleshooting in a large data center went 
into even figuring out what happened and then matching up with what the RFCs say.

Given my personal lack of similar experience with IPv6 flow label,
i will not voice an opinion here for myself, but if you listen to
6man recordings you will know i had what i would call very similar
experiences with router alert - bad specs, bad implementations,
bad interop in deployments.

IMHO: sometimes it is more prudent to leave the past behind, even if
you need to rebuild it (i hear BBB is a thing now anyhow).

Cheers
    Toerless

On Mon, Aug 02, 2021 at 10:04:29AM -0700, Bob Hinden wrote:
> Shuping,
> 
> Changing the subject to focus on a new topic.
> 
> > On Aug 2, 2021, at 8:07 AM, Pengshuping (Peng Shuping) <[e-mail]> wrote:
> > 
> > Hi Jari,
> > 
> > Many thanks for the objective capture of the BoF in your report and the constructive suggestions in this report as well as in the chat box.
> > 
> > Just some clarifications on this following point if I may.
> > 
> > "IPv6 flow labels, SFC serviceIDs, SR binding SIDs, etc. are lacking according to the proponents, largely based on argument about them being used in special circumstances (?) Although to me it seemed that any design based on a new APN encapsulation protocol would also be used in the special circumstance of APN being deployed in that particular network. “
> 
> Regarding the IPv6 flow label, I don’t think the analysis presented was correct.  It describe one way the Flow label could be used end to end, but not others.  Specifically (see below) it was describing the stateless scenario, not the stateful scenario.
> 
> I went back and reread RFC 6437 that defines the IPv6 Flow label, the text there sound very similar to what APN wants to do.  Specifically from the Introduction:
> 
>   Traditionally, flow classifiers have been based on the 5-tuple of the
>   source address, destination address, source port, destination port,
>   and the transport protocol type.  However, some of these fields may
>   be unavailable due to either fragmentation or encryption, or locating
>   them past a chain of IPv6 extension headers may be inefficient.
>   Additionally, if classifiers depend only on IP-layer headers, later
>   introduction of alternative transport-layer protocols will be easier.
> 
>   The usage of the 3-tuple of the Flow Label, Source Address, and
>   Destination Address fields enables efficient IPv6 flow
>   classification, where only IPv6 main header fields in fixed positions
>   are used.
> 
>   The flow label could be used in both stateless and stateful
>   scenarios.  A stateless scenario is one where any node that processes
>   the flow label in any way does not need to store any information
>   about a flow before or after a packet has been processed.  A stateful
>   scenario is one where a node that processes the flow label value
>   needs to store information about the flow, including the flow label
>   value.  A stateful scenario might also require a signaling mechanism
>   to inform downstream nodes that the flow label is being used in a
>   certain way and to establish flow state in the network.  For example,
>   RSVP [RFC2205] and General Internet Signaling Transport (GIST)
>   [RFC5971] can signal flow label values.
> 
> The “stateful scenario” reads to me very similar what APN wants to do.   Especially since a tunnel is created to cross the APN domain, the encapsulating node has complete control of what goes in the flow label.   Also seems like the flow label along with judicious use of the traffic class field would allow a significant amount of differentiation of traffic.
> 
> This would have a big benefit of not needing any new packet headers and identification identifiers standards, and should meet most of the goals of APN.
> 
> Bob
> 
> 
> 
>