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

[Bob Hinden <[e-mail]>]

Jeffery,

> On Aug 3, 2021, at 10:08 AM, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
> 
> Hi Bob,
> 
>> 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.
> 
> Completely agree with the above.
> Even if somehow Flow Label is concluded to be not appropriate for what APN wants to do, there are other ways to encode an opaque number - an MPLS label (not just the entropy label as Tarek pointed out during the BoF) or part of the IPv6 address (e.g. the func/arg bits after the locator). There was even a suggestion (in another context for another purpose) to encode the VPN identifier into the source address (I am mentioning this just to show that there are lots of ways to make use of existing forwarding plane).
> 
> I also want to take this opportunity to reconfirm if we are indeed agreeing on an opaque number - instead of defining a structure for the APN attribute (I had explained in BoF and other emails why I don't think we should define structured fields for it).

I think there are tradeoff.   If the attribute is stateful is can be done either way.   Structured allows for less state in the nodes enforcing policy but less attributes, unstructured probably means a lot more possible possible attribute values at the cost of more state in the nodes enforcing policy.

I tend to lean toward unstructured, but it depends on how many concurrent APN attributes are needed.

Bob


> 
> And for the size of the opaque number - I remember that during the RtgWG interim meeting for APN the scaling concern was brought up and the answer was that it is intended for a closed domain so the scaling is not a concern. From that I take it that the opaque number does not have to be large.
> 
> Jeffrey
> 
> -----Original Message-----
> From: Apn <[e-mail]> On Behalf Of Bob Hinden
> Sent: Monday, August 2, 2021 1:04 PM
> To: Pengshuping (Peng Shuping) <[e-mail]>
> Cc: Jari Arkko <[e-mail]>; Bob Hinden <[e-mail]>; apn <[e-mail]>
> Subject: [Apn] Using IPv6 Flow Label for APN [was Re: Fwd: [IAB] IETF 111 reports: APN BOF]
> 
> [External Email. Be cautious of content]
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> Juniper Business Use Only