Re: RE: RTGWG feedback on APN next steps

Hi Robert, UTTARO

    I agree that we should be careful. 

    But IMO, in APN, not all the traffic will be marked that much information, and only the specific traffic that needs the specific treatment will be marked.

    There should be some usecases that marking in the packet can be more efficient. Not all the clients are interested in choosing route.

Best Regards
Zongpeng Du

duzongpeng@foxmail.com & duzongpeng@chinamobile.com

From: UTTARO, JAMES
Date: 2022-04-08 00:45
To: Robert Raszuk; Jeff Tantsura
CC: rtg-ads@ietf.org; rtgwg-chairs; RTGWG
Subject: RE: RTGWG feedback on APN next steps
+1

From: rtgwg <rtgwg-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 6:29 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: rtg-ads@ietf.org; rtgwg-chairs <rtgwg-chairs@ietf.org>rg>; RTGWG <rtgwg@ietf.org>
Subject: Re: RTGWG feedback on APN next steps

All,

I believe that we should be very careful here. 

Adding more application awareness to the network layer means more state more complexity and much higher network cost (both OPEX and CAPEX). It also means in vast majority of cases more overhead for packets. 

The moment you cross network domain boundary it all breaks as this is purely unrealistic to synchronize how application A should be treated across N domains. 

IMO we should actually go in complete opposite direction. Instead of loading networks with application awareness let application to choose end to end path by themselves which meet their requirements. 

Keeping network primitive to allow basic IP forwarding while exposing different paths application packets may take will not only be much more scalable but will also allow application to adjust and tune its logic or buffering (which btw is already happening today anyway) to the actual needs. 

Some of this exposure is already taking place today. But there is still room for improvement. 

And let's keep it in mind that current networks both open as well as internal do struggle to offer end to end 8 classes of basic QoS. 

Thinking that bunch of IETF drafts or RFCs will suddenly allow it to properly handle lot's of Application_IDs or Slice_IDs seems to me like a wish (at best). 

Regards,
Robert

On Tue, Apr 5, 2022 at 7:15 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
Dear RTGWG,

APN has been presented at RTGWG multiple times, and we see the evolution of the
documents, including the scope of the problem and framework.  This topic needs
collaboration across WGs; we can foresee that not all issues to be addressed are
within the charter of RTGWG and would span beyond the Routing area.

RTGWG is chartered to provide a venue for new work, there are a couple of different options and one option for handling
such new work would be to recommend the development of a new WG.  
The Chairs would then want to recommend that the ADs consider forming a focus WG, with a set of well defined deliverables and milestones (after delivery the group would be shut down) to work on a framework for APN.

We would like to solicit the WG for opinions.  Please note that comments about
existing APN documents should be sent to apn@ietf.org.  This thread focuses on
support or objection to recommending that the ADs consider the formation of a
new WG.

Please send your comments, support, or objectiond.
Thanks!

Cheers,
Yingzhen  Jeff

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg