Re: [Apn] Problem statement

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

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]

发件人：Joel Halpern <[e-mail]>
收件人：Pengshuping (Peng Shuping) <[e-mail]>
抄 送：apn <[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