Subject: RTGWG feedback on APN next steps

From: Jeff Tantsura <[email-masked]>
Date: Tue, 5 Apr 2022 10:14:55 -0700

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-masked].  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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Apr 2022 13:28:38 -0400

It is not clear to me that there is a well-defined problem or a 
willingness to embrace community process around the APN work.  (Feedback 
suggesting that there are existing approaches to be considered has 
consistently been met with repetitions of the same "new" proposals.)

That said, whether "a focus WG, with a set of well defined deliverables 
and milestones" would be a good idea or not depends in large part on 
what the terms are for the WG.  I can imagine cases which, while I might 
think them less than useful, would not be harmful and might be helpful. 
  I can equally imagine terms from the same premise that would be 
unacceptable.

Yours,
Joel

On 4/5/2022 1:14 PM, Jeff Tantsura wrote:
> RTGWG is chartered to provide a venue for new work, there are a couple 
> of different options and one option for handling
> 
> 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.
> 
> existing APN documents should be sent to [email-masked] 
> <mailto:[email-masked]>.  This thread focuses on
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Feng Yang" <[email-masked]>
Date: Wed, 6 Apr 2022 20:45:32 +0800

Hi folks, 

After so many rounds of clarifications and a lot of work, now APN has a very clear scope as well as problem statement. We also have an use case draft of APN. 

We support the suggestion to have this APN focused WG and we would like to join the work on the APN framework. 

BR，

Feng Yang

发件人: rtgwg [mailto:[email-masked]] 代表 Jeff Tantsura
发送时间: 2022年4月6日 01:15
收件人: RTGWG; rtgwg-chairs; [email-masked]
主题: RTGWG feedback on APN next steps

Dear RTGWG,

new WG.

Thanks!

Cheers,

Yingzhen  Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 6 Apr 2022 09:48:28 -0400

Dear RTGWG

After the BOF and many rounds of review of APN, we  have from each round
have clarified the scope of APN as well as resolution of all outstanding
issues from the BOF.  Any outstanding issues not closed out that still
exist, we would like to openly address and make part of the defined
deliverables.

We would like to continue the work as we have received positive feedback
and interest from the IETF community.

Many thanks to the RTGWG to provide a venue for APN for discussions.

As the APN work spans beyond the RTGWG charter to 6MAN, SPRING, BESS, IDR,
PCE  and possibly other WGs, I support the chairs recommendations on
forming a limited lifetime Focus WG for APN work with a set of defined
deliverables and milestones.

We would like to work with the RTGWG WG to solicit feedback on APN  in
building the set of defined deliverables and milestones.

Thank you

Gyan

On Wed, Apr 6, 2022 at 8:45 AM Feng Yang <[email-masked]> wrote:

> Hi folks,
>
>
>
> After so many rounds of clarifications and a lot of work, now APN has a
> very clear scope as well as problem statement. We also have an use case
> draft of APN.
>
> *发件人:* rtgwg [mailto:[email-masked]] *代表 *Jeff Tantsura
> *发送时间:* 2022年4月6日 01:15
> *收件人:* RTGWG; rtgwg-chairs; [email-masked]
> *主题:* RTGWG feedback on APN next steps
>
>
>
> Dear RTGWG,
>
>
>
>
>
> RTGWG is chartered to provide a venue for new work, there are a couple of
> different options and one option for handling
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 6 Apr 2022 22:28:39 +0800

Hi WG，

I have been interested in the APN work and It has made the remarkable progress such as problem statement, scope and the analysis work due to the extensive contribution.

So I support the formation of a new WG of APN, which could really help to handle the work such as framework. 

Regards,
Peng

[email-masked]
 
From: Jeff Tantsura
Date: 2022-04-06 01:14
To: RTGWG; rtgwg-chairs; [email-masked]
Subject: RTGWG feedback on APN next steps
Dear RTGWG,

 

Cheers,
Yingzhen  Jeff

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Apr 2022 18:41:10 -0400

Hi,

I think that the APN scope has been sufficiently clarified and bounded and
that there are enough people interested and willing to work on it that the
formation of a WG is justified.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: strong <[email-masked]>
Date: Thu, 7 Apr 2022 10:54:03 +0800

Hi WGs,

It’s  great to have this focus WG for APN. We have tried some use cases, and we would like to do more under the  APN framework.

Thanks!

Yours sincerely
ZhuangZhuang

发件人: rtgwg <[email-masked]> 代表 Jeff Tantsura <[email-masked]>
日期: 2022年4月6日 星期三 上午1:14
收件人: RTGWG <[email-masked]>, rtgwg-chairs <[email-masked]>, "[email-masked]" <[email-masked]>
主题: RTGWG feedback on APN next steps

Dear RTGWG,

We would like to solicit the WG for opinions.  Please note that comments about
existing APN documents should be sent to [email-masked]<mailto:[email-masked]>.  This thread focuses on
support or objection to recommending that the ADs consider the formation of a
new WG.

Cheers,
Yingzhen  Jeff

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: 鱼亚锋 <[email-masked]>
Date: Thu, 7 Apr 2022 17:15:18 +0800

Hi WGs，

I support the creation of this APN focus group. We have clear use cases 
on APN especially for traffic steering and performance measurement. It 
will be great to have this working group focusing on APN framework.

Yafeng Yu
China Construction Bank

-------- 原始邮件 --------

日期: 2022-04-06 01:14
> 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.
>

---

From: Stefano Previdi IETF <[email-masked]>
Date: Thu, 7 Apr 2022 11:58:22 +0200

Hi,

I support the creation of an APN focused working group. The problem statement, requirements and framework have been properly documented and there’s a good consensus in the industry that this topic needs to be worked out. A dedicated WG seems, to me, as the best approach.

Thanks.
s.

> On Apr 5, 2022, at 7:14 PM, Jeff Tantsura <[email-masked]> wrote:
> 
> Dear RTGWG,
>  
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 12:28:48 +0200

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

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 7 Apr 2022 15:56:13 +0000

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-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 5:29 AM
To: Jeff Tantsura <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: RTGWG feedback on APN next steps

All,

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-masked]<mailto:[email-masked]>> wrote:
Dear RTGWG,

Cheers,
Yingzhen  Jeff

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<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>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 7 Apr 2022 15:59:04 +0000

I think APN scope is clear and deserve a dedicated focus group.

Linda

From: Linda Dunbar
Sent: Thursday, April 7, 2022 10:56 AM
To: Robert Raszuk <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; RTGWG <[email-masked]>
Subject: RE: RTGWG feedback on APN next steps

Robert,

Linda

From: rtgwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 5:29 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; rtgwg-chairs <[email-masked]<mailto:[email-masked]>>; RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: Re: RTGWG feedback on APN next steps

All,

Regards,
Robert

Cheers,
Yingzhen  Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 18:04:59 +0200

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 :).

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-masked]>
wrote:

> “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-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Thursday, April 7, 2022 5:29 AM
> *To:* Jeff Tantsura <[email-masked]>
> *Cc:* [email-masked]; rtgwg-chairs <[email-masked]>; RTGWG <
> [email-masked]>
> *Subject:* Re: RTGWG feedback on APN next steps
>
>
>
> All,
>
>
>
> <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>
>
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 7 Apr 2022 16:35:26 +0000

Hi All,
I support the creation of a focus WG for APN. The APN scope has been properly clarified and bounded. The multiple discussions on APN have also showed enough interest from the IETF community to work on it.

Regards,

Giuseppe

From: rtgwg <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Tuesday, April 5, 2022 7:15 PM
To: RTGWG <[email-masked]>; rtgwg-chairs <[email-masked]>; [email-masked]
Subject: RTGWG feedback on APN next steps

Dear RTGWG,

Cheers,
Yingzhen  Jeff

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 7 Apr 2022 16:44:41 +0000

Comments In-Line..

Thanks,
            Jim Uttaro

From: rtgwg <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 12:05 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; RTGWG <[email-masked]>
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.

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-masked]<mailto:[email-masked]>> 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

All,

Regards,
Robert

Cheers,
Yingzhen  Jeff

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
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$>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 7 Apr 2022 16:45:50 +0000

+1

Sent: Thursday, April 7, 2022 6:29 AM

All,

Regards,
Robert

Cheers,
Yingzhen  Jeff

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rtgwg__;!!BhdT!iUc8CE10Kf7KiD2fgHo0rCwjB8JNOmUJLpAizUYT5CwCHkdt1yyjero3Rm9ihPcGSANNI_KrWPU$>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Apr 2022 09:11:59 +0800

Hi, all

    I am interested in the focus WG. APN is some extension in the IP layer, and can provide more information to the network.

Best Regards
Zongpeng Du 

[email-masked] & [email-masked]
 
From: Jeff Tantsura
Date: 2022-04-06 01:14

 

Cheers,
Yingzhen  Jeff

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Apr 2022 09:22:53 +0800

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

From: UTTARO, JAMES
Date: 2022-04-08 00:45
To: Robert Raszuk; Jeff Tantsura
CC: [email-masked]; rtgwg-chairs; RTGWG
Subject: RE: RTGWG feedback on APN next steps
+1

All,

 

 

 
Regards,
Robert

On Tue, Apr 5, 2022 at 7:15 PM Jeff Tantsura <[email-masked]> wrote:
Dear RTGWG,

 

Cheers,
Yingzhen  Jeff

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 8 Apr 2022 08:37:29 +0530

Hi Chairs,

Thanks for initiating this call for the feedback!

I support the creation of a new WG and will participate and contribute to
it.

A dedicated home to reach a rough consensus on the scope of the problem and
framework is necessary to make progress. I see that there are still some
concerns that have been expressed on the list, but IMHO the chances of
resolving them in a dedicated WG are higher as we drive towards consensus.
I agree that the scope of the WG and the charter would need to be well
crafted.

Thanks!
Dhruv

---

From: "Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]" <[email-masked]>
Date: Fri, 8 Apr 2022 07:18:12 +0000

This is great news !!!
Effectively, we have use cases in our environment that are oriented APN.
I strongly support the construction the APN WG and will be happy to be part of the WG.

​Warm regards,
Luc-Fabrice
 
Ndifor
Specialist - IP Access and Data center
[email-masked]
T +237 677 55 02 13
Head Office: 360, Rue Drouot
​P.O. Box 15 574 Douala, Cameroon
T +237 679 00 90 90
 | mtn.cm
This email is confidential. If you have received it in error, you are on notice of its status. Please notify ​the ​​sender immediately by 
​reply email and then delete this message from your system. Please do not copy it ​or use it for any purpose or disclose its content 
​to any other person as to do so could be a breach of ​confidentiality.
​
 Please be informed that no employee or agent is authorized to conclude any legally binding agreement ​on behalf of MTN Cameroon
​via email. This can be only done if the email is confirmed explicitly in writing ​by an MTN Cameroon authorized officer. In no event 
​will this email or its content be construed as a written ​approval.
From: rtgwg <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Tuesday, April 5, 2022 6:15 PM
To: RTGWG <[email-masked]>; rtgwg-chairs <[email-masked]>; [email-masked]
Subject: RTGWG feedback on APN next steps

Dear RTGWG,

Cheers,
Yingzhen  Jeff

---

From: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>
Date: Fri, 8 Apr 2022 14:34:04 +0000

Hi all,

I support the creation of a new APN focus group, and would like to contribute to the WG.

Best regards,
Pang Ran.

From: Jeff Tantsura<mailto:[email-masked]>
Date: 2022-04-06 01:14
To: RTGWG<mailto:[email-masked]>; rtgwg-chairs<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RTGWG feedback on APN next steps
Dear RTGWG,

Cheers,
Yingzhen  Jeff

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Apr 2022 18:12:28 +0100

Hi Jeff and Yingzhen,

I would certainly appreciate a place that is working on a framework and the requirements that underlie the drive for APN.

I think that APN fits within the broad scope of “semantic routing” that I described at the meeting during IETF 113 and I would like us to be certain that the range of problems being addressed by APN has been fully discussed so that we avoid producing a niche solution for a subset of the use cases that might be addressed if we considered more carefully.

Robert is right that there are some risks associated with the potential complexity added to the routing and forwarding system (I hope I captured the essence of that in my presentation and in draft-king-irtf-challenges-in-routing), and I feel that working through these in a focused venue as part of the discussion of the framework would help target the solutions work better.

A small “however” here…

However, before fully supporting the creation of a working group, I do like to see the charter and scope. Obviously, that is beyond the current question that you asked (and that’s fine), but I just want the ADs to know the qualification to my answer.

Cheers,

Adrian

From: rtgwg <[email-masked]> On Behalf Of Jeff Tantsura
Sent: 05 April 2022 18:15
To: RTGWG <[email-masked]>; rtgwg-chairs <[email-masked]>; [email-masked]
Subject: RTGWG feedback on APN next steps

Dear RTGWG,

existing APN documents should be sent to [email-masked] <mailto:[email-masked]> .  This thread focuses on

new WG.

Thanks!

Cheers,

Yingzhen  Jeff

---

From: "Luis M. Contreras" <[email-masked]>
Date: Mon, 11 Apr 2022 15:36:53 +0200

Hi all,

I see of interest the work on the APN concept, as expressed several times
during BoFs and meetings. Moving the work to a dedicated WG seems to be a
good and focused option. As mentioned by others in the list, terms and
scope should be carefully defined for that purpose. So I support this way
of moving forward.

Thanks

Luis

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 11 Apr 2022 18:25:08 +0000

Hi all,

Clearly there are important technical concerns wrt APN that need to be addressed, as expressed by Robert.  However, just as clearly there is a need for a forum beyond RTGWG where those discussions can take place and where new ways of solving valid technical problems can be explored.  There is also a critical mass of people who are apparently interested in working on this.  In light of this, formation of a working group makes sense to me and is something that I support.

--- Alex

From: rtgwg <[email-masked]> On Behalf Of Luis M. Contreras
Sent: Monday, April 11, 2022 6:37 AM
To: Jeff Tantsura <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: RTGWG feedback on APN next steps

Hi all,

I see of interest the work on the APN concept, as expressed several times during BoFs and meetings. Moving the work to a dedicated WG seems to be a good and focused option. As mentioned by others in the list, terms and scope should be carefully defined for that purpose. So I support this way of moving forward.

Thanks

Luis

El mar, 5 abr 2022 a las 19:15, Jeff Tantsura (<[email-masked]<mailto:[email-masked]>>) escribió:
Dear RTGWG,

Cheers,
Yingzhen  Jeff

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&data=04%7C01%7Calex%40futurewei.com%7Cd7c390b478174c21b66408da1bc06862%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637852810463817537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8Vx0upXLowt7ZnnhXQyjlAl85nJuc3LbyM6c4FS35mA%3D&reserved=0>

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 12 Apr 2022 07:53:03 +0000

Dear all,

I do support the creation of a place where APN and its requirements as well as framework could be worked on.

In line with this support, I also want to point out the linkage to the discussion on ‘routing beyond reachability’ (RBR) and ‘semantic routing’, which were both presented at the recent IETF, in that APN fits the many examples given already for extending the functionality of the Internet’s capabilities beyond a mere reachability, possibly through APN-specific semantic enhancements that may be used for an app-specific traffic steering.

But it also shows, in my view, the need for a wider understanding of how various reachability mechanisms will need to architecturally fit together in order to work together, a point that both aforementioned efforts on RBR and semantic routing tried to make, also working through concerns of complexity raised in this specific APN discussion.

In conclusion, I support the creation of those APN effort but also hope we can make progress on the wider picture.

Best,

Dirk

From: rtgwg [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: 05 April 2022 19:15
To: RTGWG <[email-masked]>; rtgwg-chairs <[email-masked]>; [email-masked]
Subject: RTGWG feedback on APN next steps

Dear RTGWG,

Cheers,
Yingzhen  Jeff

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 12 Apr 2022 17:32:13 +0800

Hi, folks,
APN has been discussed in IETF for several times, and multiple use cases has been presented which shows its necessarities, I support the creation of a WG to push forward this work. Moreover, since Application-aware Network means encoding application-related information in the network layer, the future protocol design should avoid making the network-layer excessive complex, there should be a balance betweeen cost and the goals that APN pursues. 

Regards
Chongfeng

From: Jeff Tantsura
Date: 2022-04-06 01:14

 

Cheers,
Yingzhen  Jeff

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 12 Apr 2022 17:44:19 +0800

Hi,
 
I support to create the APN WG.
 
The APN work has progressed for a few years. We can focus on the use cases, problem statement and its framework in this WG.
 
Yongqing Zhu

[email-masked]
 
From: Jeff Tantsura
Date: 2022-04-06 01:14

 

Cheers,
Yingzhen  Jeff

---

From: 贺鲲鹏 <[email-masked]>
Date: Wed, 13 Apr 2022 22:02:43 +0800

Hi WG,

I support the creation of a new WG for APN. There are many discussions on APN which show enough interest from the community. The scope and framework of APN have also been clarified. But as some in the community have feared, the complexity that APN brings to the network requires further discussion and practice by the community. I think it is a good idea to suggest a new WG for more discussion of APN. We also want to explore the benefits that APN can bring.

Regards,

Kunpeng He

> 2022年4月6日 01:14，Jeff Tantsura <[email-masked]> 写道：
> 
> Dear RTGWG,
> 
> 
> existing APN documents should be sent to [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>. This thread focuses on
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtgwg <https://www.ietf.org/mailman/listinfo/rtgwg>