Subject: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

From: Lizhenbin <[email-masked]>
Date: Tue, 15 Jun 2021 15:27:05 +0000

Hi Folks,
In the interim meeting, there were much discussion on the BNG deployment in the home broadband scenario. In the section 5 of the following draft, there is more details about the scenarios.
https://www.ietf.org/archive/id/draft-li-apn-problem-statement-usecases-03.txt

As far as I know, there are types of deployment of BNGs in the scenarios:
1. RG is directly connected with the BNG
2. RG is connected spanning the metro network.
Because the BNG is responsible for the user management, if failure happens, it will have much negative effect on the users’ access to the Internet or other network services. If the second deployment method is used, the number of the BNG is small and the BNG can access more users, but the risk is high. If the first deployment is adopted, it may need more BNGs, but the risk can be low. So there is the trade-off in the network design and the deployment of the BNG.

The draft takes the second deployment to illustrate that the QinQ information besides the 5-tuple information can also be mapped to APN ID when the packet traverses the metro network.  That is the reason why not describe the first type of deployment.

Best Regards,
Robin

From: Apn [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Friday, June 4, 2021 10:53 PM
To: [email-masked]
Cc: 6MAN <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: [Apn] Application-Aware Networking (APN) focused interim

Dear all,

Many thanks for the questions, comments, and suggestions from those who joined the APN focused Interim meeting yesterday, which were very helpful to further refine the work and progress it forwards.

Please find the meeting minutes and materials discussed yesterday.
https://datatracker.ietf.org/meeting/interim-2021-rtgwg-01/session/rtgwg

If you have any views, comments, and questions, please don’t hesitate to post them in the mailing list.

Many thanks again to our AD and Chairs for arranging this Interim meeting!

Nice weekend! ☺

Best regards,
Shuping j

From: ipv6 [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Wednesday, June 2, 2021 9:14 AM
To: [email-masked]<mailto:[email-masked]>
Cc: 6MAN <[email-masked]<mailto:[email-masked]>>; RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: FW: Application-Aware Networking (APN) focused interim

Dear all,

Just a reminder that the APN focused Interim meeting @RTG will be held tomorrow, Thursday 2021-06-03 14:00 UTC. The Webex is attached.

You could find the slides that are going to guide the discussions in the following link. There might be minor updates in the final slides.
https://datatracker.ietf.org/meeting/interim-2021-rtgwg-01/session/rtgwg

The tentative agenda is as follows,

1.      Agenda bashing (10mins) –AD, Chairs

2.      Problem Statement (30mins) – Gyan Mishra

3.      Solution discussions (45-60mins) – Shuping/Robin

4.      Wrap-up & action plan (10mins) – Chairs

If you have any suggestions and comments, please let us know. Many thanks!

Best regards,
Shuping

From: Apn [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Friday, May 14, 2021 8:55 AM
To: 6MAN <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Routing Area Working Group <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Apn] FW: Application-Aware Networking (APN) focused interim

Dear all,

The APN Interim meeting has been scheduled on June 3rd. Please find the meeting information shared by the Chairs of the RTG WG below.

In this APN Interim meeting, we are going to focus more on the discussions of the solutions (more overview than details), including
1.       the design of the APN attribute itself
2.       the encapsulation of the APN attribute on the various data planes (the encapsulation on the IPv6 data plane is an example)
3.       the control plane protocols extensions for exchanging the APN attribute
4.       NETCONF/YANG models for the NBI and SBI

You are very welcomed to join the discussions, and your comments and suggestions are very much appreciated.

Thank you!

Best regards,
Shuping

From: rtgwg [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, May 7, 2021 6:38 AM
To: Routing WG <[email-masked]<mailto:[email-masked]>>; RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: Application-Aware Networking (APN) focused interim

Dear RTGWG,

We have scheduled Application-Aware Networking (APN) focused interim (agenda to be published), June 3rd, 2021, 7:00AM PST

Looking forward to seeing you,

Cheers,
Jeff and Chris

When it's time, start your Webex meeting here.

Thursday, June 3, 2021

7:00 AM  |  (UTC-07:00) Pacific Time (US & Canada)  |  2 hrs

Start meeting<https://ietf.webex.com/ietf/j.php?MTID=mc8ee2b80cb0fdd92745199a121f452db>

More ways to join:

Join from the meeting link

https://ietf.webex.com/ietf/j.php?MTID=mc8ee2b80cb0fdd92745199a121f452db

Join by meeting number

Meeting number (access code): 161 149 3477

Meeting password: gpN26drAet4

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1611493477##<tel:%2B1-650-479-3208,,*01*1611493477%23%23*01*> Call-in toll number (US/Canada)

Join by phone

1-650-479-3208 Call-in toll number (US/Canada)

Global call-in numbers<https://ietf.webex.com/ietf/globalcallin.php?MTID=m8fc024386f16ac264aaa306eeb5dff0c>

Join from a video system or application

Dial [email-masked]<sip:[email-masked]>

You can also dial 173.243.2.68 and enter your meeting number.

Join using Microsoft Lync or Microsoft Skype for Business

Dial [email-masked]<sip:[email-masked]>

If you are a host, click here<https://ietf.webex.com/ietf/j.php?MTID=m6b0d9545f1c064a6aa8f7739e2d4c763> to view host information.

Need help? Go to https://help.webex.com

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 15:28:11 -0400

> 2. RG is connected spanning the metro network.

These are not two cases.

The RG is never connected directly to the BNG, there is always some cables in between.
The metro network is just some rather smarter cable.  Sometimes it is just
L2 switches with ethernet-looking interfaces.
For many decades it was LANE (LAN emulation over ATM), and there are more
complex situations involving L2TP over IP.

But, the RG just sees ethernet on which it puts PPPoE, and the BNG sees some
amount of encapsulation (QinQ, PPPoE, PPPoA, L2TP: often more than one...),
in which PPP is finally found.

Third Party Internet Access (TPIA) DSL in Canada (and many other countries)
depends heavily upon a metro (nah, province-wide) network operated by the
incumbent telco in order to allow traffic to reach the BNGs of different ISPs.
Smarter places heavily regulate the SLA across the metro network, and do not
allow it to be oversubscribed, dumber places let the incumbent telco
do all sorts of lame stuff.

    > Because the BNG is responsible for the user management, if failure
    > happens, it will have much negative effect on the users’ access to the
    > Internet or other network services. If the second deployment method is
    > used, the number of the BNG is small and the BNG can access more users,
    > but the risk is high. If the first deployment is adopted, it may need
    > more BNGs, but the risk can be low. So there is the trade-off in the
    > network design and the deployment of the BNG.

I don't think any of this is relevant.
If the BNG fails, the user loses access. Period.

It is possible to build networks (and most do), where sessions will load
balance among BNG, and if the session fails, when the user's RG attempts to reconnect
then they get a "fresh" BNG.
I have deployed such configurations in a few dozen developing countries and a
few tropical islands [but alas, all remote]

    > The draft takes the second deployment to illustrate that the QinQ
    > information besides the 5-tuple information can also be mapped to APN
    > ID when the packet traverses the metro network.  That is the reason why
    > not describe the first type of deployment.

The application 5-tuple is burried in the PPP header.
20 years ago, I worked for a company that sold silicon to do classify based
upon that deeper header.  There are companies that sell devices that will
re-route traffic (in the PPPoE headers, etc.) that looks to be video so that
it will go another route.

So, it certainly can be done, but given QUIC, it's stupid to try to guess.

At the virtual interim, we were told that this wasn't important, that
the application information was not taken out in this way.  Now, you again
refer to it.

Note that in the PPPoE/L2TP/UDPb/IPb, there is a second 5-tuple, that is UDPb/IPb,
which represents a specific *customer*, but doesn't reflect which application
(of many) the customer is using.   yet, it's Application-Aware Networking.

If APN is gonna help me watch football in 3D while making supper, I think it
needs to know how to prioritize my needs over the teenager twitching minecraft.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 15 Jun 2021 20:52:57 +0000

It seems odd not to consider a broadband deployment architecture like
https://www.broadband-forum.org/technical/download/TR-470.pdf
in the context of wanting to enable improved usage of network slicing and such.

The BNG architecture does what it was intended to do: Ethernet aggregation.
If you want to do something else, you should probably consider a different architecture (or
consider working with BBF to evolve its BNG architecture into something different --
if you don't want the AGF architecture with a 5G-RG described in the above link).

Note the BNG is a BBF-defined network element. AFAIK, it was originally defined in:
https://www.broadband-forum.org/technical/download/TR-101_Issue-2.pdf

To Michael's comments: While there are still some (many?) operators who use PPPoE, I'm aware of
major operators who use BNGs without PPP or PPPoE. PPP is not a core function when
operating a BNG in an access network. Ethernet-based aggregation is the central feature that
defines a BNG.

So, again, if someone wants to do network slicing instead of Ethernet aggregation
(based on VLAN tags), they are right that the BNG is not the right access architecture
component. The AGF with a 5G-RG is much better suited to supporting network slicing.
Fortunately, a specification already exists for that architecture (complete with detailed
requirements for the 5G-RG [in TR-124] and how to manage the 5G-RG using TR-181).
Barbara

From: ipv6 <[email-masked]> On Behalf Of Lizhenbin
Sent: Tuesday, June 15, 2021 10:27 AM
To: [email-masked]; RTGWG <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

Hi Folks,
In the interim meeting, there were much discussion on the BNG deployment in the home broadband scenario. In the section 5 of the following draft, there is more details about the scenarios.
https://www.ietf.org/archive/id/draft-li-apn-problem-statement-usecases-03.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-li-apn-problem-statement-usecases-03.txt__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX9EiAnJ_w$>

As far as I know, there are types of deployment of BNGs in the scenarios:
1. RG is directly connected with the BNG
2. RG is connected spanning the metro network.
Because the BNG is responsible for the user management, if failure happens, it will have much negative effect on the users' access to the Internet or other network services. If the second deployment method is used, the number of the BNG is small and the BNG can access more users, but the risk is high. If the first deployment is adopted, it may need more BNGs, but the risk can be low. So there is the trade-off in the network design and the deployment of the BNG.

Best Regards,
Robin

Dear all,

Please find the meeting minutes and materials discussed yesterday.
https://datatracker.ietf.org/meeting/interim-2021-rtgwg-01/session/rtgwg<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2021-rtgwg-01/session/rtgwg__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX8NEVCG-Q$>

If you have any views, comments, and questions, please don't hesitate to post them in the mailing list.

Nice weekend! :)

Best regards,
Shuping j

Dear all,

You could find the slides that are going to guide the discussions in the following link. There might be minor updates in the final slides.
https://datatracker.ietf.org/meeting/interim-2021-rtgwg-01/session/rtgwg<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2021-rtgwg-01/session/rtgwg__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX8NEVCG-Q$>

1.      Agenda bashing (10mins) -AD, Chairs

2.      Problem Statement (30mins) - Gyan Mishra

3.      Solution discussions (45-60mins) - Shuping/Robin

4.      Wrap-up & action plan (10mins) - Chairs

Best regards,
Shuping

Dear all,

Thank you!

Best regards,
Shuping

Dear RTGWG,

Cheers,
Jeff and Chris

Thursday, June 3, 2021

Start meeting<https://urldefense.com/v3/__https:/ietf.webex.com/ietf/j.php?MTID=mc8ee2b80cb0fdd92745199a121f452db__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX_uCjrJSg$>

More ways to join:

Join from the meeting link
https://ietf.webex.com/ietf/j.php?MTID=mc8ee2b80cb0fdd92745199a121f452db<https://urldefense.com/v3/__https:/ietf.webex.com/ietf/j.php?MTID=mc8ee2b80cb0fdd92745199a121f452db__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX_uCjrJSg$>

Join by meeting number

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Global call-in numbers<https://urldefense.com/v3/__https:/ietf.webex.com/ietf/globalcallin.php?MTID=m8fc024386f16ac264aaa306eeb5dff0c__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX9uh2QDPQ$>

If you are a host, click here<https://urldefense.com/v3/__https:/ietf.webex.com/ietf/j.php?MTID=m6b0d9545f1c064a6aa8f7739e2d4c763__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX8obFl-0w$> to view host information.

Need help? Go to https://help.webex.com<https://urldefense.com/v3/__https:/help.webex.com__;!!BhdT!3x44cVFathXW5PntzRYHyVvBmnpz1XlgAyiKPu5OZGeTMI8ZIF8YEX8uzIUdug$>

---

From: David Allan I <[email-masked]>
Date: Tue, 15 Jun 2021 21:13:59 +0000

Hi

Looking over the draft I’m struggling to tell the difference between an APN encoded in tunnel meta data and a 5G System QFI encoded in tunnel meta data. There appears to be a 1:1 conceptual alignment, classification at system ingress, derive the value, encode for use by intermediate systems in encapsulating metadata.

So I would observe that besides being functionally identical, compared to existing wireline deployments, the 5G System also has the rest of the tools to fully operationalize, apply policy to and monetize this stuff.  And the BBF along with 3GPP are busy specifying convergence to add this functionality to wireline access….
5G FMC Architecture (broadband-forum.org)<https://www.broadband-forum.org/technical/download/TR-470.pdf>
And the 3GPP counterpart is TS 23.316 (release 16).  FYI, the BBF is currently working on issue 2 of the 5G WWC specification set and looking to publish by YE.

So what problem are we solving again here?

Cheers
Dave

From: ipv6 <[email-masked]> On Behalf Of Lizhenbin
Sent: Tuesday, June 15, 2021 8:27 AM
To: [email-masked]; RTGWG <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

Hi Folks,

Best Regards,
Robin

Dear all,

Nice weekend! ☺

Best regards,
Shuping j

Dear all,

Best regards,
Shuping

Dear all,

Thank you!

Best regards,
Shuping

Dear RTGWG,

Cheers,
Jeff and Chris

Thursday, June 3, 2021

More ways to join:

Join by meeting number

Join by phone

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 16 Jun 2021 03:00:49 +0000

Hi David,

I think the network scenarios in Robin’s mind are something like the diagrams below.

MBB:
gNB --  PE1 -----  (SRv6) tunnel ---- PE2 -- UPF

FBB:
RG --  PE1 ----- (SRv6) tunnel ---- PE2 -- BNG

In the MBB, “The QFI is carried in an encapsulation header on N3 (and N9)” – TS23.501. That is between gNB and UPF is the GTP-u and QFI is used in the GTP-u tunnel, while between PE1 and PE2 is the IP metro network and APN attribute is used in the IP tunnel (e.g. SRv6 tunnel). At PE1, the QFI and other information in the packet header (payload is not touched) could be used to construct the APN attribute based on the Operator’s configurations, which will be encapsulated in an IP tunnel header such as SRv6 header on top of the GTP-u tunnel. This APN attribute will be used within the IP metro network to do the policy enforcement and service provisioning. Once the packet leaves the IP metro network, the APN attribute will be removed/decapsulated together with the IP tunnel header.

The FBB case is similar to MBB.

Here RG/BNG (BBF is responsible) and gNB/UPF (3GPP is responsible) are not touched.

Best regards,
Shuping

From: ipv6 [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, June 16, 2021 5:14 AM
To: Lizhenbin <[email-masked]>; [email-masked]; RTGWG <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: RE: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

Hi

Cheers
Dave

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Lizhenbin
Sent: Tuesday, June 15, 2021 8:27 AM
To: [email-masked]<mailto:[email-masked]>; RTGWG <[email-masked]<mailto:[email-masked]>>
Cc: 6MAN <[email-masked]<mailto:[email-masked]>>
Subject: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

Hi Folks,

Best Regards,
Robin

Dear all,

Nice weekend! ☺

Best regards,
Shuping j

Dear all,

Best regards,
Shuping

Dear all,

Thank you!

Best regards,
Shuping

Dear RTGWG,

Cheers,
Jeff and Chris

Thursday, June 3, 2021

More ways to join:

Join by meeting number

Join by phone

---

From: Lizhenbin <[email-masked]>
Date: Wed, 16 Jun 2021 09:56:08 +0000

Hi Michael,
Please refer to my reply inline. 

Best Regards,
Robin

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: Wednesday, June 16, 2021 3:28 AM
To: Lizhenbin <[email-masked]>; [email-masked]; RTGWG <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

These are not two cases.

For many decades it was LANE (LAN emulation over ATM), and there are more complex situations involving L2TP over IP.

But, the RG just sees ethernet on which it puts PPPoE, and the BNG sees some amount of encapsulation (QinQ, PPPoE, PPPoA, L2TP: often more than one...), in which PPP is finally found.

Third Party Internet Access (TPIA) DSL in Canada (and many other countries) depends heavily upon a metro (nah, province-wide) network operated by the incumbent telco in order to allow traffic to reach the BNGs of different ISPs.
Smarter places heavily regulate the SLA across the metro network, and do not allow it to be oversubscribed, dumber places let the incumbent telco do all sorts of lame stuff.

[Robin] I agree with you that the RG is not directly connected to the BNG. In the figure, the OLT device is omitted. The more accurate figure can be as follows:
Deployment 1: RG --- OLT ----- Metro Network ---- BNG
Deployment 2: RG----OLT------BNG ----Metro Network 
L2 switches can be located between RG and OLT. In these scenario, our focus is on the Metro Network instead of the RG/OLT/BNG. The metro network which is the APN domain can deploy the EVPN VPLS over MPLS/SR/SRv6 tunnel. In the deployment 1, when the PPPOE packet arrives at the edge of the PE of the metro network, the edge can map the QinQ information to the APN ID encapsulated with the MPLS/SR/SRv6 tunnel and apply the corresponding service. In the deployment 2, when the packet arrives at the edge of the PE of the metro network, the edge can map the 5-tuple information to the APN ID and apply the corresponding service. Since the existing information is used to map to the APN ID in the similar as that of the SD-WAN scenario, it is not described.
In fact we proposed the three scenarios to identify the different scenarios to map the existing information to the APN ID which can be carried along with the MPLS/SR/SRv6/VxLAN tunnels. 
1. SD-WAN scenario: the 5-tuple information can be used.
2. Home broadband scenario: the L2 QinQ information of the PPPOE/IPOE-based packet can be used at the edge of the metro network.
3. Mobile broadband scenario: the extra information (TEID, etc.) of the GTP-tunnel packet can be used at the edge of the mobile transport network.
Then we can design the YANG models as the solution accordingly.

It is possible to build networks (and most do), where sessions will load balance among BNG, and if the session fails, when the user's RG attempts to reconnect then they get a "fresh" BNG.
I have deployed such configurations in a few dozen developing countries and a few tropical islands [but alas, all remote]

The application 5-tuple is burried in the PPP header.
20 years ago, I worked for a company that sold silicon to do classify based upon that deeper header.  There are companies that sell devices that will re-route traffic (in the PPPoE headers, etc.) that looks to be video so that it will go another route.

At the virtual interim, we were told that this wasn't important, that the application information was not taken out in this way.  Now, you again refer to it.

Note that in the PPPoE/L2TP/UDPb/IPb, there is a second 5-tuple, that is UDPb/IPb, which represents a specific *customer*, but doesn't reflect which application
(of many) the customer is using.   yet, it's Application-Aware Networking.
[Robin] As I explained above, we focus on the scenario of the deployment 1. There is the practice that in the deployment 1, the RG can tag the packet with the S-VLAN (Service VLAN) identifying the services (VoIP, Internet Access, IPTV, etc.) with and the OLT can go on to tag packet with the U-VLAN (User VLAN) identifying the user. So the edge of the metro network can map the QinQ information (including S-VLAN and C-VLAN) to the APN ID. This is the scenario we described in the draft. Thanks for your proposed more existing information which can be used to implement the mapping, we will take it into account.

If APN is gonna help me watch football in 3D while making supper, I think it needs to know how to prioritize my needs over the teenager twitching minecraft.
[Robin] In the network side, it is difficult to get more accurate application information according to the mapping from the existing information of the packet header to the APN ID. APN is just to provide a practical way instead of satisfying all possible requirements. It has been discussed that the application information is directly derived in the application side. But there are too many challenges of privacy and security to be taken into account now.

---

From: Lizhenbin <[email-masked]>
Date: Wed, 16 Jun 2021 10:23:07 +0000

Hi Barbara,

Best Regards,
Robin

From: STARK, BARBARA H [mailto:[email-masked]]
Sent: Wednesday, June 16, 2021 4:53 AM
To: Lizhenbin <[email-masked]>; [email-masked]' <[email-masked]>; 'RTGWG' <[email-masked]>
Cc: '6MAN' <[email-masked]>
Subject: RE: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

[Robin] Thanks for your information on the network architecture of the BNG. As what I reply Michael,
in the home broadband scenario, we focus on the metro network and the case that the existing L2
information in the packet can also be used to map to the APN ID. There may be more existing
information from the PPPOE or IPOE packet header. We can take them into account. Your information
is a good input to prioritize the possible existing information.

So, again, if someone wants to do network slicing instead of Ethernet aggregation
(based on VLAN tags), they are right that the BNG is not the right access architecture
component. The AGF with a 5G-RG is much better suited to supporting network slicing.
Fortunately, a specification already exists for that architecture (complete with detailed
requirements for the 5G-RG [in TR-124] and how to manage the 5G-RG using TR-181).
[Robin] The network slice described in the drafts of the APN work is the IETF network slice scenario in the metro
network or the mobile transport network. The edge can steer the packet to the corresponding IETF network slice
according to the policy matching the APN ID.

Barbara

Hi Folks,

Best Regards,
Robin

Dear all,

Nice weekend! :)

Best regards,
Shuping j

Dear all,

Best regards,
Shuping

Dear all,

Thank you!

Best regards,
Shuping

Dear RTGWG,

Cheers,
Jeff and Chris

Thursday, June 3, 2021

More ways to join:

Join by meeting number

Join by phone

---

From: Eduard Metz <[email-masked]>
Date: Wed, 16 Jun 2021 15:54:44 +0200

Is it correct to say that this proposes a mapping / encoding of
"application" information into a common transport / infrastructure layer
based on information from either the encapsulated / carried traffic and/or
the originating domain? Kind of similar to how e.g. the classification and
marking of the MPLS TC field on a PE, but now with a more wider use of the
application information.

I find the term application a bit confusing, in particular in the fixed
broadband case the granularity in the example is rather coarse.
Application suggests something more finegrained, at least to me.
The use of VLAN for classification may not be generally available, if the
access is based on a single VLAN a more complex classification is required
anyway.

All scenarios include some kind of tunneling in which the actual user
carried. Is this the scope of this APN solution?
I would expect application awareness would be relevant end-to-end, or at
least within one domain. For example, in the fixed broadband case, what
happens after the BNG?

SD-WAN on the other hand is an "end-to-end" scenario,it may even span
multiple operator domains.
Also note that SD-WAN may make use of FBB or MBB as an access, possibly
creating multiple layers of APN.

The APN domain now is bounded by PEs (for FBB and MBB), wouldn't it be
better to specify functional elements as the boundaries? Or do you consider
the PE to be a functional element as well?
In case of FBB the edge of an APN domain could be implemented in the same
node as the OLT (or BNG on the other side) or even the CPE.

cheers,
  Eduard

On Wed, Jun 16, 2021 at 5:01 AM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> In the MBB, “The QFI is carried in an encapsulation header on N3 (and N9)”
> – TS23.501. That is between gNB and UPF is the GTP-u and QFI is used in the
> GTP-u tunnel, while between PE1 and PE2 is the IP metro network and APN
> attribute is used in the IP tunnel (e.g. SRv6 tunnel). At PE1, the QFI and
> other information in the packet header (payload is not touched) could be
> used to construct the APN attribute based on the Operator’s configurations,
> which will be encapsulated in an IP tunnel header such as SRv6 header on
> top of the GTP-u tunnel. This APN attribute will be used within the IP
> metro network to do the policy enforcement and service provisioning. Once
> the packet leaves the IP metro network, the APN attribute will be
> removed/decapsulated together with the IP tunnel header.
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *David Allan I
> *Sent:* Wednesday, June 16, 2021 5:14 AM
> *To:* Lizhenbin <[email-masked]>; [email-masked]; RTGWG <
> [email-masked]>
> *Cc:* 6MAN <[email-masked]>
> *Subject:* RE: Clarification on the BNG deployment//RE: Application-Aware
> Networking (APN) focused interim
>
>
>
> Hi
>
>
>
> Looking over the draft I’m struggling to tell the difference between an
> APN encoded in tunnel meta data and a 5G System QFI encoded in tunnel meta
> data. There appears to be a 1:1 conceptual alignment, classification at
> system ingress, derive the value, encode for use by intermediate systems in
> encapsulating metadata.
>
>
>
> So I would observe that besides being functionally identical, compared to
> existing wireline deployments, the 5G System also has the rest of the tools
> to fully operationalize, apply policy to and monetize this stuff.  And the
> BBF along with 3GPP are busy specifying convergence to add this
> functionality to wireline access….
>
> 5G FMC Architecture (broadband-forum.org)
> <https://www.broadband-forum.org/technical/download/TR-470.pdf>
>
> And the 3GPP counterpart is TS 23.316 (release 16).  FYI, the BBF is
> currently working on issue 2 of the 5G WWC specification set and looking to
> publish by YE.
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Lizhenbin
> *Sent:* Tuesday, June 15, 2021 8:27 AM
> *To:* [email-masked]; RTGWG <[email-masked]>
> *Cc:* 6MAN <[email-masked]>
> *Subject:* Clarification on the BNG deployment//RE: Application-Aware
> Networking (APN) focused interim
>
>
>
> Hi Folks,
>
> In the interim meeting, there were much discussion on the BNG deployment
> in the home broadband scenario. In the section 5 of the following draft,
> there is more details about the scenarios.
>
>
> used, the number of the BNG is small and the BNG can access more users, but
> the risk is high. If the first deployment is adopted, it may need more
> BNGs, but the risk can be low. So there is the trade-off in the network
> design and the deployment of the BNG.
>
>
>
> information besides the 5-tuple information can also be mapped to APN ID
> when the packet traverses the metro network.  That is the reason why not
> describe the first type of deployment.
>
>
>
>
>
> Best Regards,
>
> Robin
>
>
>
>
>
>
>
>
>
>
>
> *From:* Apn [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Friday, June 4, 2021 10:53 PM
> *To:* [email-masked]
> *Cc:* 6MAN <[email-masked]>; RTGWG <[email-masked]>
> *Subject:* Re: [Apn] Application-Aware Networking (APN) focused interim
>
>
>
> Dear all,
>
>
>
> Many thanks for the questions, comments, and suggestions from those who
> joined the APN focused Interim meeting yesterday, which were very helpful
> to further refine the work and progress it forwards.
>
>
>
> Nice weekend! J
> *From:* ipv6 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Wednesday, June 2, 2021 9:14 AM
> *To:* [email-masked]
> *Cc:* 6MAN <[email-masked]>; RTGWG <[email-masked]>
> *Subject:* FW: Application-Aware Networking (APN) focused interim
>
>
>
> Dear all,
>
>
>
> Just a reminder that the APN focused Interim meeting @RTG will be held
> tomorrow, Thursday 2021-06-03 14:00 UTC. The Webex is attached.
>
>
>
> You could find the slides that are going to guide the discussions in the
> following link. There might be minor updates in the final slides.
>
> *From:* Apn [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Friday, May 14, 2021 8:55 AM
> *To:* 6MAN <[email-masked]>
> *Cc:* [email-masked]; Routing Area Working Group <[email-masked]>;
> [email-masked]
> *Subject:* [Apn] FW: Application-Aware Networking (APN) focused interim
>
>
>
> Dear all,
>
>
>
> The APN Interim meeting has been scheduled on June 3rd. Please find the
> meeting information shared by the Chairs of the RTG WG below.
>
>
>
> In this APN Interim meeting, we are going to focus more on the discussions
> of the solutions (more overview than details), including
>
> 2.       the encapsulation of the APN attribute on the various data planes
> (the encapsulation on the IPv6 data plane is an example)
>
> *From:* rtgwg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Jeff Tantsura
> *Sent:* Friday, May 7, 2021 6:38 AM
> *To:* Routing WG <[email-masked]>; RTGWG <[email-masked]>
> *Subject:* Application-Aware Networking (APN) focused interim
>
>
>
> Dear RTGWG,
>
> We have scheduled Application-Aware Networking (APN) focused interim
> (agenda to be published), June 3rd, 2021, 7:00AM PST
>
> Start meeting
> <https://ietf.webex.com/ietf/j.php?MTID=mc8ee2b80cb0fdd92745199a121f452db>
>
>
>
>
>
> *More ways to join:*
>
>
>
>
>
> *Join from the meeting link*
>
> *Join by meeting number*
> *Tap to join from a mobile device (attendees only)*
>
> +1-650-479-3208,,1611493477##
> <%2B1-650-479-3208,,*01*1611493477%23%23*01*> Call-in toll number
> (US/Canada)
>
>
>
>
>
> *Join by phone*
>
> Global call-in numbers
> <https://ietf.webex.com/ietf/globalcallin.php?MTID=m8fc024386f16ac264aaa306eeb5dff0c>
>
>
>
>
>
>
>
> *Join from a video system or application*
>
> Dial [email-masked]
>
> *Join using Microsoft Lync or Microsoft Skype for Business*
>
> Dial [email-masked]
>
>
>
>
>
>
>
> If you are a host, click here
> <https://ietf.webex.com/ietf/j.php?MTID=m6b0d9545f1c064a6aa8f7739e2d4c763>
> to view host information.
>
>
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: David Allan I <[email-masked]>
Date: Wed, 16 Jun 2021 13:57:45 +0000

Hi Shuping:

Some comments in line prefaced with DA>

From: Pengshuping (Peng Shuping) <[email-masked]>
Sent: Tuesday, June 15, 2021 8:01 PM
To: David Allan I <[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]; RTGWG <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: RE: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

Hi David,

MBB:

FBB:
RG --  PE1 ----- (SRv6) tunnel ---- PE2 – BNG

DA> The scenarios I’m considering area:

MBB:
UE------------gNB------UPF
WWC:
5G-RG-------PON/DSL-----AGF------UPF

In the MBB, “The QFI is carried in an encapsulation header on N3 (and N9)” – TS23.501. That is between gNB and UPF is the GTP-u and QFI is used in the GTP-u tunnel, while between PE1 and PE2 is the IP metro network and APN attribute is used in the IP tunnel (e.g. SRv6 tunnel).
DA> Well it actually originates in the UE and IIRC it is encoded in PDCP.  So the basic classification occurs at the ingress points to the 5G System.  In the wireline WWC case it is the 5G-RG and encoded in RFC 8822 encapsulation.
At PE1, the QFI and other information in the packet header (payload is not touched) could be used to construct the APN attribute based on the Operator’s configurations, which will be encapsulated in an IP tunnel header such as SRv6 header on top of the GTP-u tunnel. This APN attribute will be used within the IP metro network to do the policy enforcement and service provisioning. Once the packet leaves the IP metro network, the APN attribute will be removed/decapsulated together with the IP tunnel header.
DA> I could see the utility of classifying at the PE to find the QFI and using it as an input at an ingress SR-PE but that requires coordination with the 5G system.  Duplicating it or something similar in yet another layer seems to be baggage, and counter to the design philosophy of SR as the utility of this would appear to require statefulness in the P routers.

The FBB case is similar to MBB.
DA>  Well PON architectures commonly deployed tend to fill the gap between the RG and the BNG with fiber and an OLT with a TR-101 like handoff to the BNG.  A much much simpler topology than what is suggested here.

Here RG/BNG (BBF is responsible) and gNB/UPF (3GPP is responsible) are not touched.
DA> In my experience this is not really appliable to a lot of existing FBB deployments, and duplicates all the moving parts of the MBB/WWC architecture at yet another layer.

Best regards,
Shuping
Cheers
Dave

To: Lizhenbin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; RTGWG <[email-masked]<mailto:[email-masked]>>

Hi

So I would observe that besides being functionally identical, compared to existing wireline deployments, the 5G System also has the rest of the tools to fully operationalize, apply policy to and monetize this stuff.  And the BBF along with 3GPP are busy specifying convergence to add this functionality to wireline access….
5G FMC Architecture (broadband-forum.org)<https://protect2.fireeye.com/v1/url?k=8bf2f419-d469cd1c-8bf2b482-86959e472243-29d6ea77ba4fad20&q=1&e=bcdb72d7-8f87-4824-bcfa-9b831ad71e14&u=https%3A%2F%2Fwww.broadband-forum.org%2Ftechnical%2Fdownload%2FTR-470.pdf>
And the 3GPP counterpart is TS 23.316 (release 16).  FYI, the BBF is currently working on issue 2 of the 5G WWC specification set and looking to publish by YE.

Cheers
Dave

Hi Folks,

Best Regards,
Robin

Dear all,

Nice weekend! ☺

Best regards,
Shuping j

Dear all,

Best regards,
Shuping

Dear all,

Thank you!

Best regards,
Shuping

Dear RTGWG,

Cheers,
Jeff and Chris

Thursday, June 3, 2021

More ways to join:

Join by meeting number

Join by phone

---

From: Lizhenbin <[email-masked]>
Date: Thu, 17 Jun 2021 03:02:47 +0000

Hi Eduard,

Best Regards,
Robin

From: Eduard Metz [mailto:[email-masked]]
Sent: Wednesday, June 16, 2021 9:55 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: David Allan I <david.i.allan=[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]; RTGWG <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: Clarification on the BNG deployment//RE: Application-Aware Networking (APN) focused interim

Is it correct to say that this proposes a mapping / encoding of "application" information into a common transport / infrastructure layer based on information from either the encapsulated / carried traffic and/or the originating domain? Kind of similar to how e.g. the classification and marking of the MPLS TC field on a PE, but now with a more wider use of the application information.
[Robin] YES. The APN work is to introduce a general encapsulation with the identifier with bigger space comparing with the existing mechanisms. It is to facilitate the finer-granularity service provisioning.
I find the term application a bit confusing, in particular in the fixed broadband case the granularity in the example is rather coarse. Application suggests something more finegrained, at least to me.
[Robin] We will take this into account. The suggestions on the better name are always welcome.

The use of VLAN for classification may not be generally available, if the access is based on a single VLAN a more complex classification is required anyway.
[Robin] The APN usecase draft proposes this case to show that the existing L2 information can be mapped to APN ID. More details need to be considered when design the possible YANG models.

All scenarios include some kind of tunneling in which the actual user carried. Is this the scope of this APN solution?
[Robin] YES. This guarantees that the APN attributes will be only used in the limited domain.

I would expect application awareness would be relevant end-to-end, or at least within one domain. For example, in the fixed broadband case, what happens after the BNG?

SD-WAN on the other hand is an "end-to-end" scenario,it may even span multiple operator domains.
Also note that SD-WAN may make use of FBB or MBB as an access, possibly creating multiple layers of APN.
[Robin] It is a little difficult since there are always different network designs and deployment for the end-to-end case. We will think some typical end-to-end usease can be added. Or maybe later the draft led by the operators about the operation and deployment of APN can be proposed to cover the possible end-to-end cases.

The APN domain now is bounded by PEs (for FBB and MBB), wouldn't it be better to specify functional elements as the boundaries? Or do you consider the PE to be a functional element as well?
[Robin] Please refer to the section 4 of the APN framework draft (https://datatracker.ietf.org/doc/html/draft-li-apn-framework). Here the function elements are abstracted.

In case of FBB the edge of an APN domain could be implemented in the same node as the OLT (or BNG on the other side) or even the CPE.
[Robin] Now I do not think the usecase complies with the definition of the APN domain. 1. There is no tunnel start at the OLT. 2. Where is the APN attribute in the forwarding plane?

cheers,
  Eduard

On Wed, Jun 16, 2021 at 5:01 AM Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

MBB:

FBB:

Best regards,
Shuping

From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David Allan I

Hi

Cheers
Dave

Hi Folks,

Best Regards,
Robin

Dear all,

Nice weekend! ☺

Best regards,
Shuping j

Dear all,

Best regards,
Shuping

Dear all,

Thank you!

Best regards,
Shuping

Dear RTGWG,

Cheers,
Jeff and Chris

Thursday, June 3, 2021

More ways to join:

Join by meeting number

Join by phone

Dial [email-masked]<mailto:[email-masked]>

Dial [email-masked]<mailto:[email-masked]>

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

---

From: Eduard Metz <[email-masked]>
Date: Thu, 17 Jun 2021 13:38:05 +0200

Hi Robin,

Thanks for your response.

With regard to:

[Robin] Now I do not think the usecase complies with the definition of the
APN domain. 1. There is no tunnel start at the OLT. 2. Where is the APN
attribute in the forwarding plane?

What I meant is that the OLT could be an APN edge / head (in terms of the
framework), the tunnel could start there right? I assume APN does not
exclude this, the scenario described I see as an example of how things can
be done.

cheers,
  Eduard

On Thu, Jun 17, 2021 at 5:02 AM Lizhenbin <[email-masked]> wrote:

> *From:* Eduard Metz [mailto:[email-masked]]
> *Sent:* Wednesday, June 16, 2021 9:55 PM
> *To:* Pengshuping (Peng Shuping) <[email-masked]>
> *Cc:* David Allan I <david.i.allan=[email-masked]>;
> Lizhenbin <[email-masked]>; [email-masked]; RTGWG <[email-masked]>;
> 6MAN <[email-masked]>
> *Subject:* Re: Clarification on the BNG deployment//RE: Application-Aware
> [Robin] YES. The APN work is to introduce a general encapsulation with the
> identifier with bigger space comparing with the existing mechanisms. It is
> to facilitate the finer-granularity service provisioning.
>
> [Robin] The APN usecase draft proposes this case to show that the existing
> L2 information can be mapped to APN ID. More details need to be considered
> when design the possible YANG models.
>
>
>
> [Robin] It is a little difficult since there are always different network
> designs and deployment for the end-to-end case. We will think some typical
> end-to-end usease can be added. Or maybe later the draft led by the
> operators about the operation and deployment of APN can be proposed to
> cover the possible end-to-end cases.
>
>
>
>
>
> [Robin] Please refer to the section 4 of the APN framework draft (
> https://datatracker.ietf.org/doc/html/draft-li-apn-framework). Here the
> function elements are abstracted.
>
>
>
> [Robin] Now I do not think the usecase complies with the definition of the
> APN domain. 1. There is no tunnel start at the OLT. 2. Where is the APN
> attribute in the forwarding plane?
>
>
>
> cheers,
>
>   Eduard
>
>
>
>
>
>
>