Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt
Du Wenhua <duwh@huawei.com> Fri, 08 October 2004 12:42 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20151 for <l2vpn-web-archive@ietf.org>; Fri, 8 Oct 2004 08:42:21 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFuEf-0005oX-Mq for l2vpn-web-archive@ietf.org; Fri, 08 Oct 2004 08:52:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFu3j-00021k-OA; Fri, 08 Oct 2004 08:41:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFu1R-0001mm-Og for l2vpn@megatron.ietf.org; Fri, 08 Oct 2004 08:38:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19970 for <l2vpn@ietf.org>; Fri, 8 Oct 2004 08:38:56 -0400 (EDT)
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFuB7-0005js-FV for l2vpn@ietf.org; Fri, 08 Oct 2004 08:49:12 -0400
Received: from d07358 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I5900MFIN0H5O@mta0.huawei.com> for l2vpn@ietf.org; Fri, 08 Oct 2004 20:36:17 +0800 (CST)
Date: Fri, 08 Oct 2004 20:39:40 +0800
From: Du Wenhua <duwh@huawei.com>
To: Marc Lasserre <marc@riverstonenet.com>, Loa Andersson <loa@pi.se>, L2VPN <l2vpn@ietf.org>
Message-id: <0I5900MFJN0H5O@mta0.huawei.com>
Organization: Huawei Techlonogies, Co., Ltd
MIME-version: 1.0
X-Mailer: Foxmail 4.2 [cn]
Content-type: text/plain; charset="GB2312"
Content-transfer-encoding: quoted-printable
X-imss-version: 2.7
X-imss-result: Passed
X-imss-approveListMatch: *@huawei.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <narten@us.ibm.com>, Alex Zinin <zinin@psg.com>
Subject: Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: duwh@huawei.com
List-Id: l2vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
Sender: l2vpn-bounces@ietf.org
Errors-To: l2vpn-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8cb9b411340046bf4080a729180a0672
Content-Transfer-Encoding: quoted-printable
Hi,Marc Lasserre, Thanks for your reply. See my comments bellow. >To: duwh <duwh@huawei.com> >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).... >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. 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" >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. >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 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" <duwh@huawei.com> >To: "Loa Andersson" <loa@pi.se>; "L2VPN" <l2vpn@ietf.org> >Cc: "Thomas Narten" <narten@us.ibm.com>; "Alex Zinin" <zinin@psg.com> >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 <loa@pi.se> >>Sent: 14:46:00,2004-09-30 >>To: L2VPN <l2vpn@ietf.org> >>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: +46 8 632 77 14 >>Isafjordsgatan 22 mobile: +46 739 81 21 64 >>Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.se >= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
- wg last call - draft-ietf-l2vpn-vpls-ldp-05.txt Loa Andersson
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Yakov Rekhter
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Yakov Rekhter
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Du Wenhua
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Marc Lasserre
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Marc Lasserre
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Marc Lasserre
- Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-… Du Wenhua
- Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-… Marc Lasserre
- Re: Re: wg last call - draft-ietf-l2vpn-vpls-ldp-… Du wenhua
- RE: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Busschbach, Peter B (Peter)
- Re: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Marc Lasserre
- RE: wg last call - draft-ietf-l2vpn-vpls-ldp-05.t… Busschbach, Peter B (Peter)