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

[Michael Richardson <[e-mail]>]

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.

    > 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide