Re: [Apn] Problem statement

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

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]>; Ted Hardie <[e-mail]>
Cc: [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