RE: [Apn] Questions about draft-li-6man-app-aware-ipv6-network-02

[Lizhong Jin <[e-mail]>]

Hi Robin,
One more question as below. Thanks.

==================snipped=============

   1. How can residential/enterprise intranet VLAN information traverse the
   CE device? Or should the CE device use the ‘internal/private network’ VLAN
   tag to mark the traffic ?


[Robin] I propose the following example for your reference:

Host/App ------- residential gateway ------------------ DSLAM
------------------Metro PE -------- P ---------- Metro PE --------------
BRAS

Packet S-VLAN + Packet C-VLAN + S-VLAN + Packet L2VPN/MPLS L2VPN/MPLS
C-VLAN + S-VLAN + Packet

>From the above topology, DSLAM can be seen as the CE which adds the C-VLAN
and access the PE of the metro network.

[Lizhong] If DSLAM is as CE in APN, how does DSLAM identify every
application traffic? That will conflict the promise stated in
[draft-li-apn-problem-statement-usecases-01].

One of the key objectives of APN is for network operators to provide
fine-granularity SLA guarantees instead of coarse-grain traffic operations.

Regards

Lizhong

*From:* Lizhenbin <[e-mail]>
*Sent:* Thursday, October 8, 2020 23:15
*To:* Eric Vyncke (evyncke) <evyncke=[e-mail]>; Linda
Dunbar <[e-mail]>; IPv6 List <[e-mail]>;
[e-mail]
*Cc:* [e-mail]
*Subject:* Re: [Apn] Questions about draft-li-6man-app-aware-ipv6-network-02

Hi Eric,

Thanks for your greetings. Please refer to my reply inline.

Best Regards,

Robin

*From:* Apn [mailto:[e-mail]] *On Behalf Of *Eric Vyncke
(evyncke)
*Sent:* Thursday, October 8, 2020 7:52 PM
*To:* Lizhenbin <[e-mail]>; Linda Dunbar <
[e-mail]>; IPv6 List <[e-mail]>;
[e-mail]
*Cc:* [e-mail]
*Subject:* Re: [Apn] Questions about draft-li-6man-app-aware-ipv6-network-02

Hello Robin,

I hope that you and your family were able to enjoy a nice family time !

About the VLAN, if you consider that the APN6 ‘tag’ is originated by the CE
device, then indeed it will stay intact accross the SP access network and
could be propagated across L2VPN/EVPN but then:

   1. It really requires deep packet inspection to get access to the .1Q
   tag in the SP network in case of L2VPN/EVPN

   [Robin] This is related with the possible new work items for APN to
   encapsulate the user information with MPLS/SRv6. That is, if the VLAN
   tagging information is acquired in the PE, when encapsulate the VLAN tagged
   packet with the outer MPLS/SRv6, the user information from the VLAN tagging
   will be mapped to the user information encapsulated with MPLS/SRv6. So the
   user information can be acquired from the outer encapsulation instead of
   deep packet inspection.

   2. How can residential/enterprise intranet VLAN information traverse the
   CE device? Or should the CE device use the ‘internal/private network’ VLAN
   tag to mark the traffic ?


[Robin] I propose the following example for your reference:

Host/App ------- residential gateway ------------------ DSLAM
------------------Metro PE -------- P ---------- Metro PE --------------
BRAS

Packet S-VLAN + Packet C-VLAN + S-VLAN + Packet L2VPN/MPLS L2VPN/MPLS
C-VLAN + S-VLAN + Packet

>From the above topology, DSLAM can be seen as the CE which adds the C-VLAN
and access the PE of the metro network.

I will need to think more about the ‘user’ information but it appears to me
that is rather ‘SP subscriber’ and not "individual user" (such as a student
in a University). Did I get the high-level view right?

[Robin] I like the name of ‘SP subscriber‘. The ‘user’ information of the
‘SP subscriber‘ can be used in the SP network without propagating to the
open internet. This is one of the right cases for APN.

I wonder if there is pure ‘individual user’ which can directly access the
open Internet since these users may have to pass through some of the AAA
(Authentication, Authorization and Accounting) in a limited domain before
their packets can access the open Internet. These users needs to provide
the necessary user information in the limited domain though these
information may be not the direct user information in the packet.

e
Regards

-éric

*From: *Lizhenbin <[e-mail]>
*Date: *Thursday, 8 October 2020 at 10:28
*To: *Eric Vyncke <[e-mail]>, Linda Dunbar <
[e-mail]>, IPv6 List <[e-mail]>, "
[e-mail]" <
[e-mail]>
*Cc: *"[e-mail]" <[e-mail]>
*Subject: *RE: Questions about draft-li-6man-app-aware-ipv6-network-02

Hi Eric,

Sorry for the delayed reply because we are having an 8-day holiday. Please
refer to my reply inline.

Best Regards,

Robin

*From:* Eric Vyncke (evyncke) [mailto:[e-mail]]
*Sent:* Tuesday, September 29, 2020 4:07 PM
*To:* Lizhenbin <[e-mail]>; Linda Dunbar <
[e-mail]>; IPv6 List <[e-mail]>;
[e-mail]
*Cc:* [e-mail]
*Subject:* Re: Questions about draft-li-6man-app-aware-ipv6-network-02

Robin,

About Linda’s interesting questions about APN, I also wonder why using VLAN
tagging as this tag will be lost quickly after a couple of hops while the
IPv6 prefix will be kept (this is what DT Terastream did if not mistaken).

[Robin] The VLAN tagging will truly be lost after a couple of hops. This is
why we call it is used in the limited domains. In fact the VLAN tagged
packet may traverse the metro network where L2VPN/EVPN + MPLS/SR are used
before it arrives at the BRAS device. After the VLAN tagged packet are used
for accounting at the BRAS, the packet whose VLAN tagging is removed maybe
enter the IP core network where L3VPN + MPLS/SR are used for the transport.
In the process, the packet will traverse a trusted domain under the control
of one carrier. And it is possible that the user and service identification
information represented by the VLAN tagging can be mapped to the possible
MPLS encapsulated information or IPv6 encapsulated information if SRv6 is
used as the transport tunnel for the purpose of fine-granularity services.
This is an example that the user/service information can be acquired at the
edge of network without interfering the original user packet though the
information is not as accurate as that could be carried by the original
packet.

Else, I agree with you that Flow-Id should not be used as it is assumed to
be opaque.

Still puzzled though about the ‘user’ information as if the traffic is
encrypted it is also often to hide the user identity.

[Robin] The above example show how to get the ‘user’ information (VLAN
tagging) and how to use the ‘user’ information (in the limited domains).
The information will be lost after traversing the limited domains. If still
hope to use the user information, the only possibility is the possible user
information encrypted. It is another problem beyond the scope of APN and
face much challenges of security, privacy, etc.

In order to explain the issue clearly, I will try use another method. In
fact the packet traverse the network can adopt the form of ‘X in Y’ where Y
is the original packet and X is the outer encapsulation. You mentioned the
user information in X. In fact, the outer encapsulation Y (here VLAN
tagging is the example of Y) can also provide some user information besides
the original user information in X. In the limited domains, the ‘X in Y’
can be changed to ‘X in Y in Z’ (IP in VLAN in MPLS/SRv6) or ‘X in Z’ (IP
in MPLS/SRv6) where Y (VLAN tagging) is mapped to Z (MPLS/SRv6). APN work
focuses on the user information in the ‘X in Y’, ‘X in Y in Z’ and ‘X in
Z’. There is other work, especially in the APP/TSV area, which focuses
directly on the user information in X. They seems similar, but are
different in essence.

Regards

-éric

*From: *ipv6 <[e-mail]> on behalf of Lizhenbin <
[e-mail]>
*Date: *Monday, 28 September 2020 at 19:33
*To: *Linda Dunbar <[e-mail]>, IPv6 List <[e-mail]>,
"[e-mail]" <
[e-mail]>
*Cc: *"[e-mail]" <[e-mail]>
*Subject: *RE: Questions about draft-li-6man-app-aware-ipv6-network-02

Hi Linda,

Please refer to my reply inline. APN mailing list is copied.

Best Regards,

Zhenbin (Robin)

*From:* Linda Dunbar [mailto:[e-mail]]
*Sent:* Saturday, September 26, 2020 2:23 AM
*To:* IPv6 List <[e-mail]>;
[e-mail]
*Subject:* Questions about draft-li-6man-app-aware-ipv6-network-02

Zhenbin, et al,

I have some questions on the draft-li-6man-app-aware-ipv6-network-02:

Page 5: App-aware Edge Device: This network device receives packets from
IPv6 enabled applications and obtains the application characteristic
information.

I am curious how does App-aware Edge Device derives the application
characteristics information ? Your draft mentioned VLAN tagging, How VLAN
tagging can provide Application characteristics information?

[Robin] There are different ways for VLAN tagging to provide application
characteristics information. Here I propose one example: the user
hosts/apps can connect to the home gateway which can add different VLANs
called S-VLAN to identify the different services. For example VLAN1 is used
for Internet service and VLAN2 is used for IPTV service. The home gateway
will connect to the DSLAM on which the VLAN call C-VLAN will be added to
identify the home user. So when the IP-based edge network device receives
the packet, it can derive the user ID and service type information from the
VLAN tagging. We have explained that the APN work focuses on the limited
domains rather than open Internet. The VLAN tagging shows that there is
similar practice in the access network.

Page 6: Is the Application-aware ID another extension field? Or part of
existing extension header? Like a subTLV within the Hop-by-hop options
Header Type?

[Robin] Application-aware ID is an option which can be used in DOH/HBH/SRH.
It is part of existing extension headers. It can be seen as a type of TLV.

Questions about the Application-Aware ID structure in Figure 4:

Why not use IPv6 Header "Priority/Traffic class" field to represent the SLA
Level?

[Robin] The design is to take integrity into account. That is, all the
information can be obtained from the single Application-aware ID.
Traditionally we can get different parts’ information to compose some type
of tuple. The process has effect on the forwarding performance and the
scalability of forwarding entries.

Can you use IPv6 Header’s "Flow Label" field to represent the App ID and
Flow ID?

[Robin] Integrity is the same reason for the problem. In addition "flow
label" will be used for ECMP. Reusing it may cause the compatibility issue.

How can network acquire the information about "USER" information? I would
think most applications encrypt their user information.

[Robin] The above example shows that C-VLAN can be used to acquire USER
information. Though the application may encrypt their user information, not
only APN needs the USER information, but also the carriers need to learn
the USER information for accounting to get revenue. There already exists
the possible way to solve the issue.

What kind of functions do you envision to be listed in the Figure 6’s
Function ID?

[Robin] Figure 6 is to reuse the SRv6 SID. The function ID means just the
functions supported by the existing SRv6. The Application-aware ID is put
into the arguments of the SRv6 SID. The function ID part will not have
effect on the Application-aware ID.

[Robin] Thanks for your comments and questions. Now the draft is in the
early phase. The usage of the Application-aware ID option can be further
discussed.

Thank you very much.

Linda Dunbar