Re: [Apn] Problem statement

["Pengshuping (Peng Shuping)" <[e-mail]>]

Hi all,

After some off-list discussions with people, below please find the text that shows the current problem statement. Your comments and suggestions are welcomed. Thank you!

In a network operator controlled domain, the ingress edge devices usually have access to rich information, such as VLAN/QinQ, VPN ID, and access interface, which is used to classify the packets into fine granular virtual groups of flows at the edge.

However, after the packets enter the network operator’s domain, all such information is not immediately visible at transit nodes: it may be hidden inside encapsulation, masked by encryption, mapped to other protocol fields, or stripped from the packets completely.

Furthermore, many mapping schemes, where they are used, lose some level of granularity from the information available at the network edge. For example, when the information is mapped into small fields like DSCP (6 bits) or MPLS EXP (3 bits) the result is that only relatively coarse grained QoS treatment can be provided. MPLS EXP bits are sometimes insufficient to carry what an operator needs, even the DSCP is really too small.

The packet treatments needed may vary at different parts of the packet’s path within the domain, and enough information is needed to determine these treatments such as steering, triggering, and identifying in an efficient way, that is, to efficiently realize a composite network service provisioning along the path. For example, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies flexibly.

Furthermore, when the packet traversing through multiple technology domains of a single operator, where each domain is controlled independently without a hierarchical controller being deployed and each has its own SLA mechanism, in this case, it is difficult to achieve end-to-end consistency in service provisioning (e.g. visualization) due to lack of information to indicate the granularity of traffic flow across multiple domains. The ACL configuration at the following domains’ edge devices are very complex and dynamic.

Best Regards,
Shuping

From: Apn [mailto:[e-mail]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Wednesday, May 31, 2023 9:49 PM
To: Joel Halpern <[e-mail]>
Cc: apn <[e-mail]>
Subject: Re: [Apn] Problem statement

Hi Joel,

Thank you for reminding me of the difficulties. What you mentioned are what we are trying to do here in the mailing list, getting a clear problem statement and so on.

Best regards,
Shuping



________________________________

彭书萍 Peng Shuping
Mobile: [phone](优先)
Email: [e-mail]<mailto:[e-mail]>
发件人：Joel Halpern <[e-mail]<mailto:[e-mail]>>
收件人：Pengshuping (Peng Shuping) <[e-mail]<mailto:[e-mail]>>
抄 送：apn <[e-mail]<mailto:[e-mail]>>
时 间：2023-05-31 13:58:10
主 题：Re: [Apn] Problem statement


I think there are some important aspects you are not addressing.

WHile it may not reflect the order in which the proponents thought of the work that i snow spring, in convining the IETF to undertake the work and create the workin ggroup, there were two veyr important points that were made.  First and foremost, there was a clear description of the problems with using RSVP-TE, and with LDP (particularly as it related to the IGPs.)  So we had a clear problem statement.

Second, there was a clear description of an architectural change from the existing MPLS approach, that required investigation and clear statement.

Even with those good reasons, the overlap between spring and other working groups often causes difficulties.  It was probably the right call to do it this way, given the above two items.  But it did not come for free.

Yours,

Joel
On 5/31/2023 2:57 AM, Pengshuping (Peng Shuping) wrote:
Hi Joel,

Like SPRING, all the protocol extensions are being done in other working groups, being distributed in the INT and RTG areas actually, but still it needs a place, i.e. the SPRING WG, to define the essential parts which do not suit any other existing work groups.

Best Regards,
Shuping


From: Joel Halpern [mailto:[e-mail]]
Sent: Wednesday, May 31, 2023 4:00 AM
To: Pengshuping (Peng Shuping) <[e-mail]><mailto:[e-mail]>; Ted Hardie <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Apn] Problem statement


Trimmed to focus on one point.

Joel
On 5/30/2023 10:05 PM, Pengshuping (Peng Shuping) wrote:
Hi Ted,

Thank you! Please find in line.

From: Ted Hardie [mailto:[e-mail]]
Sent: Thursday, May 25, 2023 8:21 PM
To: Pengshuping (Peng Shuping) <[e-mail]><mailto:[e-mail]>
Cc: Joel Halpern <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Apn] Problem statement

...
Existing protocols such as SFC/NSH, SR/SRv6, MPLS, VXLAN, and IPv6, can be taken as implementation basis, but in each case the protocol may need extensions.”

If the intent is to avoid a proliferation of standards (https://xkcd.com/927/) by limiting the work of the group to extensions of existing standards, it might be useful to say so directly.  As it stands, this could be read to allow for the creation of yet another approach.

This list also tends to reinforce my concern on the utility of this effort.  I do not yet see in the problem statement any use case that cannot be handled by one of the existing approaches.  It's easy to prefer an ideal approach that has not yet been sullied by deployment and compromise, but the reality is that anything that starts as an ideal to handle all available use cases may have to make all those same compromises again.  As the comic implies, it's easy to go through that time and trouble and just end up with, well, number 15.  I'm not sure that I understand how this effort avoids that fate and the resulting impact on the technical ecosystem.

Shuping> I like the comic. Just here the tunnels are existing technologies in the networking/routing area and they are taken as the ways to carry the information in corresponding network deployment scenarios. In order to carry the new information these existing tunnels need some extensions to be defined, e.g. a new type of TLV.



If there are a number of extensions to existing protocols to address a number of needs, it seems like there are various working groups to address those.  And while we do want to take advantage of commonality and avoid duplication, we do not need to try to define a single extension that can do all the things that have been suggested in thsi effort.

If there is a real need that the existing tools can't easily be extended to address, then we should carefully describe and motivate that.

Yours,

Joel