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

[Lizhenbin <[e-mail]>]

Hi Michael,
Please refer to my reply inline. 

Best Regards,
Robin



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


Lizhenbin <[e-mail]> wrote:
    > 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.

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.

[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.


    > 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.
[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.


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