Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt

["Marc Lasserre" <[e-mail]>]

Du,

See my answers inline.

Thanks,
Marc

>To: duwh <[e-mail]>
>Subject: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt

>Du,
>
>Section 8.1.3 describes how a router (PE-r) that does not support VPLS
>bridging functions can participate in the VPLS service.
But why only describes a router? Why not describes a non-bridging MTU?
It is not enough to only describe a route in this chapter.
The title is "8.1.3 Spoke connectivity for non-bridging _devices_".
"Devices" includes router, MTU(such as example of the DSLAM)....

[Marc] MTU devices are defined as bridging capable in the draft, PE-r 
devices as not bridging capable. The case you describe is neither a switch 
nor a router, but simply a cross-connect device, but still falls into the 
PE-r case from a logical standpoint, except that it uses P-VLAN tags as 
demultiplexors instead of PWs.

>PE-r devices do not
>have the ability to add P-VLAN tags (this is a provider bridge function),
>and hence must use PWs on a per physical port basis.
Not true.
[PWE3-ETHERNET] defines the function of "stripping, overwriting or adding
VLAN tags". PE-r support [PWE3-ETHERNET], so PE-r have the ability of add
VLAN tag.

[Marc] The behavior defined in [PWE3-ETHERNET] applies to 802.1Q VLAN tags 
not to 802.1ad Provider VLAN tags.

Please notice that here the two ACs belong to a same PE-r, which is defines
in [draft-ietf-l2vpn-l2-framework-05.txt] 3.2.3. Forwarders:
"The case in which PE1 and PE2 are the same device is an important case
to handle correctly"

[Marc] One-to-one mapping (simple cross-connect) does not require any 
bridging support, but as soon as several ACs need to be part of the same 
bridging domain, support for bridging is required: This can be done in 
either a PE-rs or an MTU-s. If the "MTU" does not support bridging (as in 
your DSLAM example), it can be treated as a PE-r in which case bridging is 
handled by the ingress PE-rs as mentioned earlier.

>A P-VLAN as defined in the IEEE 802.1ad represents a unique customer domain
>within the provider network, which is mapped to a unique VSI.
>In your DSLAM
>example,  P-VLANs are used as circuit identifiers instead.
True.
Using P-VLANs as circuit identifiers is function of [PWE3-ETHERNET].
Here the  DSLAM works in the way of [PWE3-ETHERNET], forwarding frames
from one AC to another AC. One VC is RFC1483B PVC, another AC is Ethernet
VLAN.

[Marc] The use of P-VLANs as circuit ids is not specified anywhere, which is 
why this case is not described.

>The ability for
>PE-rs devices to be able to treat such P-VLANs as virtual ports in order
to
>make them part of the same VPLS domain would be implementation specific.
I think it is not "implementation specific", it is better to write the
function of PE-rs in the this draft <draft-ietf-l2vpn-vpls-ldp-05.txt>.

RFC should guarantee the cooperation of different devices from different
companies.

If, a customer buys a DSLAM from me and buys a PE-rs from you,
The DSLAM support [PWE3-ETHERNET], maps two DSL 1483B PVC to two V-LANs.
The PE-rs supports [VPLS-LDP], maps one P-VLAN to one VPLS.
What will happen if the two DSL PVCs belong to one VPLS?  It does not
work, because the PE-r can not map two P-VLANs to one VPLS and the DSLAM
is non-bridging.
How to solve this issue of cooperation? I think [VPLS-LDP] need add a

[Marc] I do not have a problem saying in section 8.1.3 that "in the case 
where PE-r use P-VLANs as demultiplexors instead of PWs, and PE-rs can treat 
them as such, PE-rs can map these "circuits" into a VPLS domain and provide 
bridging support between them."

function to PE-rs in "8.1.3 Spoke connectivity for non-bridging devices":
"treat such P-VLANs as virtual ports and o make them part of the same
VPLS domain".



>
>Thanks,
>Marc
>
>----- Original Message ----- 
>From: "Du Wenhua" <[e-mail]>
>To: "Loa Andersson" <[e-mail]>; "L2VPN" <[e-mail]>
>Cc: "Thomas Narten" <[e-mail]>; "Alex Zinin" <[e-mail]>
>Sent: Tuesday, October 05, 2004 11:24 AM
>Subject: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt
>
>
>Loa, Rick and Vach
>
>My comment:
>   When non-bridging device use Q-in-Q as spoke VC, the PE-rs
>needs map many P-VLAN to one VPLS instance, not only "one to one".
>
>In "8.1.3 Spoke connectivity for non-bridging devices", the draft gives
>only the example of LSP tunnel as spoke VC. But, when the non-bridge
>device chooses Q-in-Q as spoke VC. The PE-rs need map many P-VLAN to
>one VPLS instance.
>This "many to one" scenario conflicts with the sentence in chapter "9.
>Hierarchical VPLS model using Ethernet Access Network": "Therefore,
>there is a one to one correspondence between a P-VLAN and a VPLS
>instance."
>
>In the flowing example, both CE-1, CE-2 and CE-3 belongs to one VPLS
>instance. So PE1-rs map PVLAN-101 and PVLAN-102 to one VPLS instance.
>
>Figure 1: non-bridge device use Q-in-Q as spoke vc
>                                                          PE2-rs
>                                                          ------
>                                                         /      \
>                                                        |   --   |
>                                                        |  /  \  |
>    CE-1                                                |  \B /  |
>     \                                                   \  --  /
>      \   MTU-r(non-bridging)                            /------
>       \  PE-r(non-bridging)              PE1-rs        /   |
>        \ ------                          ------       /    |
>         /      \                        /      \     /     |
>        | \      |     PVLAN-101        |   --   |---/      |
>        |  ------|- - - - - - - - - - - |--/  \  |          |
>        |   -----|- - - - - - - - - - - |--\B /  |          |
>         \ /    /      PVLAN-102         \  --  / ---\      |
>          ------                          ------      \     |
>         /                                             \    |
>       ----                                             \------
>      | Agg|                                            /      \
>       ----                                            |  --    |
>      /    \                                           | /  \   |
>     CE-2  CE-3                                        | \B /   |
>                                                        \ --   /
>                                                         ------ 
>                                                         PE3-rs
>
>
>Give an example of non-bridging device: IP-DSLAM
>
>In the past, DSLAM have ATM uplink port. One ADSL CE have at least one
>ATM PVC on the uplink port. When a CE belongs to one VPLS, it use
>RFC1483B PVC. Different ADSL CEs use different RFC1483B PVCs, no mater
>they belong to one VPLS or not.
>
>At recently, many carrier move to IP-DSLAM, which replaces ATM uplink
>port with Ethernet uplink port. Many of these IP-DSLAMs just have
>Ethernet
>uplink port, but have no bridging function.
>In these IP-DSLAMs, one ADSL CE map to one P-VLAN (use Q-in-Q
>technologies, because maybe the CE have VLAN tag already) on the
>Ethernet unplink port.
>Different ADSL CEs map to different P-VLAN tags, no mater they belong to
>one VPLS or not. Since IP-DSLAM has no bridging function, it can not map
>many CEs to one P-VLAN.
>So, the PE-rs needs to map many P-VLAN to one VPLS instance.
>
>
>
>IP-DSLAM have Ethernet uplink port. The device just map one DSL to one
>VLAN, as the same way to map one DSL CE site to one 1483 PVC,
>have no bridging function.
>
>Figure 2: IP-DSLAM with Ethernet uplink port
>   CE-1(ADSL PVC 1)
>     \
>      \
>       \  IP-DSLAM(non-bridging)
>        \ ------
>         /      \
>        | \      |      PVLAN-101
>        |  ------|- - - - - - - - - - (Ethernet uplink port)
>        |   -----|- - - - - - - - - -
>         \ /    /       PVLAN-102
>          ------
>         /
>        /
>       /
>     CE-2(ADSL PVC 2)
>
>
>Figure 3: DSLAM with ATM uplink port
>   CE-1(ADSL PVC 1)
>     \
>      \
>       \  IP-DSLAM(non-bridging)
>        \ ------
>         /      \
>        | \      |      PVC-101 RFC1483B
>        |  ------|- - - - - - - - - -  (ATM uplink Port)
>        |   -----|- - - - - - - - - -
>         \ /    /       PVC-102 RFC1483B
>          ------
>         /
>        /
>       /
>     CE-2(ADSL PVC 2)
>
>
>
>
>Yours
>　　　　　　　　Du Wenhua
>　　　　　　　　　　2004-10-05
>
>
>>-----Original Message-----
>>From: Loa Andersson <[e-mail]>
>>Sent: 14:46:00,2004-09-30
>>To: L2VPN <[e-mail]>
>>Subject: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt
>
>>Working group,
>>
>>this mail is to initiate a working group last call
>>on draft-ietf-l2vpn-vpls-ldp-05.txt.
>>
>>Please send comments to the l2vpn mailing list and
>>to the working co-chairs.
>>
>>The last call ends end of business day October 15 PST.
>>
>>Loa, Rick and Vach
>>
>>
>>-- 
>>Loa Andersson
>>
>>Principal Networking Architect
>>Acreo AB                           phone:  [phone]
>>Isafjordsgatan 22                  mobile: [phone]
>>Kista, Sweden                      email:  [e-mail]
>>                                            [e-mail]
>= = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =