From exim@www1.ietf.org Mon Mar 1 14:06:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28309 for ; Mon, 1 Mar 2004 14:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsjj-000122-HY for l2vpn-archive@odin.ietf.org; Mon, 01 Mar 2004 14:05:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21J5tZU003965 for l2vpn-archive@odin.ietf.org; Mon, 1 Mar 2004 14:05:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsjj-00011s-3B for l2vpn-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:05:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28298 for ; Mon, 1 Mar 2004 14:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axsjg-0002ct-00 for l2vpn-web-archive@ietf.org; Mon, 01 Mar 2004 14:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axsin-0002Xl-00 for l2vpn-web-archive@ietf.org; Mon, 01 Mar 2004 14:04:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axsi1-0002SP-00 for l2vpn-web-archive@ietf.org; Mon, 01 Mar 2004 14:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axshs-0000vQ-Jc; Mon, 01 Mar 2004 14:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsgx-0000up-D6 for l2vpn@optimus.ietf.org; Mon, 01 Mar 2004 14:03:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28172 for ; Mon, 1 Mar 2004 14:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axsgu-0002KY-00 for l2vpn@ietf.org; Mon, 01 Mar 2004 14:03:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axsg9-0002EG-00 for l2vpn@ietf.org; Mon, 01 Mar 2004 14:02:14 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AxsfF-00021y-00 for l2vpn@ietf.org; Mon, 01 Mar 2004 14:01:17 -0500 Received: from ma8117exch002u.wins.lucent.com (h152-148-8-136.lucent.com [152.148.8.136]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21J0ir04254 for ; Mon, 1 Mar 2004 13:00:44 -0600 (CST) Received: by ma8117exch002u.inse.lucent.com with Internet Mail Service (5.5.2657.72) id <15S59V7H>; Mon, 1 Mar 2004 14:00:43 -0500 Message-ID: <4F9DBE266768DC46A1F17E875D371641044581E8@ma8117exch002u.inse.lucent.com> From: "Hunt, Douglas H (Douglas)" To: Mustapha Aissaoui , "Hunt, Douglas H (Douglas)" Cc: l2vpn@ietf.org Subject: RE: Comments on draft-aissaoui-l2vpn-vpws-iw-oam-00.txt Date: Mon, 1 Mar 2004 14:00:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Mustapha, Thanks for your responses. I've included further comments inline below prepended by DH. Regards, Doug -----Original Message----- From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] Sent: Saturday, February 28, 2004 8:07 AM To: Hunt, Douglas H (Douglas) Cc: l2vpn@ietf.org Subject: Re: Comments on draft-aissaoui-l2vpn-vpws-iw-oam-00.txt Doug, thanks for the comments. See my response below prepended by MA. Regards, Mustapha. ----------- "Hunt, Douglas H (Douglas)" wrote: > > Here are comments on draft-aissaoui-l2vpn-vpws-iw-oam-00.txt, regarding (1) some of the terminology being used, and (2) concerns that the draft is unnecessarily limiting the set of relevant network scenarios. > > Regarding the terminology, the l2vpn framework draft (draft-ietf-l2vpn-l2-framework-03) refers to "heterogeneous transport" in section 3.2.2 and to "heterogeneous pseudowires" in section 3.3.3. In both cases, the framework draft is describing a characteristic of a given pseudowire. The transport or the pseudowire is defined to be homogeneous if the 2 ACs are of the same technology, and heterogeneous otherwise. > > Draft-aissaoui uses the terms "heterogeneous" and "homogeneous" in some different ways -- to characterize ACs (section 2), or a VPWS itself (section 3.2), or a VPWS OAM model (section 3.2). In the case of section 2, it appears that the terms "homogeneous AC" and "heterogeneous AC" can be replaced by "homogeneous PW" and "heterogeneous PW" respectively and still convey the intended meaning. > > However it is not clear how to reconcile the use of "homogeneous VPWS" and "heterogeneous VPWS" in Section 3.2 with the use of these terms in the framework draft. In particular it is not clear whether a VPWS constructed from a network that contains some homogeneous PWs as well as some heterogeneous PWs would be regarded as a homogeneous VPWS or a heterogeneous VPWS. It may be helpful to remove the terms "homogeneous VPWS" and "heterogeneous VPWS", as they do not seem necessary in defining an OAM model, since the homogeneous and heterogeneous VPWS OAM models defined in section 3.2 are in terms of procedures that apply to a single pseudowire. MA> I can see there is a terminology issue. A VPWS is a collection of CE's attached through a set of . It is this latter that can be charaterized as "homogeneous" or "heterogeneous". This set is referred to in the L2 VPN framework as a "virtual circuit" in Section 3.3. DH> agree OAM can be applied to a segment of the virtual circuit or end-to-end. That is why, the draft does not use the the terminology such as "heterogeneous PW", since the PW is just a segment of the end-to-end circuit. DH> agree So, one possible way out is to refer to them as "homogeneous circuit" and "heterogeneous circuit". Let me know what you think. DH> Or perhaps "homogeneous virtual circuit" and "heterogeneous virtual circuit", or the shorter forms "homogeneous VC" and "heterogeneous VC" I will also change the terminology of "homogeneous/heterogeneous VPWS model" to "homogeneous/heterogeneous circuit OAM model". DH> Or, similar to the above, the terms "homogeneous/heterogeneous VC OAM model" could be used. > Regarding the set of network scenarios addressed, the draft currently restricts the set of PW types being considered for some of the VPWS scenarios, and this in turn restricts the set of VPWS OAM models considered. In particular, the draft does not consider a likely scenario in which a network evolves from one with just FR and ATM ACs to one with FR, ATM, and/or Ethernet ACs. In the case where the VPWS ACs are either ATM or FR (section 5.1), the draft allows for either FR or ATM PW types, and for either the homogeneous or heterogeneous VPWS OAM models to be used. Specifically, section 5.1.2 indicates that when the PW type is ATM, the homogeneous VPWS OAM procedures may be used. However in the case where the VPWS ACs may be ATM, FR, or Ethernet, the draft considers only the cases where a PW is of type Ethernet (section 5.2) or of type IP (section 5.3), and the heterogeneous VPWS OAM model is proposed for both these PW types. The OAM models in the draft can be more broadly ! applicable if PWs of type ATM (as well as Ethernet and IP) are considered, as some service providers may evolve networks that are entirely FR or ATM at the edges to networks with some Ethernet ACs at the edge. An example evolution might be to add gigE ACs at some locations in a corporate customer's VPN. In this scenario, a service provider that had implemented its VPWS service using PWs of type ATM may continue to do so. Considering this case in the draft would support the operational requirements of these service providers. MA> This is a good point. In general, if you extend a ATM PW to a remote Ethernet AC, then this is still a "heterogeneous circuit". DH> Or "heterogeneous VC" if using the terminology suggested above But, as in the case of FR-ATM in section 5.1.2, you can use what the draft refer to as "homogeneous OAM model". DH> agree The key point is the following: if the link layer of the AC is terminated at the PE, then the link layer OAM is also terminated. I will add this example into section 5 of the draft. DH> Then as I understand it, section 5 of the draft will consider the interworking FR, ATM, and Ethernet ACs over the PSN when the PW can be of type Ethernet, or IP, or ATM. As in the case of FR-ATM in section 5.1.2, if the PW type is ATM, the homogeneous (VC) OAM procedures may be used. With these modifications to section 5, some changes would also need to be made to section 2. Perhaps the simplest change is to add an item 5 to the list VPWS types considered in the document; item 5 would look very much like items 3 or 4, except that the PW type is ATM. Another way to modify section 2 would be to combine the current items 3 and 4, together with the item 5 as suggested above, into a single modified item 3 that would read "VPWS with heterogeneous ..., and in which the PW type may be Ethernet, IP, or ATM." In this case the terms "Ethernet Interworking VPWS" and "IP Interworking VPWS" would not be needed, and sections 5.2 and 5.3 plus the additional text covering the ATM PW t! ype can be combined into a single updated section that would have a structure similar to that of section 5.1. Like section 5.1, the updated section would contain two subsections, covering the heterogeneous and the homogeneous (VC) OAM models. From exim@www1.ietf.org Wed Mar 3 18:49:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07518 for ; Wed, 3 Mar 2004 18:49:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayg75-0005WR-Hh for l2vpn-archive@odin.ietf.org; Wed, 03 Mar 2004 18:49:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23NnJtP021221 for l2vpn-archive@odin.ietf.org; Wed, 3 Mar 2004 18:49:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayg75-0005WC-AR for l2vpn-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 18:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07361 for ; Wed, 3 Mar 2004 18:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayg72-0004F8-00 for l2vpn-web-archive@ietf.org; Wed, 03 Mar 2004 18:49:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayg50-0003h0-00 for l2vpn-web-archive@ietf.org; Wed, 03 Mar 2004 18:47:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayg3x-0003UY-00 for l2vpn-web-archive@ietf.org; Wed, 03 Mar 2004 18:46:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyftK-0000mo-MV for l2vpn-web-archive@ietf.org; Wed, 03 Mar 2004 18:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyftG-0004Oe-Sp; Wed, 03 Mar 2004 18:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfsR-0004Go-1J for l2vpn@optimus.ietf.org; Wed, 03 Mar 2004 18:34:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06860 for ; Wed, 3 Mar 2004 18:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfsN-0001e9-00 for l2vpn@ietf.org; Wed, 03 Mar 2004 18:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayfrm-0001S3-00 for l2vpn@ietf.org; Wed, 03 Mar 2004 18:33:31 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ayfqc-0000xq-00 for l2vpn@ietf.org; Wed, 03 Mar 2004 18:32:18 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i23NVfG01303 for ; Wed, 3 Mar 2004 18:31:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 18:31:41 -0500 Message-ID: <710197BD5AF9D4119E4400508BCFA1360823701B@zcard04u.ca.nortel.com> From: "Dinesh Mohan" To: l2vpn@ietf.org Subject: [VPLS OAM] Follow-up from Seoul L2VPN session Date: Wed, 3 Mar 2004 18:31:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40174.9F210C16" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40174.9F210C16 Content-Type: text/plain As a follow-up from yesterday's discussion, let me first point out to the following slides that were presented during the meeting: http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt The drafts that were represented are: http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.txt During the meeting it was acknowledged that VPLS OAM is an important area to tackle since it is a key requirement for providers. It was also my observation that the material was generally well received. However, few questions that came up during discussions included: - What really is the scope of VPLS OAM? - Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport? Subsequently, it was generally felt that as next steps: - Scope for VPLS OAM needs to be clarified - Requirements and Framework for VPLS OAM needs to be created. There would then serve as inputs to other working groups/bodies. - VPLS specific OAM solutions should then be worked in IETF. Towards that, I would like to add that: - The drafts introduce important constructs/framework for dealing with the OAM that differentiate between the service/network layers. It also aligns with ongoing OAM work in other bodies (we may not want to re-invent the wheel!) - The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a Ethernet service irrespective of the underlying transport mechanism e.g. LDP based or BGP based solutions. - Infact, the mechanisms proposed equally apply to Ethernet VPWS as a Ethernet service. - MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the presentation and in the drafts. - There is no reason, why service layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as an optimization, however, for preserving the layer sanity, each layer still needs to be equipped with right OAM toolset. Comments? Best Regards, Dinesh Mohan Tel: (613) 763-4794 [ESN: 393-4794] Nortel Networks Fax: (613) 763-2697 3500 Carling Ave. Email: mohand@nortelnetworks.com Ottawa, Canada K1Y4H7 http://www.nortelnetworks.com ------_=_NextPart_001_01C40174.9F210C16 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [VPLS OAM] Follow-up from Seoul L2VPN session

As a follow-up from yesterday's = discussion, let me first point out to the following slides that were = presented during the meeting:

http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt

The drafts that were represented = are:
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l= 2vpn-vpls-fm-00.txt
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l= 2vpn-vpls-pm-00.txt

During the meeting it was acknowledged = that VPLS OAM is an important area to tackle since it is a key = requirement for providers.

It was also my observation that the = material was generally well received. However, few questions that came = up during discussions included:

- What really is the scope of VPLS = OAM?
- Should it be different from = Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS = deals specifically with MPLS/IP transport?

Subsequently, it was generally felt = that as next steps:
- Scope for VPLS OAM needs to be = clarified
- Requirements and Framework for VPLS = OAM needs to be created. There would then serve as inputs to other = working groups/bodies.

- VPLS specific OAM solutions should = then be worked in IETF.

Towards that, I would like to add = that:
- The drafts introduce important = constructs/framework for dealing with the OAM that differentiate = between the service/network layers. It also aligns with ongoing OAM = work in other bodies (we may not want to re-invent the = wheel!)

- The FM/PM mechanisms proposed in the = drafts are applicable for VPLS as a Ethernet service irrespective of = the underlying transport mechanism e.g. LDP based or BGP based = solutions.

- Infact, the mechanisms proposed = equally apply to Ethernet VPWS as a Ethernet service.
- MPLS based OAM mechanisms belong to = the MPLS layer, as highlighted in the presentation and in the = drafts.
- There is no reason, why service = layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as = an optimization, however, for preserving the layer sanity, each layer = still needs to be equipped with right OAM toolset.

Comments?

Best Regards,
Dinesh = Mohan           &= nbsp;           &= nbsp;           &= nbsp;      
Tel: (613) 763-4794 [ESN: = 393-4794]     Nortel Networks
Fax: (613) = 763-2697          &nbs= p;           &nbs= p;          3500 Carling = Ave.
Email: = mohand@nortelnetworks.com        = Ottawa, Canada K1Y4H7
http://www.nortelnetworks.com


------_=_NextPart_001_01C40174.9F210C16-- From exim@www1.ietf.org Thu Mar 4 10:48:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27875 for ; Thu, 4 Mar 2004 10:48:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv4Y-0007yn-Jp for l2vpn-archive@odin.ietf.org; Thu, 04 Mar 2004 10:47:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Flgtg030669 for l2vpn-archive@odin.ietf.org; Thu, 4 Mar 2004 10:47:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv4Y-0007ya-EL for l2vpn-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 10:47:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27758 for ; Thu, 4 Mar 2004 10:47:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv4W-00035B-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 10:47:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayv3P-0002ea-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 10:46:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv2E-0002NP-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 10:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv1y-0007dO-GI; Thu, 04 Mar 2004 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv1m-0007cY-Kn for l2vpn@optimus.ietf.org; Thu, 04 Mar 2004 10:44:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27473 for ; Thu, 4 Mar 2004 10:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv1k-0002JV-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 10:44:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayv0s-00026h-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 10:43:56 -0500 Received: from howler.tri.sbc.com ([205.173.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv09-0001uI-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 10:43:09 -0500 Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.9) with ESMTP id i24Fh5xu005630; Thu, 4 Mar 2004 09:43:07 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (trimail2.ad.tri.sbc.com [144.60.55.227]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id i24Fgx8x023754; Thu, 4 Mar 2004 09:42:59 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Mar 2004 09:42:59 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D61C4@trimail2> From: "Serbest, Yetik" To: "'Dinesh Mohan'" , l2vpn@ietf.org Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session Date: Thu, 4 Mar 2004 09:42:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401FF.5E1D8E20" X-Scanned-By: MIMEDefang 2.38 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C401FF.5E1D8E20 Content-Type: text/plain Dinesh, Thank you the concise and excellent update. OAM for L2VPN services (VPWS and VPLS alike) is an important requirement. My understanding is that your drafts are summary of the work going on in ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as Ethernet layer procedures are defined. There is a draft aimed to be specific to VPLS. It is the HVPLS-OAM draft, which received four main objections: 1. Special TTL (Time To Live) processing: HVPLS-OAM proposal requires that the PE router remember the TTL value of the VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and place it in the TTL value of the VC-LSP (PW between PEs) at the egress of the PE. This is a layering violation. 2. No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is specifically designed for the architecture with MPLS attachment circuits. 3. Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE tunnels). 4. Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal utilizes an OAM label (value of 14) at the bottom of the label stack, which is aligned with ITU Y.1711. With ECMP hashing using all the labels in the stack, OAM packets will not follow the same path as the customer data packets. Based on this observation, the question is "do we need to work on OAM solutions in this group?" As you put it, perhaps we should only define the requirements/framework for L2VPN OAM, and let other bodies work on the solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS. I would appreciate some discussion on this in the group. Thanks, yetik -----Original Message----- From: Dinesh Mohan [mailto:mohand@nortelnetworks.com] Sent: Wednesday, March 03, 2004 5:32 PM To: l2vpn@ietf.org Subject: [VPLS OAM] Follow-up from Seoul L2VPN session As a follow-up from yesterday's discussion, let me first point out to the following slides that were presented during the meeting: http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt The drafts that were represented are: http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.txt During the meeting it was acknowledged that VPLS OAM is an important area to tackle since it is a key requirement for providers. It was also my observation that the material was generally well received. However, few questions that came up during discussions included: - What really is the scope of VPLS OAM? - Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport? Subsequently, it was generally felt that as next steps: - Scope for VPLS OAM needs to be clarified - Requirements and Framework for VPLS OAM needs to be created. There would then serve as inputs to other working groups/bodies. - VPLS specific OAM solutions should then be worked in IETF. Towards that, I would like to add that: - The drafts introduce important constructs/framework for dealing with the OAM that differentiate between the service/network layers. It also aligns with ongoing OAM work in other bodies (we may not want to re-invent the wheel!) - The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a Ethernet service irrespective of the underlying transport mechanism e.g. LDP based or BGP based solutions. - Infact, the mechanisms proposed equally apply to Ethernet VPWS as a Ethernet service. - MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the presentation and in the drafts. - There is no reason, why service layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as an optimization, however, for preserving the layer sanity, each layer still needs to be equipped with right OAM toolset. Comments? Best Regards, Dinesh Mohan Tel: (613) 763-4794 [ESN: 393-4794] Nortel Networks Fax: (613) 763-2697 3500 Carling Ave. Email: mohand@nortelnetworks.com Ottawa, Canada K1Y4H7 http://www.nortelnetworks.com ------_=_NextPart_001_01C401FF.5E1D8E20 Content-Type: text/html [VPLS OAM] Follow-up from Seoul L2VPN session

Dinesh,

 

Thank you the concise and excellent update.

 

OAM for L2VPN services (VPWS and VPLS alike) is an important requirement.

 

My understanding is that your drafts are summary of the work going on in ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as Ethernet layer procedures are defined. There is a draft aimed to be specific to VPLS. It is the HVPLS-OAM draft, which received four main objections:

1.       Special TTL (Time To Live) processing: HVPLS-OAM proposal requires that the PE router remember the TTL value of the VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and place it in the TTL value of the VC-LSP (PW between PEs) at the egress of the PE. This is a layering violation.

2.       No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is specifically designed for the architecture with MPLS attachment circuits.

3.       Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE tunnels).

4.       Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal utilizes an OAM label (value of 14) at the bottom of the label stack, which is aligned with ITU Y.1711. With ECMP hashing using all the labels in the stack, OAM packets will not follow the same path as the customer data packets.

 

Based on this observation, the question is "do we need to work on OAM solutions in this group?" As you put it, perhaps we should only define the requirements/framework for L2VPN OAM, and let other bodies work on the solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS.

 

I would appreciate some discussion on this in the group.

 

Thanks,

yetik

 

-----Original Message-----
From: Dinesh Mohan [mailto:mohand@nortelnetworks.com]
Sent: Wednesday, March 03, 2004 5:32 PM
To: l2vpn@ietf.org
Subject: [VPLS OAM] Follow-up from Seoul L2VPN session

 

As a follow-up from yesterday's discussion, let me first point out to the following slides that were presented during the meeting:

http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt

The drafts that were represented are:
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.txt

During the meeting it was acknowledged that VPLS OAM is an important area to tackle since it is a key requirement for providers.

It was also my observation that the material was generally well received. However, few questions that came up during discussions included:

- What really is the scope of VPLS OAM?
- Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport?

Subsequently, it was generally felt that as next steps:
- Scope for VPLS OAM needs to be clarified
- Requirements and Framework for VPLS OAM needs to be created. There would then serve as inputs to other working groups/bodies.

- VPLS specific OAM solutions should then be worked in IETF.

Towards that, I would like to add that:
- The drafts introduce important constructs/framework for dealing with the OAM that differentiate between the service/network layers. It also aligns with ongoing OAM work in other bodies (we may not want to re-invent the wheel!)

- The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a Ethernet service irrespective of the underlying transport mechanism e.g. LDP based or BGP based solutions.

- Infact, the mechanisms proposed equally apply to Ethernet VPWS as a Ethernet service.
- MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the presentation and in the drafts.
- There is no reason, why service layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as an optimization, however, for preserving the layer sanity, each layer still needs to be equipped with right OAM toolset.

Comments?

Best Regards,
Dinesh Mohan                                          
Tel: (613) 763-4794 [ESN: 393-4794]     Nortel Networks
Fax: (613) 763-2697                                 3500 Carling Ave.
Email: mohand@nortelnetworks.com        Ottawa, Canada K1Y4H7
http://www.nortelnetworks.com

 

------_=_NextPart_001_01C401FF.5E1D8E20-- From exim@www1.ietf.org Thu Mar 4 11:12:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29060 for ; Thu, 4 Mar 2004 11:12:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvRq-0002UY-Mq for l2vpn-archive@odin.ietf.org; Thu, 04 Mar 2004 11:11:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24GBkDI009572 for l2vpn-archive@odin.ietf.org; Thu, 4 Mar 2004 11:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvRq-0002UJ-Fy for l2vpn-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 11:11:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29028 for ; Thu, 4 Mar 2004 11:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyvRn-00004d-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 11:11:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyvQy-0007hE-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 11:10:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyvQD-0007VL-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 11:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvQA-0001uH-PD; Thu, 04 Mar 2004 11:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvPv-0001sY-Bj for l2vpn@optimus.ietf.org; Thu, 04 Mar 2004 11:09:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28891 for ; Thu, 4 Mar 2004 11:09:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyvPs-0007SZ-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 11:09:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyvOq-0007GC-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 11:08:42 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyvNy-0006uE-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 11:07:46 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2004 08:19:07 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i24G7CiQ009292; Thu, 4 Mar 2004 08:07:12 -0800 (PST) Received: from tnadeauvmware (che-vpn-cluster-2-38.cisco.com [10.86.242.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGN21108; Thu, 4 Mar 2004 11:07:10 -0500 (EST) From: "Thomas D. Nadeau" To: "'Serbest, Yetik'" , "'Dinesh Mohan'" , Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session Date: Thu, 4 Mar 2004 11:06:50 -0500 Message-ID: <008601c40202$b4b44640$805aa8c0@tnadeauvmware> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C401D8.CBDE3E40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D61D61C4@trimail2> Importance: Normal Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C401D8.CBDE3E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of Serbest, Yetik Sent: Thursday, March 04, 2004 10:43 AM To: 'Dinesh Mohan'; l2vpn@ietf.org Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session Dinesh, Thank you the concise and excellent update. OAM for L2VPN services (VPWS and VPLS alike) is an important requirement. My understanding is that your drafts are summary of the work going on in ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as Ethernet layer procedures are defined. There is a draft aimed to be specific to VPLS. It is the HVPLS-OAM draft, which received four main objections: 1. Special TTL (Time To Live) processing: HVPLS-OAM proposal requires that the PE router remember the TTL value of the VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and place it in the TTL value of the VC-LSP (PW between PEs) at the egress of the PE. This is a layering violation. 2. No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is specifically designed for the architecture with MPLS attachment circuits. 3. Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE tunnels). 4. Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal utilizes an OAM label (value of 14) at the bottom of the label stack, which is aligned with ITU Y.1711. With ECMP hashing using all the labels in the stack, OAM packets will not follow the same path as the customer data packets. Based on this observation, the question is "do we need to work on OAM solutions in this group?" As you put it, perhaps we should only define the requirements/framework for L2VPN OAM, and let other bodies work on the solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS. [>] I think it is important to have a draft such as the one we just proposed because it makes clear how to test the complete picture without having people re-invent the wheel (i.e.: re-use existing tools/techniques), or try to do things as described in points 1-4 for the sake of solving this specific VPLS OAM problem. As such, the actual mechanisms probably should be defined in their respective standards bodies (PWs in PWE3, Enet in IEEE, etc...), thus this draft would be considered informational in nature as it only describes how to combine these mechanisms together to achieve the goal of describing comprehensive OAM for VPLS. --Tom I would appreciate some discussion on this in the group. Thanks, yetik -----Original Message----- From: Dinesh Mohan [mailto:mohand@nortelnetworks.com] Sent: Wednesday, March 03, 2004 5:32 PM To: l2vpn@ietf.org Subject: [VPLS OAM] Follow-up from Seoul L2VPN session As a follow-up from yesterday's discussion, let me first point out to the following slides that were presented during the meeting: http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt The drafts that were represented are: http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00 .txt http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00 .txt During the meeting it was acknowledged that VPLS OAM is an important area to tackle since it is a key requirement for providers. It was also my observation that the material was generally well received. However, few questions that came up during discussions included: - What really is the scope of VPLS OAM? - Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport? Subsequently, it was generally felt that as next steps: - Scope for VPLS OAM needs to be clarified - Requirements and Framework for VPLS OAM needs to be created. There would then serve as inputs to other working groups/bodies. - VPLS specific OAM solutions should then be worked in IETF. Towards that, I would like to add that: - The drafts introduce important constructs/framework for dealing with the OAM that differentiate between the service/network layers. It also aligns with ongoing OAM work in other bodies (we may not want to re-invent the wheel!) - The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a Ethernet service irrespective of the underlying transport mechanism e.g. LDP based or BGP based solutions. - Infact, the mechanisms proposed equally apply to Ethernet VPWS as a Ethernet service. - MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the presentation and in the drafts. - There is no reason, why service layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as an optimization, however, for preserving the layer sanity, each layer still needs to be equipped with right OAM toolset. Comments? Best Regards, Dinesh Mohan Tel: (613) 763-4794 [ESN: 393-4794] Nortel Networks Fax: (613) 763-2697 3500 Carling Ave. Email: mohand@nortelnetworks.com Ottawa, Canada K1Y4H7 http://www.nortelnetworks.com ------=_NextPart_000_0087_01C401D8.CBDE3E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From:=20 l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of=20 Serbest, Yetik
Sent: Thursday, March 04, 2004 10:43=20 AM
To: 'Dinesh Mohan'; l2vpn@ietf.org
Subject: RE: = [VPLS=20 OAM] Follow-up from Seoul L2VPN session

Dinesh,

 

Thank you the concise = and=20 excellent update.

 

OAM for L2VPN services = (VPWS and=20 VPLS alike) is an important requirement.

 

My understanding is that = your=20 drafts are summary of the work going on in ITU-T Q.3/13, IEEE 802.1 = and MEF.=20 They are not specific to this group, as Ethernet layer procedures are = defined.=20 There is a draft aimed to be specific to VPLS. It is the HVPLS-OAM = draft,=20 which received four main objections:

1.      =20 Special TTL (Time To = Live)=20 processing: HVPLS-OAM proposal = requires that=20 the PE router remember the TTL value of the VC Label (VC-LSP spoke) at = the=20 ingress of the PE, and decrement and place it in the TTL value of the = VC-LSP=20 (PW between PEs) at the egress of the PE. This is a layering=20 violation.

2.      =20 No support for 802.1Q = (VLANs)=20 spokes: HVPLS-OAM proposal is=20 specifically designed for the architecture with MPLS attachment=20 circuits.

3.      =20 Transport (MPLS)=20 dependency: HVPLS-OAM solution is = for MPLS=20 transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE = tunnels).

4.      =20 Lack of ECMP (Equal Cost = Multi-Path) support: HVPLS-OAM proposal = utilizes an=20 OAM label (value of 14) at the bottom of the label stack, which is = aligned=20 with ITU Y.1711. With ECMP hashing using all the labels in the stack, = OAM=20 packets will not follow the same path as the customer data=20 packets.

 

Based on=20 this observation, the question is "do we need to work on OAM solutions = in this=20 group?" As you put it, perhaps we should only define the=20 requirements/framework for L2VPN OAM, and let other bodies work on the = solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS.
 
[>]  I think = it is=20 important to have a draft such as the one we just proposed = because
it makes=20 clear how to test the complete picture without having people=20 re-invent

the wheel (i.e.: = re-use existing=20 tools/techniques), or try to do things as described in points 1-4=20

for the sake of=20 solving this specific = VPLS OAM=20 problem. As such, the actual mechanisms
probably should be defined = in their=20 respective standards bodies (PWs in PWE3,
Enet in IEEE, etc...), = thus this=20 draft would be considered informational in = nature

as it only describes = how to=20 combine these mechanisms together to achieve

the goal of = describing=20 comprehensive OAM for VPLS.

 

    --Tom

 

 

 

I would appreciate some = discussion=20 on this in the group.

 

Thanks,

yetik

 

-----Original=20 Message-----
From: = Dinesh=20 Mohan [mailto:mohand@nortelnetworks.com]
Sent: Wednesday, March 03, 2004 = 5:32=20 PM
To:=20 l2vpn@ietf.org
Subject: [VPLS=20 OAM] Follow-up from Seoul L2VPN session

 

As a follow-up from = yesterday's=20 discussion, let me first point out to the following slides that were = presented=20 during the meeting:

http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt=20

The drafts that were = represented=20 are:
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls= -fm-00.txt=20
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls= -pm-00.txt=20

During the meeting it = was=20 acknowledged that VPLS OAM is an important area to tackle since it is = a key=20 requirement for providers.

It was also my = observation that=20 the material was generally well received. However, few questions that = came up=20 during discussions included:

- What really is the = scope of VPLS=20 OAM?
- Should it be different = from=20 Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since = VPLS deals=20 specifically with MPLS/IP transport?

Subsequently, it was = generally=20 felt that as next steps:
- Scope for VPLS OAM = needs to be=20 clarified
- Requirements and = Framework for=20 VPLS OAM needs to be created. There would then serve as inputs to = other=20 working groups/bodies.

- VPLS specific OAM = solutions=20 should then be worked in IETF.

Towards that, I would = like to add=20 that:
- The drafts introduce = important=20 constructs/framework for dealing with the OAM that differentiate = between the=20 service/network layers. It also aligns with ongoing OAM work in other = bodies=20 (we may not want to re-invent the wheel!)

- The FM/PM mechanisms = proposed in=20 the drafts are applicable for VPLS as a Ethernet service irrespective = of the=20 underlying transport mechanism e.g. LDP based or BGP based=20 solutions.

- Infact, the mechanisms = proposed=20 equally apply to Ethernet VPWS as a Ethernet service. =
- MPLS=20 based OAM mechanisms belong to the MPLS layer, as highlighted in the=20 presentation and in the drafts.
- There = is no reason,=20 why service layer OAM mechanisms cannot interwork with the MPLS-based=20 mechanisms as an optimization, however, for preserving the layer = sanity, each=20 layer still needs to be equipped with right OAM = toolset.

Comments? =

Best Regards,
Dinesh=20 = Mohan           &n= bsp;           &nb= sp;           &nbs= p;      =20
Tel: (613)=20 763-4794 [ESN: 393-4794]     Nortel = Networks=20
Fax: (613)=20 = 763-2697           = ;            =          =20 3500 Carling Ave.
Email:=20 mohand@nortelnetworks.com        = Ottawa,=20 Canada K1Y4H7
http://www.nortelnetworks.com

 

------=_NextPart_000_0087_01C401D8.CBDE3E40-- From exim@www1.ietf.org Thu Mar 4 15:34:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13034 for ; Thu, 4 Mar 2004 15:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyzXT-0005YM-Kg for l2vpn-archive@odin.ietf.org; Thu, 04 Mar 2004 15:33:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24KXpMC021345 for l2vpn-archive@odin.ietf.org; Thu, 4 Mar 2004 15:33:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyzXT-0005YC-8p for l2vpn-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 15:33:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13022 for ; Thu, 4 Mar 2004 15:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyzXR-0005tM-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 15:33:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyzWV-0005jc-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 15:32:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyzVn-0005Zi-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 15:32:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyzVh-000526-P7; Thu, 04 Mar 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyzVW-00051Y-4x for l2vpn@optimus.ietf.org; Thu, 04 Mar 2004 15:31:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12973 for ; Thu, 4 Mar 2004 15:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyzVV-0005Yj-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 15:31:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyzUd-0005Ox-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 15:30:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AyzU5-0005Co-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 15:30:21 -0500 Received: from sajassi-w2k4.cisco.com (sjc-vpn3-341.cisco.com [10.21.65.85]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i24KTlD2024140; Thu, 4 Mar 2004 12:29:48 -0800 (PST) Message-Id: <4.3.2.7.2.20040304120028.029c5838@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Mar 2004 12:29:47 -0800 To: "Serbest, Yetik" , "'Dinesh Mohan'" , l2vpn@ietf.org From: Ali Sajassi Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D61D61C4@trimail2> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_146922303==_.ALT" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 --=====================_146922303==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Yetik, Given that VPLS service as defined in the L2VPN framework is an emulated LAN service wrt to a group of CEs and it can use different PSN network (e.g., IP or MPLS), it is important to be able to address VPLS OAM at the service layer (as well as network layer) and for different types of PSN. The propose of this draft is mainly two folds: 1) to inform the IETF community of the current mechanisms under development in other standard bodies in regard to Ethernet services and 2) to show the applicability of these mechanisms to VPLS service. The draft just describes the concepts and mechanisms for fault management portion of OAM at the high level and it does that in order to acquaint the IETF audience with the type of tools/mechanisms that will be available for this purpose and to open the discussion to see if these tools are enough for FM aspect of VPLS service or do we need to consider additional tools/mechanisms. The mechanisms that are discussed in the draft, are being worked on in other standard bodies such as ITU, MEF, and IEEE and I would expect the detail message specifications to be done in IEEE. However, we just want to ensure that L2VPN is informed of the activity and its applicability and its coverage to VPLS - e.g., whether VPLS FM is covered well with these mechanisms or not. I think this is a good informative draft for the subject of VPLS fault management as it describes at high level how FM tools for Ethernet can be applied to VPLS. -Ali At 09:42 AM 3/4/2004 -0600, Serbest, Yetik wrote: >Dinesh, > > > >Thank you the concise and excellent update. > > > >OAM for L2VPN services (VPWS and VPLS alike) is an important requirement. > > > >My understanding is that your drafts are summary of the work going on in >ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as >Ethernet layer procedures are defined. There is a draft aimed to be >specific to VPLS. It is the HVPLS-OAM draft, which received four main >objections: > >1. Special TTL (Time To Live) processing: HVPLS-OAM proposal >requires that the PE router remember the TTL value of the VC Label (VC-LSP >spoke) at the ingress of the PE, and decrement and place it in the TTL >value of the VC-LSP (PW between PEs) at the egress of the PE. This is a >layering violation. > >2. No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is >specifically designed for the architecture with MPLS attachment circuits. > >3. Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS >transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE >tunnels). > >4. Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal >utilizes an OAM label (value of 14) at the bottom of the label stack, >which is aligned with ITU Y.1711. With ECMP hashing using all the labels >in the stack, OAM packets will not follow the same path as the customer >data packets. > > > >Based on this observation, the question is "do we need to work on OAM >solutions in this group?" As you put it, perhaps we should only define the >requirements/framework for L2VPN OAM, and let other bodies work on the >solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS. > > > >I would appreciate some discussion on this in the group. > > > >Thanks, > >yetik > > > >-----Original Message----- >From: Dinesh Mohan [mailto:mohand@nortelnetworks.com] >Sent: Wednesday, March 03, 2004 5:32 PM >To: l2vpn@ietf.org >Subject: [VPLS OAM] Follow-up from Seoul L2VPN session > > > >As a follow-up from yesterday's discussion, let me first point out to the >following slides that were presented during the meeting: > >http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt > > >The drafts that were represented are: >http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt > >http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.txt > >During the meeting it was acknowledged that VPLS OAM is an important area >to tackle since it is a key requirement for providers. > >It was also my observation that the material was generally well received. >However, few questions that came up during discussions included: > >- What really is the scope of VPLS OAM? >- Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, >IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport? > >Subsequently, it was generally felt that as next steps: >- Scope for VPLS OAM needs to be clarified >- Requirements and Framework for VPLS OAM needs to be created. There would >then serve as inputs to other working groups/bodies. > >- VPLS specific OAM solutions should then be worked in IETF. > >Towards that, I would like to add that: >- The drafts introduce important constructs/framework for dealing with the >OAM that differentiate between the service/network layers. It also aligns >with ongoing OAM work in other bodies (we may not want to re-invent the wheel!) > >- The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a >Ethernet service irrespective of the underlying transport mechanism e.g. >LDP based or BGP based solutions. > >- Infact, the mechanisms proposed equally apply to Ethernet VPWS as a >Ethernet service. >- MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in >the presentation and in the drafts. >- There is no reason, why service layer OAM mechanisms cannot interwork >with the MPLS-based mechanisms as an optimization, however, for preserving >the layer sanity, each layer still needs to be equipped with right OAM toolset. > >Comments? > >Best Regards, >Dinesh Mohan >Tel: (613) 763-4794 [ESN: 393-4794] Nortel Networks >Fax: (613) 763-2697 3500 Carling Ave. >Email: mohand@nortelnetworks.com Ottawa, Canada K1Y4H7 >http://www.nortelnetworks.com > > --=====================_146922303==_.ALT Content-Type: text/html; charset="us-ascii" Hi Yetik,

Given that VPLS service as defined in the L2VPN framework is an emulated LAN service wrt to a group of CEs and it can use different PSN network (e.g., IP or MPLS), it is important to be able to address VPLS OAM at the service layer (as well as network layer) and for different types of PSN. The propose of this draft is mainly two folds: 1) to inform the IETF community of the current mechanisms under development in other standard bodies in regard to Ethernet services and 2) to show the applicability of these mechanisms to VPLS service.

The draft just describes the concepts and mechanisms for fault management portion of OAM at the high level and it does that in order to acquaint the IETF audience with the type of tools/mechanisms that will be available for this purpose and to open the discussion to see if these tools are enough for FM aspect of VPLS service or do we need to consider additional tools/mechanisms.

The mechanisms that are discussed in the draft, are being worked on in other standard bodies such as ITU, MEF, and IEEE and I would expect the detail message specifications to be done in IEEE. However, we just want to ensure that L2VPN is informed of the activity and its applicability and its coverage to VPLS - e.g., whether VPLS FM is covered well with these mechanisms or not.

I think this is a good informative draft for the subject of VPLS  fault management as it describes at high level how FM tools for Ethernet can be applied to VPLS.

-Ali


At 09:42 AM 3/4/2004 -0600, Serbest, Yetik wrote:

Dinesh,

 

Thank you the concise and excellent update.

 

OAM for L2VPN services (VPWS and VPLS alike) is an important requirement.

 

My understanding is that your drafts are summary of the work going on in ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as Ethernet layer procedures are defined. There is a draft aimed to be specific to VPLS. It is the HVPLS-OAM draft, which received four main objections:

1.       Special TTL (Time To Live) processing: HVPLS-OAM proposal requires that the PE router remember the TTL value of the VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and place it in the TTL value of the VC-LSP (PW between PEs) at the egress of the PE. This is a layering violation.

2.       No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is specifically designed for the architecture with MPLS attachment circuits.

3.       Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE tunnels).

4.       Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal utilizes an OAM label (value of 14) at the bottom of the label stack, which is aligned with ITU Y.1711. With ECMP hashing using all the labels in the stack, OAM packets will not follow the same path as the customer data packets.

 

Based on this observation, the question is "do we need to work on OAM solutions in this group?" As you put it, perhaps we should only define the requirements/framework for L2VPN OAM, and let other bodies work on the solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS.

 

I would appreciate some discussion on this in the group.

 

Thanks,

yetik

 

-----Original Message-----
From: Dinesh Mohan [mailto:mohand@nortelnetworks.com]
Sent: Wednesday, March 03, 2004 5:32 PM
To: l2vpn@ietf.org
Subject: [VPLS OAM] Follow-up from Seoul L2VPN session

 

As a follow-up from yesterday's discussion, let me first point out to the following slides that were presented during the meeting:

http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt

The drafts that were represented are:
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00.txt
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00.txt

During the meeting it was acknowledged that VPLS OAM is an important area to tackle since it is a key requirement for providers.

It was also my observation that the material was generally well received. However, few questions that came up during discussions included:

- What really is the scope of VPLS OAM?
- Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport?

Subsequently, it was generally felt that as next steps:
- Scope for VPLS OAM needs to be clarified
- Requirements and Framework for VPLS OAM needs to be created. There would then serve as inputs to other working groups/bodies.

- VPLS specific OAM solutions should then be worked in IETF.

Towards that, I would like to add that:
- The drafts introduce important constructs/framework for dealing with the OAM that differentiate between the service/network layers. It also aligns with ongoing OAM work in other bodies (we may not want to re-invent the wheel!)

- The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a Ethernet service irrespective of the underlying transport mechanism e.g. LDP based or BGP based solutions.

- Infact, the mechanisms proposed equally apply to Ethernet VPWS as a Ethernet service.
- MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the presentation and in the drafts.
- There is no reason, why service layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as an optimization, however, for preserving the layer sanity, each layer still needs to be equipped with right OAM toolset.

Comments?

Best Regards,
Dinesh Mohan                                          
Tel: (613) 763-4794 [ESN: 393-4794]     Nortel Networks
Fax: (613) 763-2697                                 3500 Carling Ave.
Email: mohand@nortelnetworks.com        Ottawa, Canada K1Y4H7
http://www.nortelnetworks.com

 
--=====================_146922303==_.ALT-- From exim@www1.ietf.org Thu Mar 4 17:55:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18395 for ; Thu, 4 Mar 2004 17:55:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1k1-0006ah-2r for l2vpn-archive@odin.ietf.org; Thu, 04 Mar 2004 17:54:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Msv7x025329 for l2vpn-archive@odin.ietf.org; Thu, 4 Mar 2004 17:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1k0-0006aS-T9 for l2vpn-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 17:54:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18353 for ; Thu, 4 Mar 2004 17:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1jy-0000Dz-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 17:54:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1j6-00002W-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 17:54:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az1iD-0007fn-00 for l2vpn-web-archive@ietf.org; Thu, 04 Mar 2004 17:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1i9-0006Ry-5f; Thu, 04 Mar 2004 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1hB-0006Qq-4Y for l2vpn@optimus.ietf.org; Thu, 04 Mar 2004 17:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18263 for ; Thu, 4 Mar 2004 17:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1h8-0007TP-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 17:51:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1gD-0007Iu-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 17:51:03 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Az1fs-000782-00 for l2vpn@ietf.org; Thu, 04 Mar 2004 17:50:40 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2004 14:57:22 +0000 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i24Mne1v014577; Thu, 4 Mar 2004 23:49:40 +0100 (MET) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Mar 2004 23:50:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4023B.0A541310" Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session Date: Thu, 4 Mar 2004 23:50:07 +0100 Message-ID: <3C775706078CA347A8653E03E14691060318A23E@xbe-ams-313.cisco.com> Thread-Topic: [VPLS OAM] Follow-up from Seoul L2VPN session Thread-Index: AcQCJ+W3E2/lKbt6R8eOSraCTn/cFwAETFkA From: "Monique Morrow (mmorrow)" To: "Ali Sajassi (sajassi)" Cc: "Serbest, Yetik" , "Dinesh Mohan" , X-OriginalArrivalTime: 04 Mar 2004 22:50:08.0219 (UTC) FILETIME=[0AE2FAB0:01C4023B] Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4023B.0A541310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ali et al, =20 I would have to agree with your assessment of the draft,its applicability to VPLS service and the alignment to IEEE, ITU-T, and MEF .=20 It is reasonable therefore,to ask this WG whether or not the mechanisms that are being developed elsewhere shall be sufficient as a base for VPLS FM. =20 Monique -----Original Message----- From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: 04 March 2004 21:30 To: Serbest, Yetik; 'Dinesh Mohan'; l2vpn@ietf.org Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session =09 =09 Hi Yetik, =09 Given that VPLS service as defined in the L2VPN framework is an emulated LAN service wrt to a group of CEs and it can use different PSN network (e.g., IP or MPLS), it is important to be able to address VPLS OAM at the service layer (as well as network layer) and for different types of PSN. The propose of this draft is mainly two folds: 1) to inform the IETF community of the current mechanisms under development in other standard bodies in regard to Ethernet services and 2) to show the applicability of these mechanisms to VPLS service.=20 =09 The draft just describes the concepts and mechanisms for fault management portion of OAM at the high level and it does that in order to acquaint the IETF audience with the type of tools/mechanisms that will be available for this purpose and to open the discussion to see if these tools are enough for FM aspect of VPLS service or do we need to consider additional tools/mechanisms.=20 =09 The mechanisms that are discussed in the draft, are being worked on in other standard bodies such as ITU, MEF, and IEEE and I would expect the detail message specifications to be done in IEEE. However, we just want to ensure that L2VPN is informed of the activity and its applicability and its coverage to VPLS - e.g., whether VPLS FM is covered well with these mechanisms or not. =09 I think this is a good informative draft for the subject of VPLS fault management as it describes at high level how FM tools for Ethernet can be applied to VPLS. =09 -Ali =09 =09 At 09:42 AM 3/4/2004 -0600, Serbest, Yetik wrote: =09 =09 Dinesh, =09 =20 =09 Thank you the concise and excellent update. =09 =20 =09 OAM for L2VPN services (VPWS and VPLS alike) is an important requirement. =09 =20 =09 My understanding is that your drafts are summary of the work going on in ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as Ethernet layer procedures are defined. There is a draft aimed to be specific to VPLS. It is the HVPLS-OAM draft, which received four main objections: =09 1. Special TTL (Time To Live) processing: HVPLS-OAM proposal requires that the PE router remember the TTL value of the VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and place it in the TTL value of the VC-LSP (PW between PEs) at the egress of the PE. This is a layering violation. =09 2. No support for 802.1Q (VLANs) spokes: HVPLS-OAM proposal is specifically designed for the architecture with MPLS attachment circuits. =09 3. Transport (MPLS) dependency: HVPLS-OAM solution is for MPLS transport. It does not support IP backbones (e.g., L2TPv3 or IP or GRE tunnels). =09 4. Lack of ECMP (Equal Cost Multi-Path) support: HVPLS-OAM proposal utilizes an OAM label (value of 14) at the bottom of the label stack, which is aligned with ITU Y.1711. With ECMP hashing using all the labels in the stack, OAM packets will not follow the same path as the customer data packets. =09 =20 =09 Based on this observation, the question is "do we need to work on OAM solutions in this group?" As you put it, perhaps we should only define the requirements/framework for L2VPN OAM, and let other bodies work on the solutions, e.g., PWE3 for VPWS, ITU/802.1 for VPLS. =09 =20 =09 I would appreciate some discussion on this in the group. =09 =20 =09 Thanks, =09 yetik =09 =20 =09 -----Original Message----- From: Dinesh Mohan [mailto:mohand@nortelnetworks.com]=20 Sent: Wednesday, March 03, 2004 5:32 PM To: l2vpn@ietf.org Subject: [VPLS OAM] Follow-up from Seoul L2VPN session =09 =20 =09 As a follow-up from yesterday's discussion, let me first point out to the following slides that were presented during the meeting:=20 =09 http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt=20 =09 The drafts that were represented are:=20 =09 http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00 .txt=20 =09 http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00 .txt=20 =09 During the meeting it was acknowledged that VPLS OAM is an important area to tackle since it is a key requirement for providers. =09 It was also my observation that the material was generally well received. However, few questions that came up during discussions included: =09 - What really is the scope of VPLS OAM?=20 - Should it be different from Ethernet OAM discussions in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with MPLS/IP transport? =09 Subsequently, it was generally felt that as next steps:=20 - Scope for VPLS OAM needs to be clarified=20 - Requirements and Framework for VPLS OAM needs to be created. There would then serve as inputs to other working groups/bodies. =09 - VPLS specific OAM solutions should then be worked in IETF.=20 =09 Towards that, I would like to add that:=20 - The drafts introduce important constructs/framework for dealing with the OAM that differentiate between the service/network layers. It also aligns with ongoing OAM work in other bodies (we may not want to re-invent the wheel!) =09 - The FM/PM mechanisms proposed in the drafts are applicable for VPLS as a Ethernet service irrespective of the underlying transport mechanism e.g. LDP based or BGP based solutions. =09 - Infact, the mechanisms proposed equally apply to Ethernet VPWS as a Ethernet service.=20 - MPLS based OAM mechanisms belong to the MPLS layer, as highlighted in the presentation and in the drafts.=20 - There is no reason, why service layer OAM mechanisms cannot interwork with the MPLS-based mechanisms as an optimization, however, for preserving the layer sanity, each layer still needs to be equipped with right OAM toolset. =09 Comments?=20 =09 Best Regards,=20 Dinesh Mohan =20 Tel: (613) 763-4794 [ESN: 393-4794] Nortel Networks=20 Fax: (613) 763-2697 3500 Carling Ave.=20 Email: mohand@nortelnetworks.com Ottawa, Canada K1Y4H7=20 http://www.nortelnetworks.com=20 =09 =20 ------_=_NextPart_001_01C4023B.0A541310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Ali et=20 al,
 
I=20 would have to agree with your assessment of the draft,its applicability = to VPLS=20 service and the alignment to IEEE,  ITU-T, and MEF=20 . 
It is=20 reasonable therefore,to ask this WG whether or not the mechanisms = that are=20 being developed elsewhere shall be sufficient as a base for VPLS=20 FM.
 
Monique
-----Original Message-----
From:=20 l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of = Ali=20 Sajassi (sajassi)
Sent: 04 March 2004 21:30
To: = Serbest,=20 Yetik; 'Dinesh Mohan'; l2vpn@ietf.org
Subject: RE: [VPLS = OAM]=20 Follow-up from Seoul L2VPN session

Hi = Yetik,

Given=20 that VPLS service as defined in the L2VPN framework is an emulated LAN = service=20 wrt to a group of CEs and it can use different PSN network (e.g., IP = or MPLS),=20 it is important to be able to address VPLS OAM at the service layer = (as well=20 as network layer) and for different types of PSN. The propose of this = draft is=20 mainly two folds: 1) to inform the IETF community of the current = mechanisms=20 under development in other standard bodies in regard to Ethernet = services and=20 2) to show the applicability of these mechanisms to VPLS service. =

The=20 draft just describes the concepts and mechanisms for fault management = portion=20 of OAM at the high level and it does that in order to acquaint the = IETF=20 audience with the type of tools/mechanisms that will be available for = this=20 purpose and to open the discussion to see if these tools are enough = for FM=20 aspect of VPLS service or do we need to consider additional = tools/mechanisms.=20

The mechanisms that are discussed in the draft, are being = worked on in=20 other standard bodies such as ITU, MEF, and IEEE and I would expect = the detail=20 message specifications to be done in IEEE. However, we just want to = ensure=20 that L2VPN is informed of the activity and its applicability and its = coverage=20 to VPLS - e.g., whether VPLS FM is covered well with these mechanisms = or=20 not.

I think this is a good informative draft for the subject = of=20 VPLS  fault management as it describes at high level how FM tools = for=20 Ethernet can be applied to VPLS.

-Ali


At 09:42 AM = 3/4/2004=20 -0600, Serbest, Yetik wrote:

Dinesh,

 

Thank you = the concise=20 and excellent update.

 

OAM for = L2VPN services=20 (VPWS and VPLS alike) is an important = requirement.

 

My=20 understanding is that your drafts are summary of the work going on = in ITU-T=20 Q.3/13, IEEE 802.1 and MEF. They are not specific to this group, as = Ethernet=20 layer procedures are defined. There is a draft aimed to be specific = to VPLS.=20 It is the HVPLS-OAM draft, which received four main=20 objections:

1.      =20 Special TTL (Time To Live) = processing:=20 HVPLS-OAM proposal requires that the PE router remember the TTL = value of the=20 VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and = place it=20 in the TTL value of the VC-LSP (PW between PEs) at the egress of the = PE.=20 This is a layering violation.

2.       No support for 802.1Q (VLANs) spokes: HVPLS-OAM = proposal is=20 specifically designed for the architecture with MPLS attachment=20 circuits.

3.      =20 Transport (MPLS) = dependency: HVPLS-OAM=20 solution is for MPLS transport. It does not support IP backbones = (e.g.,=20 L2TPv3 or IP or GRE tunnels).

4.       Lack of ECMP (Equal Cost Multi-Path) support: = HVPLS-OAM=20 proposal utilizes an OAM label (value of 14) at the bottom of the = label=20 stack, which is aligned with ITU Y.1711. With ECMP hashing using all = the=20 labels in the stack, OAM packets will not follow the same path as = the=20 customer data packets.

 

Based on = this=20 observation, the question is "do we need to work on OAM solutions in = this=20 group?" As you put it, perhaps we should only define the=20 requirements/framework for L2VPN OAM, and let other bodies work on = the=20 solutions, e.g., PWE3 for VPWS, ITU/802.1 for = VPLS.

 

I would=20 appreciate some discussion on this in the group.

 

Thanks,

yetik

 

-----Original=20 Message-----
From: Dinesh Mohan [mailto:mohand@nortelnetworks.com] =
Sent:=20 Wednesday, March 03, 2004 5:32 PM
To:=20 l2vpn@ietf.org
Subject: [VPLS OAM] Follow-up from Seoul = L2VPN=20 session

 

As a follow-up from yesterday's discussion, let me first = point out to=20 the following slides that were presented during the meeting:=20

http://urax.u= tfors.net/~loa/ietf59-vpls-oam-v1.ppt

The=20 drafts that were represented are:
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vp= n-vpls-fm-00.txt=20
http://www.ietf.org/internet-drafts/draft-mohan-sajass= i-l2vpn-vpls-pm-00.txt=20

During the meeting it was = acknowledged that=20 VPLS OAM is an important area to tackle since it is a key = requirement for=20 providers.

It was also my = observation=20 that the material was generally well received. However, few = questions that=20 came up during discussions included:

-=20 What really is the scope of VPLS OAM?
-=20 Should it be different from Ethernet OAM discussions in ITU-T = Q.3/13, IEEE=20 802.1 and MEF since VPLS deals specifically with MPLS/IP=20 transport?

Subsequently, = it was=20 generally felt that as next steps:
-=20 Scope for VPLS OAM needs to be clarified
- Requirements and Framework for VPLS OAM needs to be = created. There=20 would then serve as inputs to other working=20 groups/bodies.

- VPLS = specific OAM=20 solutions should then be worked in IETF.

Towards that, I would like to add that:
- The drafts introduce important constructs/framework for = dealing=20 with the OAM that differentiate between the service/network layers. = It also=20 aligns with ongoing OAM work in other bodies (we may not want to = re-invent=20 the wheel!)

- The FM/PM = mechanisms=20 proposed in the drafts are applicable for VPLS as a Ethernet service = irrespective of the underlying transport mechanism e.g. LDP based or = BGP=20 based solutions.

- Infact, = the=20 mechanisms proposed equally apply to Ethernet VPWS as a Ethernet=20 service.
- MPLS based OAM = mechanisms=20 belong to the MPLS layer, as highlighted in the presentation and in = the=20 drafts.
- There is no reason, = why service=20 layer OAM mechanisms cannot interwork with the MPLS-based mechanisms = as an=20 optimization, however, for preserving the layer sanity, each layer = still=20 needs to be equipped with right OAM toolset.

Comments?

Best Regards,
Dinesh=20 = Mohan           &n= bsp;           &nb= sp;           &nbs= p;      =20
Tel: (613) 763-4794 [ESN:=20 393-4794]     Nortel Networks
Fax: (613)=20 = 763-2697           = ;            =          =20 3500 Carling Ave.
Email:=20 mohand@nortelnetworks.com        = Ottawa,=20 Canada K1Y4H7
http://www.nortelnetworks.com<= /FONT>=20

 
=00 ------_=_NextPart_001_01C4023B.0A541310-- From exim@www1.ietf.org Sun Mar 7 18:15:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11662 for ; Sun, 7 Mar 2004 18:15:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B07U6-0005Me-Ti for l2vpn-archive@odin.ietf.org; Sun, 07 Mar 2004 18:15:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27NF2ZU020616 for l2vpn-archive@odin.ietf.org; Sun, 7 Mar 2004 18:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B07U6-0005MR-Mh for l2vpn-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 18:15:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11618 for ; Sun, 7 Mar 2004 18:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B07U4-0003Gf-00 for l2vpn-web-archive@ietf.org; Sun, 07 Mar 2004 18:15:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B07T4-00038f-00 for l2vpn-web-archive@ietf.org; Sun, 07 Mar 2004 18:13:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B07SR-000312-00 for l2vpn-web-archive@ietf.org; Sun, 07 Mar 2004 18:13:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B07S9-0004kh-7k; Sun, 07 Mar 2004 18:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B07RF-0004U9-G1 for l2vpn@optimus.ietf.org; Sun, 07 Mar 2004 18:12:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11311 for ; Sun, 7 Mar 2004 18:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B07RC-0002rE-00 for l2vpn@ietf.org; Sun, 07 Mar 2004 18:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B07QF-0002iS-00 for l2vpn@ietf.org; Sun, 07 Mar 2004 18:11:04 -0500 Received: from av7-1-sn4.m-sp.skanova.net ([81.228.10.110]) by ietf-mx with esmtp (Exim 4.12) id 1B07PT-0002S8-00 for l2vpn@ietf.org; Sun, 07 Mar 2004 18:10:15 -0500 Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id EEA7837EE4; Mon, 8 Mar 2004 00:09:44 +0100 (CET) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id E00D637E86; Mon, 8 Mar 2004 00:09:44 +0100 (CET) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 9810337E4C; Mon, 8 Mar 2004 00:09:44 +0100 (CET) Message-ID: <404BABA1.8020701@pi.se> Date: Mon, 08 Mar 2004 00:09:21 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Monique Morrow (mmorrow)" Cc: "Ali Sajassi (sajassi)" , "Serbest, Yetik" , Dinesh Mohan , l2vpn@ietf.org Subject: Re: [VPLS OAM] Follow-up from Seoul L2VPN session References: <3C775706078CA347A8653E03E14691060318A23E@xbe-ams-313.cisco.com> In-Reply-To: <3C775706078CA347A8653E03E14691060318A23E@xbe-ams-313.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, what we said in summarising the Seoul meeting was that there are three possible areas we need to look at to see if the working need to do any work. - definition of vpls specific OAM (could be a framework) - if there are vpls specific OAM requirements that we need to produce, in order to support other standards organizations in their work - if there are protocol extensions to existing IETF protocols we need to initiate in the IETF for vpls specific OAM It was also accepted that most of the OAM work (read non-vpls specific) should be done in other standards organizations. /Loa Monique Morrow (mmorrow) wrote: > Ali et al, > > I would have to agree with your assessment of the draft,its > applicability to VPLS service and the alignment to IEEE, ITU-T, and MEF > . > It is reasonable therefore,to ask this WG whether or not the mechanisms > that are being developed elsewhere shall be sufficient as a base for > VPLS FM. > > Monique > > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > Behalf Of Ali Sajassi (sajassi) > Sent: 04 March 2004 21:30 > To: Serbest, Yetik; 'Dinesh Mohan'; l2vpn@ietf.org > Subject: RE: [VPLS OAM] Follow-up from Seoul L2VPN session > > > Hi Yetik, > > Given that VPLS service as defined in the L2VPN framework is an > emulated LAN service wrt to a group of CEs and it can use different PSN > network (e.g., IP or MPLS), it is important to be able to address VPLS > OAM at the service layer (as well as network layer) and for different > types of PSN. The propose of this draft is mainly two folds: 1) to > inform the IETF community of the current mechanisms under development in > other standard bodies in regard to Ethernet services and 2) to show the > applicability of these mechanisms to VPLS service. > > The draft just describes the concepts and mechanisms for fault > management portion of OAM at the high level and it does that in order to > acquaint the IETF audience with the type of tools/mechanisms that will > be available for this purpose and to open the discussion to see if these > tools are enough for FM aspect of VPLS service or do we need to consider > additional tools/mechanisms. > > The mechanisms that are discussed in the draft, are being worked > on in other standard bodies such as ITU, MEF, and IEEE and I would > expect the detail message specifications to be done in IEEE. However, we > just want to ensure that L2VPN is informed of the activity and its > applicability and its coverage to VPLS - e.g., whether VPLS FM is > covered well with these mechanisms or not. > > I think this is a good informative draft for the subject of VPLS > fault management as it describes at high level how FM tools for Ethernet > can be applied to VPLS. > > -Ali > > > At 09:42 AM 3/4/2004 -0600, Serbest, Yetik wrote: > > > > Dinesh, > > > > Thank you the concise and excellent update. > > > > OAM for L2VPN services (VPWS and VPLS alike) is an > important requirement. > > > > My understanding is that your drafts are summary of the > work going on in ITU-T Q.3/13, IEEE 802.1 and MEF. They are not specific > to this group, as Ethernet layer procedures are defined. There is a > draft aimed to be specific to VPLS. It is the HVPLS-OAM draft, which > received four main objections: > > 1. Special TTL (Time To Live) processing: > HVPLS-OAM proposal requires that the PE router remember the TTL value of > the VC Label (VC-LSP spoke) at the ingress of the PE, and decrement and > place it in the TTL value of the VC-LSP (PW between PEs) at the egress > of the PE. This is a layering violation. > > 2. No support for 802.1Q (VLANs) spokes: HVPLS-OAM > proposal is specifically designed for the architecture with MPLS > attachment circuits. > > 3. Transport (MPLS) dependency: HVPLS-OAM solution > is for MPLS transport. It does not support IP backbones (e.g., L2TPv3 or > IP or GRE tunnels). > > 4. Lack of ECMP (Equal Cost Multi-Path) support: > HVPLS-OAM proposal utilizes an OAM label (value of 14) at the bottom of > the label stack, which is aligned with ITU Y.1711. With ECMP hashing > using all the labels in the stack, OAM packets will not follow the same > path as the customer data packets. > > > > Based on this observation, the question is "do we need > to work on OAM solutions in this group?" As you put it, perhaps we > should only define the requirements/framework for L2VPN OAM, and let > other bodies work on the solutions, e.g., PWE3 for VPWS, ITU/802.1 for > VPLS. > > > > I would appreciate some discussion on this in the group. > > > > Thanks, > > yetik > > > > -----Original Message----- > From: Dinesh Mohan [mailto:mohand@nortelnetworks.com] > Sent: Wednesday, March 03, 2004 5:32 PM > To: l2vpn@ietf.org > Subject: [VPLS OAM] Follow-up from Seoul L2VPN session > > > > As a follow-up from yesterday's discussion, let me first > point out to the following slides that were presented during the > meeting: > > http://urax.utfors.net/~loa/ietf59-vpls-oam-v1.ppt > > The drafts that were represented are: > > http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-fm-00 > .txt > > http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-pm-00 > .txt > > During the meeting it was acknowledged that VPLS OAM is > an important area to tackle since it is a key requirement for providers. > > > It was also my observation that the material was > generally well received. However, few questions that came up during > discussions included: > > - What really is the scope of VPLS OAM? > - Should it be different from Ethernet OAM discussions > in ITU-T Q.3/13, IEEE 802.1 and MEF since VPLS deals specifically with > MPLS/IP transport? > > Subsequently, it was generally felt that as next steps: > - Scope for VPLS OAM needs to be clarified > - Requirements and Framework for VPLS OAM needs to be > created. There would then serve as inputs to other working > groups/bodies. > > - VPLS specific OAM solutions should then be worked in > IETF. > > Towards that, I would like to add that: > - The drafts introduce important constructs/framework > for dealing with the OAM that differentiate between the service/network > layers. It also aligns with ongoing OAM work in other bodies (we may not > want to re-invent the wheel!) > > - The FM/PM mechanisms proposed in the drafts are > applicable for VPLS as a Ethernet service irrespective of the underlying > transport mechanism e.g. LDP based or BGP based solutions. > > - Infact, the mechanisms proposed equally apply to > Ethernet VPWS as a Ethernet service. > - MPLS based OAM mechanisms belong to the MPLS layer, as > highlighted in the presentation and in the drafts. > - There is no reason, why service layer OAM mechanisms > cannot interwork with the MPLS-based mechanisms as an optimization, > however, for preserving the layer sanity, each layer still needs to be > equipped with right OAM toolset. > > Comments? > > Best Regards, > Dinesh Mohan > Tel: (613) 763-4794 [ESN: 393-4794] Nortel Networks > Fax: (613) 763-2697 3500 > Carling Ave. > Email: mohand@nortelnetworks.com Ottawa, Canada > K1Y4H7 > http://www.nortelnetworks.com > > > > -- Loa Andersson mobile +46 739 81 21 64 From exim@www1.ietf.org Mon Mar 8 12:48:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16306 for ; Mon, 8 Mar 2004 12:48:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OrV-0001st-CK for l2vpn-archive@odin.ietf.org; Mon, 08 Mar 2004 12:48:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28HmLek007236 for l2vpn-archive@odin.ietf.org; Mon, 8 Mar 2004 12:48:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OrV-0001sc-3u for l2vpn-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 12:48:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16213 for ; Mon, 8 Mar 2004 12:48:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0OrT-0000SK-00 for l2vpn-web-archive@ietf.org; Mon, 08 Mar 2004 12:48:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0OqF-00008c-00 for l2vpn-web-archive@ietf.org; Mon, 08 Mar 2004 12:47:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0OoL-0007Of-00 for l2vpn-web-archive@ietf.org; Mon, 08 Mar 2004 12:45:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OoI-0001a1-Dw; Mon, 08 Mar 2004 12:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OnK-0001WS-1O for l2vpn@optimus.ietf.org; Mon, 08 Mar 2004 12:44:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15759 for ; Mon, 8 Mar 2004 12:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0OnI-00073u-00 for l2vpn@ietf.org; Mon, 08 Mar 2004 12:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0OlV-0006Vs-00 for l2vpn@ietf.org; Mon, 08 Mar 2004 12:42:11 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1B0Oip-0005fo-00 for l2vpn@ietf.org; Mon, 08 Mar 2004 12:39:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i28HcrBm047485; Mon, 8 Mar 2004 09:38:53 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp118.static.jnpr.net [172.24.253.118]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i28Hcpo63714; Mon, 8 Mar 2004 09:38:52 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040308123505.02e6a228@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 08 Mar 2004 12:38:53 -0500 To: l2vpn@ietf.org From: Ross Callon Subject: Fwd: Last Call on Cc: Ronald.P.Bonica@mci.com, rick@rhwilder.net, rcallon@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This message begins l2vpn working group last call on "Generic Requirements for Provider Provisioned Virtual Private Networks" . Note that this draft has already passed last call in the l3vpn working group, and a very similar earlier version already passed working group last call in both the l2vpn and l3vpn working groups. This last call will therefore be limited to the changes that have been made, and is abbreviated in time frame. This last call will therefore end in one week, on monday March 15, 2005. >The changes which have been made include: > >- Explanation of 3 scenarios for the deployment of VPNs. (see >section 1.2). In those cases where requirements vary between >scenarios, stating how. > >- Substantial increase in the scaling requirements presented in >section 5.1.2. > >- Editorial changes (typos corrected, extra spaces removed, "VPN" >in the title expanded to "Virtual Private Networks"). > >- Some text clarification. > >- Capitalization of keywords such as "MUST" and "SHOULD". > >- Adding reference to Security Framework document and general >cleaning up of references, along with mentioning draft names in >addition to titles. thanks, Ross From exim@www1.ietf.org Mon Mar 8 21:00:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16473 for ; Mon, 8 Mar 2004 21:00:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0WXU-000073-Cz for l2vpn-archive@odin.ietf.org; Mon, 08 Mar 2004 21:00:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2920CAE000430 for l2vpn-archive@odin.ietf.org; Mon, 8 Mar 2004 21:00:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0WXU-00006p-3y for l2vpn-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 21:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16451 for ; Mon, 8 Mar 2004 21:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0WXR-00038j-00 for l2vpn-web-archive@ietf.org; Mon, 08 Mar 2004 21:00:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0WWU-0002yR-00 for l2vpn-web-archive@ietf.org; Mon, 08 Mar 2004 20:59:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0WVd-0002oq-00 for l2vpn-web-archive@ietf.org; Mon, 08 Mar 2004 20:58:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0WVN-0008NI-AL; Mon, 08 Mar 2004 20:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0WUQ-0008M1-IP for l2vpn@optimus.ietf.org; Mon, 08 Mar 2004 20:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16350 for ; Mon, 8 Mar 2004 20:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0WUO-0002dG-00 for l2vpn@ietf.org; Mon, 08 Mar 2004 20:57:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0WTP-0002Tp-00 for l2vpn@ietf.org; Mon, 08 Mar 2004 20:55:59 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0WSU-0002Lq-00; Mon, 08 Mar 2004 20:55:02 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0WSU-000AGd-MR; Tue, 09 Mar 2004 01:55:02 +0000 Date: Mon, 8 Mar 2004 17:54:07 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <87163495484.20040308175407@psg.com> To: l2vpn@ietf.org, l3vpn@ietf.org Subject: Review of routing protocol extensions in L2/L3-VPN documents MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Regarding the discussion that happened in the L2VPN and L3VPN working groups on splitting WG documents containing descriptions of extensions to routing protocols and submitting them to the protocol-specific WGs: we had a discussion with L2VPN, L3VPN, and IDR WG chairs and reached the following agreement. 1. Appropriate level of technical review by the protocol-specific WGs needs to be ensured, regardless of whether extensions to a given protocol are defined in a separate document or not. 2. To avoid extra delays, existing L2VPN- and L3VPN- related working group documents will not be required to move the parts of the documents that specify changes to BGP into separate documents, but will be referred for a review to the IDR WG. 3. Several (not less than 2) reviewers from the IDR WG will be assigned to each document. The review will not be considered completed until all reviews have been completed and posted to the WG mailing lists. 4. For the WG documents ready for advancement, the review process will be done during the WG Last Call process. In future, reviews will be conducted earlier in the process. 5. Alex will work with other ADs and WG chairs on guidelines for documentation and review of the routing protocol extensions for future work. -- Alex Zinin IETF RTG Area co-Director From exim@www1.ietf.org Thu Mar 11 09:06:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02452 for ; Thu, 11 Mar 2004 09:06:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qoe-0005ka-M5 for l2vpn-archive@odin.ietf.org; Thu, 11 Mar 2004 09:05:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BE5epn022098 for l2vpn-archive@odin.ietf.org; Thu, 11 Mar 2004 09:05:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qoe-0005kL-GQ for l2vpn-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 09:05:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02434 for ; Thu, 11 Mar 2004 09:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qoc-0004yh-00 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 09:05:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Qni-0004rI-00 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 09:04:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qn9-0004jZ-00 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 09:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qn3-0005a1-Sv; Thu, 11 Mar 2004 09:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qmq-0005Xo-Ic for l2vpn@optimus.ietf.org; Thu, 11 Mar 2004 09:03:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02334 for ; Thu, 11 Mar 2004 09:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qmp-0004ic-00 for l2vpn@ietf.org; Thu, 11 Mar 2004 09:03:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Qlu-0004aS-00 for l2vpn@ietf.org; Thu, 11 Mar 2004 09:02:51 -0500 Received: from av9-1-sn1.fre.skanova.net ([81.228.11.115]) by ietf-mx with esmtp (Exim 4.12) id 1B1QlU-0004RC-00 for l2vpn@ietf.org; Thu, 11 Mar 2004 09:02:24 -0500 Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id E3E7737EA6; Thu, 11 Mar 2004 15:01:52 +0100 (CET) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id D32C737E50; Thu, 11 Mar 2004 15:01:52 +0100 (CET) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id B449337E52; Thu, 11 Mar 2004 15:01:52 +0100 (CET) Message-ID: <40507146.1010909@pi.se> Date: Thu, 11 Mar 2004 15:01:42 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org, MPLS wg Subject: notes from the wg meetings in seoul Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit WGs (this time it is a correct cross posting :), could notetakers send their notes from the meetings (l2vpn and mpls) to the wg co-chairs! Just sendthe notes as is, we'll do the editing. Could presenters send their slides to the wg co-chairs! Again both from l2vpn and the mpls meeting. You'll don't need to crosspost ;), mpls stuff to me and George and me, l2vpn stuff to me, Vach and Rick. If I have the notes and slides before EoBD March 12 I will be able to write up the minutes next week, otherwise their will be a delay as I will not have network connectivity coming week. /Loa -- Loa Andersson mobile +46 739 81 21 64 From exim@www1.ietf.org Thu Mar 11 16:07:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25803 for ; Thu, 11 Mar 2004 16:07:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XOc-0001yk-OR for l2vpn-archive@odin.ietf.org; Thu, 11 Mar 2004 16:07:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BL7E2G007589 for l2vpn-archive@odin.ietf.org; Thu, 11 Mar 2004 16:07:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XOa-0001xv-1I for l2vpn-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25632 for ; Thu, 11 Mar 2004 16:07:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XOY-0003bQ-00 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 16:07:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XLt-000325-00 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 16:04:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1XKd-0002gK-00 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 16:03:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1XDx-0002tl-K9 for l2vpn-web-archive@ietf.org; Thu, 11 Mar 2004 15:56:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDq-00084J-40; Thu, 11 Mar 2004 15:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1WeZ-0002Bm-8F for l2vpn@optimus.ietf.org; Thu, 11 Mar 2004 15:19:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20109; Thu, 11 Mar 2004 15:19:36 -0500 (EST) Message-Id: <200403112019.PAA20109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-signaling-01.txt Date: Thu, 11 Mar 2004 15:19:36 -0500 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Provisioning Models and Endpoint Identifiers in L2VPN Signaling Author(s) : E. Rosen, V. Radoaca Filename : draft-ietf-l2vpn-signaling-01.txt Pages : 24 Date : 2004-3-11 [PWE3-CONTROL] specifies a 'signaling protocol' which uses extensions of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-ARCH]. Like any protocol which sets up connections, the signaling protocol provides a method by which each endpoint can identify the other. [L2VPN-FW] describes a number of different ways in which sets of pseudowires may be combined together into 'Provider Provisioned Layer 2 VPNs' (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. Different kinds of L2VPN may have different 'provisioning models', i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a 'discovery process', and once the information is discovered, the signaling protocol is automatically invoked to set up the required pseudowires. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of PPVPN provisioning models, and specifies the semantic structure of the endpoint identifiers required. It further specifies how the endpoint identifiers are carried in the 'Generalized Identifier FEC' of [PWE3-CONTROL]. It is believed that the specified identifiers can also be carried within the L2TP signaling protocol, though this is currently not specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-signaling-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-signaling-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-signaling-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-signaling-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142851.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Mar 16 12:38:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12649 for ; Tue, 16 Mar 2004 12:38:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IVj-00046e-K1 for l2vpn-archive@odin.ietf.org; Tue, 16 Mar 2004 12:37:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GHbp9p015776 for l2vpn-archive@odin.ietf.org; Tue, 16 Mar 2004 12:37:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IVj-00046N-AP for l2vpn-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 12:37:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12604 for ; Tue, 16 Mar 2004 12:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3IVh-0002c6-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 12:37:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3IUs-0002VK-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 12:36:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3IU2-0002Qm-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 12:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ITx-0003o5-Ec; Tue, 16 Mar 2004 12:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ITl-0003nk-2Q for l2vpn@optimus.ietf.org; Tue, 16 Mar 2004 12:35:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12545 for ; Tue, 16 Mar 2004 12:35:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ITj-0002P4-00 for l2vpn@ietf.org; Tue, 16 Mar 2004 12:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ISo-0002LK-00 for l2vpn@ietf.org; Tue, 16 Mar 2004 12:34:50 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B3IS9-0002C1-00 for l2vpn@ietf.org; Tue, 16 Mar 2004 12:34:09 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2GHXbl78926; Tue, 16 Mar 2004 09:33:37 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp056.static.jnpr.net [172.24.253.56]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2GHXVJ29823; Tue, 16 Mar 2004 09:33:31 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040316123157.02f9e550@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 16 Mar 2004 12:32:45 -0500 To: l2vpn@ietf.org From: Ross Callon Subject: End of Last Call on Cc: Ronald.P.Bonica@mci.com, rick@rhwilder.net, rcallon@juniper.net In-Reply-To: <4.3.2.20040308123505.02e6a228@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This message ends the l2vpn working group last call on "Generic Requirements for Provider Provisioned Virtual Private Networks" . Thanks, Ross At 12:38 PM 3/8/2004 -0500, Ross Callon wrote: >This message begins l2vpn working group last call on >"Generic Requirements for Provider Provisioned Virtual Private >Networks" . > >Note that this draft has already passed last call in the l3vpn >working group, and a very similar earlier version already passed >working group last call in both the l2vpn and l3vpn working groups. >This last call will therefore be limited to the changes that have >been made, and is abbreviated in time frame. > >This last call will therefore end in one week, on monday >March 15, 2005. > > >The changes which have been made include: > > > >- Explanation of 3 scenarios for the deployment of VPNs. (see > >section 1.2). In those cases where requirements vary between > >scenarios, stating how. > > > >- Substantial increase in the scaling requirements presented in > >section 5.1.2. > > > >- Editorial changes (typos corrected, extra spaces removed, "VPN" > >in the title expanded to "Virtual Private Networks"). > > > >- Some text clarification. > > > >- Capitalization of keywords such as "MUST" and "SHOULD". > > > >- Adding reference to Security Framework document and general > >cleaning up of references, along with mentioning draft names in > >addition to titles. > >thanks, Ross > > From exim@www1.ietf.org Tue Mar 16 18:06:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03133 for ; Tue, 16 Mar 2004 18:06:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NdH-0005tj-Cu for l2vpn-archive@odin.ietf.org; Tue, 16 Mar 2004 18:05:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GN5xcY022665 for l2vpn-archive@odin.ietf.org; Tue, 16 Mar 2004 18:05:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NdH-0005tU-3f for l2vpn-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 18:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03074 for ; Tue, 16 Mar 2004 18:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3NdE-0000au-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 18:05:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3NcI-0000V9-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 18:04:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3NbQ-0000NF-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 18:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NbN-0005LJ-IT; Tue, 16 Mar 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wf6-0007JH-P1 for l2vpn@optimus.ietf.org; Mon, 15 Mar 2004 13:18:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14448 for ; Mon, 15 Mar 2004 13:18:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wf4-0002Mf-00 for l2vpn@ietf.org; Mon, 15 Mar 2004 13:18:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2we8-0002Jk-00 for l2vpn@ietf.org; Mon, 15 Mar 2004 13:17:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2wdF-0002Gv-00 for l2vpn@ietf.org; Mon, 15 Mar 2004 13:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wdG-0007Dd-I4; Mon, 15 Mar 2004 13:16:10 -0500 Received: (from nobody@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FIG9ss027751; Mon, 15 Mar 2004 13:16:09 -0500 Date: Mon, 15 Mar 2004 13:16:09 -0500 Message-Id: <200403151816.i2FIG9ss027751@www1.ietf.org> X-Authentication-Warning: www1.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f From: "Amy Katherine" To: nadine.joubert@itu.int Subject: Re: [iesg-secretary #20182] Liaison statement from ITU-T SG 13 to IETF Internet Area (l2VPN) Cc: l2vpn@ietf.org Reply-To: iesg-secretary@ietf.org X-Loop: WREQ 2 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Your request #20182 was updated by amyk: Dear Georges, Your Liaison Statement entitled "L2VPN over MPLS solution space" has been posted on the "Liaison Statements" Web page (http://www.ietf.org/IESG/liaison.html). Thank you, The IETF Secretariat From exim@www1.ietf.org Tue Mar 16 18:52:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03136 for ; Tue, 16 Mar 2004 18:06:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NdI-0005uL-8N for l2vpn-archive@odin.ietf.org; Tue, 16 Mar 2004 18:06:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GN60Cj022702 for l2vpn-archive@odin.ietf.org; Tue, 16 Mar 2004 18:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NdI-0005tu-1W for l2vpn-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 18:06:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03077 for ; Tue, 16 Mar 2004 18:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3NdF-0000az-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 18:05:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3NcJ-0000VH-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 18:04:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3NbQ-0000NG-00 for l2vpn-web-archive@ietf.org; Tue, 16 Mar 2004 18:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NbO-0005LZ-36; Tue, 16 Mar 2004 18:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wk1-0007f9-0D for l2vpn@optimus.ietf.org; Mon, 15 Mar 2004 13:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14587 for ; Mon, 15 Mar 2004 13:23:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wjz-0002cR-00 for l2vpn@ietf.org; Mon, 15 Mar 2004 13:23:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wj6-0002Za-00 for l2vpn@ietf.org; Mon, 15 Mar 2004 13:22:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2wi4-0002WY-00; Mon, 15 Mar 2004 13:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wi5-0007Zw-1P; Mon, 15 Mar 2004 13:21:09 -0500 Received: (from nobody@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FIL87W029133; Mon, 15 Mar 2004 13:21:08 -0500 Date: Mon, 15 Mar 2004 13:21:08 -0500 Message-Id: <200403151821.i2FIL87W029133@www1.ietf.org> X-Authentication-Warning: www1.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f From: "Amy Katherine" To: nadine.joubert@itu.int Subject: Re: [iesg-secretary #20173] Liaison statement from ITU-T SG 13 to IETF Routing Area (CCAMP) o Cc: l2vpn@ietf.org, l3vpn@ietf.org, ccamp@ops.ietf.org Reply-To: iesg-secretary@ietf.org X-Loop: WREQ 2 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Your request #20173 was updated by amyk: Dear Georges, Your Liaison Statement entitled "Information on L1VPN related work," with its two attachments, "Layer 1 VPN work in SG 13 up to now" and "Questionaire in the area of Layer 1 VPN series," have been posted on the "Liaison Statements" Web page (http://www.ietf.org/IESG/liaison.html). Thank you, The IETF Secretariat From exim@www1.ietf.org Wed Mar 17 19:06:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18704 for ; Wed, 17 Mar 2004 19:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l2r-0006Vi-34 for l2vpn-archive@odin.ietf.org; Wed, 17 Mar 2004 19:05:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I05vBx025013 for l2vpn-archive@odin.ietf.org; Wed, 17 Mar 2004 19:05:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l2q-0006VM-A1 for l2vpn-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 19:05:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18673 for ; Wed, 17 Mar 2004 19:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l2n-0004Kz-00 for l2vpn-web-archive@ietf.org; Wed, 17 Mar 2004 19:05:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3l1u-0004D5-00 for l2vpn-web-archive@ietf.org; Wed, 17 Mar 2004 19:04:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3l1G-00045r-00 for l2vpn-web-archive@ietf.org; Wed, 17 Mar 2004 19:04:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l1D-0006Fa-Ny; Wed, 17 Mar 2004 19:04:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l0C-0006Cd-NO for l2vpn@optimus.ietf.org; Wed, 17 Mar 2004 19:03:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18573 for ; Wed, 17 Mar 2004 19:03:07 -0500 (EST) From: Gijsbert.Van_Kersen@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l09-0003xk-00 for l2vpn@ietf.org; Wed, 17 Mar 2004 19:03:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3kzM-0003pD-00 for l2vpn@ietf.org; Wed, 17 Mar 2004 19:02:20 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3kyb-0003f3-00 for l2vpn@ietf.org; Wed, 17 Mar 2004 19:01:33 -0500 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2I00lIl018398 for ; Thu, 18 Mar 2004 01:01:20 +0100 Subject: Gijsbert VAN KERSEN/BE/ALCATEL is out of the office. To: l2vpn@ietf.org Message-ID: Date: Thu, 18 Mar 2004 01:01:04 +0100 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/18/2004 01:01:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 I will be out of the office starting 15/03/2004 and will not return until 29/03/2004. Timely response to emails is not guaranteed. Feel free to call me at +32 477 605 008. From exim@www1.ietf.org Thu Mar 18 03:26:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26806 for ; Thu, 18 Mar 2004 03:26:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3sqz-00024O-Om for l2vpn-archive@odin.ietf.org; Thu, 18 Mar 2004 03:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I8QD97007956 for l2vpn-archive@odin.ietf.org; Thu, 18 Mar 2004 03:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3sqz-00024F-6E for l2vpn-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 03:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26758 for ; Thu, 18 Mar 2004 03:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3sqw-0005B1-00 for l2vpn-web-archive@ietf.org; Thu, 18 Mar 2004 03:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3spz-00051z-00 for l2vpn-web-archive@ietf.org; Thu, 18 Mar 2004 03:25:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3sox-0004t2-00 for l2vpn-web-archive@ietf.org; Thu, 18 Mar 2004 03:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3sor-0001qN-Bo; Thu, 18 Mar 2004 03:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3soG-0001p3-EB for l2vpn@optimus.ietf.org; Thu, 18 Mar 2004 03:23:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26637 for ; Thu, 18 Mar 2004 03:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3soE-0004mc-00 for l2vpn@ietf.org; Thu, 18 Mar 2004 03:23:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3snI-0004eC-00 for l2vpn@ietf.org; Thu, 18 Mar 2004 03:22:25 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B3smM-0004N3-00 for l2vpn@ietf.org; Thu, 18 Mar 2004 03:21:27 -0500 Received: from d07358 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HUR00H8TIXCTH@mta0.huawei.com> for l2vpn@ietf.org; Thu, 18 Mar 2004 16:15:13 +0800 (CST) Date: Thu, 18 Mar 2004 16:29:00 +0800 From: Du Wenhua Subject: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? To: "l2vpn@ietf.org" Reply-to: duwh@huawei.com Message-id: <0HUR00H8UIXDTH@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 Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi,all=A3=AC 11. Hierarchical VPLS model using Ethernet Access Network of= say > If customer VLANs need to be treated as service delimiter= (e.g., > customer UNI port is a multiplexed port), then the MTU-s= needs to > have the additional capability of translating a customer VLAN= (C- > VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids= used by > different customers. Therefore, the MTU-s device in this= model can be > considered as a typical bridge with this additional UNI= capability. In my option, it is not a good idea to let the MTU-s device= to do VLAN translation. There are 3 reason: 1)As we known, MTU-s are low cost devices, are made by the= standard commercial chips. These chips has no VLAN translation= function. 2) On the another side, many MTU-s(a.k.a ethernet switch) have= been installed in the carrier network already. It is very= difficult to upgrade these ethernet switch to support VLAN= translation. 3)[PWE3-ETHERNET]= defines the VLAN translation function for PW. say= VPLS supports such PW defined by [PWE3-ETHERNET]. So I think= PE-rs support VLAN translation also. In summary, I suggest to move the VLAN translation function= from the MTU-s to PE-rs. PE-rs are more powerful and more= expensive. PE-rs is more easy to do VLAN translation, which is= defened in . MTU-s is just a typical bridge, no additional UNI capability,= no VLAN translation. =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Yours=09 =09=09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-03-18 From exim@www1.ietf.org Thu Mar 18 12:21:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26094 for ; Thu, 18 Mar 2004 12:21:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41CF-0007ZR-L4 for l2vpn-archive@odin.ietf.org; Thu, 18 Mar 2004 12:20:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IHKhwj029100 for l2vpn-archive@odin.ietf.org; Thu, 18 Mar 2004 12:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41CF-0007ZH-GY for l2vpn-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 12:20:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26063 for ; Thu, 18 Mar 2004 12:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41CE-0005J0-00 for l2vpn-web-archive@ietf.org; Thu, 18 Mar 2004 12:20:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41BX-0005FS-00 for l2vpn-web-archive@ietf.org; Thu, 18 Mar 2004 12:20:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B41Af-0005AU-00 for l2vpn-web-archive@ietf.org; Thu, 18 Mar 2004 12:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41Ac-0007Cl-8G; Thu, 18 Mar 2004 12:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41AC-000782-Rn for l2vpn@optimus.ietf.org; Thu, 18 Mar 2004 12:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25972 for ; Thu, 18 Mar 2004 12:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41AB-00057v-00 for l2vpn@ietf.org; Thu, 18 Mar 2004 12:18:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B419N-00054s-00 for l2vpn@ietf.org; Thu, 18 Mar 2004 12:17:45 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B418u-0004yh-00 for l2vpn@ietf.org; Thu, 18 Mar 2004 12:17:16 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 09:21:44 +0000 Received: from sajassi-w2k4.cisco.com (ams-clip-vpn-dhcp4444.cisco.com [10.61.81.91]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IHFuia004069; Thu, 18 Mar 2004 18:15:57 +0100 (MET) Message-Id: <4.3.2.7.2.20040318072704.01cd2de0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Mar 2004 09:16:26 -0800 To: duwh@huawei.com, "l2vpn@ietf.org" From: Ali Sajassi Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? In-Reply-To: <0HUR00H8UIXDTH@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At 04:29 PM 3/18/2004 +0800, Du Wenhua wrote: >Hi,all=A3=AC > > 11. Hierarchical VPLS model using Ethernet Access Network of=20 > say > > > If customer VLANs need to be treated as service delimiter (e.g., > > customer UNI port is a multiplexed port), then the MTU-s needs to > > have the additional capability of translating a customer VLAN (C- > > VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids used by > > different customers. Therefore, the MTU-s device in this model can be > > considered as a typical bridge with this additional UNI capability. > > In my option, it is not a good idea to let the MTU-s device to do=20 > VLAN translation. There are 3 reason: > 1)As we known, MTU-s are low cost devices, are made by the standard=20 > commercial chips. These chips has no VLAN translation function. And I am talking about low-cost bridges based on IEEE 802.1ad that can=20 perform this functionality. Take a look at IEEE 802.1ad rev. D2. > 2) On the another side, many MTU-s(a.k.a ethernet switch) have been=20 > installed in the carrier network already. It is very difficult to upgrade= =20 > these ethernet switch to support VLAN translation. Many deployed Bridges/MTU-s in carrier networks can support predecessor=20 version of 802.1ad standard (QinQ) that have similar capabilities. You=20 cannot eat your cake and have it too. If you want to use a) Ethernet access network and b) allow muxed UNI port and c) don't restrict customer VLAN assignment, then MTU-s need to support VLAN translation (e.g., based on 802.1ad). But=20 if you want to restrict customer VLAN assignment or use PW between your=20 u-PE and n-PE, then you don't need this feature. > 3)[PWE3-ETHERNET] defines the=20 > VLAN translation function for PW. say VPLS supports such PW=20 > defined by [PWE3-ETHERNET]. So I think PE-rs support VLAN translation= also. But for that you need MPLS access network and your u-PE needs to support=20 MPLS PW (e.g., your MTU-s becomes PE-r) and this is different from section= =20 11.2 whose title is "H-VPLS model using Ethernet Access Network". Besides,= =20 if you use MPLS PW between u-PE and n-PE, then you wouldn't need VLAN=20 traslation to begin with since each customer VLAN gets mapped to a=20 different PW. > In summary, I suggest to move the VLAN translation function from the= =20 > MTU-s to PE-rs. PE-rs are more powerful and more expensive. PE-rs is more= =20 > easy to do VLAN translation, which is defened in=20 > . > MTU-s is just a typical bridge, no additional UNI capability, no VLAN= =20 > translation. I think you might have misunderstood the scenario for H-VPLS with Ethernet= =20 access network. Hope the above explanation helps in clarifying it. -Ali >=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Yours > >=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-03-18 From exim@www1.ietf.org Fri Mar 19 02:09:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14913 for ; Fri, 19 Mar 2004 02:09:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E82-0004Ns-OY for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J79EwD016843 for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E81-0004N5-0l for l2vpn-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:09:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14315 for ; Fri, 19 Mar 2004 02:09:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7x-0000WF-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 02:09:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E72-0000RA-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 02:08:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E6G-0000M6-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5v-0003OS-Pa; Fri, 19 Mar 2004 02:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4v-00034T-Dj for l2vpn@optimus.ietf.org; Fri, 19 Mar 2004 02:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11029 for ; Fri, 19 Mar 2004 02:05:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E4r-0000FL-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 02:05:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E3x-0000BL-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 02:05:02 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B4E32-00003l-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 02:04:05 -0500 Received: from d07358 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HUT00MZ49LGH7@mta0.huawei.com> for l2vpn@ietf.org; Fri, 19 Mar 2004 14:48:54 +0800 (CST) Date: Fri, 19 Mar 2004 15:02:42 +0800 From: Du Wenhua Subject: Re: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? To: Ali Sajassi , "l2vpn@ietf.org" Reply-to: duwh@huawei.com Message-id: <0HUT00MZ69LGH7@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 Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi,Ali Sajassi, Thanks for your comments. Please see my comments bellow. >-----Original Message----- >From: Ali Sajassi >Sent: 09:16:00,2004-03-18 >To: duwh >Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or= MTU-s? >At 04:29 PM 3/18/2004 +0800, Du Wenhua wrote: >>Hi,all=A3=AC >> >> 11. Hierarchical VPLS model using Ethernet Access Network of= >> say >> >> > If customer VLANs need to be treated as service delimiter= (e.g., >> > customer UNI port is a multiplexed port), then the MTU-s= needs to >> > have the additional capability of translating a customer= VLAN (C- >> > VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids= used by >> > different customers. Therefore, the MTU-s device in this= model can be >> > considered as a typical bridge with this additional UNI= capability. >> >> In my option, it is not a good idea to let the MTU-s= device to do >> VLAN translation. There are 3 reason: >> 1)As we known, MTU-s are low cost devices, are made by the= standard >> commercial chips. These chips has no VLAN translation= function. > >And I am talking about low-cost bridges based on IEEE 802.1ad= that can >perform this functionality. Take a look at IEEE 802.1ad rev.= D2. true. But how many bridge chips support 802.1ad d2 do you think? I have= checked more 10 kind of commercial chips, but only one support VLAN translation. > >> 2) On the another side, many MTU-s(a.k.a ethernet switch)= have been >> installed in the carrier network already. It is very difficult= to upgrade >> these ethernet switch to support VLAN translation. > >Many deployed Bridges/MTU-s in carrier networks can support= predecessor >version of 802.1ad standard (QinQ) that have similar= capabilities. You >cannot eat your cake and have it too. QinQ is not VLAN translation. >If you want to use >a) Ethernet access network and >b) allow muxed UNI port and >c) don't restrict customer VLAN assignment, >then MTU-s need to support VLAN translation (e.g., based on= 802.1ad). But PE-rs can do VLAN translation. MTU-s need not to do VLAN= translation. >if you want to restrict customer VLAN assignment or use PW= between your >u-PE and n-PE, then you don't need this feature. > >> 3)[PWE3-ETHERNET]= defines the >> VLAN translation function for PW. say VPLS supports= such PW >> defined by [PWE3-ETHERNET]. So I think PE-rs support VLAN= translation also. > >But for that you need MPLS access network and your u-PE needs to= support >MPLS PW (e.g., your MTU-s becomes PE-r) and this is different= from section I think you might have misunderstood what I mean. u-PE(MTU-s) is typical bridge, just carry PDU over C-VLAN. n-PE(PE-rs) do C-VLAN tranlation when the PDU come into an= VC(a.k.a PW). [PWE3-ETHERNET] defines the VLAN translation function for= VC(PW). >11.2 whose title is "H-VPLS model using Ethernet Access= Network". Besides, >if you use MPLS PW between u-PE and n-PE, then you wouldn't need= VLAN >traslation to begin with since each customer VLAN gets mapped to= a >different PW. > > >> In summary, I suggest to move the VLAN translation= function from the >> MTU-s to PE-rs. PE-rs are more powerful and more expensive.= PE-rs is more >> easy to do VLAN translation, which is defened in >> . >> MTU-s is just a typical bridge, no additional UNI= capability, no VLAN >> translation. > >I think you might have misunderstood the scenario for H-VPLS= with Ethernet >access network. Hope the above explanation helps in clarifying= it. > >-Ali > > > >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Yours >> >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-03-18 =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D From exim@www1.ietf.org Fri Mar 19 15:53:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22020 for ; Fri, 19 Mar 2004 15:53:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Qyo-0006W8-4k for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 15:52:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JKqYkC025051 for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 15:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Qyo-0006Vy-0R for l2vpn-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 15:52:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22016 for ; Fri, 19 Mar 2004 15:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Qym-0000NE-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 15:52:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Qxt-0000Gm-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 15:51:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4QxQ-0000BT-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 15:51:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4QxK-0006K9-Rf; Fri, 19 Mar 2004 15:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Qwi-0006I6-Fv for l2vpn@optimus.ietf.org; Fri, 19 Mar 2004 15:50:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21928 for ; Fri, 19 Mar 2004 15:50:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Qwg-00008b-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 15:50:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Qvo-00003N-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 15:49:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B4QvM-0007l2-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 15:49:00 -0500 Received: from sajassi-w2k4.cisco.com (sjc-vpn3-1048.cisco.com [10.21.68.24]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2JKmQWL016435; Fri, 19 Mar 2004 12:48:27 -0800 (PST) Message-Id: <4.3.2.7.2.20040319105329.02b56f00@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 12:48:26 -0800 To: duwh@huawei.com, Ali Sajassi , "l2vpn@ietf.org" From: Ali Sajassi Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? In-Reply-To: <0HUT00MZ69LGH7@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At 03:02 PM 3/19/2004 +0800, Du Wenhua wrote: >Hi,Ali Sajassi, > >Thanks for your comments. Please see my comments bellow. You're welcome. Please refer to my comments inline. > >-----Original Message----- > >From: Ali Sajassi > >Sent: 09:16:00,2004-03-18 > >To: duwh > >Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? > > >At 04:29 PM 3/18/2004 +0800, Du Wenhua wrote: > >>Hi,all=A3=AC > >> > >> 11. Hierarchical VPLS model using Ethernet Access Network of > >> say > >> > >> > If customer VLANs need to be treated as service delimiter (e.g., > >> > customer UNI port is a multiplexed port), then the MTU-s needs to > >> > have the additional capability of translating a customer VLAN (C- > >> > VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids used by > >> > different customers. Therefore, the MTU-s device in this model can= be > >> > considered as a typical bridge with this additional UNI capability. > >> > >> In my option, it is not a good idea to let the MTU-s device to do > >> VLAN translation. There are 3 reason: > >> 1)As we known, MTU-s are low cost devices, are made by the standard > >> commercial chips. These chips has no VLAN translation function. > > > >And I am talking about low-cost bridges based on IEEE 802.1ad that can > >perform this functionality. Take a look at IEEE 802.1ad rev. D2. >true. >But how many bridge chips support 802.1ad d2 do you think? I have checked= =20 >more 10 kind of >commercial chips, but only one support VLAN translation. But the ones that have it, can do it with low-cost Ethernet switches :-) > > > > >> 2) On the another side, many MTU-s(a.k.a ethernet switch) have been > >> installed in the carrier network already. It is very difficult to= upgrade > >> these ethernet switch to support VLAN translation. > > > >Many deployed Bridges/MTU-s in carrier networks can support predecessor > >version of 802.1ad standard (QinQ) that have similar capabilities. You > >cannot eat your cake and have it too. >QinQ is not VLAN translation. I was trying to point out that the platforms based on QinQ implementation=20 may also do VLAN translation. However, 802.1ad is more than just QinQ and=20 VLAN translation. > >If you want to use > >a) Ethernet access network and > >b) allow muxed UNI port and > >c) don't restrict customer VLAN assignment, > >then MTU-s need to support VLAN translation (e.g., based on 802.1ad). But >PE-rs can do VLAN translation. MTU-s need not to do VLAN translation. > >if you want to restrict customer VLAN assignment or use PW between your > >u-PE and n-PE, then you don't need this feature. > > > >> 3)[PWE3-ETHERNET] defines the > >> VLAN translation function for PW. say VPLS supports such PW > >> defined by [PWE3-ETHERNET]. So I think PE-rs support VLAN translation= =20 > also. > > > >But for that you need MPLS access network and your u-PE needs to support > >MPLS PW (e.g., your MTU-s becomes PE-r) and this is different from= section >I think you might have misunderstood what I mean. >u-PE(MTU-s) is typical bridge, just carry PDU over C-VLAN. >n-PE(PE-rs) do C-VLAN tranlation when the PDU come into an VC(a.k.a PW). >[PWE3-ETHERNET] defines the VLAN translation function for VC(PW). I think you are talking about a scenario in which the MTU-s (the bridge) is= =20 directly connected to the PE-rs without any Ethernet network in between=20 (even a single bridge). If that's the case, then yes you don't need to=20 have VLAN translation at the MTU-S since each pair of port+vlan at the=20 PE-rs is considered as an AC that can be associated with a given VSI.=20 However, I was talking about the more general case of "Ethernet access=20 network" in which MTU-S is connected via one or more provider bridges to=20 the PE-rs. And in such general scenario, the VLAN translation must be done= =20 at the MTU-s since each provider VLAN represent a VPLS instance. -Ali > >11.2 whose title is "H-VPLS model using Ethernet Access Network".= Besides, > >if you use MPLS PW between u-PE and n-PE, then you wouldn't need VLAN > >traslation to begin with since each customer VLAN gets mapped to a > >different PW. > > > > > >> In summary, I suggest to move the VLAN translation function from= the > >> MTU-s to PE-rs. PE-rs are more powerful and more expensive. PE-rs is= more > >> easy to do VLAN translation, which is defened in > >> . > >> MTU-s is just a typical bridge, no additional UNI capability, no= VLAN > >> translation. > > > >I think you might have misunderstood the scenario for H-VPLS with= Ethernet > >access network. Hope the above explanation helps in clarifying it. > > > >-Ali > > > > > > > >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Yours > >> > >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua > >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-03= -18 >=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D= =3D From exim@www1.ietf.org Fri Mar 19 16:44:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26029 for ; Fri, 19 Mar 2004 16:44:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RmQ-00031d-ET for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 16:43:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLhopg011623 for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 16:43:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RmQ-00031O-9a for l2vpn-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:43:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25850 for ; Fri, 19 Mar 2004 16:43:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RmO-0006RC-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 16:43:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RlS-0006FQ-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 16:42:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4RkY-00066R-03 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 16:41:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4RbB-0007w9-Fg for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 16:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Raz-0001oI-30; Fri, 19 Mar 2004 16:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rab-0001nb-2f for l2vpn@optimus.ietf.org; Fri, 19 Mar 2004 16:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25295 for ; Fri, 19 Mar 2004 16:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RaZ-0005BM-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 16:31:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RZj-000554-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 16:30:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B4RZ8-0004up-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 16:30:06 -0500 Received: from sajassi-w2k4.cisco.com (sjc-vpn3-1048.cisco.com [10.21.68.24]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2JLTV8Q025120; Fri, 19 Mar 2004 13:29:32 -0800 (PST) Message-Id: <4.3.2.7.2.20040319130447.02bf1f00@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 13:29:31 -0800 To: Ali Sajassi , duwh@huawei.com, "l2vpn@ietf.org" From: Ali Sajassi Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? In-Reply-To: <4.3.2.7.2.20040319105329.02b56f00@airborne.cisco.com> References: <0HUT00MZ69LGH7@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> >If you want to use >> >a) Ethernet access network and >> >b) allow muxed UNI port and >> >c) don't restrict customer VLAN assignment, >> >then MTU-s need to support VLAN translation (e.g., based on 802.1ad).= But >>PE-rs can do VLAN translation. MTU-s need not to do VLAN translation. >> >if you want to restrict customer VLAN assignment or use PW between your >> >u-PE and n-PE, then you don't need this feature. >> > >> >> 3)[PWE3-ETHERNET] defines= the >> >> VLAN translation function for PW. say VPLS supports such PW >> >> defined by [PWE3-ETHERNET]. So I think PE-rs support VLAN translation= =20 >> also. >> > >> >But for that you need MPLS access network and your u-PE needs to support >> >MPLS PW (e.g., your MTU-s becomes PE-r) and this is different from= section >>I think you might have misunderstood what I mean. >>u-PE(MTU-s) is typical bridge, just carry PDU over C-VLAN. >>n-PE(PE-rs) do C-VLAN tranlation when the PDU come into an VC(a.k.a PW). >>[PWE3-ETHERNET] defines the VLAN translation function for VC(PW). > >I think you are talking about a scenario in which the MTU-s (the bridge)=20 >is directly connected to the PE-rs without any Ethernet network in between= =20 >(even a single bridge). If that's the case, then yes you don't need to=20 >have VLAN translation at the MTU-S since each pair of port+vlan at the=20 >PE-rs is considered as an AC that can be associated with a given VSI.=20 >However, I was talking about the more general case of "Ethernet access=20 >network" in which MTU-S is connected via one or more provider bridges to=20 >the PE-rs. And in such general scenario, the VLAN translation must be done= =20 >at the MTU-s since each provider VLAN represent a VPLS instance. I think I need to further clarify what I said earlier to ensure that there= =20 is no ambiguity. In the above paragraph, I said that if the MTU-S is=20 directly connected to PE-rs, then you don't need to have VLAN translation=20 at the MTU-s; however, to be more precise, I should have said that if there= =20 is no VLAN ambiguity within MTU-S, then there is no need for VLAN=20 translation and the PE-rs can resolve the VLAN ambiguity between different= =20 MTU-s. However, for scenario where different ports of a MTU-s is connected= =20 to different customers (and different customers use different VLAN=20 assignments to represent different services, then VLAN translation is still= =20 needed in the MTU-s even though it can be directly connected to PE-rs or=20 else traffic from one customer can leak to another because of local=20 switching property of MTU-s. Another way of doing this is to use=20 encapsulate all the the VLANs from a given customer with a provider VLAN=20 tag and use double-tag lookup at the PE-rs. This method was explained in=20 detail in draft-sajassi-ppvpn-vpls-architectures. However, VLAN translation= =20 is more general and covers more cases and thus it is the only method=20 mentioned in vpls-ldp draft. -Ali >-Ali > >> >11.2 whose title is "H-VPLS model using Ethernet Access Network".= Besides, >> >if you use MPLS PW between u-PE and n-PE, then you wouldn't need VLAN >> >traslation to begin with since each customer VLAN gets mapped to a >> >different PW. >> > >> > >> >> In summary, I suggest to move the VLAN translation function from= the >> >> MTU-s to PE-rs. PE-rs are more powerful and more expensive. PE-rs is= more >> >> easy to do VLAN translation, which is defened in >> >> . >> >> MTU-s is just a typical bridge, no additional UNI capability, no= VLAN >> >> translation. >> > >> >I think you might have misunderstood the scenario for H-VPLS with= Ethernet >> >access network. Hope the above explanation helps in clarifying it. >> > >> >-Ali >> > >> > >> > >> >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Yours >> >> >> >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua >> >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-0= 3-18 >>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D > From exim@www1.ietf.org Fri Mar 19 21:01:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05894 for ; Fri, 19 Mar 2004 21:01:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vnn-0005U1-1a for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 21:01:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K21Vt5021076 for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 21:01:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vnm-0005Tr-TA for l2vpn-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 21:01:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05891 for ; Fri, 19 Mar 2004 21:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Vnk-0006gt-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 21:01:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Vmr-0006d5-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 21:00:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4VmT-0006Yt-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 21:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VmO-0005Na-Tv; Fri, 19 Mar 2004 21:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vlw-0005Mb-2P for l2vpn@optimus.ietf.org; Fri, 19 Mar 2004 20:59:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05811 for ; Fri, 19 Mar 2004 20:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Vlt-0006Y0-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 20:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Vl0-0006TQ-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 20:58:39 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B4VkZ-0006Mp-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 20:58:12 -0500 Received: from d07358 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HUU00DF3QPUUM@mta0.huawei.com> for l2vpn@ietf.org; Sat, 20 Mar 2004 09:56:19 +0800 (CST) Date: Sat, 20 Mar 2004 10:10:10 +0800 From: Du Wenhua Subject: Re: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? To: Ali Sajassi , Ali Sajassi , "l2vpn@ietf.org" Reply-to: duwh@huawei.com Message-id: <0HUU00DF4QPUUM@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 Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi,Ali Sajassi, Thanks for your careful clarity. >-----Original Message----- >From: Ali Sajassi >Sent: 13:29:00,2004-03-19 >To: Ali Sajassi >Subject: Re: Who do VLAN translation in LDP-VPLS? PE-rs or= MTU-s? >>> >If you want to use >>> >a) Ethernet access network and >>> >b) allow muxed UNI port and >>> >c) don't restrict customer VLAN assignment, >>> >then MTU-s need to support VLAN translation (e.g., based on= 802.1ad). But >>>PE-rs can do VLAN translation. MTU-s need not to do VLAN= translation. >>> >if you want to restrict customer VLAN assignment or use PW= between your >>> >u-PE and n-PE, then you don't need this feature. >>> > >>> >> = 3)[PWE3-ETHERNET] defines= the >>> >> VLAN translation function for PW. say VPLS= supports such PW >>> >> defined by [PWE3-ETHERNET]. So I think PE-rs support VLAN= translation >>> also. >>> > >>> >But for that you need MPLS access network and your u-PE= needs to support >>> >MPLS PW (e.g., your MTU-s becomes PE-r) and this is= different from section >>>I think you might have misunderstood what I mean. >>>u-PE(MTU-s) is typical bridge, just carry PDU over C-VLAN. >>>n-PE(PE-rs) do C-VLAN tranlation when the PDU come into an= VC(a.k.a PW). >>>[PWE3-ETHERNET] defines the VLAN translation function for= VC(PW). >> >>I think you are talking about a scenario in which the MTU-s= (the bridge) >>is directly connected to the PE-rs without any Ethernet network= in between >>(even a single bridge). If that's the case, then yes you don't= need to >>have VLAN translation at the MTU-S since each pair of port+vlan= at the >>PE-rs is considered as an AC that can be associated with a= given VSI. >>However, I was talking about the more general case of "Ethernet= access >>network" in which MTU-S is connected via one or more provider= bridges to >>the PE-rs. And in such general scenario, the VLAN translation= must be done >>at the MTU-s since each provider VLAN represent a VPLS= instance. > >I think I need to further clarify what I said earlier to ensure= that there >is no ambiguity. In the above paragraph, I said that if the= MTU-S is >directly connected to PE-rs, then you don't need to have VLAN= translation >at the MTU-s; however, to be more precise, I should have said= that if there >is no VLAN ambiguity within MTU-S, then there is no need for= VLAN >translation and the PE-rs can resolve the VLAN ambiguity between= different >MTU-s. true. I agree with you. >However, for scenario where different ports of a MTU-s is= connected >to different customers (and different customers use different= VLAN >assignments to represent different services, then VLAN= translation is still >needed in the MTU-s even though it can be directly connected to= PE-rs or >else traffic from one customer can leak to another because of= local >switching property of MTU-s. true. I agree with you. >Another way of doing this is to use >encapsulate all the the VLANs from a given customer with a= provider VLAN >tag and use double-tag lookup at the PE-rs. This method was= explained in >detail in draft-sajassi-ppvpn-vpls-architectures. However, VLAN= translation >is more general and covers more cases and thus it is the only= method >mentioned in vpls-ldp draft. So, we get two scenarios: 1) If there is no VLAN ambiguity within MTU-S, then there is no= need for VLAN translation and the PE-rs can resolve the VLAN ambiguity between= different MTU-s. each pair of port+vlan at the PE-rs is considered as an AC that= can be associated with a given VSI. 2) If there is VLAN ambiguity within one MTU-S(to be more= precise, within one Ethernet access network),then VLAN translation is still needed in= the MTU-s. Let's review the 1st scenario. Give an example, if {port 3,VLAN= 100} and {port 3, VLAN 200} of a PE-rs are considered as two ACs, are associated= with one VSI. It become amusing, there are two idea not to be think about: 1)PDU come into the PE-rs on {port 3, VLAN 100}, and leave out= of the same PE-rs on {port 3, VLAN 200} when data exchanging between two ACs. 2)In port 3 of the PE-rs, 2 VLANs map to 1 VSI. Here is C-VLAN,= but have the same function as P-VLAN. This differs from the sentence in= LDP-VLPS: "Therefore, there is a one to one correspondence between a= P-VLAN and a VPLS instance." The above scenarios is not clear in the LDP-VPLS. My suggestion are: 1)Both PE-rs and MTU-s can do VLAN translation. MTU-s do VLAN= translation only when there is VLAN ambiguity in one Ethernet access networks. 2) In one port of a PE-rs, many P-VLAN can map to one VSI. > >-Ali > > >>-Ali >> >>> >11.2 whose title is "H-VPLS model using Ethernet Access= Network". Besides, >>> >if you use MPLS PW between u-PE and n-PE, then you wouldn't= need VLAN >>> >traslation to begin with since each customer VLAN gets= mapped to a >>> >different PW. >>> > >>> > >>> >> In summary, I suggest to move the VLAN translation= function from the >>> >> MTU-s to PE-rs. PE-rs are more powerful and more= expensive. PE-rs is more >>> >> easy to do VLAN translation, which is defened in >>> >> . >>> >> MTU-s is just a typical bridge, no additional UNI= capability, no VLAN >>> >> translation. >>> > >>> >I think you might have misunderstood the scenario for H-VPLS= with Ethernet >>> >access network. Hope the above explanation helps in= clarifying it. >>> > >>> >-Ali >>> > >>> > >>> > >>> >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Yours >>> >> >>> >>=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua >>> >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-03-18 >>>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D From exim@www1.ietf.org Fri Mar 19 22:26:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08723 for ; Fri, 19 Mar 2004 22:26:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4X7G-0001Jr-3n for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 22:25:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K3PgIg005065 for l2vpn-archive@odin.ietf.org; Fri, 19 Mar 2004 22:25:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4X7F-0001JM-U4 for l2vpn-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 22:25:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08718 for ; Fri, 19 Mar 2004 22:25:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4X7C-0006uB-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 22:25:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4X6H-0006pF-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 22:24:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4X5e-0006jr-00 for l2vpn-web-archive@ietf.org; Fri, 19 Mar 2004 22:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4X5d-0001Ct-Jo; Fri, 19 Mar 2004 22:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4X5K-0001CC-6Q for l2vpn@optimus.ietf.org; Fri, 19 Mar 2004 22:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08618 for ; Fri, 19 Mar 2004 22:23:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4X5H-0006j1-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 22:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4X4E-0006dv-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 22:22:35 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B4X3v-0006Z7-00 for l2vpn@ietf.org; Fri, 19 Mar 2004 22:22:15 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2004 19:25:57 +0000 Received: from sajassi-w2k4.cisco.com (dhcp-171-68-147-23.cisco.com [171.68.147.23]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2K3LgK3018291; Fri, 19 Mar 2004 19:21:43 -0800 (PST) Message-Id: <4.3.2.7.2.20040319180853.02c86bc8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 19:21:41 -0800 To: duwh@huawei.com, Ali Sajassi , "l2vpn@ietf.org" From: Ali Sajassi Subject: Re: Re: Who do VLAN translation in LDP-VPLS? PE-rs or MTU-s? In-Reply-To: <0HUU00DF4QPUUM@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 >So, we get two scenarios: >1) If there is no VLAN ambiguity within MTU-S, then there is no need for VLAN >translation and the PE-rs can resolve the VLAN ambiguity between different >MTU-s. >each pair of port+vlan at the PE-rs is considered as an AC that can be >associated >with a given VSI. >2) If there is VLAN ambiguity within one MTU-S(to be more precise, within one >Ethernet access network),then VLAN translation is still needed in the MTU-s. > >Let's review the 1st scenario. Give an example, if {port 3,VLAN 100} and >{port 3, >VLAN 200} of a PE-rs are considered as two ACs, are associated with one VSI. >It become amusing, there are two idea not to be think about: > 1)PDU come into the PE-rs on {port 3, VLAN 100}, and leave out of the > same PE-rs >on {port 3, VLAN 200} when data exchanging between two ACs. > 2)In port 3 of the PE-rs, 2 VLANs map to 1 VSI. Here is C-VLAN, but have >the same function as P-VLAN. This differs from the sentence in LDP-VLPS: >"Therefore, there is a one to one correspondence between a P-VLAN and a >VPLS instance." In your example, both VLAN 100 and 200 come through port 3 of PE-rs which means they come through the same MTU-s (since MTU-s is directly connected to PE-rs). What this implies is that if VLAN 100 and 200 are used by customer A connected to that MTU-s, then no other customers can use these VLANs (e.g., there is no VLAN ambiguity); however, this contradicts the initial premise that any customer can use any VLAN. Even if we go based on the assumption that the customer's VLAN-100 and 200 don't overlap with any other customer VLAN, there is no P-VLAN in here !!! Because all you have done is to aggregate customer's VLANs (C-VLANs) and bring them to PE-rs. >The above scenarios is not clear in the LDP-VPLS. >My suggestion are: >1)Both PE-rs and MTU-s can do VLAN translation. MTU-s do VLAN translation >only when >there is VLAN ambiguity in one Ethernet access networks. In most applications you have VLAN ambiguity. In other words, as soon as you have two customers connected to a MTU-s, you can have VLAN ambiguity because the two customer's VLAN can overlap. >2) In one port of a PE-rs, many P-VLAN can map to one VSI. No. not P-VLAN. Multiple C-VLAN can map to one VSI but not multiple P-VLAN. P-VLAN is used in conjunction with Ethernet access network and it corresponds to a broadcast domain and thus to a VPLS instance. -Ali From exim@www1.ietf.org Sun Mar 21 11:34:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18585 for ; Sun, 21 Mar 2004 11:34:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B55tU-0002yw-EV for l2vpn-archive@odin.ietf.org; Sun, 21 Mar 2004 11:33:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LGXmol011456 for l2vpn-archive@odin.ietf.org; Sun, 21 Mar 2004 11:33:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B55tU-0002yh-7D for l2vpn-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 11:33:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18500 for ; Sun, 21 Mar 2004 11:33:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B55tT-00032m-00 for l2vpn-web-archive@ietf.org; Sun, 21 Mar 2004 11:33:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B55sZ-0002w5-00 for l2vpn-web-archive@ietf.org; Sun, 21 Mar 2004 11:32:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B55ro-0002q5-00 for l2vpn-web-archive@ietf.org; Sun, 21 Mar 2004 11:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B55rl-0002r9-Dg; Sun, 21 Mar 2004 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B55rU-0002qG-KZ for l2vpn@optimus.ietf.org; Sun, 21 Mar 2004 11:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18393 for ; Sun, 21 Mar 2004 11:31:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B55rT-0002n5-00 for l2vpn@ietf.org; Sun, 21 Mar 2004 11:31:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B55qX-0002fK-00 for l2vpn@ietf.org; Sun, 21 Mar 2004 11:30:45 -0500 Received: from [62.90.130.2] (helo=ilmail1.atrica.com) by ietf-mx with esmtp (Exim 4.12) id 1B55pb-0002Sz-00 for l2vpn@ietf.org; Sun, 21 Mar 2004 11:29:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: "colored pools" in draft-ietf-l2vpn-signaling-01 Date: Sun, 21 Mar 2004 18:29:34 +0200 Message-ID: Thread-Topic: "colored pools" in draft-ietf-l2vpn-signaling-01 Thread-Index: AcQPYascxCko3BzuTgCsopOih8Xw9w== From: "Dror Caspi" To: Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, In the new draft of "Provisioning Models and Endpoint Identifiers in = L2VPN Signaling", it is not clear to me what is the actual usage = envisioned for "Colored Pools" discussed in section 3.3. Could anyone = please explain? Thanks Dror From exim@www1.ietf.org Mon Mar 22 08:34:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23250 for ; Mon, 22 Mar 2004 08:34:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PZR-0008L6-6P for l2vpn-archive@odin.ietf.org; Mon, 22 Mar 2004 08:34:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDYPt4032050 for l2vpn-archive@odin.ietf.org; Mon, 22 Mar 2004 08:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PZQ-0008Kl-O8 for l2vpn-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:34:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23108 for ; Mon, 22 Mar 2004 08:34:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PZP-0001B5-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 08:34:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PXm-0000wd-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 08:32:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5PXD-0000pN-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 08:32:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PX7-0007ts-3y; Mon, 22 Mar 2004 08:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PWk-0007sy-Fl for l2vpn@optimus.ietf.org; Mon, 22 Mar 2004 08:31:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23035 for ; Mon, 22 Mar 2004 08:31:36 -0500 (EST) From: Matthew.Bocci@alcatel.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PWj-0000oa-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 08:31:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PVk-0000jI-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 08:30:36 -0500 Received: from mail.alcatel.co.uk ([208.178.18.30]) by ietf-mx with esmtp (Exim 4.12) id 1B5PVB-0000dB-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 08:30:02 -0500 Received: from gbmail02.netfr.alcatel.fr (IDENT:root@relay01.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.6/8.9.3) with ESMTP id i2MDRCX14894 for ; Mon, 22 Mar 2004 13:27:12 GMT Subject: ATMF Liaison on ATM-MPLS Interworking To: l2vpn@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 22 Mar 2004 13:23:58 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/22/2004 13:27:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Last October the ATM Forum sent a liaison statement to the PWE3 working group announcing the approval of 3 new specs on ATM-MPLS network interworking, inlcuding both user plane and control plane interworking. Since this is relevant to the virtual private wire service, participants in the L2VPN working group might also be interested in the liaison. The liaison is recorded on the IETF liaison's page at the following URL: http://www.ietf.org/IESG/LIAISON/atm-forum-ls-ietf-pwe3.html Best regards, Matthew From exim@www1.ietf.org Mon Mar 22 08:54:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24769 for ; Mon, 22 Mar 2004 08:54:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ps8-0002YU-7t for l2vpn-archive@odin.ietf.org; Mon, 22 Mar 2004 08:53:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDriap009811 for l2vpn-archive@odin.ietf.org; Mon, 22 Mar 2004 08:53:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ps6-0002Y8-U8 for l2vpn-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24766 for ; Mon, 22 Mar 2004 08:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ps5-0003vM-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 08:53:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PrT-0003o5-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 08:53:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5PqZ-0003d4-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 08:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PqU-0002LO-0s; Mon, 22 Mar 2004 08:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ppw-0002EI-QW for l2vpn@optimus.ietf.org; Mon, 22 Mar 2004 08:51:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24559 for ; Mon, 22 Mar 2004 08:51:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ppv-0003W7-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 08:51:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Pp6-0003Qe-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 08:50:37 -0500 Received: from 66.238.227.126.ptr.us.xo.net ([66.238.227.126] helo=ACHAL.westridgenetworks.com) by ietf-mx with smtp (Exim 4.12) id 1B5Po8-0003Jq-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 08:49:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: RE: "colored pools" in draft-ietf-l2vpn-signaling-01 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2004 08:49:30 -0500 Message-ID: <4CBA3FC94D69F945A50C05DA8EA2C4D0021F2F@ACHAL.westridgenetworks.com> Thread-Topic: "colored pools" in draft-ietf-l2vpn-signaling-01 Thread-Index: AcQPYascxCko3BzuTgCsopOih8Xw9wAsXQqA From: "Eric Gray" To: "Dror Caspi" , Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section 3.3.1 gives a fairly comprehensive description of what the authors mean by "colored pool". Perhaps you could be more specific about the points that are not clear? By the way, my pointing this out does not imply my own complete understanding of their description. For example, I do not know how they intend to ensure "global uniqueness" of the combination of "color" and "pool identifier" and - from the description - I am not sure they even mean "global uniqueness"... -- Eric > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of Dror Caspi > Sent: Sunday, March 21, 2004 11:30 AM > To: l2vpn@ietf.org > Subject: "colored pools" in draft-ietf-l2vpn-signaling-01 >=20 > Hi, >=20 > In the new draft of "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", it is not > clear to me what is the actual usage envisioned for "Colored Pools" discussed in section 3.3. Could > anyone please explain? >=20 > Thanks >=20 > Dror From exim@www1.ietf.org Mon Mar 22 19:16:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05742 for ; Mon, 22 Mar 2004 19:16:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZaT-0007UV-KQ for l2vpn-archive@odin.ietf.org; Mon, 22 Mar 2004 19:16:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N0G9Ns028791 for l2vpn-archive@odin.ietf.org; Mon, 22 Mar 2004 19:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZaT-0007UI-GO for l2vpn-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 19:16:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05724 for ; Mon, 22 Mar 2004 19:16:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZaR-0004tE-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 19:16:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZZX-0004l9-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 19:15:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZYT-0004ce-00 for l2vpn-web-archive@ietf.org; Mon, 22 Mar 2004 19:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZYO-0007H9-2O; Mon, 22 Mar 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZXD-0007Cx-46 for l2vpn@optimus.ietf.org; Mon, 22 Mar 2004 19:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05574 for ; Mon, 22 Mar 2004 19:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZXB-0004Sy-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 19:12:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZWH-0004Md-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 19:11:50 -0500 Received: from mx02.melco.co.jp ([192.218.140.142]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZVQ-0004Fv-00 for l2vpn@ietf.org; Mon, 22 Mar 2004 19:10:56 -0500 Received: from mr02.melco.co.jp (unknown [133.141.98.157]) by mx02.melco.co.jp (Postfix) with ESMTP id E10237AA6B for ; Tue, 23 Mar 2004 09:10:47 +0900 (JST) Received: from elgw.isl.melco.co.jp (localhost [127.0.0.1]) by mr02.melco.co.jp (Postfix) with ESMTP id 3E7FB2A7A0 for ; Tue, 23 Mar 2004 09:10:47 +0900 (JST) Received: from elmail by elgw.isl.melco.co.jp (8.12.10+Sun/3.7W) id i2N0AkMR017719; Tue, 23 Mar 2004 09:10:46 +0900 (JST) Received: from isl.melco.co.jp (cannes.isl.melco.co.jp [10.74.53.179]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HV0008GQ5TYT9@elmail.isl.melco.co.jp>; Tue, 23 Mar 2004 09:10:46 +0900 (JST) Date: Tue, 23 Mar 2004 09:14:05 +0900 From: Tetsushi Matsuda Subject: [L2VPN] please comment on draft-matsuda-l2vpn-access-service-protocol To: l2vpn@ietf.org Message-id: <405F814D.81DF45F6@isl.melco.co.jp> Organization: Mitsubishi Electric Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.7 [ja] (WinNT; I) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT X-Accept-Language: ja Content-Transfer-Encoding: 7BIT Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dear L2VPN WG members, I posted a revised version of I-D "draft-matsuda-l2vpn-access-service-protocol". I removed stuffs which seems irrelevant to L2VPN WG and rewrote to describe broadcast/multicast Ethernet frame forwarding behavior of bridge module explicitly. It is located at http://www.ietf.org/internet-drafts/draft-matsuda-l2vpn-access-service-protocol-01.txt I would appreciate any comments and would like you to discuss if Access Service Network application of VPLS can be a WG item. Thank you. -- Tetsushi Matsuda Information Technology R&D Center Mitsubishi Electric Corporation 5-1-1, Ohfuna, Kamakura-shi, Kanagawa-ken, Japan, 247-8501 ph. +81-467-41-2869, FAX +81-467-41-2819 From exim@www1.ietf.org Tue Mar 23 15:50:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28093 for ; Tue, 23 Mar 2004 15:50:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sqk-00049m-ST for l2vpn-archive@odin.ietf.org; Tue, 23 Mar 2004 15:50:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKoEiG015978 for l2vpn-archive@odin.ietf.org; Tue, 23 Mar 2004 15:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sqk-00049d-Le for l2vpn-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 15:50:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27993 for ; Tue, 23 Mar 2004 15:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sqj-00061h-00 for l2vpn-web-archive@ietf.org; Tue, 23 Mar 2004 15:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5spR-0005of-00 for l2vpn-web-archive@ietf.org; Tue, 23 Mar 2004 15:48:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5snm-0005TI-00 for l2vpn-web-archive@ietf.org; Tue, 23 Mar 2004 15:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5snd-0003OQ-DY; Tue, 23 Mar 2004 15:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smo-0002xB-56 for l2vpn@optimus.ietf.org; Tue, 23 Mar 2004 15:46:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27253; Tue, 23 Mar 2004 15:46:07 -0500 (EST) Message-Id: <200403232046.PAA27253@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-l2-framework-04.txt Date: Tue, 23 Mar 2004 15:46:06 -0500 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Framework for Layer 2 Virtual Private Networks (L2VPNs Author(s) : L. Andersson, E. Rosen Filename : draft-ietf-l2vpn-l2-framework-04.txt Pages : 45 Date : 2004-3-23 This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-l2-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-l2-framework-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-23155648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-l2-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-l2-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-23155648.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Mar 25 05:19:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13311 for ; Thu, 25 Mar 2004 05:19:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RxT-0008Nm-97 for l2vpn-archive@odin.ietf.org; Thu, 25 Mar 2004 05:19:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PAJVGV032216 for l2vpn-archive@odin.ietf.org; Thu, 25 Mar 2004 05:19:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6RxT-0008NX-2Y for l2vpn-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 05:19:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13118 for ; Thu, 25 Mar 2004 05:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6RxP-0006oq-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 05:19:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6RvU-0006MB-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 05:17:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6RtR-0005x1-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 05:15:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Rh5-0000ud-CI for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 05:02:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rgd-0005tA-O8; Thu, 25 Mar 2004 05:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QII-0000Pt-1G for l2vpn@optimus.ietf.org; Thu, 25 Mar 2004 03:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09074 for ; Thu, 25 Mar 2004 03:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6QIF-0004ut-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 03:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6QHL-0004qh-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 03:31:56 -0500 Received: from web25105.mail.ukl.yahoo.com ([217.12.10.53]) by ietf-mx with smtp (Exim 4.12) id 1B6QGL-0004hU-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 03:30:53 -0500 Message-ID: <20040325083024.24442.qmail@web25105.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25105.mail.ukl.yahoo.com via HTTP; Thu, 25 Mar 2004 08:30:24 GMT Date: Thu, 25 Mar 2004 08:30:24 +0000 (GMT) From: =?iso-8859-1?q?John=20Smith?= Subject: BGP in L2VPN To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello, Can anybody give me a brief idea as to how BGP is used in establishing L2VPNs/VPLS. I am familiar with how BGP is used in 2547bis networks. Is easy extensibility provided via AFI/SAFI in MP_REACH_NLRI the reason? Or the fact that BGP can be used to span multiple networks the main motivation factor? Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From exim@www1.ietf.org Thu Mar 25 09:12:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22327 for ; Thu, 25 Mar 2004 09:12:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaD-00088T-Ra for l2vpn-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBjxP031268 for l2vpn-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaD-000887-Ee for l2vpn-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22197 for ; Thu, 25 Mar 2004 09:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VaB-0006ZQ-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VYw-0006JA-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXm-00065S-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXQ-0006WA-Jp; Thu, 25 Mar 2004 09:08:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Sbq-00028f-JU for l2vpn@optimus.ietf.org; Thu, 25 Mar 2004 06:01:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14725 for ; Thu, 25 Mar 2004 06:01:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Sbm-0003DF-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 06:01:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Sat-00036Q-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 06:00:15 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6SaD-0002yf-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 05:59:33 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2004 03:04:18 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2PAx2GX014684; Thu, 25 Mar 2004 02:59:02 -0800 (PST) Received: from cisco.com (sjc-vpn2-28.cisco.com [10.21.112.28]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM12953; Thu, 25 Mar 2004 02:59:00 -0800 (PST) Message-ID: <4062BB73.9010107@cisco.com> Date: Thu, 25 Mar 2004 02:58:59 -0800 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Smith CC: l2vpn@ietf.org Subject: Re: BGP in L2VPN References: <20040325083024.24442.qmail@web25105.mail.ukl.yahoo.com> In-Reply-To: <20040325083024.24442.qmail@web25105.mail.ukl.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi John, > Can anybody give me a brief idea as to how BGP is used in establishing > L2VPNs/VPLS. I am familiar with how BGP is used in 2547bis networks. I think you will find your answer in the below document: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-01.txt > Is easy extensibility provided via AFI/SAFI in MP_REACH_NLRI the reason? Or the fact that > BGP can be used to span multiple networks the main motivation factor? IMHO the main reason is the observation that for VPLS topologies which are by nature full mesh regardless of the number of ASes given VPLS spans the fact that BGP is used for auto discovery justifies the addition of label block information to the new NLRI format to achieve both discovery and signaling in the same protocol. The size of this delta addition from the protocol perspective is negligible. Cheers, R. From exim@www1.ietf.org Thu Mar 25 09:44:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25401 for ; Thu, 25 Mar 2004 09:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W5Q-0006VQ-8t for l2vpn-archive@odin.ietf.org; Thu, 25 Mar 2004 09:44:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEi0In025003 for l2vpn-archive@odin.ietf.org; Thu, 25 Mar 2004 09:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W5Q-0006VA-3f for l2vpn-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:44:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25378 for ; Thu, 25 Mar 2004 09:43:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6W5O-0002yq-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 09:43:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6W4X-0002sz-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 09:43:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6W3h-0002mT-00 for l2vpn-web-archive@ietf.org; Thu, 25 Mar 2004 09:42:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W3g-0006Jo-1J; Thu, 25 Mar 2004 09:42:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W2l-0006Go-KQ for l2vpn@optimus.ietf.org; Thu, 25 Mar 2004 09:41:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25228 for ; Thu, 25 Mar 2004 09:41:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6W2j-0002f9-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 09:41:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6W1n-0002WV-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 09:40:16 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1B6W0z-0002I9-00 for l2vpn@ietf.org; Thu, 25 Mar 2004 09:39:25 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2PEchl24088; Thu, 25 Mar 2004 09:38:43 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Mar 2004 09:38:44 -0500 Message-ID: <635C6B4620C6D411909100508BCFE67A10FAFA48@zrtpd0jd.us.nortel.com> From: "Paul Unbehagen" To: John Smith , l2vpn@ietf.org Subject: RE: BGP in L2VPN Date: Thu, 25 Mar 2004 09:38:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41276.DEA64ADC" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41276.DEA64ADC Content-Type: text/plain If you are referring to: http://www.ietf.org/internet-drafts/draft-hlmu-l2vpn-bgp-discovery-00.txt Yes BGP does provide both extensibility and granularity of type of L2VPN w/ different AFI/SAFI values. It also provides a method of discovering VPN endpoints in a different AS's. As well as a method of easing the provisioning model for the operator. Since BGP is acting as a auto-discovery method for LDP, the user is only required to be involved for the creation of the forwarders. BGP will then announce the existence of the forwarders to all other PEs and the filtering rules of RT apply in a similar manner as 2547bis. Also the use of BGP for auto-discovery applies to both VPWS as well as VPLS. - Paul -----Original Message----- From: John Smith [mailto:jsmith4112003@yahoo.co.uk] Sent: Thursday, March 25, 2004 3:30 AM To: l2vpn@ietf.org Subject: BGP in L2VPN Hello, Can anybody give me a brief idea as to how BGP is used in establishing L2VPNs/VPLS. I am familiar with how BGP is used in 2547bis networks. Is easy extensibility provided via AFI/SAFI in MP_REACH_NLRI the reason? Or the fact that BGP can be used to span multiple networks the main motivation factor? Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html ------_=_NextPart_001_01C41276.DEA64ADC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: BGP in L2VPN

If you are referring to:
http://www.ietf.org/internet-drafts/draft-hlmu-l2vpn-b= gp-discovery-00.txt

Yes BGP does provide both extensibility and = granularity of type of L2VPN w/ different AFI/SAFI values. It also = provides a method of discovering VPN endpoints in a different = AS's.  As well as a method of easing the provisioning model for = the operator.  Since BGP is acting as a auto-discovery method for = LDP, the user is only required to be involved for the creation of the = forwarders.  BGP will then announce the existence of the = forwarders to all other PEs and the filtering rules of RT apply in a = similar manner as 2547bis.  Also the use of BGP for auto-discovery = applies to both VPWS as well as VPLS. 

- Paul

-----Original Message-----
From: John Smith [mailto:jsmith4112003@yahoo.co.= uk]
Sent: Thursday, March 25, 2004 3:30 AM
To: l2vpn@ietf.org
Subject: BGP in L2VPN


Hello,

Can anybody give me a brief idea as to how BGP is = used in establishing L2VPNs/VPLS. I am familiar with how BGP is used in = 2547bis networks.

Is easy extensibility provided via AFI/SAFI in = MP_REACH_NLRI the reason? Or the fact that BGP can be used to span = multiple networks the main motivation factor?

Regards,
Smith


       =20
       =20
        =        =20
___________________________________________________________
Yahoo! Messenger - Communicate = instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html<= /FONT>

------_=_NextPart_001_01C41276.DEA64ADC-- From exim@www1.ietf.org Fri Mar 26 17:58:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22637 for ; Fri, 26 Mar 2004 17:58:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70HR-0002MT-Gd for l2vpn-archive@odin.ietf.org; Fri, 26 Mar 2004 17:58:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QMwPrU009070 for l2vpn-archive@odin.ietf.org; Fri, 26 Mar 2004 17:58:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70HR-0002MD-BF for l2vpn-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 17:58:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22634 for ; Fri, 26 Mar 2004 17:58:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70HO-0002MC-00 for l2vpn-web-archive@ietf.org; Fri, 26 Mar 2004 17:58:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70GS-0002Gv-00 for l2vpn-web-archive@ietf.org; Fri, 26 Mar 2004 17:57:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B70GA-0002DT-00 for l2vpn-web-archive@ietf.org; Fri, 26 Mar 2004 17:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70G4-0002FK-Q9; Fri, 26 Mar 2004 17:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70FU-0002ES-K5 for l2vpn@optimus.ietf.org; Fri, 26 Mar 2004 17:56:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22588 for ; Fri, 26 Mar 2004 17:56:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70FS-0002Cf-00 for l2vpn@ietf.org; Fri, 26 Mar 2004 17:56:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70EU-00029T-00 for l2vpn@ietf.org; Fri, 26 Mar 2004 17:55:22 -0500 Received: from web21404.mail.yahoo.com ([216.136.232.74]) by ietf-mx with smtp (Exim 4.12) id 1B70E1-00026V-00 for l2vpn@ietf.org; Fri, 26 Mar 2004 17:54:53 -0500 Message-ID: <20040326225453.10076.qmail@web21404.mail.yahoo.com> Received: from [64.221.212.137] by web21404.mail.yahoo.com via HTTP; Fri, 26 Mar 2004 14:54:53 PST Date: Fri, 26 Mar 2004 14:54:53 -0800 (PST) From: narasimhan g Subject: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1231724216-1080341693=:9797" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,FROM_HAS_ULINE_NUMS, HTML_MESSAGE autolearn=no version=2.60 --0-1231724216-1080341693=:9797 Content-Type: text/plain; charset=us-ascii Hello, I have a question regarding hybrid learning. My question is regarding the following text in section 8.1.1 last paragrah. "When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic"... I have the following questions regarding this statement. 1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 and 300 ) and B have vlans ( 400, 500 and 600) on the same port? 2., Does it mean that one of the vlans in each customer domain is reserved for sending/receiving STP/MSTP BPDUs? Say vlan 100 for customer domain A and 500 for customer domain B? Is this to be done through configuration on both the VPLS PE and the customer node? Also can regular data frames be also sent on this reserved vlan? 3. Does it really matter to the VPLS PE which of the customer vlans the STP/MSTP BPDUS are received? Would really appreciate any reply thanks, narasim -------------------------------------------------------------------- --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --0-1231724216-1080341693=:9797 Content-Type: text/html; charset=us-ascii
Hello,
 
I have a question regarding hybrid learning.  My question
is regarding the following text  in section 8.1.1 last paragrah.
 
"When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic"...  
 
I have the following questions regarding this statement. 
 
1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 and 300 )  and B have vlans ( 400, 500 and 600) on the same port?
 
2., Does it mean that one of the vlans in each customer domain is reserved for sending/receiving STP/MSTP BPDUs?  Say vlan 100 for
customer domain A and 500 for customer domain B? Is this to be done through configuration on both the VPLS PE and the customer node?  Also can regular data frames be also sent on this reserved vlan?
 
3. Does it really matter to the VPLS PE which of the customer vlans the STP/MSTP BPDUS are received?
 
Would really appreciate any reply
 
thanks,
 
narasim
 
--------------------------------------------------------------------

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time. --0-1231724216-1080341693=:9797-- From exim@www1.ietf.org Sat Mar 27 18:12:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05187 for ; Sat, 27 Mar 2004 18:12:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7MyG-0007s3-4U for l2vpn-archive@odin.ietf.org; Sat, 27 Mar 2004 18:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2RNC8Jt030249 for l2vpn-archive@odin.ietf.org; Sat, 27 Mar 2004 18:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7MyF-0007ro-VC for l2vpn-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 18:12:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05144 for ; Sat, 27 Mar 2004 18:12:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7MyD-00060c-00 for l2vpn-web-archive@ietf.org; Sat, 27 Mar 2004 18:12:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7MxH-0005w2-00 for l2vpn-web-archive@ietf.org; Sat, 27 Mar 2004 18:11:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7MwX-0005rB-00 for l2vpn-web-archive@ietf.org; Sat, 27 Mar 2004 18:10:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7MwD-000726-Bx; Sat, 27 Mar 2004 18:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7MvO-0006lc-RY for l2vpn@optimus.ietf.org; Sat, 27 Mar 2004 18:09:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04885 for ; Sat, 27 Mar 2004 18:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7MvL-0005lP-00 for l2vpn@ietf.org; Sat, 27 Mar 2004 18:09:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7MuR-0005g4-00 for l2vpn@ietf.org; Sat, 27 Mar 2004 18:08:12 -0500 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1B7Mtb-0005Uq-00 for l2vpn@ietf.org; Sat, 27 Mar 2004 18:07:19 -0500 Received: from MARCLL2K by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA04749; Sat, 27 Mar 2004 15:06:42 -0800 (PST) Message-ID: <107401c41450$26559a60$6501a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "narasimhan g" , References: <20040326225453.10076.qmail@web21404.mail.yahoo.com> Subject: Re: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt Date: Sun, 28 Mar 2004 00:06:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1071_01C41458.7AE8C810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_1071_01C41458.7AE8C810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Narasim, See my answers inline. Thanks, Marc ----- Original Message -----=20 From: narasimhan g=20 To: l2vpn@ietf.org=20 Sent: March 26, 2004 23:54 Subject: question on hybrid learning and = draft-ietf-ppvpn-vpls-ldp-01.txt Hello, I have a question regarding hybrid learning. My question is regarding the following text in section 8.1.1 last paragrah. "When an access port is shared among multiple customers, a reserved = VLAN per customer domain must be used to carry STP/MSTP traffic"... =20 I have the following questions regarding this statement.=20 1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 = and 300 ) and B have vlans ( 400, 500 and 600) on the same port? Yes, it is possible. 2., Does it mean that one of the vlans in each customer domain is = reserved for sending/receiving STP/MSTP BPDUs? Say vlan 100 for=20 customer domain A and 500 for customer domain B? Is this to be done = through configuration on both the VPLS PE and the customer node? Also = can regular data frames be also sent on this reserved vlan? STP/MSTP BPDUs must be VLAN tagged in order for VPLS PEs to know which = VPLS domain to forward BPDUs to. This VLAN tag can be any of the customer's VLANs. Both CE and PE devices = would have to be configured with the corresponding VLAN tag. Regular frames can be sent on this VLAN. 3. Does it really matter to the VPLS PE which of the customer vlans = the STP/MSTP BPDUS are received? No, it does not since the only requirement is for a PE to know where to = forward such BPDUs. Would really appreciate any reply thanks, narasim -------------------------------------------------------------------- -------------------------------------------------------------------------= ----- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. ------=_NextPart_000_1071_01C41458.7AE8C810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Narasim,
 
See my answers inline.
 
Thanks,
Marc
----- Original Message -----
From:=20 narasimhan=20 g
Sent: March 26, 2004 = 23:54
Subject: question on hybrid = learning and=20 draft-ietf-ppvpn-vpls-ldp-01.txt

Hello,
 
I have a question regarding hybrid learning.  My = question
is regarding the following text  in section 8.1.1 last=20 paragrah.
 
"When an access port is shared among multiple customers, a = reserved VLAN=20 per customer domain must be used to carry STP/MSTP=20 traffic"...  
 
I have the following questions regarding this = statement. 
 
1. Can the customer domain ( say A ) have a few vlans ( eg., 100, = 200 and=20 300 )  and B have vlans ( 400, 500 and 600) on the same = port?
 
Yes, it is possible.
 
2., Does it mean that one of the vlans in each customer domain is = reserved for sending/receiving STP/MSTP BPDUs?  Say vlan 100 for =
customer domain A and 500 for customer domain B? Is this to = be done=20 through configuration on both the VPLS PE and the customer = node? =20 Also can regular data frames be also sent on this reserved=20 vlan?
STP/MSTP BPDUs must be VLAN tagged in = order for=20 VPLS PEs to know which VPLS domain to forward BPDUs to.
This VLAN tag can be any of = the customer's=20 VLANs. Both CE and PE devices would have to be configured with = the
corresponding VLAN tag. Regular frames = can be sent=20 on this VLAN.
 
3. Does it really matter to the VPLS PE which of the customer = vlans the=20 STP/MSTP BPDUS are received?
 
No, it does not since the only = requirement is for a=20 PE to know where to forward such BPDUs.
 
Would really appreciate any reply
 
thanks,
 
narasim
 
=
--------------------------------------------------------------------=

Do you Yahoo!?
Yahoo! Finance Tax = Center=20 - File online. File on time. ------=_NextPart_000_1071_01C41458.7AE8C810-- From exim@www1.ietf.org Mon Mar 29 04:29:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21295 for ; Mon, 29 Mar 2004 04:29:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7t4a-0008Vq-3j for l2vpn-archive@odin.ietf.org; Mon, 29 Mar 2004 04:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9SmT5032721 for l2vpn-archive@odin.ietf.org; Mon, 29 Mar 2004 04:28:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7t4Z-0008Vg-JG for l2vpn-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 04:28:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21275 for ; Mon, 29 Mar 2004 04:28:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7t4W-0006cR-00 for l2vpn-web-archive@ietf.org; Mon, 29 Mar 2004 04:28:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7t3c-0006Sv-00 for l2vpn-web-archive@ietf.org; Mon, 29 Mar 2004 04:27:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7t2t-0006HN-00 for l2vpn-web-archive@ietf.org; Mon, 29 Mar 2004 04:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7t2q-0008KJ-JA; Mon, 29 Mar 2004 04:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7t2G-0008JE-RO for l2vpn@optimus.ietf.org; Mon, 29 Mar 2004 04:26:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21071 for ; Mon, 29 Mar 2004 04:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7t2D-0006Dx-00 for l2vpn@ietf.org; Mon, 29 Mar 2004 04:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7t1M-000663-00 for l2vpn@ietf.org; Mon, 29 Mar 2004 04:25:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B7t0c-0005w1-00 for l2vpn@ietf.org; Mon, 29 Mar 2004 04:24:42 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2004 01:24:27 -0800 Received: from sajassi-w2k4.cisco.com (sjc-vpn2-7.cisco.com [10.21.112.7]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2T9O7BC023690; Mon, 29 Mar 2004 01:24:08 -0800 (PST) Message-Id: <4.3.2.7.2.20040329002458.02852478@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Mar 2004 01:24:05 -0800 To: "Marc Lasserre" , "narasimhan g" , From: Ali Sajassi Subject: Re: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt In-Reply-To: <107401c41450$26559a60$6501a8c0@rs.riverstonenet.com> References: <20040326225453.10076.qmail@web21404.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_129631550==_.ALT" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --=====================_129631550==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Marc, I think it needs to be assumed that in a qualified mode, if multiple customers are getting multiplexed over the same PE's port, then the BPDU frames of a given customer will have the same service tag as the data for that customer (e.g., there should be no need for any reserved tag for customer's BPDUs inside the PE). Lets go over the following scenarios: 1) A standard bridge is used to multiplex the traffic from multiple customers over a single port: In this case, the untagged BPDU traffic from the standard bridge would represent the traffic for all the customers and thus the PE needs to participate in customers' BPDUs and once it does that it can mark the BPDUs for each customer with the same service tag as the data for that customer and thus direct that into the proper filtering database. 2) A new Provider Bridge (802.1ad) is used to multiplex the traffic from multiple customers over a single port: In this case, the Provider Bridge does the work and does the proper tagging of the customers' BPDUs and as the result, the BPDU traffic for each customer will carry the same service tag as the customer traffic. Furthermore, if there are multiple service instances for a given customer, then each such service instance would carry its own BPDUs which would have the same service tag as its corresponding data for that service. If what I am saying is not very clear, then I would recommend going over sections 5.2 through 5.9 of 802.1ad. Regards, Ali At 12:06 AM 3/28/2004 +0100, Marc Lasserre wrote: >Narasim, > >See my answers inline. > >Thanks, >Marc >----- Original Message ----- >From: narasimhan g >To: l2vpn@ietf.org >Sent: March 26, 2004 23:54 >Subject: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt > >Hello, > >I have a question regarding hybrid learning. My question >is regarding the following text in section 8.1.1 last paragrah. > >"When an access port is shared among multiple customers, a reserved VLAN >per customer domain must be used to carry STP/MSTP traffic"... > >I have the following questions regarding this statement. > >1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 and >300 ) and B have vlans ( 400, 500 and 600) on the same port? > > >Yes, it is possible. > >2., Does it mean that one of the vlans in each customer domain is reserved >for sending/receiving STP/MSTP BPDUs? Say vlan 100 for >customer domain A and 500 for customer domain B? Is this to be done >through configuration on both the VPLS PE and the customer node? Also can >regular data frames be also sent on this reserved vlan? > >STP/MSTP BPDUs must be VLAN tagged in order for VPLS PEs to know which >VPLS domain to forward BPDUs to. >This VLAN tag can be any of the customer's VLANs. Both CE and PE devices >would have to be configured with the >corresponding VLAN tag. Regular frames can be sent on this VLAN. > >3. Does it really matter to the VPLS PE which of the customer vlans the >STP/MSTP BPDUS are received? > > >No, it does not since the only requirement is for a PE to know where to >forward such BPDUs. > >Would really appreciate any reply > >thanks, > >narasim > >-------------------------------------------------------------------- > >Do you Yahoo!? >Yahoo! Finance Tax Center - File >online. File on time. --=====================_129631550==_.ALT Content-Type: text/html; charset="us-ascii" Marc,

I think it needs to be assumed that in a qualified mode, if multiple customers are getting multiplexed over the same PE's port, then the BPDU frames of a given customer will have the same service tag as the data for that customer (e.g., there should be no need for any reserved tag for customer's BPDUs inside the PE). Lets go over the following scenarios:

1) A standard bridge is used to multiplex the traffic from multiple customers over a single port:
In this case, the untagged BPDU traffic from the standard bridge would represent the traffic for all the customers and thus the PE needs to participate in customers' BPDUs and once it does that it can mark the BPDUs for each customer with the same service tag as the data for that customer and thus direct that into the proper filtering database.

2) A new Provider Bridge (802.1ad) is used to multiplex the traffic from multiple customers over a single port:
In this case, the Provider Bridge does the work and does the proper tagging of the customers' BPDUs and as the result, the BPDU traffic for each customer will carry the same service tag as the customer traffic. Furthermore, if there are multiple service instances for a given customer, then each such service instance would carry its own BPDUs which would have the same service tag as its corresponding data for that service. If what I am saying is not very clear, then I would recommend going over sections 5.2 through 5.9 of 802.1ad.

Regards,
Ali


At 12:06 AM 3/28/2004 +0100, Marc Lasserre wrote:
Narasim,
 
See my answers inline.
 
Thanks,
Marc
----- Original Message -----
From: narasimhan g
To: l2vpn@ietf.org
Sent: March 26, 2004 23:54
Subject: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt

Hello,
 
I have a question regarding hybrid learning.  My question
is regarding the following text  in section 8.1.1 last paragrah.
 
"When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic"... 
 
I have the following questions regarding this statement.
 
1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 and 300 )  and B have vlans ( 400, 500 and 600) on the same port?
 

Yes, it is possible.
 
2., Does it mean that one of the vlans in each customer domain is reserved for sending/receiving STP/MSTP BPDUs?  Say vlan 100 for
customer domain A and 500 for customer domain B? Is this to be done through configuration on both the VPLS PE and the customer node?  Also can regular data frames be also sent on this reserved vlan?

STP/MSTP BPDUs must be VLAN tagged in order for VPLS PEs to know which VPLS domain to forward BPDUs to.
This VLAN tag can be any of the customer's VLANs. Both CE and PE devices would have to be configured with the
corresponding VLAN tag. Regular frames can be sent on this VLAN.
 
3. Does it really matter to the VPLS PE which of the customer vlans the STP/MSTP BPDUS are received?
 

No, it does not since the only requirement is for a PE to know where to forward such BPDUs.
 
Would really appreciate any reply
 
thanks,
 
narasim
 
--------------------------------------------------------------------

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
--=====================_129631550==_.ALT-- From exim@www1.ietf.org Mon Mar 29 17:41:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00771 for ; Mon, 29 Mar 2004 17:41:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85R3-0003SI-Jw for l2vpn-archive@odin.ietf.org; Mon, 29 Mar 2004 17:40:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TMen8k013278 for l2vpn-archive@odin.ietf.org; Mon, 29 Mar 2004 17:40:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85R3-0003S5-BN for l2vpn-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 17:40:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00764 for ; Mon, 29 Mar 2004 17:40:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B85R0-0004RI-00 for l2vpn-web-archive@ietf.org; Mon, 29 Mar 2004 17:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B85Q0-0004Jf-00 for l2vpn-web-archive@ietf.org; Mon, 29 Mar 2004 17:39:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B85PJ-0004CP-00 for l2vpn-web-archive@ietf.org; Mon, 29 Mar 2004 17:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85PI-0003I3-BU; Mon, 29 Mar 2004 17:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85OD-00038T-SK for l2vpn@optimus.ietf.org; Mon, 29 Mar 2004 17:37:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00615 for ; Mon, 29 Mar 2004 17:37:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B85O8-00042W-00 for l2vpn@ietf.org; Mon, 29 Mar 2004 17:37:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B85NK-0003tD-00 for l2vpn@ietf.org; Mon, 29 Mar 2004 17:37:00 -0500 Received: from web21406.mail.yahoo.com ([216.136.232.76]) by ietf-mx with smtp (Exim 4.12) id 1B85MV-0003iV-00 for l2vpn@ietf.org; Mon, 29 Mar 2004 17:36:07 -0500 Message-ID: <20040329223600.15117.qmail@web21406.mail.yahoo.com> Received: from [64.221.212.137] by web21406.mail.yahoo.com via HTTP; Mon, 29 Mar 2004 14:36:00 PST Date: Mon, 29 Mar 2004 14:36:00 -0800 (PST) From: narasimhan g Subject: Re: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt To: Ali Sajassi , Marc Lasserre , l2vpn@ietf.org In-Reply-To: <4.3.2.7.2.20040329002458.02852478@airborne.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-318170245-1080599760=:13977" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,FROM_HAS_ULINE_NUMS, HTML_MESSAGE autolearn=no version=2.60 --0-318170245-1080599760=:13977 Content-Type: text/plain; charset=us-ascii Thanks Marc, Sajassi for your answers. narasim Ali Sajassi wrote: Marc, I think it needs to be assumed that in a qualified mode, if multiple customers are getting multiplexed over the same PE's port, then the BPDU frames of a given customer will have the same service tag as the data for that customer (e.g., there should be no need for any reserved tag for customer's BPDUs inside the PE). Lets go over the following scenarios: 1) A standard bridge is used to multiplex the traffic from multiple customers over a single port: In this case, the untagged BPDU traffic from the standard bridge would represent the traffic for all the customers and thus the PE needs to participate in customers' BPDUs and once it does that it can mark the BPDUs for each customer with the same service tag as the data for that customer and thus direct that into the proper filtering database. 2) A new Provider Bridge (802.1ad) is used to multiplex the traffic from multiple customers over a single port: In this case, the Provider Bridge does the work and does the proper tagging of the customers' BPDUs and as the result, the BPDU traffic for each customer will carry the same service tag as the customer traffic. Furthermore, if there are multiple service instances for a given customer, then each such service instance would carry its own BPDUs which would have the same service tag as its corresponding data for that service. If what I am saying is not very clear, then I would recommend going over sections 5.2 through 5.9 of 802.1ad. Regards, Ali At 12:06 AM 3/28/2004 +0100, Marc Lasserre wrote: Narasim, See my answers inline. Thanks, Marc ----- Original Message ----- From: narasimhan g To: l2vpn@ietf.org Sent: March 26, 2004 23:54 Subject: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt Hello, I have a question regarding hybrid learning. My question is regarding the following text in section 8.1.1 last paragrah. "When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic"... I have the following questions regarding this statement. 1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 and 300 ) and B have vlans ( 400, 500 and 600) on the same port? Yes, it is possible. 2., Does it mean that one of the vlans in each customer domain is reserved for sending/receiving STP/MSTP BPDUs? Say vlan 100 for customer domain A and 500 for customer domain B? Is this to be done through configuration on both the VPLS PE and the customer node? Also can regular data frames be also sent on this reserved vlan? STP/MSTP BPDUs must be VLAN tagged in order for VPLS PEs to know which VPLS domain to forward BPDUs to. This VLAN tag can be any of the customer's VLANs. Both CE and PE devices would have to be configured with the corresponding VLAN tag. Regular frames can be sent on this VLAN. 3. Does it really matter to the VPLS PE which of the customer vlans the STP/MSTP BPDUS are received? No, it does not since the only requirement is for a PE to know where to forward such BPDUs. Would really appreciate any reply thanks, narasim -------------------------------------------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --0-318170245-1080599760=:13977 Content-Type: text/html; charset=us-ascii
Thanks Marc, Sajassi for your answers.
 
narasim

Ali Sajassi <sajassi@cisco.com> wrote:
Marc,

I think it needs to be assumed that in a qualified mode, if multiple customers are getting multiplexed over the same PE's port, then the BPDU frames of a given customer will have the same service tag as the data for that customer (e.g., there should be no need for any reserved tag for customer's BPDUs inside the PE). Lets go over the following scenarios:

1) A standard bridge is used to multiplex the traffic from multiple customers over a single port:
In this case, the untagged BPDU traffic from the standard bridge would represent the traffic for all the customers and thus the PE needs to participate in customers' BPDUs and once it does that it can mark the BPDUs for each customer with the same service tag as the data for that customer and thus direct that into the proper filtering database.

2) A new Provider Bridge (802.1ad) is used to multiplex ! the traffic from multiple customers over a single port:
In this case, the Provider Bridge does the work and does the proper tagging of the customers' BPDUs and as the result, the BPDU traffic for each customer will carry the same service tag as the customer traffic. Furthermore, if there are multiple service instances for a given customer, then each such service instance would carry its own BPDUs which would have the same service tag as its corresponding data for that service. If what I am saying is not very clear, then I would recommend going over sections 5.2 through 5.9 of 802.1ad.

Regards,
Ali


At 12:06 AM 3/28/2004 +0100, Marc Lasserre wrote:
Narasim,
 
See my answers inline.
 
Thanks,
Marc
----- Original Message -----
From: narasimhan g
To: l2vpn@ietf.org
Sent: March 26, 2004 23:54
Subject: question on hybrid learning and draft-ietf-ppvpn-vpls-ldp-01.txt

Hello,
I have a question regarding hybrid learning.  My question
is regarding the following text  in section 8.1.1 last paragrah.
"When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic"... 
I have the following questions regarding this statement.
1. Can the customer domain ( say A ) have a few vlans ( eg., 100, 200 and 300 )  and B have vlans ( 400, 500 and 600) on the same port?


 
Yes, it is possible.
2., Does it mean that one of the vlans in each customer domain is reserved for sending/receiving STP/MSTP BPDUs?  Say vlan 100 for
customer domain A and 500 for customer domain B? Is this to be done through configuration on both the VPLS PE and the customer node?  Also can regular data frames be also sent on this reserved vlan?

STP/MSTP BPDUs must be VLAN tagged in order for VPLS PEs to know which VPLS domain to forward BPDUs to.
This VLAN tag can be any of the customer's VLANs. Both CE and PE devices would have to be configured with the
corresponding VLAN tag. Regular frames can be sent on this VLAN.
3. Does it really matter to the VPLS PE which of the customer vlans the STP/MSTP BPDUS are received?


 
No, it does not since the only requirement is for a PE to know where to forward such BPDUs.
 
Would really appreciate any reply
thanks,
narasim
--------------------------------------------------------------------

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time. --0-318170245-1080599760=:13977-- From exim@www1.ietf.org Tue Mar 30 17:20:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17187 for ; Tue, 30 Mar 2004 17:20:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RaA-00062v-3F for l2vpn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:19:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UMJgBv023236 for l2vpn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:19:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ra9-00062Q-Pl for l2vpn-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 17:19:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17179 for ; Tue, 30 Mar 2004 17:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Ra7-00056B-00 for l2vpn-web-archive@ietf.org; Tue, 30 Mar 2004 17:19:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8RZB-00052c-00 for l2vpn-web-archive@ietf.org; Tue, 30 Mar 2004 17:18:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8RYZ-0004zq-00 for l2vpn-web-archive@ietf.org; Tue, 30 Mar 2004 17:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RYX-0005vm-TM; Tue, 30 Mar 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RY6-0005ud-2f for l2vpn@optimus.ietf.org; Tue, 30 Mar 2004 17:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17087 for ; Tue, 30 Mar 2004 17:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8RY3-0004xA-00 for l2vpn@ietf.org; Tue, 30 Mar 2004 17:17:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8RX8-0004si-00 for l2vpn@ietf.org; Tue, 30 Mar 2004 17:16:37 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1B8RWH-0004jH-00 for l2vpn@ietf.org; Tue, 30 Mar 2004 17:15:42 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 14:15:11 -0800 Reply-To: From: "Vach Kompella" To: Subject: Minutes from IETF59 L2VPN WG Date: Tue, 30 Mar 2004 14:15:10 -0800 Organization: Alcatel USA Message-ID: <00a801c416a4$78eecca0$0101010a@eng.timetra.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A9_01C41661.6ACB8CA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 30 Mar 2004 22:15:11.0626 (UTC) FILETIME=[77F5C6A0:01C416A4] Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C41661.6ACB8CA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I finally got around to collating the minutes. Unfortunately, the presentations and minutes zipped up was considerably over the max email size and got rejected. I have submitted them to the official IETF authorities. Meanwhile, I'll see if Loa can host them on his site for a bit? Thanks to Thomas Eriksson, Giles Heron and Dimitri Papadimitriou for taking copious notes on a rather fast-paced WG session. Vach Kompella IP Division, Alcatel vach.kompella@alcatel.com +1 650 237-5152=20 ------=_NextPart_000_00A9_01C41661.6ACB8CA0 Content-Type: text/plain; name="l2vpn-minutes.txt" Content-Disposition: attachment; filename="l2vpn-minutes.txt" Content-Transfer-Encoding: quoted-printable WG status - Vach ---------------- big trouble with MIBs. Need volunteers. Vach had no time to do straw = men. After meeting can anyone who is willing to work on VPWS/VPLS MIBs = please get together with Vach. draft on OAM for VPLS expired as not resubmitted. Will get it = resubmitted. draft being presented on OAM for VPWS by Dinesh Mohan. L2 requirements ready for submit to IESG. Will do WG last call = immediately after IETF. L2 framework in good shape. Eric Rosen has some nits to fix which he'll = do once fixes some nits in other drafts. Kireeti ready to last call BGP VPLS soln. Vach has work to do on LDP = VPLS soln. Asked at last IETF for comments on the change of FEC. Only = 3 comments. This time will just go ahead and do it. Should be ready to = submit for last call by the week after IETF. VPWS solutions need to check with authors if they are ready. Need to talk more about IP-only L2VPN docs. These are interworking. Need: Work on MIBs VPLS/VPWS OAM work applicability statements for VPWS and VPLS Marc will present on VPLS-LDP Can Kireeti take a crack at VPLS-BGP? Kireeti - OK, will do applicability for VPLS-BGP Discussing BGP with Routing Area directors. Docs that propose changes = to routing area protocols need to be addressed. Not in agreement with = ADs. We think there is need to have full standard in one doc and take = the BGP related parts to IDR for last call/WG approval. Not clear how = we'll do it - will sort out this week. Kireeti - have a couple of Qs on applicability for BGP. Does this = process of reviewing BGP part of VPLS apply only to VPLS-BGP, or do we = take VPLS-LDP to MPLS, and do we take 2547 to IDR? Vach - this is a general direction for everything we do here. For VPLS = will piggyback on PWE3. Kireeti - does that mean we take Martini to MPLS also? Vach - do we take a section and present it at the other group, or = present the whole thing. Doesn't make sense to extract BGP related = stuff. Trying to figure out what the ADs want us to do. LDP should be = vetted in MPLS and BGP in IDR. Kireeti - as a precedent when we did TE we didn't pull stuff out. The = reason we pulled out routing in GMPLS was that there was two ways of = doing it. Had there been one way we'd have had one doc. Vach - what does Alex want? Alex - the default mode should be that all changes to protocols happen = in protocol specific WGs. Probably should look at specific docs and see = if it makes sense to pull out the protocol specific stuff. Either way = docs that propose changes should go to protocol specific WG and check = that we have consensus that this is the right way (rather than just no = objection). Goal is not to stall the work, but to ensure that the = expert group has a chance to comment on the work and agree that it's the = right way to do it. Kireeti - is this just for BGP? Alex - should look at all docs. Kireeti - 2547? Alex - 2547 has been there too long. Loa - we can cut discussion off here. We've got a feel for the scope. = Got a problem and we need to do something about it. Alex - will be sorted within a couple of weeks. Sasha V. - have we had a decision on whether ARP mediation is in scope? Vach - that's why I'm going to present on why ARP mediation/interworking = of a particular type is in scope. Yakov - question on VPLS LDP. Must specify at least one default mode = for auto-discovery to have interoperable implementations. Giles - manual config? Yakov - spell it out in spec? Vach - OK. Marc - what discovery we use (manual vs provisioned vs autodiscovery) is = implicit in VPLS draft VPLS Applicability - Marc Lasserre ---------------------------------- mix of the work in the VPLS draft and practical experience with = deployments. base draft specifies signalling and bridging rules. applicability describes the applicability of the base draft to meet the = requirements in the requirements draft. Content: 1) Overview of solution operation and alternative approaches (and = migration from the latter to the former) 2) scalability 3) deployment aspects (2) and (3) may be combined in future as overlap. for scalability have same old L2 issues: 1) full mesh - and use of H-VPLS to break mesh 2) MAc address scaling (can't summarise them so need mechanisms to cope = with large numbers). One solution is to say interconnect model is to = use routers and limit to one per site, but in the case of a bridge we = have other mechanisms - e.g. MAC limiting per port/VLAN per VPLS etc. 3) broadcast - need to protect SPs resources by limiting amount of = broadcast per customer or per VPLS instance 4) replication - need to look at how efficient it can be in L2 domain. = Need to be wirespeed. Look at how hierarchy can help. Also enhance = multicast replication by using IGMP snooping. for deployment we have: provisioning/management has various requirements: 1) How do we do PE discovery. Various competing approaches for = auto-discovery, plus management based solution (OSS). 2) traffic conditioning at ingress - limit amount of traffic a customer = can send per VPLS (to meet specific customer SLAs, and to protect core = SP resource). 3) how to do TE on PSN tunnels for VPLS 4) will have a couple of drafts presented on fault and performance = management migration aspects - how to go from Q or QinQ to VPLS and how to use VPLS = to interconnect QinQ islands etc. multihoming aspects. When MTUs are multihomed then how do we cope. = Could use STP or could use primary/secondary links. So could be handled = in customer network (using STPs - means PEs are transparent and = backdoors are allowed). Primary/secondary is similar - up to customer = to dictate how it works. SP doesn't interact much with customer = network. However still need for SP to guarantee loop-free topology. packet reordering issues (in presence of ECMP etc.) QoS Mappings multi-domain connectivity - using H-VPLS spoke to interconnect domains = (one spoke per domain). How do we interwork with BGP VPN. interworking with FR/aTM/PP attachments: - data plane is bridged encaps - need to specify how to map service profiles, OAM, circuit management. = Draft today on OAM. rest still to be done - no draft yet. Security - use of per VPLS FIB, but also DoS mitigation. This is first rev. Future revs need to describe capacity scaling etc = (hard to pick numbers as are implementation dependent). Also how to = prevent unauthorised CEs attaching. Sense of room vis a vis WG doc? Yakov - mentioned need for TE in an earlier slide? Question is this = just for unicast, or for unicast and multicast. Marc - good question. TE today is primarily for unicast today, as is = FRR. Multicast gets carried over P2P PWs in VPLS so if each P2P circuit = is TE then OK on the protection side. for QoS is more at ingress (rate = limiting). Yakov - not answered my Q. Marc - not required. Yakov - useful to clarify in this doc. Dinesh Mohan - in draft on OAM section you have taken some of my work = into consideration, along with the expired VPLS OAM draft. Two points: 1) some aspects in the refs you quote to IEEE. Not .1ad. In march will = have new ref. 2) with regards to capability for MPLS-based network and PWs the = inter-working aspects you've mentioned will still be possible. Sense of room for WG doc. Not a representative IETF - will ask the = question. First time people have seen this so more a sense of whether = Marc should continue the work. A few in favour. Nobody opposed. VPLS Fault and Performance Management - Dinesh Mohan ---------------------------------------------------- these drafts are in charter. Trying to focus on fault/performance = aspects and maintain alignment with work in other standards bodies. OAM typically has two elements: 1) Interface between NMS and EMS 2) Interface between EMS and nodes we are focussing on the 2nd. VPLS is an Ethernet service. May have Ethernet or MPLS access, and an = MPLS core. From customer POV OAM is CE to CE. From provider POV it is = U-PE to U-PE. From operator POV it is U-PE to N-PE or N-PE to N-PE = (therefore multiple operator domains for one service). Admin boundaries = are important as when different bus models/deployment scenarios are = applied there will be different responsibilities. Will need filtering = of OAM flows so they don't flow into the wrong domain. Maintenance Points - nodes where OAM flows are inserted/terminated Intermediate Points - nodes beteen MPs which are responsible for = processing OAMs Interesting that in Ethernet domain there are IPs, but in MPLS domain = there aren't. Need to look at PW/MPLS OAM. This is a generic mechanism that can be applied to MPLS layer and to = Ethernet layer. Is possible to have I/W between layers. Can also be = applied to BGP based mechanisms. Location of IPs is driven by business relations and deployment = scenarios. Some of the layerings are: 1) Service layer =3D VPLS Service. =3D> needs service OAM. 2) Network layer =3D> needs network OAM 3) Transport Links =3D> each link has OAM trying to manage various entities. An association of MPs. May not want = to have all maintenance entities enabled - is a question of which = entities the SP is interested in managing. Fault Management: Need to detect faults, verify them, once verified isolate location, = notify maintenance entities, and where possible restore the fault. This draft focusses on detect/verify/isolate. OAM messages may be sent across various entities depending on reqs. for = service. For detection may take precedents from ATM etc. Continuity Check used = to send periodic heartbeats. No response expected - rather expect to = receive messages and declare a fault if don't get message in time. For verify may send a unicast loopback which is non-intrusive and = doesn't impact data path. Can be used to verify if fault detected. Traceroute may be used to isolate fault location. Interesting for = Ethernet as notion of MAC address ageout where MACs are aged if no = activity seen from pair of MAcs - typically 5 minute ageing. If want to = do isolation have additional requirement (3 options in draft) to sort = this. In IP routing tables aren't flushed so is different. Various information elements might be needed. Want to discuss further = in this WG to find out what subset are required for VPLS. Want OAM to = indicate that it is OAM. Might need a version. Needs an OPcode to say = what function it is. Need to indicate if is customer to customer or SP = to SP. Also notion of service ID and a transaction ID if that is felt = necessary. Intent is to discuss requirements and more specifically the = information elements required. Exact frame formats are expected to be = done in IEEE. Performance Management: Typically need to measure performance parms across MEs (need to know = what they are). Need a collection mechanism and then measure/calculate = stats. Need then to determine if SLAs at service or network level were = met. Focus of this draft is on frame loss/delay/DV measurements and on = availability. Diff techs have different terms (e.g. latency and jitter = rather than delay and DV). Draft has some other parameters. When methods are considered is possible to measure in different ways. = Need to consider level of accuracy required, and cost associated with = that. Draft looks at 3 methods considered: Statistical - not accurate as OAM may differ from data plane due to = transients or due to forwarding. Not very accurate. Data Plane Managed Objects in management plane - apply data path = counters to management plane. Can be done in software. Only limitation = (which can be addressed) is delay between time the OAM frame is inserted = and time the counters can be accessed. So results may be inaccurate = (but can sample to fix this). Data Plane Managed Objects in data plane - typically requires h/w assist = but is most accurate. Recommendation is Data Plane Managed Objects in management plane. = Recommendation is to use a generic method. Typically CC is unsolicited = (and can be extended for perf). Loopback is unsolicited (and ditto can = be extended). Draft also discusses how frame loss and frame delay can be measured. Need for further discussion in this group to identify reqs. for VPLS = OAM. Need to co-ordinate with IETF WGs for L2VPN reqs (L2VPN) and management = framework for OAM (L3VPN - but has L2 components in). Also need to = co-ordinate with other standards bodies (802.1, ITU-T Q.3/13, MEF). Rahul - need to scope out what is the meaning of VPLS OAM as far as this = WG is concerned. To me traceroute would seem to be out of scope. Dinesh - not sure why you think Traceroute is out of scope. It's = required. VPLS is ethernet-based service and fact it's realised over = MPLS or IP PSN introduces layering. Each layer may have OAM, but need = capability at service layer. Rahul - WG needs to scope whether traceroute is in or out of scope. Vach (WG chair hat off) - this is good work but doesn't belong here. = It's an OAM for an Ethernet service, part of which includes VPLS. VPLS = is done here in IETF. But may be used in addition with Q and QinQ. End = to end service OAM includes VPLSes, but isn't specific to VPLS - so = doesn't belong to IETF. Ethernet header/MAC layer stuff belongs = elsewhere. If you can point out what IETF-defined VPLS needs to do so = your OAM works then we can address that. While VPLS has MAC layer the = MAC layer is outside VPLS scope. Dinesh - in OAM layering slide was trying to address why we need this = work here, and why is aligned with work in other groups. If you = consider this outside WG scope then need to consider that we have work = on MAC scaling. We're not transparent to that. Vach - but you are talking about work done at MAC layer. Ought to be in = IEEE or ITU. What does IETF need to do to support that work? This work = can be fully done in IEEE. Dinesh - still feel that part of this work belongs to this WG as much as = to other bodies. When considering VPLS as a service there is a = component of VPLS OAM. When we have hierarchy then we can understand = service aspects and service OAM for VPLS. IETF has expertise and should = provide requirements. Monique - having been involved in the discussions I want to support this = work. Not a trivial issue to say this is out of scope. For Ethernet = period need to be very careful. Customers are asking what we're doing = about Ethernet OAM. Need to address scope of what can be done in IETF = wrt VPLS OAM. But can't afford to ignore work going on in other = standards groups. Kireeti - need to discuss what VPLS OAM is. Ethernet OAM doesn't belong = here. Not to say we should ignore work and work blindly without being = aware of it. If it's specific to VPLS then it's in-scope. If it's for = Ethernet and can be applied to VPLS then it isn't. When talking about = scoping you are guilty unless proven innocent (assume is out of scope = unless can prove is in-scope). Liason is a good way of staying in = synch. Not saying that whenever work needs IETF attention that it needs = to be done in IETF. Dinesh - there are aspects that we require in terms of capabilities. = Not up to L2VPN to determine specifics of frame formats, but is up to us = to figure out information elements. Kireeti - FRF did LMI. Defined their info elements. What PWE3 did was = to say what LMI meant in PWE3. Dinesh - next step I've identified is to indicate other groups we need = to work with. Need to define what this group needs to define in terms = of VPLS OAM. No intent to duplicate work in other bodies. Marc - applicability for having framework doc for OAM. VPLS is an = Ethernet service as far as a customer is concerned. This group is = concerned with management of VPLS as a provider provisioned VPN. So = subset of your draft is relevant to this group. Dinesh - there are aspects we haven't addressed in this WG - e.g. = layers. That is an area we need to extend and augment in terms of the = framework. Vach (WG chair hat on) - need to end discussion here. Will make = statement on mailing list wrt scope. Still don't see why you think this = belongs here. If is informational then liason is way to go. If you = have specific requirements then let us know about those in particular - = otherwise rest can be done through liason. Loa - not really clear to me whether we need to do anything. May be = that we need to add information element to signalling, or might have to = come up with requirements for others to do their work, or might see a = VPLS OAM framework as useful for others to refer to. Let's continue = that discussion on the WG list. Dinesh should initiate. Dinesh - I concur. L2 IP Interworking - Vach ------------------------- Problem statement:=20 providers are trying to move to bigger/faster technologies but can't do = it in one hit. Would like a VPWS where they can move one end from FR to = GigE, but leave the other end. In IETF we're concerned with IP. so if L2VPN carries IP we have a way = of transferring IP packets from FR to Ethernet. Need to work this out = between L2VPN and PWE3. Can have an IP-only PW. Then need to address address resolution. How = do CE nodes figure out who the far end is. We need to develop NSP function to take ARP from PE-CE AC at one end, = turn into canonical form, and hand to other side - who can make = appropriate mods to proxy etc. So interworking of address resolution protocols. When people say "let's = do somewhere else" is saying "tell someone else to do ARP to Inverse = ARP" etc. That's a job for IETF. Once have figured this out we can = make this I/W PW work. Issues around IGP impact (e.g. can't use broadcast links on a PW). Need = to determine limitations. Are ADs happy with this work in L2VPN, given = this scope. Thomas Narten - ARP mediation draft has a question mark on IS-IS. Need = to understand implications of that. For OSPF can work-around by = configuring as P2P link. Do we have same option for IS-IS? Vach - IS-IS issue can be handled in two ways. (1) P2P mode. (2) Not = many customer locations actually use IS-IS so may be non-problem even = though it is a problem. Thomas - I'm fairly comfortable but need to take it to IESG. Question = is how much complexity does this add. Can't speak for IESG. Will need = to tweak charter. Naiming - have a draft on P2P over LAN for IGP. Works fine for ISIS and = OSPF. Giles - problem with ISIS is that ISIS isn't IP. Vach - issue is encaps. Do we want to carry L2 headers. Draft has two = modes. If we get go from ADs would like to discuss that - and pursue = ONE encaps. OAM for VPWS - Mustapha ----------------------- Two types of PW: 1) Homogenous - ACs are of same type 2) Heterogenous - ACs may be different types: IP only Frame to ATM SIW (FRF 12) Ethernet Interworking (bridged mode) Frame/ATM and Ethernet aren't discussed in charter, but is OK as PW and = AC are standard. Interworking is done outside PW. Procedures for IP = interworking apply to these also. For homogenous VPWS this is covered by draft-nadul (presented Monday in = PWE3). Nadul was focussed on mapping VCCV to Frame/ATM/etc. Scope was = increased to be a more generic VPWS OAM. Common people on both drafts, = and turns out that drafts have converged in many aspects. Homogenous = stuff will be in draft-nadul and presented in PWE3 and L2VPN. Not defining protocols - all describes how native OAM works with PW OAM = to get end-to-end OAM working (e.g. how does segment OAM from ATM to PW = to Ethernet work). Need to look into types of defect and define procedures for handling = them. Using PWE3 protocols, and those defined in other bodies for = ATM/Frame/Ethernet. Comment on mail-list about terminology. Circuit consists of . Homogenous =3D are all same type. Heterogeous =3D any two segments are different type. Homogenous VPWS - key is that link layer is not terminated at the PE. = L2 protocol runs end-to-end. So if native service has an OAM we should = use it as much as possible. Need to test end to end and segments. That = way SP can troubleshoot any segment. So PW OAM is a segment of the = end-to-end native service OAM. Exception is that FR has LMI (end to end = OAM is FRF.19 but hasn't been deployed much). For FR can't really = extend native service OAM so will use heterogeous model. Ethernet has = link management/OAM progressing in other bodies, but no deployed inband = Ethernet OAM so again use heterogeous model. Good example of heterogeous is IP. Send IP over MPLS using PW. Once = you terminate link layer you can't extend it. So you have boundaries = for your OAM (one at each PE). 3 segments for OAM (native on each AC, = and PW in the middle). No choice but to use PW-specific OAM. So use PW = control draft. Exception is Frame-ATM with an ATM PW (as can extend ATM = PW as if was heterogenous). In terms of detecting if PW is down reiterate that for FR not much = FRF.19. For ATM have OAM. For Ethernet today only have physical = interface. OAM for homogenous is very simple - tunnel native OAM through PW. OAM for heterogenous have no tunnelling over PW. So if detect problem = in, e.g. ATM attachment, then PE generates RDI back to CE and sends = status message to remote PE - which will send AIS to the remote CE = (which will send RDI back). Issues of flooding of alarms on ACs resulting in large amounts of PW = status signalling. Issue for discussion. drafts have converged on many aspects so will work together for full = alignment and present back to PWE3 and to L2VPN (draft-nadul =3D = homogenous). Suggest we progress heterogenous here (main focus on IP = for now). One important point is that this work (heterogenous) is fully = aligned with service interworking work in MPLS and FR alliance. Also = need to discuss heterogeous in PWE3 - is it just L2VPN specific. Rahul - couple of points. Need to clarify scope of interworking and = where it lives in IETF. Also need to define what is VPWS OAM. Have = homogenous, IP only, any to any interworking. Need to address any to = any first as IP is subset of that. Mustapha - in terms of what we mean by VPWS OAM we mean how to use the = native service OAM and PW-specific OAM to ensure VPWS service has = end-to-end OAM. Not about defining protocols (PW-specific done in PWE3 = and native services elsewhere). Defining rather procedures and saying = what is done at boundaries. Rahul - homogenous is covered in nadul draft. Mustapha - need to refer to nadul once we've aligned (so just have a = pointer here). Need to cover heterogeous (currently IP only) and = explain the procedures - explain why heterogenous is different to = homogeous. Rahul - defining scope of interworking and OAM will help move this = forward. Vach - we'll take that to mailing list. Vach - if we talk about Ethernet to Ethernet as using heterogenous model = as Ethernet has no OAM today. Let's keep it as that. When IEEE does = OAM for Ethernet we'll use that and not terminate OAM and go to PW OAM. = So keep things simple and clean. Mustapha - I agree with that. This is an exception as don't have = deployed Ethernet OAM. Once we have inband OAM for Ethernet we'll have = to support it. Monique - fully support that. Let's be pragmatic - carriers want us to = solve this. Craig White - we need PWE to come up with a generic link encaps and use = L2VPN for the one to many case. So if you just want P2P link PWE can = cover it fine. One to many is much better covered here. vach - NSP is our mediation between AC OAM and PW OAM Craig - I'd propose that PWE is best group for P2P. This group builds = VPNs out of PWs. So PWE3 should define new PW type for interworking. Vach - IP PW should be defined in PWE3. And PWE3 should define = heterogenous OAM. Craig - have come up with subset that could go in a CW to have base = functionality of OAM for the generic. Vach - let's continue on mailing list. Signalling for Access Service Network using LDP - Tetsushi --------------------------------------------------------- Access Service Network is broadband access. Uses authentication (NAI). = Typically PPPoE etc. today. Aim is to allow subscriber to use IEEE 802.1X to connect to ISP as a = special case of VPLS. Special type of VPLS as: 1) don't forward broadcast/multicast between subscribers. Bridge only = exists on network server. LDP signalling used to set up PW from Network Access Concentrator to = Network Server. Use single sided signalling (but not AGI). QoS info can be specified - RADIUS Access-Accept and in LDP mapping = message. Merit: 1) less encaps overhead than L2TP. 2) QoS. Vach - two comments. NAC to bridge element is H-VPLS spoke. If QoS is = important then take that to PWE3 (not here). That way can be used for = PW in general. Tetsushi - not H-VPLS because of forwarding plane Giles - is H-VPLS but tie all PWs into the same mesh group at the hub = end. Good as it ensures even known MACs from NAC to NAC go via Network = Server. - Loa Andersson: too early for this to become a working group document and want to see the discussion on the mailing list BGP Autodiscovery for LDP/L2TP VPWS/VPLS - Paul Unbehagen --------------------------------------------------------- can do auto-discovery and auto-establish of PWs. Use RTs PE can use AFI/SAFI to encode VPWS/VPLS etc. AFI needs to be assigned by IANA SAFI is a bit pattern. NLRI based on AFI/SAFI. Encode AGI and AII (single sided signalling). AGI needs to match from BGP to LDP. AII becomes a Target AII. Transparent mode - PE1 and PE2 build PW directly (ASBRs unaware of = L2VPNs). Need reachability to PE devices in each AS. Proxy mode - ASBRs need to be VPN aware. Stitch 3 PWs together to = provide service (PE-ASBR, ASBR-ASBR, ASBR-PE). Can use SNAP in MP-BGP = to allow operator to see actual path of PW on remote PE through ASes. Question - do we need to support PW-id as well as GID? Move to WG? Yakov - SAFI is bitmask so can carry VPLS and VPWS in one message. Is = that required/useful? Paul - Yes. Yakov - same as unicast/multicast in IP routers. Sue Hares - we thought there would be a lot of both eventually. but = might not be much VPLS at first. Paul - allows you to communicate PE-PE if we do both, or one or other. = In future might want to split the two. Yakov - which WG is this a WG doc for? It uses BGP. So should it be = reviewed by IDR? Paul - needs to go in front of IDR. Vach - need to go to IDR and have IDR say is no problem. Need to wait = for their response. Yakov - what is question to IDR? We need to be very specific. Vach - does this break/affect BGP in some way? The BGP experts are over = there and can tell us if is good. Not asking them if it is a good idea. Kireeti - please make clear what questions are asked of IDR wrt the = auto-disc and BGP VPLS drafts Kireeti - should there not be similar soul-searching in the MPLS WG = regarding LDP VPLS? Ross Callon - do we want one or multiple documents? Do people taking = care about BGP care about what's done here in the L2VPN working group? = How do we make these people aware of these activities -> discuss these = documents that uses BGP and have last call there to ensure common = acceptance. Loa Andersson - there is a group working on how to resolve this issue ------=_NextPart_000_00A9_01C41661.6ACB8CA0-- From exim@www1.ietf.org Tue Mar 30 18:21:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29088 for ; Tue, 30 Mar 2004 18:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006WI-8Q for l2vpn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THRWkw027529 for l2vpn-archive@odin.ietf.org; Thu, 29 Jan 2004 12:27:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFwy-00079w-Q6 for l2vpn-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 12:27:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02959 for ; Thu, 29 Jan 2004 12:27:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmFwx-0004UI-00 for l2vpn-web-archive@ietf.org; Thu, 29 Jan 2004 12:27:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmFvI-00042r-00 for l2vpn-web-archive@ietf.org; Thu, 29 Jan 2004 12:25:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmFu7-0003nO-00 for l2vpn-web-archive@ietf.org; Thu, 29 Jan 2004 12:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFty-0005cI-2k; Thu, 29 Jan 2004 12:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFQ1-0003tO-HM for l2vpn@optimus.ietf.org; Thu, 29 Jan 2004 11:53:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01160 for ; Thu, 29 Jan 2004 11:53:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmFQ0-00009N-00 for l2vpn@ietf.org; Thu, 29 Jan 2004 11:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmFPC-00002O-00 for l2vpn@ietf.org; Thu, 29 Jan 2004 11:52:39 -0500 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 1AmFOJ-0007aN-00 for l2vpn@ietf.org; Thu, 29 Jan 2004 11:51:44 -0500 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Thu, 29 Jan 2004 18:49:10 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 18:47:33 +0200 Message-ID: From: Sasha Vainshtein To: "'W. Mark Townsley'" , richard.spencer@bt.com Cc: steph@sandburst.com, jh@tutpro.com, l2vpn@ietf.org, Elena Vinkler , Sharon Galtzur , Gonen Zilber , Alik Shimelmits Subject: RE: Comments on draft-ietf-l2vpn-l2tp-radius-vpls-00.txt Date: Thu, 29 Jan 2004 18:47:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Mark, Richard and all, When I have started this thread I have assumed that my basic support of the draft in question goes without saying, even if some issues remain to be clarified. Since the need for this draft is now questioned, I'd like to express my support explicitly and also to explain why, IMO, such a draft is useful. I agree that RADIUS-based auto-discovery as descrived in draft-heinanen is orthogonal to any specific transport (IP or MPLS), demultiplexing (MPLS or L2TPv3) and signaling (LDP, L2TPv3, BGP etc.) methods. However, two points should be noted: 1. It is usually helpful to have a single document that expicitly shows how all the things described in various protocol specs "fit together" to provide a complete solution of a well-defined problem. This is especially true for tge L2VPN WG that is not inventing new protocols. And, IMO, the draft in question does exactly that. 2. The draft in question uses RADIUS not only for auto-discovery of PEs but also for authenication of each specific PE-to-PE session at the "passive" side. This is not mentioned in the auto-discovery draft (and, IMO, is not part of auto-discovery anyway since not every auto-discovery method allows such an authentication). And this provides an additional "security point" to be taken into account. Wrt to the proposal to have a matrix of drafts matching each known auto-discovery method with each known signaling method, I'd like to note that, IMO, this is not all that far from what we already have (e.g., there is already a draft which describes how to use MP-BGP both for VPLS auto-discovery and signaling - draft-ietf-l2vpn-vpls-bgp-01.txt.:-). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: W. Mark Townsley [mailto:townsley@cisco.com] > Sent: Thursday, January 29, 2004 4:41 PM > To: richard.spencer@bt.com > Cc: Sasha Vainshtein; steph@sandburst.com; jh@tutpro.com; > l2vpn@ietf.org; Elena Vinkler; Sharon Galtzur; Gonen Zilber; > Alik Shimelmits > Subject: Re: Comments on draft-ietf-l2vpn-l2tp-radius-vpls-00.txt > > > > Hello Richard. Please see responses inline. > > richard.spencer@bt.com wrote: > > I am very supportive of using RADIUS for discovery and do > not have any issues > > with providers that want to use L2TP for VPLS, but IMO this > specific draft is > > not needed. > > > > > > > > It is a combination of extracts from the RADIUS discovery > draft, extracts > > from the L2TP drafts, and some text describing VPLS > services (which is > > equivalent to the text in the BGP and LDP VPLS drafts > describing the same > > thing). I cannot find anything new/different other than > stating what the AVP > > attributes must be. > > I think that the RADIUS extracts of this draft should be > removed and it > > should be developed to create a L2TP equivalent of the BGP > and LDP VPLS > > drafts. This should help address Sasha's concerns below, > and RADIUS discovery > > could be mentioned as a possible discovery mechanism, along > with BGP and DNS > > (as is done in the BGP and LDP VPLS drafts). > > draft-heinanen-radius-pe-discovery-04.txt already focuses on > RADIUS discovery in > a generic manner. If I understand you, you would like to see > an L2TP draft which > does what the draft-ietf-l2vpn-l2tp-radius-vpls-00.txt draft > does for RADIUS, > but also points to BGP and LDP as well. > > > From a functional perspective the RADIUS and L2TP > mechanisms are completely > > separate. > > Yes, I think that in draft-ietf-l2vpn-l2tp-radius-vpls-00.txt > Juha was just > showing how to apply the RADIUS discovery in an L2TP > environment. I think that > the text that applies to this is reasonable (perhaps it could > be whittled down a > bit as you suggest, but by some standards its a fairly terse > document at barely > 6 pages text minus headers). > > > The RADIUS discovery mechanism is a function for which the output > > is a list of IP addresses of PEs belonging to the same VPN. > If the output is > > properly defined (which I believe it already is) there is > no need to define > > new drafts for each signalling protocol that might use > RADIUS discovery. If > > there is a need for this draft then why don't we also need - > > > > > > > > 'The-RADIUS-discovery-with-LDP-signalling-VPLS-draft" > > > > 'The-RADIUS-discovery-with-BGP-signalling-VPLS-draft" > > > > 'The-BGP-discovery-with-LDP-signalling-VPLS-draft" > > > > 'The-BGP-discovery-with-L2TP-signalling-VPLS-draft" > > > > etc. > > So, I think you are suggesting that we have a generic VPLS > L2TP draft, and, > perhaps, a RADIUS, BGP and LDP section within simply as > examples of how you > might use various autodiscovery mechanisms with L2TP. > > - Mark > > > > > From exim@www1.ietf.org Wed Mar 31 06:17:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14739 for ; Wed, 31 Mar 2004 06:17:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8di5-0005iX-9D for l2vpn-archive@odin.ietf.org; Wed, 31 Mar 2004 06:16:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VBGf0I021973 for l2vpn-archive@odin.ietf.org; Wed, 31 Mar 2004 06:16:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8di4-0005iK-Sb for l2vpn-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 06:16:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14686 for ; Wed, 31 Mar 2004 06:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8di1-0005IA-00 for l2vpn-web-archive@ietf.org; Wed, 31 Mar 2004 06:16:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8dh6-00059f-00 for l2vpn-web-archive@ietf.org; Wed, 31 Mar 2004 06:15:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8dfu-00051i-00 for l2vpn-web-archive@ietf.org; Wed, 31 Mar 2004 06:14:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dfW-0005A8-BD; Wed, 31 Mar 2004 06:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dey-00058Z-Da for l2vpn@optimus.ietf.org; Wed, 31 Mar 2004 06:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14524 for ; Wed, 31 Mar 2004 06:13:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8deu-0004rk-00 for l2vpn@ietf.org; Wed, 31 Mar 2004 06:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8de2-0004l0-00 for l2vpn@ietf.org; Wed, 31 Mar 2004 06:12:31 -0500 Received: from av4-2-sn3.vrr.skanova.net ([81.228.9.112]) by ietf-mx with esmtp (Exim 4.12) id 1B8ddA-0004cF-00 for l2vpn@ietf.org; Wed, 31 Mar 2004 06:11:36 -0500 Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 955A437EE5; Wed, 31 Mar 2004 13:11:06 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8841637E43; Wed, 31 Mar 2004 13:11:06 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5994C38032; Wed, 31 Mar 2004 13:11:06 +0200 (CEST) Message-ID: <406AA717.3030000@pi.se> Date: Wed, 31 Mar 2004 13:10:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org, Vach Kompella , rick.wilder@alcatel.com Subject: minutes and slides from seoul on the web Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit WG, the minutes from the Seoul meeting is temporarily available at: http://tla-group.com/~l2vpn/l2vpn-minutes.txt The slides presented at the Seoul meeting is also there: http://tla-group.com/~l2vpn/BGP-based-Auto-Discovery-for-L2VPNs.ppt http://tla-group.com/~l2vpn/draft-aissaoui-l2vpn-vpws-iw-oam-00-ietf-59v1.ppt http://tla-group.com/~l2vpn/ietf59-vpls-oam-v1.ppt http://tla-group.com/~l2vpn/MATSUDA-ACCESS-SERVICE-040303.ppt http://tla-group.com/~l2vpn/VPLS-IETF-59-presentation.ppt Further you will find a file I use to track wg documents. Note tht this file is not rocket science, but updated at the speed I can manage. If you have questions or updates, please mail me off the list. http://tla-group.com/~l2vpn/l2vpn-wg-docs.htm /Loa -- Loa Andersson mobile +46 739 81 21 64