Comments In-Line..
Thanks,
Jim Uttaro
From: rtgwg <[email protected]> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 12:05 PM
To: Linda Dunbar <[email protected]>
Cc: [email protected]; rtgwg-chairs <[email protected]>; RTGWG
<[email protected]>
Subject: Re: RTGWG feedback on APN next steps
Hi Linda,
APN would not need to be interconnected over an overlay network. The decision
which underlay path to use could be still computed in run time and selection
made by the application provided sufficient path diversity is exposed.
Technically it could be realized by exposing two next hops on the same subnet
app hosts sits on for each disjoined flow/session.
With v6 and multiple addresses things are much easier :)
Such diversity can be as simple as using at least two upstream ISPs and letting
the application choose which way to fwd the packets. I am using such model
myself for over two years and it works very well :).
[Jim U>] Many customers do just this..
Of course you could still go much more complex and do use form of OTT for the
application endpoints too but I do not see this as a mandate.
Kind regards,
R.
On Thu, Apr 7, 2022 at 5:56 PM Linda Dunbar
<[email protected]<mailto:[email protected]>> wrote:
Robert,
What you said is basically changing the naming convention:
“APN” is an overlay network that utilizes the information carried by the
network protocols (IGP/BGP/etc.) to intelligently forward application flows
across the network.
Correct?
Linda
From: rtgwg <[email protected]<mailto:[email protected]>> On Behalf
Of Robert Raszuk
Sent: Thursday, April 7, 2022 5:29 AM
To: Jeff Tantsura <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; rtgwg-chairs
<[email protected]<mailto:[email protected]>>; RTGWG
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]>.
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Frtgwg&data=04*7C01*7Clinda.dunbar*40futurewei.com*7Ca86e02bf69d7438e623308da18817a25*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637849241637165414*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=OBTq2hTWBQPNwg3O*2FPTzz*2FG7MoLllJTtYgZSHJKPprI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!BhdT!k6GZ-kNQonAU3Fl9hQMs8ybOa6zBvHXLO73rR-BtELyLhRjEpi1KkkkQp6TcWbI-QiN1nxzo0Oo$>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
