Subject: [Apn] Fwd: [IAB] IETF 111 reports: APN BOF

From: Jari Arkko <[email-masked]>
Date: Mon, 2 Aug 2021 11:28:30 +0300

IAB members are expected to track and report on BOFs that they visit during the IETF week. Our reports are mostly made for the AD and the IAB and are just for information, but I like to send my reports to the BOF list as well in case it is useful. Of course, what is in this report is just an individual opinion. ADs, the group itself, etc. typically have different views.

Jari

> Begin forwarded message:
> 
> From: Jari Arkko <[email-masked]>
> Subject: [IAB] IETF 111 reports: APN BOF
> 
> The BOF was well run and there was enough information and plenty of time for (IMO, high quality) discussion. Thank you Adrian Farrell, Bob Hinden, and Dan Voyer for running the meeting and allowing the discussion to flow and and making sure everyone got to make their points, including prioritising new people’s comments from the mic. We should probably do that more often.
> 
> Martin Vigoureux, the AD, underlined the need for any standards work in this space to have sufficient diversity of participants and players. He also said the proposal may have started on the wrong foot, but they've changed the approach significantly. Lets give the BOF a fair shot. Similarly, Adrian noted that the effort should not be understood according to the name "application-aware", but rather according to the actual proposals as the evolving function may not match the name any more.
> 
> Zhenbin Li introduced APN. The basic idea is that packets will  be classified on the edge according to their 5-tuples and access ports, and a structured attribute attached to the packet as it is tunneled through the network. Application or user identity  based classification is not in scope. The benefit of APN is that you only do the 5-tuple mapping once, and the rest of the network can operate based on the APN attributes.
> 
> Gyan Mishra talked about why existing mechanisms are insufficient. DSCP markings do not have enough bits. 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. Three other short presentations were also given by Luis Contreras, Chongfeng Xie, and Shuping Peng.
> 
> The main points in discussion revolved around:
> 
> 1/ Whether new technology and tunneling/encapsulation technology is needed, or if existing tools are sufficient.
> 
> 2/ Whether there are issues in distributing a very general information field, rather than a specific and limited information item.
> 
> I'd say there was fairly broadly shared opinion among the chat and mic line participants that these two are issues. We could discuss the details, there are interesting points to dwell into, and certainly no uniform agreement on all details. But maybe the high-level bit is that there are some concerns at least.
> 
> I suggested that maybe a more realistic approach at the IETF would be to write an informational document that explains how to use network edge classification to encode a tag with very few bits, and  how to transport that tag using existing IETF encapsulations. That might reduce both of the above concerns.
> 
> Martin declared the BOF a success in terms of being able to discuss the topic. But he said that there is undeniably a gap that needs to be filled between the proponents and the community. The objective is generally well understood, but there's a question mark why the objective cannot be achieved using existing tools.
> 
>

---

From: David Lake <[email-masked]>
Date: Mon, 2 Aug 2021 13:58:51 +0000

Given the excellent summary, please excuse my hijacking it to make some additional points.

I would very-much have liked to have been able to make the call but it was on a Friday evening at 10pm which clashed with the First Night of the Proms here in London and after 18 months of musical drought as much as I love IETF, the music won…!

Comments <DL> in-line </DL> and I very-much look forward to the on-going work in this group.

David

On 2 Aug 2021, at 09:28, Jari Arkko <[email-masked]<mailto:[email-masked]>> wrote:

Jari

Begin forwarded message:

From: Jari Arkko <[email-masked]<mailto:[email-masked]>>
Subject: [IAB] IETF 111 reports: APN BOF

<DL> If this is the basic idea, then we need to be careful with the term ‘APN’ as it is already used in 4G/5G to accomplish almost exactly the same thing.  In 4G the TFT (Traffic Flow Template) is downloaded to the UE and it essentially ’steers’ the packet into an appropriate APN according to the 5-tuple.

The purpose of the APN is to match numerology (i.e. access parameters) with service level - the APN associated with packets carrying VoIP will be much more robust in terms of modulation scheme than the ‘best-efforts’ APN used for data. APN paths are usually mapped to MPLS queues and DSCP markings at the e/gNB.

Use is also made of RoHC to compress the IP header - air-time is money in 4G/5G so it is important that spectrum is used efficiently.  Personally, I think we would do well to start accounting for the cost of headers in wireline networks as well - every bit takes ££/$$$ to process and we need to minimise that as much as possible.

In 4G the TFT is controlled by the policy set by the PCRF - this is owned by the operator and lives only within the mobile domain.   In 5G, the AF connected to the Service Bus should be able to expose elements of policy to third parties.  It remains to be seen how this will play out.
</DL>

<DL> More ’tunnelling’ concerns me.  There are points on the network where 10 or 11 headers will be applied to data-in-flight.   There are three (inner IP, GTP, outer IP) by default from every mobile device and this is already very inefficient for small-size payloads (e.g. mMTC applications).  I think we should be looking to ensure that the ratio of control-plane:data is always geared towards the part of the packet that carries the value, i.e. the data. </DL>

<DL>  If it is too general, how is it any different from DSCP?

I’m aware that I wasn’t on the call but for me the problem we have not solved is how to ensure my application outcome across multiple domains and therefore the information that we carry must be sufficient for all actors in the delivery-chain to be able to a) validate that I have the right to request (and be supplied) a specific outcome and b) have enough information to be able to construct that outcome.

It is perfectly possible, within a single domain, to have a defined outcome today - VoLTE does this within a single operator where numerology at the RF layer and packet scheduling in the IP network are co-ordinated to permit/deny services based on resource availability.

The issue is that if there are MULTIPLE domains involved, there is no way of defining, requesting or policing an application outcome.

However there is another aspect we need to consider.

In a supply-chain with finite resources, if one actor is given a right to obtain delivery against an SLA, the flip-side is that others may not only have lower service, they may need to be denied service.

We don’t do this at-all today in the Internet (but we do do this on mobile networks, telephone networks and most other transport services, e.g. rail, gas, electricity).

I’m not sure this is fully in the scope of this group, but the data we carry also needs to reflect the entitlement of the application in the same way that if I turn-up with an off-peak ticket to travel into London before 10.00am I will be denied access or offered service based on paying an up-lift.

We talk about the ’network-edge’ being able to classify the traffic but under whose authority and where is that?  As a user, the ’network-edge’ really is my desire to have a particular application outcome - how do I express that to the infrastructure?  </DL>

<DL> I wonder if we need to abstract the problem to another layer?   We do seem to have various network-level tools we could use to provide an ‘APN’ like solution but they don’t appear to work between domains (domains being not just network domains but client and server-side applications and infrastructure).

Are we missing a common language here to describe user-desire?

We are possibly also missing an admission control side to match demand to supply.  </DL>

--
Apn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apn

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 2 Aug 2021 15:07:20 +0000

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. "

The difference is that in a tunnel across multiple domains of the same operator using the APN attribute in the outer header the operator can easily support multiple services not just a single one in a particular domain as illustrated in the usecase slides.

When there is no APN, to achieve the same, now the operator may have two options: 1. Add all the policy identifiers at the tunnel headend with various further encapsulations and enforce the policies based on them at the intermediate policy enforcement nodes along the tunnel, 2. Resolve the original 5 tuples being encapsulated inside the tunnel which will be very costly and sometimes impossible.

Moreover, the policy enforcement table in the intermediate policy enforcement nodes is significantly reduced. Because before operator needs to resolve the 5 tuple but now with APN, operator only needs to read the APN attribute in one field of the outer header.

One more thing is that since the 5 tuples of the traffic are changing frequently due to service deployment or management issues the policy enforcement table in the policy enforcement nodes is not stable and there is always a lot of stale entries in the table. But now since the APN attribute is a mapping of the 5 tuples operator will have a relatively stable policy enforcement table on their nodes.

Thank you!

Best Regards,
Shuping

________________________________

彭书萍 Peng Shuping
Mobile: +86-18210364128<tel:+86-18210364128>(优先)
Email: [email-masked]<mailto:[email-masked]>
发件人：Jari Arkko <[email-masked]>
收件人：apn <[email-masked]>
时 间：2021-08-02 16:29:58
主 题：[Apn] Fwd: [IAB] IETF 111 reports: APN BOF

Jari

Begin forwarded message:

---

From: Bob Hinden <[email-masked]>
Date: Mon, 2 Aug 2021 10:04:29 -0700

Shuping,

Changing the subject to focus on a new topic.

> On Aug 2, 2021, at 8:07 AM, Pengshuping (Peng Shuping) <[email-masked]> wrote:
> 
> Hi Jari,
> 
> "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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 2 Aug 2021 20:54:35 -0400

Hi Shuping

Another comment that I think will help the possible use of IPv6 flow label
for APN.

RFC 6437 does mention that both stateless uniform load balancing and
stateful signaling can be done simultaneously.  I think there is  big
caveat with RFC 6437 as the way it is written as well supporting RFCs RFC
6436, RFC 6438 and RFC 7098, that BFR recommended use of flow label is for
stateless uniform load balancing.  Also not recommend to use for stateless
signaling.  I think the key point here is that even though the draft says
it’s possible to use both stateless and stateful simultaneously in theory,
however the drafts all promote stateless not stateless and in reality using
both simultaneously one would step on or overwrite the other if stateful is
signaled  simultaneously with stateless local context load balancing the
5-tuple per packet flow locally generated would overwrite the signaled
stateful value this will not work.

How the stateless load balancing works is a concept that has been actually
around for decades but it’s based on using a number of keys which are
basically input to generate a random number to create entropy randomness to
be an input key to a hash function for ECMP flow or per session based load
balancing.  This is an identical concept to RFC 7448 VXLAN source port
entropy, MPLS entropy label RFC 6790 and SR entropy label RFC 8662, RFC
6391 FAT PW.  The per packet input keys are based on headers in this case
the typical 5-tuple, SA, DA, SP, DP, protocol to generate a random 20 bit
randomized unsigned integer that can now be an input key to a hashing
function so that all packets that are part of a particular flow can now me
hashed to a particular ECMP path.

I have been researching this concept for quite some time and what I have
found is that most vendors have now gone beyond 5-tuple and now adding more
keys to provide that randomization input key to the vendor proprietary
hashing function  that this is more at the vendor implementation level now
now vendors with custom proprietary ASIC Merchant silicon based or not or
NPU can now profuse this “local context” ECMP load balancing for transport
underlay IPv4 and IPV6 as well and in the case of IPv6 don’t have to rely
on stateless flow label and now the 20 bit  flow label is now wide open and
can be used for anything else the operator decided to signal and in this
case use for APN.

I think for RFC 6437 from vendor community if the uniform load balancing
function can be officially eliminated from RFC 6437 as vendors can do that
and are doing today with their own proprietary algorithms to generate the
local context key to input to the hash function, they don’t need to write
to the 20 bit flow label key and and can store the per packet 5-tuple or
x-tuple hash locally and that would officially free up the 20 bit flow
label to be only used as stateful signaling function.

Kind Regards

Gyan

On Mon, Aug 2, 2021 at 1:04 PM Bob Hinden <[email-masked]> wrote:

> > 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.
> >
> > "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:
>
> 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
>
>
>
>
>
> --
> Apn mailing list
> [email-masked]
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 2 Aug 2021 21:33:58 -0400

Hi Shuping

One caveat I wanted to clarify is that any overlay based technology, where
overlay and underlay exists and for uniform load balancing a separate
entropy label is required as a key to a hashing function for SR & MPLS have
VPN overlay that sits in the payload so 5-tuple per packet hash to identify
the flow in the payload requires a separate entropy label for load
balancing and the same goes for VXLAN source port entropy label for uniform
load balancing as well as  L2 VPN FAT pseudowire.

In order to ECMP load balance the transport layer itself in a case where
there is no overlay such as for IP L3 global table routing scenario, that
is the case where the vendor ASIC can provide the uniform load balancing
via 5-tuple per packet keys and the IPv6 flow label is not necessary for
stateless load balancing and can be dedicated to stateful signaling cases
such as APN.

Kind Regards

Gyan

On Mon, Aug 2, 2021 at 8:54 PM Gyan Mishra <[email-masked]> wrote:

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

*Gyan Mishra*

*M 301 502-1347*

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 3 Aug 2021 07:35:19 +0000

Hi David,

Thank you for your interest and the information shared! BTW, how is Guildford and Surrey? Missing my time working there. ☺

In this following draft, the third case in the section 5 is about the mobile broadband scenario. From the Figure 3, you can find that the APN domain we focused is limited to the Mobile Transport Network. It seems that here you talked more about the mobile network/path between the UE and the GW if I understood it correctly.

https://datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-04

Another point to clarify is that the network edge in APN is owned and controlled by the transport network operator.

At this network edge node of the APN domain, the GTP-u is mapped to a transport network tunnel encapsulation. In your view, what fields in the GTP-u header could be used to construct the APN attribute to be used within the APN domain?

FYI, https://datatracker.ietf.org/wg/apn/documents/

Thank you!

Best regards,
Shuping

From: Apn [mailto:[email-masked]] On Behalf Of David Lake
Sent: Monday, August 2, 2021 9:59 PM
To: [email-masked]
Subject: Re: [Apn] [IAB] IETF 111 reports: APN BOF

David

Jari

Begin forwarded message:

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 3 Aug 2021 08:02:10 +0000

Hi Bob, 

Thank you for sharing this comment here, and you have also expressed it in the Chat box. Thank you! 

I agree with you that the IPv6 Flow Label for ECMP is only one way of using it, but it has turned out to be the most widely deployed usage of the IPv6 flow label, even in the tunnel mode. In order to make the IPv6 Flow Label usable for other things, it seems that we have a lot to do first before we could start reusing it for other purposes. 

I would like to also clarify about the states and the signaling mechanism. 

Regarding the "states" for APN, it does not have to be a per-flow "state". The APN attribute is an indicator at the policy enforcement node for indicating policies to be enforced in the middle of a tunnel. 

The signaling mechanism does not have to be required. The controller could be used to enforce the policies and the corresponding attribute to the devices. How to distribute the APN attribute using the control plane protocols is also a topic to be investigated. 

Thank you! 

Best regards, 
Shuping

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Tuesday, August 3, 2021 1:04 AM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Jari Arkko <[email-masked]>; apn <[email-masked]>
Subject: Using IPv6 Flow Label for APN [was Re: [Apn] Fwd: [IAB] IETF 111 reports: APN BOF]

Shuping,

Bob

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 3 Aug 2021 14:33:06 +0000

Hi Shuping,

> In order to make the IPv6 Flow Label usable for other things, it seems that we have a lot to do first before we could start reusing it for other purposes.

Would it be more work than that of starting a complete new but similar mechanism?

Jeffrey

-----Original Message-----
From: Apn <[email-masked]> On Behalf Of Pengshuping (Peng Shuping)
Sent: Tuesday, August 3, 2021 4:02 AM
To: Bob Hinden <[email-masked]>
Cc: apn <[email-masked]>; Jari Arkko <[email-masked]>
Subject: Re: [Apn] Using IPv6 Flow Label for APN [was Re: Fwd: [IAB] IETF 111 reports: APN BOF]

[External Email. Be cautious of content]

Hi Bob,

Thank you!

Best regards,
Shuping

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]]
Sent: Tuesday, August 3, 2021 1:04 AM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Jari Arkko <[email-masked]>; apn <[email-masked]>
Subject: Using IPv6 Flow Label for APN [was Re: [Apn] Fwd: [IAB] IETF 111 reports: APN BOF]

Shuping,

Bob

--
Apn mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/apn__;!!NEt6yMaO-gk!WrIqZTUTl9O3s5ClWJaGkEn7LsCNDfPVNKPt8WKT5LWLzpqxlmF7rJ55WOoSMAcv$

Juniper Business Use Only

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Aug 2021 09:56:47 -0700

Shuping,

> On Aug 3, 2021, at 1:02 AM, Pengshuping (Peng Shuping) <[email-masked]> wrote:
> 
> Hi Bob,
> 

You are welcome.  I wanted to explain what I said in the jabber chat.

> I agree with you that the IPv6 Flow Label for ECMP is only one way of using it, but it has turned out to be the most widely deployed usage of the IPv6 flow label, even in the tunnel mode. In order…

I disagree on both points.   APN is defined as a single operator domain.  Headers that contains the flow label are tunneled and never leave that domain.   Consequently, using the flow label in the tunneling header in this domain is very controlled.    RFC 6437 allows for stateful use of the IPv6 Flow Label.   This is completely independent of how it would be used End-to-End for stateless operation like ECMP.

APN would using it for one of the purposes it was designed for.

> Regarding the "states" for APN, it does not have to be a per-flow "state". The APN attribute is an indicator at the policy enforcement node for indicating policies to be enforced in the middle of a…

Given the closed operator domain, you can define what is a flow.    Basically a flow label value would indicate packets that want to receive the same treatment (for example "indicating policies to be enforced”).

> The signaling mechanism does not have to be required. The controller could be used to enforce the policies and the corresponding attribute to the devices. How to distribute the APN attribute using…

Of course, but the advantage of using the flow label is that the information you would need to enforce policy would be in the outer IPv6 header, no need to look for it in any extension headers.   Should be simpler and faster.

I agree there would need to be something defined to distribute this state to the appropriate nodes, but I suspect in practice, this isn’t very different from what has been proposed with the APN Identifiers.

Bob

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 3 Aug 2021 17:08:42 +0000

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).

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 <[email-masked]> On Behalf Of Bob Hinden
Sent: Monday, August 2, 2021 1:04 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Jari Arkko <[email-masked]>; Bob Hinden <[email-masked]>; apn <[email-masked]>
Subject: [Apn] Using IPv6 Flow Label for APN [was Re: Fwd: [IAB] IETF 111 reports: APN BOF]

Shuping,

Bob

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Aug 2021 18:22:24 +0100

Just to be clear, the discussion has wobbled a bit. That's OK, but...

The discussion of where to carry the APN attribute in various tunnelling protocols (IPv6, SRv6, MPLS) is an important thing to cover. It was on Shuping's list of work items.

But it may be premature.

We would first need to work out:
- what information is carried in the APN attribute
- how that information is encoded in a generic way

A

-----Original Message-----
From: Apn <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 03 August 2021 18:09
To: Bob Hinden <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>
Cc: apn <[email-masked]>; Jari Arkko <[email-masked]>
Subject: Re: [Apn] Using IPv6 Flow Label for APN [was Re: Fwd: [IAB] IETF 111 reports: APN BOF]

Hi Bob,

Jeffrey

-----Original Message-----
From: Apn <[email-masked]> On Behalf Of Bob Hinden
Sent: Monday, August 2, 2021 1:04 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Jari Arkko <[email-masked]>; Bob Hinden <[email-masked]>; apn <[email-masked]>
Subject: [Apn] Using IPv6 Flow Label for APN [was Re: Fwd: [IAB] IETF 111 reports: APN BOF]

Shuping,

Bob

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Aug 2021 10:37:33 -0700

Jeffery,

> On Aug 3, 2021, at 10:08 AM, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Bob,
> 

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 4 Aug 2021 00:09:50 +0200

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