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

Hi Robin,

Thanks for your response.

With regard to:

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?

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 <lizhenbin@huawei.com> wrote:

> Hi Eduard,
>
> Please refer to my reply inline.
>
>
>
> Best Regards,
>
> Robin
>
>
>
>
>
>
>
> *From:* Eduard Metz [mailto:etmetz@gmail.com]
> *Sent:* Wednesday, June 16, 2021 9:55 PM
> *To:* Pengshuping (Peng Shuping) <pengshuping@huawei.com>
> *Cc:* David Allan I <david.i.allan=40ericsson.com@dmarc.ietf.org>;
> Lizhenbin <lizhenbin@huawei.com>; apn@ietf.org; RTGWG <rtgwg@ietf.org>;
> 6MAN <6man@ietf.org>
> *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) <
> pengshuping@huawei.com> wrote:
>
> 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:ipv6-bounces@ietf.org] *On Behalf Of *David Allan I
> *Sent:* Wednesday, June 16, 2021 5:14 AM
> *To:* Lizhenbin <lizhenbin@huawei.com>; apn@ietf.org; RTGWG <
> rtgwg@ietf.org>
> *Cc:* 6MAN <6man@ietf.org>
> *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.
>
>
>
> So what problem are we solving again here?
>
>
>
> Cheers
>
> Dave
>
>
>
> *From:* ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Lizhenbin
> *Sent:* Tuesday, June 15, 2021 8:27 AM
> *To:* apn@ietf.org; RTGWG <rtgwg@ietf.org>
> *Cc:* 6MAN <6man@ietf.org>
> *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
>
>
>
> 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:apn-bounces@ietf.org <apn-bounces@ietf.org>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Friday, June 4, 2021 10:53 PM
> *To:* apn@ietf.org
> *Cc:* 6MAN <6man@ietf.org>; RTGWG <rtgwg@ietf.org>
> *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! J
>
>
>
> Best regards,
>
> Shuping j
>
>
>
>
>
>
>
> *From:* ipv6 [mailto:ipv6-bounces@ietf.org <ipv6-bounces@ietf.org>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Wednesday, June 2, 2021 9:14 AM
> *To:* apn@ietf.org
> *Cc:* 6MAN <6man@ietf.org>; RTGWG <rtgwg@ietf.org>
> *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:apn-bounces@ietf.org <apn-bounces@ietf.org>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Friday, May 14, 2021 8:55 AM
> *To:* 6MAN <6man@ietf.org>
> *Cc:* apn@ietf.org; Routing Area Working Group <rtgwg-chairs@ietf.org>;
> 6man-chairs@ietf.org
> *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:rtgwg-bounces@ietf.org <rtgwg-bounces@ietf.org>] *On
> Behalf Of *Jeff Tantsura
> *Sent:* Friday, May 7, 2021 6:38 AM
> *To:* Routing WG <rtgwg-chairs@ietf.org>; RTGWG <rtgwg@ietf.org>
> *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##
> <%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 1611493477@ietf.webex.com
>
> You can also dial 173.243.2.68 and enter your meeting number.
>
>
>
>
>
>
>
> *Join using Microsoft Lync or Microsoft Skype for Business*
>
> Dial 1611493477.ietf@lync.webex.com
>
>
>
>
>
>
>
> 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
>
>
>
>
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>