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

[Du wenhua <[e-mail]>]

Marc
>[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."
 It is OK to add such words. Thank you.
                                                --Du Wenhua


----- Original Message ----- 
From: "Marc Lasserre" <[e-mail]>
To: <[e-mail]>; "Loa Andersson" <[e-mail]>; "L2VPN" <[e-mail]>
Cc: "Thomas Narten" <[e-mail]>; "Alex Zinin" <[e-mail]>
Sent: Friday, October 08, 2004 11:24 PM
Subject: Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt


> 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]
> >= = = = = = = = = = = = = = = = = = = =
> = = = = = = = = = = = = = = = = = = = =
> 
> 
> 
>