From exim@www1.ietf.org Mon Feb 2 13:10:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27819 for ; Mon, 2 Feb 2004 13:10: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 1AniVx-0007Ly-W8 for l2vpn-archive@odin.ietf.org; Mon, 02 Feb 2004 13:09:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12I9frL028260 for l2vpn-archive@odin.ietf.org; Mon, 2 Feb 2004 13:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniVx-0007Lj-IZ for l2vpn-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:09: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 NAA27768 for ; Mon, 2 Feb 2004 13:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniVv-000362-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:09:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniTM-0002NP-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:07:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AniOf-0001F9-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniOW-0006Xo-TD; Mon, 02 Feb 2004 13:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbyH-0001kp-M0 for l2vpn@optimus.ietf.org; Fri, 30 Jan 2004 11:58: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 LAA27830 for ; Fri, 30 Jan 2004 11:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbyG-0007Hi-00 for l2vpn@ietf.org; Fri, 30 Jan 2004 11:58:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbxT-00079Z-00 for l2vpn@ietf.org; Fri, 30 Jan 2004 11:57:31 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Ambx1-00071g-00; Fri, 30 Jan 2004 11:57:03 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-white.research.att.com (Postfix) with ESMTP id 98DF76640E8; Fri, 30 Jan 2004 11:55:36 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id 4D99EF3B45; Fri, 30 Jan 2004 11:53:54 -0500 (EST) Received: from att.com ([135.210.2.37]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i0UGuWZ20644; Fri, 30 Jan 2004 11:56:32 -0500 (EST) Message-ID: <401A8CBA.3030706@att.com> Date: Fri, 30 Jan 2004 11:56:26 -0500 From: Chris Chase 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: Kireeti Kompella Cc: Moshe.Aharon@ecitele.com, l2vpn@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] l2vpn signaling (LDP/CR-LDP/RSVP-TE) References: <20040115103027.V31112@kummer.juniper.net> In-Reply-To: <20040115103027.V31112@kummer.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; 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 How well are edge nodes going to scale for a full mesh of targeted LDP sessions? I keep hearing from vendors about connection limits on their TCP stacks. Whether it is BGP for CE-PE connections in 2547 services or targeted LDP for PWE, it seems there are constant pressures on the number of connections vendors can support. With RSVP for the vc label signaling I don't see the connection constrains from a full mesh. A couple years ago Andy Malis told me that not looking at RSVP was simply because implementations were already starting down the LDP road. Chris Chase On 1/15/2004 1:35 PM, Kireeti Kompella wrote: >On Thu, 15 Jan 2004 Moshe.Aharon@ecitele.com wrote: > > > >>This forces any edge equipment to support both RSVP-TE and LDP. >> >> > >True, if the TE LSPs extend all the way to the PEs. However, I'm not >aware of edge equipment that supports LDP but not RSVP-TE (or vice >versa). > > > >>Have the WGs considered a PWE3/VPLS signaling using RSVP? >> >> > >If you believe that PWE3 signaling should be point-to-point (and the >favorite example is carrying bandwidth/QoS information), yes, RSVP >would be a fine vehicle. Note that the LSP hierarchy draft introduces >the notion of 'targeted RSVP sessions', if you squint just right. > >The argument for doing VPLS with RSVP is weaker. > >Kireeti. >------- > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From exim@www1.ietf.org Mon Feb 2 13:59:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02208 for ; Mon, 2 Feb 2004 13:59:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjIA-0004rp-4F for l2vpn-archive@odin.ietf.org; Mon, 02 Feb 2004 13:59:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IxUAs018693 for l2vpn-archive@odin.ietf.org; Mon, 2 Feb 2004 13:59:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjI9-0004rP-R4 for l2vpn-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:59: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 NAA02121 for ; Mon, 2 Feb 2004 13:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjI7-0004Sp-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:59:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjFm-0003r4-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:57:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjCs-00034M-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjCs-0003hs-BM; Mon, 02 Feb 2004 13:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjCo-0003hF-HC for l2vpn@optimus.ietf.org; Mon, 02 Feb 2004 13:53:58 -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 NAA01225 for ; Mon, 2 Feb 2004 13:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjCm-00032b-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 13:53:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anj9T-0002GN-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 13:50:33 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1Anj6V-0001UX-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 13:47:27 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 10:46:56 -0800 Reply-To: From: "Vach Kompella" To: Subject: Changing the FEC for VPLS to generalized PWid FEC Date: Mon, 2 Feb 2004 10:47:03 -0800 Organization: Alcatel USA Message-ID: <049801c3e9bc$f4004e10$0101010a@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 02 Feb 2004 18:46:56.0385 (UTC) FILETIME=[EEAB8F10:01C3E9BC] 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 Folks, There is still no discussion on changing the FEC type from 128, as it stands today, to the generalized PW FEC type (129), as suggested by Eric Rosen. I think this is a good idea, and I know that several vendors have implemented the old style, so it will put a crimp in your implementations, but can we make some progress here? The main reason for moving forward is to address future issues with VPLSen by using a structured name and 32 bits just isn't good enough for that. This will assist in auto-discovery, inter-regional VPLSen, and adequate name-space size. -Vach From exim@www1.ietf.org Mon Feb 2 14:01:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02609 for ; Mon, 2 Feb 2004 14:01:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjK3-00056F-ER for l2vpn-archive@odin.ietf.org; Mon, 02 Feb 2004 14:01:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12J1Re9019597 for l2vpn-archive@odin.ietf.org; Mon, 2 Feb 2004 14:01:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjK2-000560-WF for l2vpn-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:01:27 -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 OAA02523 for ; Mon, 2 Feb 2004 14:01:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjK0-0004vQ-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 14:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjIh-0004dJ-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 14:00:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjGi-00045s-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 13:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjGj-0004XL-TP; Mon, 02 Feb 2004 13: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 1AnjGQ-0004QK-FD for l2vpn@optimus.ietf.org; Mon, 02 Feb 2004 13:57: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 NAA01759 for ; Mon, 2 Feb 2004 13:57:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjGO-0003zW-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 13:57:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjDf-0003GT-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 13:54:53 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1AnjAZ-0002Q5-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 13:51:39 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 10:51:08 -0800 Reply-To: From: "Vach Kompella" To: Subject: VPLS full-mesh issues Date: Mon, 2 Feb 2004 10:51:15 -0800 Organization: Alcatel USA Message-ID: <049901c3e9bd$8a8a5c40$0101010a@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 02 Feb 2004 18:51:08.0940 (UTC) FILETIME=[853464C0:01C3E9BD] 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 We need to get some discussion on whether we should put mechanisms in place to discover and/or recover from full-mesh connectivity issues. To recap, if the full-mesh connectivity is broken, then it is possible that nodes in a VPLS will be unreachable. This leads to situations where the VPLS appears to be up, but packets to some VPLS participants get black-holed. Question 1: important issue worthy of our cycles, or not? Question 2: "discover" connectivity issues or "discover and repair"? -Vach From exim@www1.ietf.org Mon Feb 2 14:41:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04668 for ; Mon, 2 Feb 2004 14:41:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjwA-0008A4-Gc for l2vpn-archive@odin.ietf.org; Mon, 02 Feb 2004 14:40:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Jeoct031366 for l2vpn-archive@odin.ietf.org; Mon, 2 Feb 2004 14:40:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjwA-00089p-7Z for l2vpn-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:40: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 OAA04623 for ; Mon, 2 Feb 2004 14:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anjw7-0001Cl-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 14:40:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjvB-00017F-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 14:39:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjuP-000129-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 14: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 1AnjuO-0007tJ-Vy; Mon, 02 Feb 2004 14: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 1AnjuG-0007st-GU for l2vpn@optimus.ietf.org; Mon, 02 Feb 2004 14:38:52 -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 OAA04523 for ; Mon, 2 Feb 2004 14:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjuD-00011I-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 14:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjtN-0000vj-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 14:37:57 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AnjsU-0000js-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 14:37:02 -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 i12JaT307194; Mon, 2 Feb 2004 14:36:30 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNHXM8G>; Mon, 2 Feb 2004 14:36:30 -0500 Message-ID: From: "Hamid Ould-Brahim" To: vach.kompella@alcatel.com, l2vpn@ietf.org Subject: RE: Changing the FEC for VPLS to generalized PWid FEC Date: Mon, 2 Feb 2004 14:36:29 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Vach, > > There is still no discussion on changing the FEC type from > 128, as it stands today, to the generalized PW FEC type > (129), as suggested by Eric Rosen. Actually I thought there were some discussions before on this item on the mailing list and in ietf meetings (for both Vienna and Minneapolis meetings). My understanding is there was no technical issue to move to generalized PW FEC. >I think this is a good > idea, and I know that several vendors have implemented the > old style, so it will put a crimp in your implementations, > but can we make some progress here? > Agreed. Anyway, I reiterate my support for moving from a four octets VCID to the AGI as specified by the Generalized ID FEC. Hamid. From exim@www1.ietf.org Mon Feb 2 15:07:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05784 for ; Mon, 2 Feb 2004 15:07:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkLK-0006ns-Nc for l2vpn-archive@odin.ietf.org; Mon, 02 Feb 2004 15:06:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12K6o4j026142 for l2vpn-archive@odin.ietf.org; Mon, 2 Feb 2004 15:06:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkLJ-0006nY-RT for l2vpn-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:06: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 PAA05739 for ; Mon, 2 Feb 2004 15:06:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkLG-0003Ry-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 15:06:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkKN-0003NC-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 15:05:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnkJa-0003IO-00 for l2vpn-web-archive@ietf.org; Mon, 02 Feb 2004 15:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkJb-0005kk-Dr; Mon, 02 Feb 2004 15:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkJN-0005hA-EB for l2vpn@optimus.ietf.org; Mon, 02 Feb 2004 15:04: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 PAA05540 for ; Mon, 2 Feb 2004 15:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkJK-0003Gp-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 15:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkIQ-0003CC-00 for l2vpn@ietf.org; Mon, 02 Feb 2004 15:03:51 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AnkHZ-00031d-00; Mon, 02 Feb 2004 15:02:57 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 15:02:27 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55FB71BD@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'vach.kompella@alcatel.com'" , l2vpn@ietf.org Cc: "'rtg-bfd@ietf.org'" Subject: RE: VPLS full-mesh issues Date: Mon, 2 Feb 2004 15:02:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Vach, [ CC'ing to RTG-BFD list, because I found this related ] -> Question 1: important issue worthy of our cycles, or not? Yes. It is an important issue to consider. -> Question 2: "discover" connectivity issues or "discover and repair"? In my opinion, this fully-connected and strongly-connected graph synchrony is required by many protocols (mostly for routing protocols) - not just VPLS. If known, communication complexity (number of message overhead) can be reduced by using well established distributed algorithms (in asynchronous problem space). For now, VPLS can have some provisioning to discover connectivity issues in full-mesh topology. But, in general, a separate protocol like http://www.ietf.org/internet-drafts/draft-katz-ward-bfd-v4v6-1hop-00.txt is good to start with. If BFD can figure out the link bi-directional connectivity, any higher-level protocol knowing the full-mesh diameter can compute which of the links went down by flooding, leader-election or BFS spanning tree methods. Venkata. From exim@www1.ietf.org Tue Feb 3 11:33:02 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 LAA16764 for ; Tue, 3 Feb 2004 11:33:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3TW-0005SY-3t for l2vpn-archive@odin.ietf.org; Tue, 03 Feb 2004 11:32:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13GWYHv020985 for l2vpn-archive@odin.ietf.org; Tue, 3 Feb 2004 11:32:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3TV-0005SO-UM for l2vpn-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 11:32:33 -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 LAA16761 for ; Tue, 3 Feb 2004 11:32:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3TU-00059T-00 for l2vpn-web-archive@ietf.org; Tue, 03 Feb 2004 11:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3Sb-00054C-00 for l2vpn-web-archive@ietf.org; Tue, 03 Feb 2004 11:31:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3SB-0004yf-00 for l2vpn-web-archive@ietf.org; Tue, 03 Feb 2004 11:31:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3S2-0005MQ-Oo; Tue, 03 Feb 2004 11:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3RW-0005K0-UG for l2vpn@optimus.ietf.org; Tue, 03 Feb 2004 11:30: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 LAA16691 for ; Tue, 3 Feb 2004 11:30:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3RV-0004xP-00 for l2vpn@ietf.org; Tue, 03 Feb 2004 11:30:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3Qd-0004s1-00 for l2vpn@ietf.org; Tue, 03 Feb 2004 11:29:35 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3Pq-0004g9-00; Tue, 03 Feb 2004 11:28:46 -0500 Received: from amalist40.comcast.net (h0010db1abb41.ne.client2.attbi.com[24.61.134.169]) by comcast.net (sccrmhc11) with SMTP id <2004020316280501100de073e> (Authid: andymalis@comcast.net); Tue, 3 Feb 2004 16:28:13 +0000 Message-Id: <6.0.1.1.2.20040203112216.02dac068@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 11:27:54 -0500 To: Chris Chase From: "Andrew G. Malis" Subject: Re: [PWE3] l2vpn signaling (LDP/CR-LDP/RSVP-TE) Cc: Kireeti Kompella , Moshe.Aharon@ecitele.com, l2vpn@ietf.org, pwe3@ietf.org In-Reply-To: <401A8CBA.3030706@att.com> References: <20040115103027.V31112@kummer.juniper.net> <401A8CBA.3030706@att.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.0 required=5.0 tests=none autolearn=no version=2.60 Hi Chris, it's always pleasant to be quoted! At the time the Martini work started, "targeted RSVP" wasn't on anybody's radar screen. As Kireeti points out, in hindsight it probably would have worked just fine. In practice using LDP over TCP, I can't speak for anyone else, but we've found in our own implementation (both in testing and in the field) that scaling hasn't been a problem for tens of thousands of sessions/circuits, and we're continually raising the limits on our testing. Cheers, Andy ----------- At 1/30/2004 11:56 AM -0500, Chris Chase wrote: >How well are edge nodes going to scale for a full mesh of targeted LDP >sessions? I keep hearing from vendors about connection limits on their >TCP stacks. Whether it is BGP for CE-PE connections in 2547 services or >targeted LDP for PWE, it seems there are constant pressures on the number >of connections vendors can support. > >With RSVP for the vc label signaling I don't see the connection constrains >from a full mesh. A couple years ago Andy Malis told me that not looking >at RSVP was simply because implementations were already starting down the >LDP road. > >Chris Chase From exim@www1.ietf.org Wed Feb 4 15:46: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 PAA25933 for ; Wed, 4 Feb 2004 15:46: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 1AoTtz-0005Mh-VQ for l2vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 15:45:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Kjdco020617 for l2vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 15:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTtz-0005MS-RU for l2vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:45:39 -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 PAA25878 for ; Wed, 4 Feb 2004 15:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTty-0001uF-00 for l2vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTsx-0001nG-00 for l2vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTsU-0001gi-00 for l2vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTsQ-0004o2-6c; Wed, 04 Feb 2004 15:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTra-0004hw-NC for l2vpn@optimus.ietf.org; Wed, 04 Feb 2004 15:43: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 PAA25655; Wed, 4 Feb 2004 15:43:08 -0500 (EST) Message-Id: <200402042043.PAA25655@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-requirements-01.txt Date: Wed, 04 Feb 2004 15:43:08 -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.4 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 : Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks Author(s) : W. Augustyn, Y. Serbest Filename : draft-ietf-l2vpn-requirements-01.txt Pages : 26 Date : 2004-2-4 This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint to multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-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-requirements-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-requirements-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-2-4160217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-4160217.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Feb 5 12:14: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 MAA24657 for ; Thu, 5 Feb 2004 12:14:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aon4k-0007Q9-Sf for l2vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 12:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15HE2QT028519 for l2vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 12: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 1Aon4k-0007Pu-Kl for l2vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 12:14: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 MAA24639 for ; Thu, 5 Feb 2004 12:13:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aon4j-000670-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 12:14:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aon3l-00061V-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 12:13:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aon2p-0005vR-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 12:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aon2m-0007Hv-Hh; Thu, 05 Feb 2004 12:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aon24-0007HI-P9 for l2vpn@optimus.ietf.org; Thu, 05 Feb 2004 12:11:16 -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 MAA24612 for ; Thu, 5 Feb 2004 12:11:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aon23-0005qH-00 for l2vpn@ietf.org; Thu, 05 Feb 2004 12:11:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aon13-0005k3-00 for l2vpn@ietf.org; Thu, 05 Feb 2004 12:10:14 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Aon0h-0005dU-00 for l2vpn@ietf.org; Thu, 05 Feb 2004 12:09:51 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15H97D17230; Thu, 5 Feb 2004 12:09:07 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3D17VJ>; Thu, 5 Feb 2004 12:09:07 -0500 Message-ID: <635C6B4620C6D411909100508BCFE67A0FDAEED8@zrtpd0jd.us.nortel.com> From: "Paul Unbehagen" To: "Hamid Ould-Brahim" , vach.kompella@alcatel.com, l2vpn@ietf.org Subject: RE: Changing the FEC for VPLS to generalized PWid FEC Date: Thu, 5 Feb 2004 12:09:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EC0A.C1BD11CC" 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=HTML_20_30,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_01C3EC0A.C1BD11CC Content-Type: text/plain I agree with Hamid. -----Original Message----- From: Ould-Brahim, Hamid [CAR:1A00:EXCH] Sent: Monday, February 02, 2004 2:36 PM To: vach.kompella@alcatel.com; l2vpn@ietf.org Subject: RE: Changing the FEC for VPLS to generalized PWid FEC Vach, > > There is still no discussion on changing the FEC type from > 128, as it stands today, to the generalized PW FEC type > (129), as suggested by Eric Rosen. Actually I thought there were some discussions before on this item on the mailing list and in ietf meetings (for both Vienna and Minneapolis meetings). My understanding is there was no technical issue to move to generalized PW FEC. >I think this is a good > idea, and I know that several vendors have implemented the > old style, so it will put a crimp in your implementations, > but can we make some progress here? > Agreed. Anyway, I reiterate my support for moving from a four octets VCID to the AGI as specified by the Generalized ID FEC. Hamid. ------_=_NextPart_001_01C3EC0A.C1BD11CC Content-Type: text/html RE: Changing the FEC for VPLS to generalized PWid FEC

I agree with Hamid.

-----Original Message-----
From: Ould-Brahim, Hamid [CAR:1A00:EXCH]
Sent: Monday, February 02, 2004 2:36 PM
To: vach.kompella@alcatel.com; l2vpn@ietf.org
Subject: RE: Changing the FEC for VPLS to generalized PWid FEC


Vach,

>
> There is still no discussion on changing the FEC type from
> 128, as it stands today, to the generalized PW FEC type
> (129), as suggested by Eric Rosen. 

Actually I thought there were some discussions before on
this item on the mailing list and in ietf meetings
(for both Vienna and  Minneapolis meetings). My understanding
is there was no technical issue to move to generalized PW FEC.

>I think this is a good
> idea, and I know that several vendors have implemented the
> old style, so it will put a crimp in your implementations,
> but can we make some progress here?
>

Agreed. Anyway, I reiterate my support for moving from a four octets
VCID to the AGI as specified by the Generalized ID FEC.

Hamid.


------_=_NextPart_001_01C3EC0A.C1BD11CC-- From exim@www1.ietf.org Thu Feb 5 16:25: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 QAA10019 for ; Thu, 5 Feb 2004 16:25: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 1Aoqzv-0001gw-LS for l2vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 16:25:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LPJrQ006496 for l2vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 16:25:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqzv-0001gh-Fo for l2vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 16:25: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 QAA09982 for ; Thu, 5 Feb 2004 16:25:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqzt-00038H-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 16:25:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqyK-0002kz-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 16:23:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqxA-0002a3-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 16:22:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqwk-0001CD-AD; Thu, 05 Feb 2004 16:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqw1-00019w-6A for l2vpn@optimus.ietf.org; Thu, 05 Feb 2004 16:21:17 -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 QAA09518 for ; Thu, 5 Feb 2004 16:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqvz-0002QD-00 for l2vpn@ietf.org; Thu, 05 Feb 2004 16:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoqv5-0002Kq-00 for l2vpn@ietf.org; Thu, 05 Feb 2004 16:20:20 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoqum-0002FF-00 for l2vpn@ietf.org; Thu, 05 Feb 2004 16:20:00 -0500 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.9/8.12.6) with ESMTP id i15LJSDI024451; Thu, 5 Feb 2004 13:19:28 -0800 (PST) Received: from cisco.com (dhcp-128-107-165-125.cisco.com [128.107.165.125]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQA26765; Thu, 5 Feb 2004 13:19:28 -0800 (PST) Message-ID: <4022B360.6010008@cisco.com> Date: Thu, 05 Feb 2004 13:19:28 -0800 From: Wei Luo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: vach.kompella@alcatel.com CC: l2vpn@ietf.org Subject: Re: Changing the FEC for VPLS to generalized PWid FEC References: <049801c3e9bc$f4004e10$0101010a@eng.timetra.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 Vach, I support this move and we also need to factor in two things: 1. The VPLS draft should to be defined as signaling protocol or transport agnostic as it states in Section 5 so that either LDP or L2TP can be used to set up VPLS connectivity. It's fine to use the terms like AGI, AII, SAI, TAI and alike. Both LDP and L2TP have the similar protocol extensions and terminology defined as in: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-05.txt http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2vpn-00.txt But protocol-specific text should be avoided in the VPLS draft. 2. Backwards compatibilty with FEC 128. But this is largely an action item for the PWE3 control draft (draft-ietf-pwe3-control-protocol-05.txt). I had proposed some text to the authors on solving the backward compatible issue. Maybe we could revive that discussion on a separate thread. ---Wei Vach Kompella wrote: > Folks, > > There is still no discussion on changing the FEC type from 128, as it > stands today, to the generalized PW FEC type (129), as suggested by Eric > Rosen. I think this is a good idea, and I know that several vendors > have implemented the old style, so it will put a crimp in your > implementations, but can we make some progress here? > > The main reason for moving forward is to address future issues with > VPLSen by using a structured name and 32 bits just isn't good enough for > that. This will assist in auto-discovery, inter-regional VPLSen, and > adequate name-space size. > > -Vach > > From exim@www1.ietf.org Thu Feb 5 17:13:01 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 RAA15714 for ; Thu, 5 Feb 2004 17:13:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorjZ-0006fi-Qt for l2vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 17:12:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15MCTaf025640 for l2vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 17:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorjZ-0006fT-Ko for l2vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:12: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 RAA15705 for ; Thu, 5 Feb 2004 17:12:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorjX-0001k7-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoriW-0001hV-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:11:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoriD-0001fD-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:11:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoriA-0006UO-DQ; Thu, 05 Feb 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNs6-00083j-B8 for l2vpn@optimus.ietf.org; Wed, 04 Feb 2004 09:19: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 JAA06820 for ; Wed, 4 Feb 2004 09:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNs4-000151-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 09:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNrB-0000yp-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 09:18:25 -0500 Received: from [213.163.128.164] (helo=shyguy.smb.utfors.se) by ietf-mx with esmtp (Exim 4.12) id 1AoNqC-0000nM-00; Wed, 04 Feb 2004 09:17:20 -0500 Received: from pi.se (md46909b9.utfors.se [212.105.9.185]) by shyguy.smb.utfors.se (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HSK00K6NCC7ZS@shyguy.smb.utfors.se>; Wed, 04 Feb 2004 15:02:46 +0100 (MET) Date: Wed, 04 Feb 2004 15:02:27 +0100 From: Loa Andersson Subject: Re: last call on terminology draft In-reply-to: <017a01c3eb03$e25c39b0$1702010a@Puppy> To: Adrian Farrel , l2vpn@ietf.org Cc: Tove Madsen , Rick Wilder , l3vpn@ietf.org Message-id: <4020FB73.9070503@pi.se> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 References: <20040120215626.64812.qmail@web109.biz.mail.yahoo.com> <017a01c3eb03$e25c39b0$1702010a@Puppy> 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 Adrian, inline Adrian Farrel wrote: >Useful draft, thanks. > :) > >Mainly typos, attached. > >I find it odd that the list of drafts that depend on this terminolog= y draft are normative >references. This will delay the publication of this document as an R= FC and doesn't seem >necessary. > good point, we'll look into how will handle it > >Not sure if references such as draft-ppvpn-metrics.00.txt in section= 3.7 should actually >be handled as other references. Perhaps add a third references secti= on "Expired >References"? > this gives some idea of the "patina" of the draft, the metrics were important when we first wrote the terminology. I guess that the appro= priate thing to do is to mention the therer are drafts that has expired, som= etimes because they've been incorported in others, sometime because they ser= ved their purpose > >I wonder whether the sections are in the right order. The building b= lock terms from >section 5 get used throughout section 3. The early subsections in se= ction 3 refer to the >later subsections. But this is hardly important. > believe me, there are circular dependencies in the draft, which ever way you do you will have forward looking references We will look in to the typos /Loa > >You seem to be missing copyright and IPR statements. > >Cheers, >Adrian > > =20 > >--------------------------------------------------------------------= ---- > >L3VPN Working Group Loa Andersso= n >Internet-Draft Tove Madse= n >< TLA=A1gr= oup > =20 > >> TLA-group >> =20 >> >Expiration Date: March 2004 > > 25 September, 200= 3 > > PPVPN terminology > > > >Status of this Memo > > This document is an Internet-Draft and is in full conformance w= ith > all provisions of Section 10 of RFC2026 [RFC2026]. > > Internet-Drafts are working documents of the Internet Engineeri= ng > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet-Draf= ts > as reference material or to cite them other than as "work in > progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed a= t > http://www.ietf.org/shadow.html. > > For potential updates to the above required-text see: > http://www.ietf.org/ietf/1id-guidelines.txt > > >Abstract > >< The provider provisioned VPN solutions has attracted a great de= al >< of interest. Memos proposing different and overlapping solution > =20 > >> The provider provisioned VPN solutions have attracted a great de= al >> of interest. Memos proposing different and overlapping solutions >> =20 >> > have been discussed on the PPVPN mailing list and in the Workin= g >< Group meetings. This has lead to a development of a partly new > =20 > >> Group meetings. This has lead to the development of a partly new >> =20 >> > set of concepts used to describe the set of VPN services. To a >< certain extent there are more than one term covering the same >< concept and sometimes the same term covers more than on concept= . > =20 > >> certain extent there is more than one term covering the same >> concept and sometimes the same term covers more than one concept= . >> =20 >> > The terminology needs to be made clearer and more intuitive. Th= is > document seeks to fill at least part of that need. > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25= .09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 2] > >Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIO= NAL" > in this document are to be interpreted as described in RFC-211= 9 > [RFC2119]. > >Table of contents > >1. Introduction ....................................................= . 3 > >2. PPVPN Terminology ...............................................= . 4 > >3. Provider Provisioned Virtual Private Network services ...........= . 5 > 3.1 IP-only LAN-like Service (IPLS)..............................= . 5 > 3.2 Layer 2 VPN (L2VPN) .........................................= . 5 > 3.3 Layer 3 VPN (L3VPN) .........................................= . 5 > 3.4 Pseudo Wire (PW) ............................................= . 5 > 3.5 Transparent LAN Service (TLS)................................= . 6 > 3.6 Virtual LAN (VLAN) ..........................................= . 6 > 3.7 Virtual Leased Line Service (VLLS)...........................= . 6 > 3.8 Virtual Private LAN Service (VPLS)...........................= . 6 > 3.9 Virtual Private Network (VPN)................................= . 6 > 3.10 Virtual Private Switched Network (VPSN).....................= . 7 > 3.11 Virtual Private Wire Service (VPWS).........................= . 7 > >4. Classification of VPNs ..........................................= . 7 > >5. Building blocks .................................................= . 9 > 5.1 Customer Edge device (CE) ...................................= . 9 > 5.1.1 Device based CE naming.................................= . 9 > 5.1.2 Service based CE naming................................= 10 > 5.2 Provider Edge (PE) ..........................................= 10 > 5.2.1 Device based PE naming.................................= 11 > 5.2.2 Service based PE naming................................= 11 > 5.2.3 Distribution based PE naming...........................= 12 > 5.3 Core ........................................................= 12 > 5.3.1 Provider router (P) ...................................= 12 > 5.4 Naming in specific Internet drafts...........................= 12 > 5.4.1 Layer 2 PE (L2PE) .....................................= 12 > 5.4.2 Logical PE (LPE) ......................................= 13 > 5.4.3 PE-CLE ................................................= 13 > 5.4.4 PE-Core ...............................................= 13 > 5.4.5 PE-Edge ...............................................= 13 > 5.4.6 PE-POP ................................................= 13 > 5.4.7 VPLS Edge (VE) ........................................= 13 > >6. Functions .......................................................= 13 > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [= Page 3] > > 6.1 Attachment Circuit (AC) ..................................= . 14 > 6.2 Backdoor Links ...........................................= . 14 > 6.3 Endpoint discovery .......................................= . 14 > 6.4 Flooding .................................................= . 14 > 6.5 MAC address learning .....................................= . 14 > 6.5.1 Qualified learning ..................................= . 14 > 6.5.2 Unqualified learning ................................= . 15 > 6.6 Signalling ...............................................= . 15 > >7. 'Boxes' .........................................................= . 15 > 7.1 Aggregation box ..........................................= . 15 > 7.2 Customer Premises Equipment (CPE).........................= . 15 > 7.3 Multi Tenant Unit (MTU) ..................................= . 16 > >8. Packet Switched Network (PSN) ...................................= . 16 > 8.1 Route Distinguisher (RD) .................................= . 16 > 8.2 Route Reflector ..........................................= . 16 > 8.3 Route Target (RT) ........................................= . 16 > 8.4 Tunnel ...................................................= . 17 > 8.5 Tunnel multiplexor .......................................= . 17 > 8.6 Virtual Channel (VC) .....................................= . 17 > 8.7 VC label .................................................= . 17 > 8.8 Inner label ..............................................= . 17 > 8.9 VPN Routing and Forwarding (VRF)..........................= . 17 > 8.10 VPN Forwarding Instance (VFI)............................= . 18 > 8.11 Virtual Switch Instance (VSI)............................= . 18 > 8.12 Virtual Router (VR) .....................................= . 18 > >9. Acknowledgements ................................................= . 18 > >10. Authors' Contact ...............................................= . 18 > >11. Normative References ...........................................= . 19 > >12. Non-Normative References .......................................= . 19 > > > >1. Introduction > >< There are a comparatively large number of memos being submit= ted to > =20 > >> There is a comparatively large number of memos being submitte= d to >> =20 >> > the former PPVPN, and L2VPN, L3VPN and PWE3 working groups t= hat >< all addresses the same problem space, provider provisioned v= irtual > =20 > >> all address the same problem space, provider provisioned virt= ual >> =20 >> > private networking for end customers. The memos address a wi= de > range of services, but there is also a great deal of commona= lity > among the proposed solutions. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [= Page 4] > >< This has lead to a development of a partly new set of concepts > =20 > >> This has lead to the development of a partly new set of concept= s >> =20 >> > used to describe this set of VPN services. To a certain extent >< there are more than one term covering the same concept and > =20 > >> there is more than one term covering the same concept and >> =20 >> > sometimes the same term covers more than one concept. The > terminology needs to be made clearer and more intuitive. > > This document seeks to fill at least part of the need and prop= oses > a foundation for a unified terminology for the L2VPN, L3VPN > working groups; in some cases the parallel concepts within the >< PWE3 working group is used as references. > =20 > >> PWE3 working group are used as references. >> =20 >> > > >2. PPVPN Terminology > > The concepts and terms in this list are gathered from Internet > Drafts sent to the L2VPN and L3VPN mailing lists (earlier PPVP= N > mailing list) and RFCs relevant to the L2VPN and L3VPN working > groups. The focus is on terminology and concepts that are spec= ific > to the PPVPN area, but this is not strictly enforced, e.g. the= re > are concepts and terms within the PWE3 and (Generalized) MPLS > areas that are closely related. We've tried to find the earlie= st > use of terms and concepts. > > This document intends to fully cover the concepts within five = core > documents from the L2VPN and L3VPN working groups the "Generic > Requirements for Provider Provisioned VPN" [GENERIC], the "A > Framework for Layer 3 Provider Provisioned Virtual Private > Networks" [L3VPN-frmwrk], the "Service requirements for Layer = 3 > Provider Provisioned Virtual Private Networks" [PPVPN-req], th= e > "L2VPN Framework [L2VPN-frmwrk] and "Service Requirements for > Layer 2 Provider Provisioned Virtual Private Networks" [L2VPN- > req]. The intention is to create a comprehensive and unified s= et > of concepts for these documents, and by extension for the enti= re >< PPVPNarea.Todosoitisalsonecessarytogivesomeofthe > =20 > >> PPVPN area. To do so it is also necessary to give some of the >> =20 >> >##huh?## development the concepts of the area have been through. > > The document is structured in four major sections. Section 4 l= ists >< the different services that has been/will be specified, Sectio= n 5 >< lists the building blocks that is used to specify those servic= es, > =20 > >> the different services that have been/will be specified, Sectio= n 5 >> lists the building blocks that are used to specify those servic= es, >> =20 >> > section 6 lists the functions needed in those services and sec= tion > 7 list some typical devices used in customer and provider > networks. > > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 = [Page 5] > >3. Provider Provisioned Virtual Private Network services > > In this section we define the terminology that relates the set= of > services to solutions specified by the L2VPN and L3VPN working > groups. The concept "pseudo wire" that belongs to the PWE3 wor= king > group is included for reference purposes. For requirements in > provider provisioned VPNs see [PPVPN-req]. > > In this section all abbreviations are listed in alphabetic ord= er. > >3.1 IP-only LAN-like Service (IPLS) > > An IPLS is very like a VPLS (see 3.8), except that: > > - it is assumed that the CE devices (see 5.1) are hosts or > routers, not switches > > - it is assumed that the service will only need to carry IP > packets, and supporting packets such as ICMP and ARP; > otherwise layer 2 packets which do not contain IP are not > supported. > > While this service is a functional subset of the VPLS service,= it > is considered separately because it may be possible to provide= it > using different mechanisms, which may allow it to run on certa= in > hardware platforms that cannot support the full VPLS functiona= lity > [PPVPN-L2-frmwrk]. > >3.2 Layer 2 VPN (L2VPN) > > Three types of L2VPNs are described in this document, Virtual >< Private Wire Service (VPWS) (section 3.11), VPLS Virtual Priva= te >< LAN Service (VPLS)(section 3.8), and IP-only LAN-like Service >< (IPLS). > =20 > >> Private Wire Service (VPWS) (section 3.11), Virtual Private >> LAN Service (VPLS) (section 3.8), and IP-only LAN-like Service >> (IPLS) (section 3.1). >> =20 >> > >3.3 Layer 3 VPN (L3VPN) > > An L3VPN is a solution that interconnects several sets of host= s > and routers and allows them to communicate based on L3 address= es, > see [L3VPN-frmwrk]. > >3.4 Pseudo Wire (PW) > >< The PWE3 working group within IETF specifies the pseudo wire > =20 > >> The PWE3 working group within the IETF specifies the pseudo wir= e >> =20 >> > technology. A pseudo wire is an emulated point-to-point >< connectivity over a packet switched network that gives the > =20 > >> connection over a packet switched network that gives the >> =20 >> > possibility to interconnect two nodes with any L2 technology. = The > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Page= 6] > > PW shares some of the building blocks and architecture construc= ts > with the point to multipoint solutions, e.g. PE (see 5.2) and C= E > (see 5.1). An early solution for PWs is described in [martini- > tran]. Encapsulation formats readily used in VPWS, VPLS and PWs > are described in [martini-encap]. Requirements for PWs are foun= d >< in [PWE3-req] and [PWE3-frmwrk] present an architectural framew= ork > =20 > >> in [PWE3-req] and [PWE3-frmwrk] presents an architectural framew= ork >> =20 >> > for PWs. > >3.5 Transparent LAN Service (TLS) > > TLS was an early name used to describe the VPLS service, it was > used e.g. in the now dated draft-lasserre-tls-mpls-00.txt. It h= as > been replaced by VPLS, which is the current term. > >3.6 Virtual LAN (VLAN) > > A VLAN is a way of separating traffic on a LAN, e.g. between > different departments within a company. This acronym is not > defined by former PPVPN working group, but is defined by IEEE > 802.1Q. The VLANID is used to mark an Ethernet frame with a tag= to > create user groups on a LAN. > >3.7 Virtual Leased Line Service (VLLS) > > The VLLS has been replaced by VPWS. It was used in now dated > draft-ppvpn-metrics.00.txt. > >3.8 Virtual Private LAN Service (VPLS) > > A VPLS is a provider service that emulates the full functionali= ty > of a traditional Local Area Network. A VPLS makes it possible t= o > interconnect several LAN segments over a packet switched networ= k > (PSN) and makes the remote LAN segments behave as one single LA= N. > For an early work on defining a solution and protocol for a VPL= S > see [L2VPN-req], [Lasserre-vkompella], and [Kompella-VPLS]. > > In a VPLS the provider network emulates a learning bridge and > forwarding decisions are taken based on MAC addresses or MAC > addresses and VLAN tag. > >3.9 Virtual Private Network (VPN) > > VPN is a generic term that covers the use of public or private > networks to create groups of users that are separated from othe= r > network users and may communicate among them as if they were on= a >< private network. The level of separation is possible to enhance > =20 > >> private network. It is possible to enhance the level of separati= on >> =20 >> > e.g. by end-to-end encryption, this is however outside the scop= e > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.09= .03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 7] > > of IETF VPN working group charters. This VPN definition is fro= m > [RFC2764]. > > In the [L3VPN-frmwrk] the term VPN is used to refer to a speci= fic > set of sites as either an intranet or an extranet that have be= en > configured to allow communication. Note that a site is a membe= r of > at least one VPN, and may be a member of many VPNs. > > In this document "VPN" is also used as a generic name for all > services listed in section 3. > >3.10 Virtual Private Switched Network (VPSN) > > A VPSN is replaced by VPLS. The VPSN abbreviation was used e.g= . in > the now dated draft-vkompella-ppvpn-vpsn.reqmts-00.txt. > >3.11 Virtual Private Wire Service (VPWS) > > A Virtual Private Wire Service (VPWS) is a point-to-point circ= uit > (link) connecting two Customer Edge devices. The CE in the > customer network is connected to a PE in the provider network = via > an Attachment Circuit (see 6.1); the Attachment Circuit is eit= her > a physical or a logical circuit. > >< The PE's in the core network is connected via a PW. > =20 > >> The PE's in the core network are connected via a PW. >> =20 >> > > The CE devices can be routers, bridges, switches or hosts. In = some > implementations a set of VPWSs is used to create a multi-site > L2VPN network. An example of a VPWS solution is described in > [L2VPN]. > >< A VPWS differs from a VPLS (section 4.8) in that the VPLS is p= oint > =20 > >> A VPWS differs from a VPLS (section 3.8) in that the VPLS is po= int >> =20 >> > to multipoint, while the VPWS is point to point. See [L2VPN- > frmwrk]. > > >4. Classification of VPNs > > The terminology used in [GENERIC] is defined based on the figu= re > below. > > > > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 8] > > PPVPN > ________________|__________________ > | | > Layer 2 Layer 3 > ______|_____ ______|______ > | | | | > P2P P2M PE-based CE-based > (VPWS) _____|____ ______|____ | > | | | | | > VPLS IPLS RFC2547 Virtual IPsec > Style Router > > > The figure above presents a taxonomy of PPVPN technologies. Som= e > of the definitions are given below: > > CE-based VPN: A VPN approach in which the shared service provid= er > network does not have any knowledge of the customer VPN. This > information is limited to CE equipment. All the VPN-specific > procedures are performed in the CE devices, and the PE devices = are > not aware in any way that some of the traffic they are processi= ng > is VPN traffic (see also [L3VPN-frmwrk]). > > PE-Based VPNs: A Layer 3 VPN approach in which a service provid= er > network is used to interconnect customer sites using shared > resources. Specifically the PE device maintains VPN state, > isolating users of one VPN from users of another VPN. Because t= he > PE device maintains all required VPN state, the CE device may > behave as if it were connected to a private network. Specifical= ly, > the CE in a PE-based VPN must not require any changes or > additional functionality to be connected to a PPVPN instead of = a > private network. > > The PE devices know that certain traffic is VPN traffic. They > forward the traffic (through tunnels) based on the destination = IP >< address of the packet, and optionally on based on other > =20 > >> address of the packet, and optionally based on other >> =20 >> > information in the IP header of the packet. The PE devices are > themselves the tunnel endpoints. The tunnels may make use of > various encapsulations to send traffic over the SP network (suc= h > as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS >< tunnels)[L3VPN-frmwrk]. > =20 > >> tunnels) [L3VPN-frmwrk]. >> =20 >> > > > Virtual Router (VR) style: A PE-based VPN approach in which the= PE > router maintains a complete logical router for each VPN that it > supports. Each logical router maintains a unique forwarding tab= le > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [= Page 9] > > and executes a unique instance of the routing protocols. These > VPNs are described in [PPVPN-VR]. > > RFC 2547 Style: A PE-based VPN approach in which the PE router > maintains separate forwarding environment for each VPN and a > separate forwarding table for each VPN. In order to maintain > multiple forwarding table instances while running only a singl= e > routing protocol instance, RFC 2547 style VPNs mark route > advertisements with attributes that identify their VPN context= . > These VPNs are based on the approach described in [RFC2547bis]= . > > >5. Building blocks > > Starting with specifications of L3VPNs, e.g. the 2547 > specification [RFC2547] and [RFC2547bis] and Virtual Routers > [PPVPN-VR], a way of describing the building blocks and alloca= tion > of functions in VPN solutions was developed. The building bloc= ks >< are often in day-to-day talk treated as if it were physical bo= xes, >< common for all services. > =20 > >> are often used in day-to-day talk as if they were physical boxe= s, >> common to all services. >> =20 >> > >< However, for different reasons this is to over-simplify. Any o= f > =20 > >> However, for different reasons this is an over-simplification. = Any of >> =20 >> > the building blocks could be implemented across more than one > physical box. How common the use of such implementations will = be > is beyond the scope of this document. > >5.1 Customer Edge device (CE) > > A CE is the name of the device with the functionality needed o= n > the customer premises to access the services specified by the > former PPVPN working group. > > There are two different aspects that need to be considered in > naming CE devices. One could start with the type of device tha= t is > used to implement the CE (see section 5.1.1). It is also possi= ble > to use the service the CE provides and with the result it will= be > a set of "prefixed CEs", (see section 5.1.2). > > It is common practice to use "CE" to indicate any of these box= es, > since it is very often unambiguous in the specific context. > >5.1.1 Device based CE naming > > >5.1.1.1 Customer Edge Router (CE-R) > > A CE-R is a router in the customer network interfacing the > provider network. There are many reasons to use a router in th= e > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 10] > > customer network, e.g. in an L3VPN using private IP addressin= g > this is the router that is able to do forwarding based on the > private addresses. Another reason to require the use of a CE-= R on > the customer side is that one want to limit the number on MAC= - > addresses that needs to be learnt in the provider network. > > A CE-R could be used to access both L2 and L3 services. > > >5.1.1.2 Customer Edge Switch (CE-S) > > A CE-S is a service aware L2 switch in the customer network > interfacing the provider network. In a VPWS or a VPLS it is n= ot > strictly necessary to use a router in the customer network, a > layer 2 switch might very well do the job. > >5.1.2 Service based CE naming > > The list below is just examples and it will be extended as th= e > number of services increases. > > >5.1.2.1 L3VPN-CE > > An L3VPN-CE is the device or set of devices on the customer > premises that attaches to a provider provisioned L3VPN, e.g. = a > 2547bis implementation. > > >5.1.2.2 VPLS-CE > > A VPLS-CE is the device or set of devices on the customer pre= mises > that attaches to a provider provisioned VPLS. > > >5.1.2.3 VPWS-CE > > A VPWS-CE is the device or set of devices on the customer pre= mises > that attaches to a provider provisioned VPWS. > >5.2 Provider Edge (PE) > > A PE is the name of the device or set of devices at the edge = of > the provider network with the functionality that is needed to > interface the customer. PE, without further qualifications, i= s > very often used for naming the devices since it is made > unambiguous by the context. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25= .09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 11] > > In naming PEs there are three aspects that we need to conside= r, > the service they support, whether the functionality needed fo= r > service is distributed across more than one device and the ty= pe of > device they are build on. > >5.2.1 Device based PE naming > > Both routers and switches may be used to implement PEs, howev= er > the scaling properties will be radically different depending = which >< type of equipment that is chosen. > =20 > >> type of equipment is chosen. >> =20 >> > > >5.2.1.1 Provider Edge Router (PE-R) > > A PE-R is a L3 device that participates in the PSN (see secti= on 8) > routing and forwards packets based on the routing information= . > > >5.2.1.2 Provider Edge Switch (PE-S) > >< APE-SisaL2devicethatparticipatesine.g.aswitched > =20 > >> A PE-S is a L2 device that participates in e.g. a switched >> =20 >> > Ethernet taking forwarding decision packets based on L2 addre= ss > information. > >5.2.2 Service based PE naming > > >5.2.2.1 L3VPN-PE > > An L3VPN-PE is a device or set of devices at the edge of the > provider network interfacing the customer network, with the > functionality needed for an L3VPN. > > >5.2.2.2 VPWS-PE > > A VPWS-PE is a device or set of devices at the edge of the > provider network interfacing the customer network, with the > functionality needed for a VPWS. > > >5.2.2.3 VPLS-PE > > A VPLS-PE is a device or set of devices at the edge of the > provider network interfacing the customer network, with the > functionality needed for a VPLS. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 12] > >5.2.3 Distribution based PE naming > > For scaling reasons it is in the VPLS/VPWS cases sometimes de= sired > to distribute the functions in the VPLS/VPWS-PE across more t= han > one device, e.g. is it feasible to allocate MAC address learn= ing > on a comparatively small and in-expensive device close to the > customer site, while participation in the PSN signalling and = set > up of PE to PE tunnels are done by routers closer to the netw= ork > core. > > When distributing functionality across devices a protocol is > needed to exchange information between the Network facing PE = (N- > PE) see section 5.2.3.1 and the User facing PE (U-PE) see sec= tion > 5.2.3.2. > > >5.2.3.1 Network facing PE (N-PE) > > The N-PE is the device to which the signalling and control > functions are allocated when a VPLS-PE is distributed across = more > than one box. > > >5.2.3.2 User facing PE (U-PE) > > The U-PE is the device to which the functions needed to take > forwarding or switching decision at the ingress of the provid= er > network. > >5.3 Core > >5.3.1 Provider router (P) > >< ThePisdefinedasarouterinthecorenetworkthatdoesnot > =20 > >> The P is defined as a router in the core network that does not >> =20 >> > have interfaces directly towards a customer. Hence a P router= does > not need to keep VPN state and is VPN un-aware. > >5.4 Naming in specific Internet drafts > >5.4.1 Layer 2 PE (L2PE) > > L2PE is the joint name of the devices in the provider network= that > implement L2 functions needed for a VPLS or a VPWS. > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 13] > >5.4.2 Logical PE (LPE) > > The term Logical PE (LPE) originates from a dated Internet Dr= aft > "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical = PE > Architecture" and was used to describe a set of devices used = in a > provider network to implement a VPLS. In a LPE, VPLS function= s are > distributed across small devices (PE-Edges/U-PE) and devices > attached to a network core (PE-Core/N-PE). In an LPE solution= the > PE-edge and PE-Core can be interconnected by a switched Ether= net > transport network(s) or uplinks. The LPE will appear to the c= ore > network as a single PE. In this document the devices that > constitutes the LPE is called N-PE and U-PE. > >5.4.3 PE-CLE > > An alternative name for the U-PE suggested in now dated Inter= net > Draft "VPLS architectures". > >5.4.4 PE-Core > > See the origins and use of this concept in section 5.4.2. > >5.4.5 PE-Edge > > See the origins and use of this concept in section 5.4.2. > >5.4.6 PE-POP > > An alternative name for the U-PE suggested in now dated Inter= net > Draft "VPLS architectures". > >5.4.7 VPLS Edge (VE) > > The term VE originates from a dated Internet Draft on a > distributed transparent LAN service and was used to describe = the >< deviceusedbyaprovidernetworktohandoffaVPLStoa > =20 > >> device used by a provider network to hand off a VPLS to a >> =20 >> > customer. In this document the VE is called a VPLS-PE. > > This name has dated. > > >6. Functions > > In this section we have grouped a number of concepts and term= s >< that has to be performed to make the VPN services work. > =20 > >> that have to be performed to make the VPN services work. >> =20 >> > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [P= age 14] > >6.1 Attachment Circuit (AC) > > In a Layer 2 VPN the CE is attached to PE via an Attachment > Circuit (AC). The AC may be a physical or logical link. > > >6.2 Backdoor Links > > Backdoor Links are links between CE devices that are provided= by > the end customer rather than the SP; may be used to interconn= ect > CE devices in multiple-homing arrangements [L3VPN-frmwrk]. > >6.3 Endpoint discovery > > Endpoint discovery is the process by which the devices that a= re > aware of a specific VPN service will find all customer facing > ports that belong to the same service. > > The requirements on endpoint discovery and signalling are > discussed in [PPVPN-req]. It was also the topic in a now date= d > Internet Draft reporting from a design team activity on VPN > discovery. > >6.4 Flooding > > Flooding is a function related to L2 and L3 services; when a = PE > receives a frame with an unknown destination MAC-address, tha= t > frame is send out over (flooded) every other interface. > >6.5 MAC address learning > > MAC address learning is a function related to L2 services; wh= en PE > receives a frame with an unknown source MAC-address the > relationship between that MAC-address and interface is learnt= for > future forwarding purposes. In a layer 2 VPN solution from th= e > L2VPN WG, this function is allocated to the VPLS-PE. > >6.5.1 Qualified learning > > In qualified learning, the learning decisions at the U-PE are > based on the customer Ethernet frame's MAC address and VLAN t= ag, > if a VLAN tag exists. If no VLAN tag exists, the default VLAN= is > assumed. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 15] > >6.5.2 Unqualified learning > > In unqualified learning, learning is based on a customer Ethe= rnet > frame's MAC address only. > >6.6 Signalling > > Signalling is the process by which the PEs that have VPNs beh= ind > them exchange information to set up PWs, PSN tunnels and tunn= el > multiplexers. This process might be automated through a proto= col > or done by manual configuration. Different protocols may be u= sed > to establish the PSN tunnels and exchange the tunnel multiple= xers. > > > > >7. 'Boxes' > > We list a set of boxes that will typically be used in an > environment that supports different kinds of VPN services. We= have > chosen to include some names of boxes that originate outside = the > protocol specifying organisations. > >7.1 Aggregation box > > The aggregation box is typically an L2 switch that is service > unaware and is used only to aggregate traffic to more functio= n > rich points in the network. > >7.2 Customer Premises Equipment (CPE) > > The CPE equipment is the box that a provider places with the > customer. It serves two purposes, giving the customer ports t= o > plug in to and making it possible for a provider to monitor t= he > connectivity to the customer site. The CPE is typically a low= cost > box with limited functionality and in most cases not aware of= the > VPN services offered by the provider network. > > The CPE equipment is not necessarily the equipment to which t= he CE > functions are allocated, but is part of the provider network = and > used for monitoring purposes. > > The CPE name is used primarily in network operation and deplo= yment > contexts, and should not be used in protocol specifications. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 16] > >7.3 Multi Tenant Unit (MTU) > > An MTU [DTLS] is typically an L2 switch placed by a service > provider in a building where customers of that service provid= er > are located. > > The MTU device name is used primarily in network operation an= d > deployment contexts, and should not be used in protocol > specifications, as it is also a used abbreviation for Maximum > Transmit Units. > > >8. Packet Switched Network (PSN) > > A PSN is the network through which the tunnels supporting the= VPN > services are set up. > >8.1 Route Distinguisher (RD) > > A Route Distinguisher [RFC2547bis] is an 8-byte value that > togetherwitha4byteIPv4addressidentifiesaVPN-IPv4address > family. If two VPNs use the same IPv4 address prefix, the PEs > translates these into unique VPN-IPv4 address prefixes. This > ensures that if the same address is used in two different VPN= s, it > is possible to install two completely different routes to tha= t > address, one for each VPN. > >8.2 Route Reflector > > A route reflector is a network element owned by a Service Pro= vider > (SP) that is used to distribute BGP routes to the SP's BGP-en= abled > routers [L3VPN-frmwrk]. > >8.3 Route Target (RT) > > A Route Target attribute [RFC2547bis] can be thought of as > identifying a set of sites, or more precisely a set of VRFs (= see > section 8.8). > > Associating a particular Route Target with a route, allows th= at > route to be placed in all VRFs that are used for routing traf= fic > received from the corresponding sites. > > A Route Target attribute is also a BGP extended community use= d in > [RFC2547], and [BGPVPN-auto]. A Route Target community is use= d to > constrain VPN information distribution to the set of VRFs. A = route > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25= .09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 17] > > target can be perceived as identifying a set of sites, or mor= e > precisely a set of VRFs. > >8.4 Tunnel > > A tunnel is connectivity through a PSN that is used to send > traffic across the network from one PE to another. The tunnel > provides a mechanism to transport packets from one PE to anot= her, > separation of one customer's traffic from another customer's > traffic is done based on tunnel multiplexers (see section 8.4= ). > How the tunnel is established depends on the tunnelling mecha= nisms > provided by the PSN, i.e. the tunnel could be based on e.g. t= he > IP-header, an MPLS label, the L2TP Session ID, or on the GRE = Key > field. > >8.5 Tunnel multiplexor > > A tunnel multiplexor is an entity that is sent with the packe= ts > traversing the tunnel to make possible to decide to which ins= tance > of a service a packet belongs and from which sender it was > received. In [L2VPN] the tunnel multiplexor is formatted as a= n > MPLS label. > >8.6 Virtual Channel (VC) > > A VC is transported within a tunnel and identified by its tun= nel > multiplexer. A virtual channel is identified by a VCI (Virtua= l > Channel Identifier). In the PPVPN context a VCI is a VC label= or > tunnel multiplexer and in the Martini case it is equal to the > VCID. > >8.7 VC label > > In an MPLS enabled IP network a VC label is an MPLS label, us= ed to > identify traffic within a tunnel that belongs to a particular= VPN, > i.e. the VC label is the tunnel multiplexer in networks that = uses > MPLS labels. > >8.8 Inner label > > "Inner label" is another name for VC label (see section 8.6). > >8.9 VPN Routing and Forwarding (VRF) > > In networks running 2547 VPN's [RFC2547], PE routers maintain > VRF's. A VRF is a per-site forwarding table. Every site to wh= ich > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Page = 18] > > the PE router is attached is associated with one of these tab= les. > A particular packet's IP destination address is looked up in = a > particular VRF only if that packet has arrived directly from = a > site, which is associated with that table. > >8.10 VPN Forwarding Instance (VFI) > > VPN Forwarding Instance (VFI) is a logical entity that reside= s in > a PE that includes the router information base and forwarding > information base for a VPN instance [L3VPN-frmwrk]. > >8.11 Virtual Switch Instance (VSI) > > In a layer 2 context a VSI is a virtual switching instance th= at > serves one single VPLS [L2VPN-frmwrk]. A VSI performs standar= d LAN > (i.e., Ethernet) bridging functions. Forwarding done by a VSI= is > based on MAC addresses and VLAN tags, and possibly other rele= vant > information on a per VPLS basis. The VSI is allocated to VPLS= -PE > or in the distributed case to the U-PE. > >8.12 Virtual Router (VR) > > A Virtual Router (VR) is software and hardware based emulatio= n of > a physical router. Virtual routers have independent IP routin= g and > forwarding tables and they are isolated from each other, see > [PPVPN-VR]. > > >9. Acknowledgements > > Much of the content in this document is based on discussion i= n the > PPVPN design teams for "auto discovery" and "l2vpn". > > >10. Authors' Contact > > Loa Andersson > TLA-group > loa@pi.se > > Tove Madsen > TLA-group > tove@niebelungen.net > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 19] >11. Normative References > >[GENERIC] Nagarajan, A (ed), "Generic Requirements for Provider >Provisioned VPN", draft-ietf-l3vpn-generic-reqts-01.txt, Work in >Progress, Internet Draft, Aug 2003 > >[L2VPN-frmwrk] Andersson, L. and Rosen, E., "L2VPN Framework", draft= - >ietf-l2vpn-l2-framework-01.txt, Work in Progress, Internet Draft, >Sept 2003 > >[L3VPN-frmwrk] Callon, R. and Suzuki, M.," A Framework for Layer 3 >Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn- >framework-00.txt, Work in Progress, Internet Draft, March 2003 > >[PPVPN-req] Carugi, M. and McDysan, D., "Service requirements for >Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf- >l3vpn-requirements-00.txt, Work in Progress, Internet Draft, Oct 200= 3 > >[L2VPN-req] Augustyn, W., and Serbest, Y., "Service Requirements for >Layer 2 Provider Provisioned Virtual Private Networks", draft-ietf- >l2vpn-requirements-00.txt, Work in Progress, Internet Draft, May 200= 3 > > >12. Non-Normative References > > >[BGPVPN-auto] Ould-Brahim, H., Rosen, E. and Rekhter, Y. "Using BGP >as an auto-discovery mechanism for network-based VPNs", draft-ietf- >l3vpn-bgpvpn-auto-00.txt, Work in progress, Internet Draft, July 200= 3 > >[kompella-VPLS] Kompella, K. "Virtual Private LAN Service", draft- >ietf-l2vpn-vpls-bgp-00.txt, Work in Progress, Internet Draft, May >2003 > >[L2VPN] Kompella, K., et.al. "Layer 2 VPNs Over Tunnels", draft- >kompella-ppvpn-l2vpn-03.txt, Work in Progress, June 2002 > >[lasserre-vkompella] Kompella, V. and Lasserre, M., "Virtual Private >LAN Services over MPLS" draft-ietf-l2vpn-vpls-ldp-00.txt, Work in >progress, Mar 2002 > >[martini-encap] Martini, L., et.al. "Encapsulation Methods for >Transport of Layer 2 Frames Over IP and MPLSNetworks", draft-martini= - >l2circuit-encap-mpls-05.txt, Work in Progress, Internet Draft, April >2003 > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 20] > >[martini-tran] Martini, L., et.al. "Transport of Layer 2 Frames Over >MPLS", draft-martini-l2circuit-trans-mpls-11.txt, Work in progress, >Internet Draft, April 2003 > >[PPVPN-VR] Ould-Brahim, H., et.al. "Network-based IP VPN using >Virtual Routers", draft-ietf-l3vpn-vpn-vr-00.txt, Work in Progress, >Internet Draft, July 2002 > >[PWE3-arch] Prayson, P. and Bryant, S., "PWE3 Architecture", draft- >ietf-pwe3-arch-05.txt, Work in Progress, Internet Draft, August 2003 > >[PWE3-req] Xiao, X., "Requirements for Pseudo-Wire Emulation Edge-to= - >Edge (PWE3)", draft-ietf-pwe3-requirements-06.txt, Work in progress, >Internet Draft, July 2003 > >[RFC2547] Rosen, E., et.al. "BGP/MPLS VPNs", rfc2547, March 1999 > >[RFC2547bis] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn- >rfc2547bis-01.txt, Work in Progress, Internet Draft, September 2003 > >[RFC2764] Gleeson, B., et.al. "A Framework for IP Based Virtual >Private Networks", rfc2764, February 2000 > > > > > > > > > > > > > > > > > > > > > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > > =20 > From exim@www1.ietf.org Thu Feb 5 17:13: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 RAA15745 for ; Thu, 5 Feb 2004 17:13: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 1Aorjg-0006g5-SS for l2vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 17:12:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15MCad0025663 for l2vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 17:12:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorjg-0006fq-Ns for l2vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:12: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 RAA15710 for ; Thu, 5 Feb 2004 17:12:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aorje-0001l6-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoria-0001ht-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:11:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoriE-0001fF-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:11:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoriA-0006Uc-Tw; Thu, 05 Feb 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoU5K-0005v4-Ak for l2vpn@optimus.ietf.org; Wed, 04 Feb 2004 15:57:22 -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 PAA26424 for ; Wed, 4 Feb 2004 15:57:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoU5I-00037B-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 15:57:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoU4M-00031g-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 15:56:22 -0500 Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx with esmtp (Exim 4.12) id 1AoU3T-0002rd-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 15:55:27 -0500 Received: from mail pickup service by BGSLC11.burtongroup.com with Microsoft SMTPSVC; Wed, 4 Feb 2004 13:54:56 -0700 thread-index: AcPrYSVITuoBr9TJSaC4hMj9UbVWSg== Thread-Topic: [MailServer Notification]To Recipient file blocking settings matched and action taken. From: To: Subject: [MailServer Notification]To Recipient file blocking settings matched and action taken. Date: Wed, 4 Feb 2004 13:54:56 -0700 Message-ID: <044e01c3eb61$2548d0f0$0d7d633f@burtongroup.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 04 Feb 2004 20:54:56.0842 (UTC) FILETIME=[2567CAA0:01C3EB61] 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ScanMail for Microsoft Exchange has blocked an attachment. Sender = Internet-Drafts@ietf.org Recipient(s) = l2vpn@ietf.org Subject = I-D ACTION:draft-ietf-l2vpn-requirements-01.txt Scanning time = 02/04/2004 13:54:56 Action on file blocking: The attachment draft-ietf-l2vpn-requirements-01.URL matches the file blocking settings. ScanMail has Deleted it. Warning to Recipient: A message sent to you by Internet-Drafts@ietf.org contained an attachment, draft-ietf-l2vpn-requirements-01.URL/Deleted , that was deemed potentially dangerous and was therefore removed. Notify your administrator if you have any questions. From exim@www1.ietf.org Thu Feb 5 18:02:11 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 RAA15715 for ; Thu, 5 Feb 2004 17:13:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorjZ-0006fS-Dt for l2vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 17:12:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15MCTKR025624 for l2vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 17:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorjX-0006fD-Su for l2vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:12: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 RAA15702 for ; Thu, 5 Feb 2004 17:12:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorjV-0001ju-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoriR-0001hL-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:11:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoriD-0001fC-00 for l2vpn-web-archive@ietf.org; Thu, 05 Feb 2004 17:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aori9-0006U8-RR; Thu, 05 Feb 2004 17:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJed-0007Tw-Lp for l2vpn@optimus.ietf.org; Wed, 04 Feb 2004 04:49: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 EAA28052 for ; Wed, 4 Feb 2004 04:49:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJea-00053g-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 04:49:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJdb-0004yS-00 for l2vpn@ietf.org; Wed, 04 Feb 2004 04:48:07 -0500 Received: from 81-178-2-190.dsl.pipex.com ([81.178.2.190] helo=dnni.com) by ietf-mx with esmtp (Exim 4.12) id 1AoJdO-0004tR-00; Wed, 04 Feb 2004 04:47:50 -0500 Received: from Puppy ([10.1.2.23]) by dnni.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Feb 2004 09:47:57 +0000 Message-ID: <017a01c3eb03$e25c39b0$1702010a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Loa Andersson" , "Tove Madsen" Cc: , "Rick Wilder" , References: <20040120215626.64812.qmail@web109.biz.mail.yahoo.com> Subject: Re: last call on terminology draft Date: Wed, 4 Feb 2004 09:47:18 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0177_01C3EB03.E0F074B0" 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 X-OriginalArrivalTime: 04 Feb 2004 09:47:57.0921 (UTC) FILETIME=[F8450D10:01C3EB03] 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_0177_01C3EB03.E0F074B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Useful draft, thanks. Mainly typos, attached. I find it odd that the list of drafts that depend on this terminology draft are normative references. This will delay the publication of this document as an RFC and doesn't seem necessary. Not sure if references such as draft-ppvpn-metrics.00.txt in section 3.7 should actually be handled as other references. Perhaps add a third references section "Expired References"? I wonder whether the sections are in the right order. The building block terms from section 5 get used throughout section 3. The early subsections in section 3 refer to the later subsections. But this is hardly important. You seem to be missing copyright and IPR statements. Cheers, Adrian ------=_NextPart_000_0177_01C3EB03.E0F074B0 Content-Type: text/plain; name="draft-andersson-ppvpn-terminology-04-af.txt" Content-Disposition: attachment; filename="draft-andersson-ppvpn-terminology-04-af.txt" Content-Transfer-Encoding: quoted-printable L3VPN Working Group Loa Andersson Internet-Draft Tove Madsen < TLA=A1group > TLA-group Expiration Date: March 2004 25 September, 2003 PPVPN terminology Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract < The provider provisioned VPN solutions has attracted a great deal < of interest. Memos proposing different and overlapping solution > The provider provisioned VPN solutions have attracted a great deal > of interest. Memos proposing different and overlapping solutions have been discussed on the PPVPN mailing list and in the Working < Group meetings. This has lead to a development of a partly new > Group meetings. This has lead to the development of a partly new set of concepts used to describe the set of VPN services. To a < certain extent there are more than one term covering the same < concept and sometimes the same term covers more than on concept. > certain extent there is more than one term covering the same > concept and sometimes the same term covers more than one concept. The terminology needs to be made clearer and more intuitive. This document seeks to fill at least part of that need. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 2] Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of contents 1. Introduction ..................................................... 3 2. PPVPN Terminology ................................................ 4 3. Provider Provisioned Virtual Private Network services ............ 5 3.1 IP-only LAN-like Service (IPLS)............................... 5 3.2 Layer 2 VPN (L2VPN) .......................................... 5 3.3 Layer 3 VPN (L3VPN) .......................................... 5 3.4 Pseudo Wire (PW) ............................................. 5 3.5 Transparent LAN Service (TLS)................................. 6 3.6 Virtual LAN (VLAN) ........................................... 6 3.7 Virtual Leased Line Service (VLLS)............................ 6 3.8 Virtual Private LAN Service (VPLS)............................ 6 3.9 Virtual Private Network (VPN)................................. 6 3.10 Virtual Private Switched Network (VPSN)...................... 7 3.11 Virtual Private Wire Service (VPWS).......................... 7 4. Classification of VPNs ........................................... 7 5. Building blocks .................................................. 9 5.1 Customer Edge device (CE) .................................... 9 5.1.1 Device based CE naming.................................. 9 5.1.2 Service based CE naming................................ 10 5.2 Provider Edge (PE) .......................................... 10 5.2.1 Device based PE naming................................. 11 5.2.2 Service based PE naming................................ 11 5.2.3 Distribution based PE naming........................... 12 5.3 Core ........................................................ 12 5.3.1 Provider router (P) ................................... 12 5.4 Naming in specific Internet drafts........................... 12 5.4.1 Layer 2 PE (L2PE) ..................................... 12 5.4.2 Logical PE (LPE) ...................................... 13 5.4.3 PE-CLE ................................................ 13 5.4.4 PE-Core ............................................... 13 5.4.5 PE-Edge ............................................... 13 5.4.6 PE-POP ................................................ 13 5.4.7 VPLS Edge (VE) ........................................ 13 6. Functions ....................................................... 13 INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 3] 6.1 Attachment Circuit (AC) ................................... 14 6.2 Backdoor Links ............................................ 14 6.3 Endpoint discovery ........................................ 14 6.4 Flooding .................................................. 14 6.5 MAC address learning ...................................... 14 6.5.1 Qualified learning ................................... 14 6.5.2 Unqualified learning ................................. 15 6.6 Signalling ................................................ 15 7. 'Boxes' .......................................................... 15 7.1 Aggregation box ........................................... 15 7.2 Customer Premises Equipment (CPE).......................... 15 7.3 Multi Tenant Unit (MTU) ................................... 16 8. Packet Switched Network (PSN) .................................... 16 8.1 Route Distinguisher (RD) .................................. 16 8.2 Route Reflector ........................................... 16 8.3 Route Target (RT) ......................................... 16 8.4 Tunnel .................................................... 17 8.5 Tunnel multiplexor ........................................ 17 8.6 Virtual Channel (VC) ...................................... 17 8.7 VC label .................................................. 17 8.8 Inner label ............................................... 17 8.9 VPN Routing and Forwarding (VRF)........................... 17 8.10 VPN Forwarding Instance (VFI)............................. 18 8.11 Virtual Switch Instance (VSI)............................. 18 8.12 Virtual Router (VR) ...................................... 18 9. Acknowledgements ................................................. 18 10. Authors' Contact ................................................ 18 11. Normative References ............................................ 19 12. Non-Normative References ........................................ 19 1. Introduction < There are a comparatively large number of memos being submitted = to > There is a comparatively large number of memos being submitted = to the former PPVPN, and L2VPN, L3VPN and PWE3 working groups that < all addresses the same problem space, provider provisioned = virtual > all address the same problem space, provider provisioned virtual private networking for end customers. The memos address a wide range of services, but there is also a great deal of commonality among the proposed solutions. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 4] < This has lead to a development of a partly new set of concepts > This has lead to the development of a partly new set of concepts used to describe this set of VPN services. To a certain extent < there are more than one term covering the same concept and > there is more than one term covering the same concept and sometimes the same term covers more than one concept. The terminology needs to be made clearer and more intuitive. This document seeks to fill at least part of the need and proposes a foundation for a unified terminology for the L2VPN, L3VPN working groups; in some cases the parallel concepts within the < PWE3 working group is used as references. > PWE3 working group are used as references. 2. PPVPN Terminology The concepts and terms in this list are gathered from Internet Drafts sent to the L2VPN and L3VPN mailing lists (earlier PPVPN mailing list) and RFCs relevant to the L2VPN and L3VPN working groups. The focus is on terminology and concepts that are specific to the PPVPN area, but this is not strictly enforced, e.g. there are concepts and terms within the PWE3 and (Generalized) MPLS areas that are closely related. We've tried to find the earliest use of terms and concepts. This document intends to fully cover the concepts within five core documents from the L2VPN and L3VPN working groups the "Generic Requirements for Provider Provisioned VPN" [GENERIC], the "A Framework for Layer 3 Provider Provisioned Virtual Private Networks" [L3VPN-frmwrk], the "Service requirements for Layer 3 Provider Provisioned Virtual Private Networks" [PPVPN-req], the "L2VPN Framework [L2VPN-frmwrk] and "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks" [L2VPN- req]. The intention is to create a comprehensive and unified set of concepts for these documents, and by extension for the entire < PPVPNarea.Todosoitisalsonecessarytogivesomeofthe > PPVPN area. To do so it is also necessary to give some of the ##huh?## development the concepts of the area have been through. The document is structured in four major sections. Section 4 lists < the different services that has been/will be specified, Section 5 < lists the building blocks that is used to specify those services, > the different services that have been/will be specified, Section 5 > lists the building blocks that are used to specify those services, section 6 lists the functions needed in those services and section 7 list some typical devices used in customer and provider networks. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 = [Page 5] 3. Provider Provisioned Virtual Private Network services In this section we define the terminology that relates the set of services to solutions specified by the L2VPN and L3VPN working groups. The concept "pseudo wire" that belongs to the PWE3 working group is included for reference purposes. For requirements in provider provisioned VPNs see [PPVPN-req]. In this section all abbreviations are listed in alphabetic order. 3.1 IP-only LAN-like Service (IPLS) An IPLS is very like a VPLS (see 3.8), except that: - it is assumed that the CE devices (see 5.1) are hosts or routers, not switches - it is assumed that the service will only need to carry IP packets, and supporting packets such as ICMP and ARP; otherwise layer 2 packets which do not contain IP are not supported. While this service is a functional subset of the VPLS service, it is considered separately because it may be possible to provide it using different mechanisms, which may allow it to run on certain hardware platforms that cannot support the full VPLS functionality [PPVPN-L2-frmwrk]. 3.2 Layer 2 VPN (L2VPN) Three types of L2VPNs are described in this document, Virtual < Private Wire Service (VPWS) (section 3.11), VPLS Virtual Private < LAN Service (VPLS)(section 3.8), and IP-only LAN-like Service < (IPLS). > Private Wire Service (VPWS) (section 3.11), Virtual Private > LAN Service (VPLS) (section 3.8), and IP-only LAN-like Service > (IPLS) (section 3.1). 3.3 Layer 3 VPN (L3VPN) An L3VPN is a solution that interconnects several sets of hosts and routers and allows them to communicate based on L3 addresses, see [L3VPN-frmwrk]. 3.4 Pseudo Wire (PW) < The PWE3 working group within IETF specifies the pseudo wire > The PWE3 working group within the IETF specifies the pseudo wire technology. A pseudo wire is an emulated point-to-point < connectivity over a packet switched network that gives the > connection over a packet switched network that gives the possibility to interconnect two nodes with any L2 technology. The INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page 6] PW shares some of the building blocks and architecture constructs with the point to multipoint solutions, e.g. PE (see 5.2) and CE (see 5.1). An early solution for PWs is described in [martini- tran]. Encapsulation formats readily used in VPWS, VPLS and PWs are described in [martini-encap]. Requirements for PWs are found < in [PWE3-req] and [PWE3-frmwrk] present an architectural framework > in [PWE3-req] and [PWE3-frmwrk] presents an architectural framework for PWs. 3.5 Transparent LAN Service (TLS) TLS was an early name used to describe the VPLS service, it was used e.g. in the now dated draft-lasserre-tls-mpls-00.txt. It has been replaced by VPLS, which is the current term. 3.6 Virtual LAN (VLAN) A VLAN is a way of separating traffic on a LAN, e.g. between different departments within a company. This acronym is not defined by former PPVPN working group, but is defined by IEEE 802.1Q. The VLANID is used to mark an Ethernet frame with a tag to create user groups on a LAN. 3.7 Virtual Leased Line Service (VLLS) The VLLS has been replaced by VPWS. It was used in now dated draft-ppvpn-metrics.00.txt. 3.8 Virtual Private LAN Service (VPLS) A VPLS is a provider service that emulates the full functionality of a traditional Local Area Network. A VPLS makes it possible to interconnect several LAN segments over a packet switched network (PSN) and makes the remote LAN segments behave as one single LAN. For an early work on defining a solution and protocol for a VPLS see [L2VPN-req], [Lasserre-vkompella], and [Kompella-VPLS]. In a VPLS the provider network emulates a learning bridge and forwarding decisions are taken based on MAC addresses or MAC addresses and VLAN tag. 3.9 Virtual Private Network (VPN) VPN is a generic term that covers the use of public or private networks to create groups of users that are separated from other network users and may communicate among them as if they were on a < private network. The level of separation is possible to enhance > private network. It is possible to enhance the level of separation e.g. by end-to-end encryption, this is however outside the scope INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 7] of IETF VPN working group charters. This VPN definition is from [RFC2764]. In the [L3VPN-frmwrk] the term VPN is used to refer to a specific set of sites as either an intranet or an extranet that have been configured to allow communication. Note that a site is a member of at least one VPN, and may be a member of many VPNs. In this document "VPN" is also used as a generic name for all services listed in section 3. 3.10 Virtual Private Switched Network (VPSN) A VPSN is replaced by VPLS. The VPSN abbreviation was used e.g. in the now dated draft-vkompella-ppvpn-vpsn.reqmts-00.txt. 3.11 Virtual Private Wire Service (VPWS) A Virtual Private Wire Service (VPWS) is a point-to-point circuit (link) connecting two Customer Edge devices. The CE in the customer network is connected to a PE in the provider network via an Attachment Circuit (see 6.1); the Attachment Circuit is either a physical or a logical circuit. < The PE's in the core network is connected via a PW. > The PE's in the core network are connected via a PW. The CE devices can be routers, bridges, switches or hosts. In some implementations a set of VPWSs is used to create a multi-site L2VPN network. An example of a VPWS solution is described in [L2VPN]. < A VPWS differs from a VPLS (section 4.8) in that the VPLS is point > A VPWS differs from a VPLS (section 3.8) in that the VPLS is point to multipoint, while the VPWS is point to point. See [L2VPN- frmwrk]. 4. Classification of VPNs The terminology used in [GENERIC] is defined based on the figure below. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 8] PPVPN ________________|__________________ | | Layer 2 Layer 3 ______|_____ ______|______ | | | | P2P P2M PE-based CE-based (VPWS) _____|____ ______|____ | | | | | | VPLS IPLS RFC2547 Virtual IPsec Style Router The figure above presents a taxonomy of PPVPN technologies. Some of the definitions are given below: CE-based VPN: A VPN approach in which the shared service provider network does not have any knowledge of the customer VPN. This information is limited to CE equipment. All the VPN-specific procedures are performed in the CE devices, and the PE devices are not aware in any way that some of the traffic they are processing is VPN traffic (see also [L3VPN-frmwrk]). PE-Based VPNs: A Layer 3 VPN approach in which a service provider network is used to interconnect customer sites using shared resources. Specifically the PE device maintains VPN state, isolating users of one VPN from users of another VPN. Because the PE device maintains all required VPN state, the CE device may behave as if it were connected to a private network. Specifically, the CE in a PE-based VPN must not require any changes or additional functionality to be connected to a PPVPN instead of a private network. The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP < address of the packet, and optionally on based on other > address of the packet, and optionally based on other information in the IP header of the packet. The PE devices are themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS < tunnels)[L3VPN-frmwrk]. > tunnels) [L3VPN-frmwrk]. Virtual Router (VR) style: A PE-based VPN approach in which the PE router maintains a complete logical router for each VPN that it supports. Each logical router maintains a unique forwarding table INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 9] and executes a unique instance of the routing protocols. These VPNs are described in [PPVPN-VR]. RFC 2547 Style: A PE-based VPN approach in which the PE router maintains separate forwarding environment for each VPN and a separate forwarding table for each VPN. In order to maintain multiple forwarding table instances while running only a single routing protocol instance, RFC 2547 style VPNs mark route advertisements with attributes that identify their VPN context. These VPNs are based on the approach described in [RFC2547bis]. 5. Building blocks Starting with specifications of L3VPNs, e.g. the 2547 specification [RFC2547] and [RFC2547bis] and Virtual Routers [PPVPN-VR], a way of describing the building blocks and allocation of functions in VPN solutions was developed. The building blocks < are often in day-to-day talk treated as if it were physical boxes, < common for all services. > are often used in day-to-day talk as if they were physical boxes, > common to all services. < However, for different reasons this is to over-simplify. Any of > However, for different reasons this is an over-simplification. Any = of the building blocks could be implemented across more than one physical box. How common the use of such implementations will be is beyond the scope of this document. 5.1 Customer Edge device (CE) A CE is the name of the device with the functionality needed on the customer premises to access the services specified by the former PPVPN working group. There are two different aspects that need to be considered in naming CE devices. One could start with the type of device that is used to implement the CE (see section 5.1.1). It is also possible to use the service the CE provides and with the result it will be a set of "prefixed CEs", (see section 5.1.2). It is common practice to use "CE" to indicate any of these boxes, since it is very often unambiguous in the specific context. 5.1.1 Device based CE naming 5.1.1.1 Customer Edge Router (CE-R) A CE-R is a router in the customer network interfacing the provider network. There are many reasons to use a router in the INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 10] customer network, e.g. in an L3VPN using private IP addressing this is the router that is able to do forwarding based on the private addresses. Another reason to require the use of a CE-R on the customer side is that one want to limit the number on MAC- addresses that needs to be learnt in the provider network. A CE-R could be used to access both L2 and L3 services. 5.1.1.2 Customer Edge Switch (CE-S) A CE-S is a service aware L2 switch in the customer network interfacing the provider network. In a VPWS or a VPLS it is not strictly necessary to use a router in the customer network, a layer 2 switch might very well do the job. 5.1.2 Service based CE naming The list below is just examples and it will be extended as the number of services increases. 5.1.2.1 L3VPN-CE An L3VPN-CE is the device or set of devices on the customer premises that attaches to a provider provisioned L3VPN, e.g. a 2547bis implementation. 5.1.2.2 VPLS-CE A VPLS-CE is the device or set of devices on the customer = premises that attaches to a provider provisioned VPLS. 5.1.2.3 VPWS-CE A VPWS-CE is the device or set of devices on the customer = premises that attaches to a provider provisioned VPWS. 5.2 Provider Edge (PE) A PE is the name of the device or set of devices at the edge of the provider network with the functionality that is needed to interface the customer. PE, without further qualifications, is very often used for naming the devices since it is made unambiguous by the context. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 11] In naming PEs there are three aspects that we need to consider, the service they support, whether the functionality needed for service is distributed across more than one device and the type = of device they are build on. 5.2.1 Device based PE naming Both routers and switches may be used to implement PEs, however the scaling properties will be radically different depending = which < type of equipment that is chosen. > type of equipment is chosen. 5.2.1.1 Provider Edge Router (PE-R) A PE-R is a L3 device that participates in the PSN (see section = 8) routing and forwards packets based on the routing information. 5.2.1.2 Provider Edge Switch (PE-S) < APE-SisaL2devicethatparticipatesine.g.aswitched > A PE-S is a L2 device that participates in e.g. a switched Ethernet taking forwarding decision packets based on L2 address information. 5.2.2 Service based PE naming 5.2.2.1 L3VPN-PE An L3VPN-PE is a device or set of devices at the edge of the provider network interfacing the customer network, with the functionality needed for an L3VPN. 5.2.2.2 VPWS-PE A VPWS-PE is a device or set of devices at the edge of the provider network interfacing the customer network, with the functionality needed for a VPWS. 5.2.2.3 VPLS-PE A VPLS-PE is a device or set of devices at the edge of the provider network interfacing the customer network, with the functionality needed for a VPLS. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 12] 5.2.3 Distribution based PE naming For scaling reasons it is in the VPLS/VPWS cases sometimes = desired to distribute the functions in the VPLS/VPWS-PE across more than one device, e.g. is it feasible to allocate MAC address learning on a comparatively small and in-expensive device close to the customer site, while participation in the PSN signalling and set up of PE to PE tunnels are done by routers closer to the network core. When distributing functionality across devices a protocol is needed to exchange information between the Network facing PE (N- PE) see section 5.2.3.1 and the User facing PE (U-PE) see section 5.2.3.2. 5.2.3.1 Network facing PE (N-PE) The N-PE is the device to which the signalling and control functions are allocated when a VPLS-PE is distributed across more than one box. 5.2.3.2 User facing PE (U-PE) The U-PE is the device to which the functions needed to take forwarding or switching decision at the ingress of the provider network. 5.3 Core 5.3.1 Provider router (P) < ThePisdefinedasarouterinthecorenetworkthatdoesnot > The P is defined as a router in the core network that does not have interfaces directly towards a customer. Hence a P router = does not need to keep VPN state and is VPN un-aware. 5.4 Naming in specific Internet drafts 5.4.1 Layer 2 PE (L2PE) L2PE is the joint name of the devices in the provider network = that implement L2 functions needed for a VPLS or a VPWS. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 13] 5.4.2 Logical PE (LPE) The term Logical PE (LPE) originates from a dated Internet Draft "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture" and was used to describe a set of devices used in a provider network to implement a VPLS. In a LPE, VPLS functions = are distributed across small devices (PE-Edges/U-PE) and devices attached to a network core (PE-Core/N-PE). In an LPE solution the PE-edge and PE-Core can be interconnected by a switched Ethernet transport network(s) or uplinks. The LPE will appear to the core network as a single PE. In this document the devices that constitutes the LPE is called N-PE and U-PE. 5.4.3 PE-CLE An alternative name for the U-PE suggested in now dated Internet Draft "VPLS architectures". 5.4.4 PE-Core See the origins and use of this concept in section 5.4.2. 5.4.5 PE-Edge See the origins and use of this concept in section 5.4.2. 5.4.6 PE-POP An alternative name for the U-PE suggested in now dated Internet Draft "VPLS architectures". 5.4.7 VPLS Edge (VE) The term VE originates from a dated Internet Draft on a distributed transparent LAN service and was used to describe the < deviceusedbyaprovidernetworktohandoffaVPLStoa > device used by a provider network to hand off a VPLS to a customer. In this document the VE is called a VPLS-PE. This name has dated. 6. Functions In this section we have grouped a number of concepts and terms < that has to be performed to make the VPN services work. > that have to be performed to make the VPN services work. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 14] 6.1 Attachment Circuit (AC) In a Layer 2 VPN the CE is attached to PE via an Attachment Circuit (AC). The AC may be a physical or logical link. 6.2 Backdoor Links Backdoor Links are links between CE devices that are provided by the end customer rather than the SP; may be used to interconnect CE devices in multiple-homing arrangements [L3VPN-frmwrk]. 6.3 Endpoint discovery Endpoint discovery is the process by which the devices that are aware of a specific VPN service will find all customer facing ports that belong to the same service. The requirements on endpoint discovery and signalling are discussed in [PPVPN-req]. It was also the topic in a now dated Internet Draft reporting from a design team activity on VPN discovery. 6.4 Flooding Flooding is a function related to L2 and L3 services; when a PE receives a frame with an unknown destination MAC-address, that frame is send out over (flooded) every other interface. 6.5 MAC address learning MAC address learning is a function related to L2 services; when = PE receives a frame with an unknown source MAC-address the relationship between that MAC-address and interface is learnt for future forwarding purposes. In a layer 2 VPN solution from the L2VPN WG, this function is allocated to the VPLS-PE. 6.5.1 Qualified learning In qualified learning, the learning decisions at the U-PE are based on the customer Ethernet frame's MAC address and VLAN tag, if a VLAN tag exists. If no VLAN tag exists, the default VLAN is assumed. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 15] 6.5.2 Unqualified learning In unqualified learning, learning is based on a customer Ethernet frame's MAC address only. 6.6 Signalling Signalling is the process by which the PEs that have VPNs behind them exchange information to set up PWs, PSN tunnels and tunnel multiplexers. This process might be automated through a protocol or done by manual configuration. Different protocols may be used to establish the PSN tunnels and exchange the tunnel = multiplexers. 7. 'Boxes' We list a set of boxes that will typically be used in an environment that supports different kinds of VPN services. We = have chosen to include some names of boxes that originate outside the protocol specifying organisations. 7.1 Aggregation box The aggregation box is typically an L2 switch that is service unaware and is used only to aggregate traffic to more function rich points in the network. 7.2 Customer Premises Equipment (CPE) The CPE equipment is the box that a provider places with the customer. It serves two purposes, giving the customer ports to plug in to and making it possible for a provider to monitor the connectivity to the customer site. The CPE is typically a low = cost box with limited functionality and in most cases not aware of the VPN services offered by the provider network. The CPE equipment is not necessarily the equipment to which the = CE functions are allocated, but is part of the provider network and used for monitoring purposes. The CPE name is used primarily in network operation and = deployment contexts, and should not be used in protocol specifications. INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 16] 7.3 Multi Tenant Unit (MTU) An MTU [DTLS] is typically an L2 switch placed by a service provider in a building where customers of that service provider are located. The MTU device name is used primarily in network operation and deployment contexts, and should not be used in protocol specifications, as it is also a used abbreviation for Maximum Transmit Units. 8. Packet Switched Network (PSN) A PSN is the network through which the tunnels supporting the VPN services are set up. 8.1 Route Distinguisher (RD) A Route Distinguisher [RFC2547bis] is an 8-byte value that togetherwitha4byteIPv4addressidentifiesaVPN-IPv4address family. If two VPNs use the same IPv4 address prefix, the PEs translates these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in two different VPNs, = it is possible to install two completely different routes to that address, one for each VPN. 8.2 Route Reflector A route reflector is a network element owned by a Service = Provider (SP) that is used to distribute BGP routes to the SP's = BGP-enabled routers [L3VPN-frmwrk]. 8.3 Route Target (RT) A Route Target attribute [RFC2547bis] can be thought of as identifying a set of sites, or more precisely a set of VRFs (see section 8.8). Associating a particular Route Target with a route, allows that route to be placed in all VRFs that are used for routing traffic received from the corresponding sites. A Route Target attribute is also a BGP extended community used in [RFC2547], and [BGPVPN-auto]. A Route Target community is used to constrain VPN information distribution to the set of VRFs. A = route INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 17] target can be perceived as identifying a set of sites, or more precisely a set of VRFs. 8.4 Tunnel A tunnel is connectivity through a PSN that is used to send traffic across the network from one PE to another. The tunnel provides a mechanism to transport packets from one PE to another, separation of one customer's traffic from another customer's traffic is done based on tunnel multiplexers (see section 8.4). How the tunnel is established depends on the tunnelling = mechanisms provided by the PSN, i.e. the tunnel could be based on e.g. the IP-header, an MPLS label, the L2TP Session ID, or on the GRE Key field. 8.5 Tunnel multiplexor A tunnel multiplexor is an entity that is sent with the packets traversing the tunnel to make possible to decide to which = instance of a service a packet belongs and from which sender it was received. In [L2VPN] the tunnel multiplexor is formatted as an MPLS label. 8.6 Virtual Channel (VC) A VC is transported within a tunnel and identified by its tunnel multiplexer. A virtual channel is identified by a VCI (Virtual Channel Identifier). In the PPVPN context a VCI is a VC label or tunnel multiplexer and in the Martini case it is equal to the VCID. 8.7 VC label In an MPLS enabled IP network a VC label is an MPLS label, used = to identify traffic within a tunnel that belongs to a particular = VPN, i.e. the VC label is the tunnel multiplexer in networks that uses MPLS labels. 8.8 Inner label "Inner label" is another name for VC label (see section 8.6). 8.9 VPN Routing and Forwarding (VRF) In networks running 2547 VPN's [RFC2547], PE routers maintain VRF's. A VRF is a per-site forwarding table. Every site to which INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page 18] the PE router is attached is associated with one of these tables. A particular packet's IP destination address is looked up in a particular VRF only if that packet has arrived directly from a site, which is associated with that table. 8.10 VPN Forwarding Instance (VFI) VPN Forwarding Instance (VFI) is a logical entity that resides in a PE that includes the router information base and forwarding information base for a VPN instance [L3VPN-frmwrk]. 8.11 Virtual Switch Instance (VSI) In a layer 2 context a VSI is a virtual switching instance that serves one single VPLS [L2VPN-frmwrk]. A VSI performs standard = LAN (i.e., Ethernet) bridging functions. Forwarding done by a VSI is based on MAC addresses and VLAN tags, and possibly other relevant information on a per VPLS basis. The VSI is allocated to VPLS-PE or in the distributed case to the U-PE. 8.12 Virtual Router (VR) A Virtual Router (VR) is software and hardware based emulation of a physical router. Virtual routers have independent IP routing = and forwarding tables and they are isolated from each other, see [PPVPN-VR]. 9. Acknowledgements Much of the content in this document is based on discussion in = the PPVPN design teams for "auto discovery" and "l2vpn". 10. Authors' Contact Loa Andersson TLA-group loa@pi.se Tove Madsen TLA-group tove@niebelungen.net INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 19] 11. Normative References [GENERIC] Nagarajan, A (ed), "Generic Requirements for Provider Provisioned VPN", draft-ietf-l3vpn-generic-reqts-01.txt, Work in Progress, Internet Draft, Aug 2003 [L2VPN-frmwrk] Andersson, L. and Rosen, E., "L2VPN Framework", draft- ietf-l2vpn-l2-framework-01.txt, Work in Progress, Internet Draft, Sept 2003 [L3VPN-frmwrk] Callon, R. and Suzuki, M.," A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn- framework-00.txt, Work in Progress, Internet Draft, March 2003 [PPVPN-req] Carugi, M. and McDysan, D., "Service requirements for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf- l3vpn-requirements-00.txt, Work in Progress, Internet Draft, Oct 2003 [L2VPN-req] Augustyn, W., and Serbest, Y., "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", draft-ietf- l2vpn-requirements-00.txt, Work in Progress, Internet Draft, May 2003 12. Non-Normative References [BGPVPN-auto] Ould-Brahim, H., Rosen, E. and Rekhter, Y. "Using BGP as an auto-discovery mechanism for network-based VPNs", draft-ietf- l3vpn-bgpvpn-auto-00.txt, Work in progress, Internet Draft, July 2003 [kompella-VPLS] Kompella, K. "Virtual Private LAN Service", draft- ietf-l2vpn-vpls-bgp-00.txt, Work in Progress, Internet Draft, May 2003 [L2VPN] Kompella, K., et.al. "Layer 2 VPNs Over Tunnels", draft- kompella-ppvpn-l2vpn-03.txt, Work in Progress, June 2002 [lasserre-vkompella] Kompella, V. and Lasserre, M., "Virtual Private LAN Services over MPLS" draft-ietf-l2vpn-vpls-ldp-00.txt, Work in progress, Mar 2002 [martini-encap] Martini, L., et.al. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLSNetworks", draft-martini- l2circuit-encap-mpls-05.txt, Work in Progress, Internet Draft, April 2003 INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C Andersson / Madsen Expires March 2004 [Page = 20] [martini-tran] Martini, L., et.al. "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-11.txt, Work in progress, Internet Draft, April 2003 [PPVPN-VR] Ould-Brahim, H., et.al. "Network-based IP VPN using Virtual Routers", draft-ietf-l3vpn-vpn-vr-00.txt, Work in Progress, Internet Draft, July 2002 [PWE3-arch] Prayson, P. and Bryant, S., "PWE3 Architecture", draft- ietf-pwe3-arch-05.txt, Work in Progress, Internet Draft, August 2003 [PWE3-req] Xiao, X., "Requirements for Pseudo-Wire Emulation Edge-to- Edge (PWE3)", draft-ietf-pwe3-requirements-06.txt, Work in progress, Internet Draft, July 2003 [RFC2547] Rosen, E., et.al. "BGP/MPLS VPNs", rfc2547, March 1999 [RFC2547bis] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn- rfc2547bis-01.txt, Work in Progress, Internet Draft, September 2003 [RFC2764] Gleeson, B., et.al. "A Framework for IP Based Virtual Private Networks", rfc2764, February 2000 INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 =0C ------=_NextPart_000_0177_01C3EB03.E0F074B0-- From exim@www1.ietf.org Fri Feb 6 04:46:03 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 EAA18074 for ; Fri, 6 Feb 2004 04:46:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2YJ-0004g9-SA for l2vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 04:45:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i169jZTD017982 for l2vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 04:45:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2YI-0004fw-4G for l2vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 04:45: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 EAA18068 for ; Fri, 6 Feb 2004 04:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2YF-0007Jq-00 for l2vpn-web-archive@ietf.org; Fri, 06 Feb 2004 04:45:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2XI-0007I2-00 for l2vpn-web-archive@ietf.org; Fri, 06 Feb 2004 04:44:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2Wv-0007GN-00 for l2vpn-web-archive@ietf.org; Fri, 06 Feb 2004 04:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2Wo-0004ZW-Ew; Fri, 06 Feb 2004 04:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2WN-0004Yk-0t for l2vpn@optimus.ietf.org; Fri, 06 Feb 2004 04:43: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 EAA18023 for ; Fri, 6 Feb 2004 04:43:31 -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 1Ap2WK-0007Fd-00 for l2vpn@ietf.org; Fri, 06 Feb 2004 04:43:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2VO-0007E1-00 for l2vpn@ietf.org; Fri, 06 Feb 2004 04:42:35 -0500 Received: from mail.alcatel.co.uk ([208.178.18.30]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2Ul-0007C5-00; Fri, 06 Feb 2004 04:41:55 -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 i169bGg28240; Fri, 6 Feb 2004 09:37:16 GMT Subject: Re: Changing the FEC for VPLS to generalized PWid FEC To: Vach.Kompella@alcatel.com Cc: l2vpn@ietf.org, l2vpn-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 6 Feb 2004 09:35:40 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/06/2004 09:37:16 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 Vach, I also agree that we should move from FEC 128 to FEC 129. However, I think FEC 129 also needs to have an equivalent of the grouping mechanism. This is needed to group label withdrawl and PW status signalling messages, addressing scalability requirements when there are large numbers of changes that must be propagated. Best regards, Matthew |---------+---------------------------> | | "Vach Kompella" | | | | | | Sent by: | | | l2vpn-admin@ietf| | | .org | | | | | | | | | 02/02/2004 18:47| | | Please respond | | | to Vach.Kompella| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: | | cc: | | Subject: Changing the FEC for VPLS to generalized PWid FEC | >-------------------------------------------------------------------------------------------------------------------------------| Folks, There is still no discussion on changing the FEC type from 128, as it stands today, to the generalized PW FEC type (129), as suggested by Eric Rosen. I think this is a good idea, and I know that several vendors have implemented the old style, so it will put a crimp in your implementations, but can we make some progress here? The main reason for moving forward is to address future issues with VPLSen by using a structured name and 32 bits just isn't good enough for that. This will assist in auto-discovery, inter-regional VPLSen, and adequate name-space size. -Vach From exim@www1.ietf.org Tue Feb 10 16:10:50 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 QAA16070 for ; Tue, 10 Feb 2004 16:10:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf9C-0006xP-E1 for l2vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 16:10:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALAMLq026737 for l2vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 16:10:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf9B-0006xA-TF for l2vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:10: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 QAA15968 for ; Tue, 10 Feb 2004 16:10:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf9A-0001lr-00 for l2vpn-web-archive@ietf.org; Tue, 10 Feb 2004 16:10:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf87-0001YP-00 for l2vpn-web-archive@ietf.org; Tue, 10 Feb 2004 16:09:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7B-0001Oy-00 for l2vpn-web-archive@ietf.org; Tue, 10 Feb 2004 16:08:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf6v-0005u5-0N; Tue, 10 Feb 2004 16:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf65-0005Zq-Fy for l2vpn@optimus.ietf.org; Tue, 10 Feb 2004 16:07:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15271; Tue, 10 Feb 2004 16:07:06 -0500 (EST) Message-Id: <200402102107.QAA15271@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-radius-pe-discovery-00.txt Date: Tue, 10 Feb 2004 16:07: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.4 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 : Using RADIUS for PE-Based VPN Discovery Author(s) : J. Heinanen Filename : draft-ietf-l2vpn-radius-pe-discovery-00.txt Pages : 9 Date : 2004-2-10 This document describes how in PE-based VPNs, a PE of a VPN can use RADIUS to authenticate its CEs and discover the other PEs of the VPN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-radius-pe-discovery-00.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-radius-pe-discovery-00.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-radius-pe-discovery-00.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-2-10154832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-radius-pe-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-radius-pe-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154832.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Feb 12 13:49:02 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 NAA06759 for ; Thu, 12 Feb 2004 13:49:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLt3-000888-EZ for l2vpn-archive@odin.ietf.org; Thu, 12 Feb 2004 13:48:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CImXUM031246 for l2vpn-archive@odin.ietf.org; Thu, 12 Feb 2004 13:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLt3-00087t-9l for l2vpn-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 13:48:33 -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 NAA06722 for ; Thu, 12 Feb 2004 13:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLsy-0005Fb-00 for l2vpn-web-archive@ietf.org; Thu, 12 Feb 2004 13:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLsC-00059g-00 for l2vpn-web-archive@ietf.org; Thu, 12 Feb 2004 13:47:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArLrY-00052a-00 for l2vpn-web-archive@ietf.org; Thu, 12 Feb 2004 13:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLrZ-0007uf-JA; Thu, 12 Feb 2004 13: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 1ArLr6-0007tJ-Df for l2vpn@optimus.ietf.org; Thu, 12 Feb 2004 13:46: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 NAA06542 for ; Thu, 12 Feb 2004 13:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLr2-00050z-00 for l2vpn@ietf.org; Thu, 12 Feb 2004 13:46:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLpy-0004vS-00 for l2vpn@ietf.org; Thu, 12 Feb 2004 13:45:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArLpL-0004lq-00; Thu, 12 Feb 2004 13:44:43 -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 i1CIiDN17989; Thu, 12 Feb 2004 13:44:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH75MH>; Thu, 12 Feb 2004 13:44:13 -0500 Message-ID: From: "Florin Balus" To: pwe3@ietf.org Cc: l2vpn@ietf.org Subject: VCCV draft and related sub-TLV options in LSP Ping Date: Thu, 12 Feb 2004 13:44:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F198.34CE06CA" 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_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_01C3F198.34CE06CA Content-Type: text/plain I have some comments related to PW OAM: 1. LSP Ping does not have a sub-TLV for the GID FEC - see 3.2 in draft-ietf-mpls-lsp-ping-04.txt. Just for the VC ID (sub-TLV of 9)- see 3.2.8 paragraph of the above draft. Shouldn't we have one for the Gid FEC (i.e. 10) as it is one of the 2 FECs described in a WG doc - see 5.2.2 of draft-ietf-pwe3-control-protocol-05.txt? 2. Also I just got a chance to check the latest version of the VCCV draft (draft-ietf-pwe3-vccv-02.txt) and I noticed that section 5.2. "MPLS Ping Packet" says: "The LSP Ping header must be used as described [LSP-PING] and must also contain the sub-TLV of 8 for PW circuits. This sub-TLV must be sent containing the circuit to be verified as the "VC ID" field:" First VC ID is identified by sub-TLV of 9 (see 3.2 in draft-ietf-mpls-lsp-ping-04.txt) - sub-TLV of 8 is actually associated with the L2VPN Endpoint. Also I think that we should let this option opened to all related PWE3 structures: VCID and GID FEC (wehenever we get the sub-TLV for it). Florin Balus Nortel Networks Tel: 1-613-768-4997 ESN: 398-4997 Fax: 1-613-765-4123 ESN: 395-4123 Email: mailto:balus@nortelnetworks.com DNE site: http://navigate.us.nortel.com/dne NPW 2003 http://www.nortelnetworks.com/npw2003 ------_=_NextPart_001_01C3F198.34CE06CA Content-Type: text/html Content-Transfer-Encoding: quoted-printable VCCV draft and related sub-TLV options in LSP Ping

I have some comments related to PW OAM:

1. LSP Ping does not have a sub-TLV for the GID FEC - = see 3.2 in draft-ietf-mpls-lsp-ping-04.txt. Just for the VC ID (sub-TLV = of 9)- see 3.2.8 paragraph of the above draft. Shouldn't we have one = for the Gid FEC (i.e. 10) as it is one of the 2 FECs described in a WG = doc - see 5.2.2 of draft-ietf-pwe3-control-protocol-05.txt?

2. Also I just got a chance to check the latest = version of the VCCV draft (draft-ietf-pwe3-vccv-02.txt) and I noticed = that section 5.2. "MPLS Ping Packet" says:

"The LSP Ping header must be used as described = [LSP-PING] and must also contain the sub-TLV of 8 for PW circuits. = This
 sub-TLV must be sent containing the circuit to = be verified as the "VC ID" field:"

First VC ID is identified by sub-TLV of 9 (see 3.2 in = draft-ietf-mpls-lsp-ping-04.txt) - sub-TLV of 8 is actually associated = with the L2VPN Endpoint. Also I think that we should let this option = opened to all related PWE3 structures: VCID and GID FEC (wehenever we = get the sub-TLV for it).

Florin Balus
Nortel Networks
Tel: 1-613-768-4997  ESN: 398-4997
Fax: 1-613-765-4123 ESN: 395-4123
Email: mailto:balus@nortelnetworks.com=
DNE site: http://navigate.us.nortel.com/dne
NPW 2003 http://www.nortelnetworks.com/npw2003

------_=_NextPart_001_01C3F198.34CE06CA-- From exim@www1.ietf.org Fri Feb 13 13:00: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 NAA23052 for ; Fri, 13 Feb 2004 13:00: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 1Arhbj-0002EQ-OL for l2vpn-archive@odin.ietf.org; Fri, 13 Feb 2004 13:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DI07f4008572 for l2vpn-archive@odin.ietf.org; Fri, 13 Feb 2004 13:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhbj-0002EB-AI for l2vpn-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 13:00:07 -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 NAA23037 for ; Fri, 13 Feb 2004 13:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arhbh-0001cY-00 for l2vpn-web-archive@ietf.org; Fri, 13 Feb 2004 13:00:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arhah-0001XF-00 for l2vpn-web-archive@ietf.org; Fri, 13 Feb 2004 12:59:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArhZk-0001Rj-00 for l2vpn-web-archive@ietf.org; Fri, 13 Feb 2004 12:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhZh-0001qJ-GM; Fri, 13 Feb 2004 12: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 1ArhYt-0001ph-Ir for l2vpn@optimus.ietf.org; Fri, 13 Feb 2004 12:57: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 MAA22852 for ; Fri, 13 Feb 2004 12:57:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhYr-0001MI-00 for l2vpn@ietf.org; Fri, 13 Feb 2004 12:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhXy-0001Hv-00 for l2vpn@ietf.org; Fri, 13 Feb 2004 12:56:15 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArhX6-00019D-00; Fri, 13 Feb 2004 12:55:20 -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 i1DHsjl05292; Fri, 13 Feb 2004 09:54:45 -0800 (PST) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1DHsdo71317; Fri, 13 Feb 2004 09:54:39 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i1DHsd934327; Fri, 13 Feb 2004 09:54:39 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs Date: Fri, 13 Feb 2004 09:54:39 -0800 (PST) From: Rahul Aggarwal To: Florin Balus cc: pwe3@ietf.org, "" Subject: Re: [PWE3] VCCV draft and related sub-TLV options in LSP Ping In-Reply-To: Message-ID: <20040213094841.M30222@sapphire.juniper.net> References: 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi Florin, On Thu, 12 Feb 2004, Florin Balus wrote: > > I have some comments related to PW OAM: > > 1. LSP Ping does not have a sub-TLV for the GID FEC - see 3.2 in > draft-ietf-mpls-lsp-ping-04.txt. Just for the VC ID (sub-TLV of 9)- see > 3.2.8 paragraph of the above draft. Shouldn't we have one for the Gid FEC > (i.e. 10) as it is one of the 2 FECs described in a WG doc - see 5.2.2 of > draft-ietf-pwe3-control-protocol-05.txt? > > 2. Also I just got a chance to check the latest version of the VCCV draft > (draft-ietf-pwe3-vccv-02.txt) and I noticed that section 5.2. "MPLS Ping > Packet" says: > "The LSP Ping header must be used as described [LSP-PING] and must also > contain the sub-TLV of 8 for PW circuits. This > sub-TLV must be sent containing the circuit to be verified as the "VC ID" > field:" > > First VC ID is identified by sub-TLV of 9 (see 3.2 in > draft-ietf-mpls-lsp-ping-04.txt) - sub-TLV of 8 is actually associated with > the L2VPN Endpoint. Thanks for catching that. We will fix it. > Also I think that we should let this option opened to > all related PWE3 structures: VCID and GID FEC (wehenever we get the sub-TLV > for it). > Agreed. We will generalize the text to cover this. Thanks for your comments ! rahul > Florin Balus > Nortel Networks > Tel: 1-613-768-4997 ESN: 398-4997 > Fax: 1-613-765-4123 ESN: 395-4123 > Email: mailto:balus@nortelnetworks.com > DNE site: http://navigate.us.nortel.com/dne > NPW 2003 http://www.nortelnetworks.com/npw2003 > From exim@www1.ietf.org Mon Feb 16 15:53: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 PAA22164 for ; Mon, 16 Feb 2004 15:53:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspjK-0004hl-5T for l2vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:52:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKqctC018079 for l2vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:52:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspjK-0004hW-0H for l2vpn-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:52: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 PAA22019 for ; Mon, 16 Feb 2004 15:52:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspjI-0004T8-00 for l2vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:52:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsphE-00041b-00 for l2vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:50:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aspf1-0003aj-00 for l2vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:48:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aspf0-0003Pq-JK for l2vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asper-0004BM-93; Mon, 16 Feb 2004 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspeN-00048J-5i for l2vpn@optimus.ietf.org; Mon, 16 Feb 2004 15:47: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 PAA21368 for ; Mon, 16 Feb 2004 15:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspeL-0003TI-00 for l2vpn@ietf.org; Mon, 16 Feb 2004 15:47:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aspd7-0003Ey-00 for l2vpn@ietf.org; Mon, 16 Feb 2004 15:46:13 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Aspc2-0002z8-00; Mon, 16 Feb 2004 15:45:06 -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 i1GKiZBm059896; Mon, 16 Feb 2004 12:44:35 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp161.static.jnpr.net [172.24.253.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1GKiYo70123; Mon, 16 Feb 2004 12:44:35 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040216154230.040f9080@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 16 Feb 2004 15:44:15 -0500 To: l3vpn@ietf.org, l2vpn@ietf.org From: Ross Callon Subject: End of Last Call (Re: last call on terminology draft) In-Reply-To: <20040120215626.64812.qmail@web109.biz.mail.yahoo.com> 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 At 01:56 PM 1/20/2004 -0800, Rick Wilder wrote: >This begins a 2-week last-call period for . > >Please let the list hear any remaining comments on this document. > >Rick The VPN Terminology Draft, , has now successfully completed last call. Ross From exim@www1.ietf.org Wed Feb 18 15:06:33 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 PAA15344 for ; Wed, 18 Feb 2004 15:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXxO-0001Va-NQ for l2vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 15:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IK66rN005797 for l2vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 15:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXxO-0001VQ-H2 for l2vpn-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 15:06:06 -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 PAA15270 for ; Wed, 18 Feb 2004 15:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXxL-00025u-00 for l2vpn-web-archive@ietf.org; Wed, 18 Feb 2004 15:06:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXwP-000221-00 for l2vpn-web-archive@ietf.org; Wed, 18 Feb 2004 15:05:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtXvR-0001zJ-00 for l2vpn-web-archive@ietf.org; Wed, 18 Feb 2004 15:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXvO-0008Ps-8B; Wed, 18 Feb 2004 15: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 1AtXuV-0007OA-FB for l2vpn@optimus.ietf.org; Wed, 18 Feb 2004 15:03:07 -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 PAA15080 for ; Wed, 18 Feb 2004 15:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXuS-0001wQ-00 for l2vpn@ietf.org; Wed, 18 Feb 2004 15:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXtT-0001u2-00 for l2vpn@ietf.org; Wed, 18 Feb 2004 15:02:03 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AtXsj-0001qA-00; Wed, 18 Feb 2004 15:01:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2004 12:00:46 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1IK0h0K026461; Wed, 18 Feb 2004 15:00:44 -0500 (EST) Received: from cisco.com (rtp-vpn3-316.cisco.com [10.82.217.62]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXB71847; Wed, 18 Feb 2004 12:00:41 -0800 (PST) Message-ID: <4033C468.8090803@cisco.com> Date: Wed, 18 Feb 2004 21:00:40 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ross Callon CC: l3vpn@ietf.org, l2vpn@ietf.org Subject: Re: End of Last Call (Re: last call on terminology draft) References: <4.3.2.20040216154230.040f9080@zircon.juniper.net> In-Reply-To: <4.3.2.20040216154230.040f9080@zircon.juniper.net> 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 Did we ever decide on the best single term for: RFC 2547-Style VPNs, or BGP/MPLS VPNs, or MPLS/BGP VPNs, or ...some other term? Thanks, - Mark Ross Callon wrote: > At 01:56 PM 1/20/2004 -0800, Rick Wilder wrote: > > >>This begins a 2-week last-call period for . >> >>Please let the list hear any remaining comments on this document. >> >>Rick > > > The VPN Terminology Draft, , > has now successfully completed last call. > > Ross > > > From exim@www1.ietf.org Wed Feb 18 20:05: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 UAA05086 for ; Wed, 18 Feb 2004 20:05: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 1AtccP-0000lz-2o for l2vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 20:04:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J14jN0002970 for l2vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 20:04:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtccO-0000lp-Uu for l2vpn-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 20:04: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 UAA05070 for ; Wed, 18 Feb 2004 20:04:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtccN-0006Ox-00 for l2vpn-web-archive@ietf.org; Wed, 18 Feb 2004 20:04:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtcbU-0006Ml-00 for l2vpn-web-archive@ietf.org; Wed, 18 Feb 2004 20:03:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atcal-0006L5-00 for l2vpn-web-archive@ietf.org; Wed, 18 Feb 2004 20:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atcaj-0000d0-Q6; Wed, 18 Feb 2004 20:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtcaP-0000cT-VR for l2vpn@optimus.ietf.org; Wed, 18 Feb 2004 20:02: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 UAA05032 for ; Wed, 18 Feb 2004 20:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtcaO-0006Je-00 for l2vpn@ietf.org; Wed, 18 Feb 2004 20:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtcZP-0006H8-00 for l2vpn@ietf.org; Wed, 18 Feb 2004 20:01:40 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AtcYV-0006EN-00; Wed, 18 Feb 2004 20:00:43 -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 i1J10Dl38565; Wed, 18 Feb 2004 17:00:13 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp045.static.jnpr.net [172.24.253.45]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1J107o50002; Wed, 18 Feb 2004 17:00:07 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040218195003.0328f160@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 18 Feb 2004 19:59:06 -0500 To: "W. Mark Townsley" From: Ross Callon Subject: Re: End of Last Call (Re: last call on terminology draft) Cc: l3vpn@ietf.org, l2vpn@ietf.org In-Reply-To: <4033C468.8090803@cisco.com> References: <4.3.2.20040216154230.040f9080@zircon.juniper.net> <4.3.2.20040216154230.040f9080@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 At 09:00 PM 2/18/2004 +0100, W. Mark Townsley wrote: >Did we ever decide on the best single term for: > >RFC 2547-Style VPNs, or >BGP/MPLS VPNs, or >MPLS/BGP VPNs, or Good question. I agree that we should have one term. with my "participant only" hat on: As I pointed out in my earlier email today (to L3vpn only regarding the MIB for BGP/MPLS VPNs) I don't like the term "RFC2547-style VPNs" because I expect that eventually a derivative of the current documents for this approach will be published as RFCs, and the number will be something other than 2547. Between the other two terms, I don't care. However, doing a quick survey (which I did a while ago), it looked to me that the term "BGP/MPLS VPNs" is used more often than "MPLS/BGP VPNs". Thus it would be easier to put the BGP first (fewer places to fix). Finally, if we are talking about layer 3 VPNs, it might be the most precise to put this as: BGP/MPLS L3 VPNs Just my opinion. thanks, Ross From exim@www1.ietf.org Fri Feb 20 00:53: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 AAA19233 for ; Fri, 20 Feb 2004 00:53: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 1Au3ag-0005Up-VG for l2vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 00:52:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5qk1Y021121 for l2vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 00:52:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3ag-0005Ua-Qe for l2vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 00:52: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 AAA19229 for ; Fri, 20 Feb 2004 00:52:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3ae-0004lN-00 for l2vpn-web-archive@ietf.org; Fri, 20 Feb 2004 00:52:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3Zo-0004ij-00 for l2vpn-web-archive@ietf.org; Fri, 20 Feb 2004 00:51:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au3Z3-0004fq-00 for l2vpn-web-archive@ietf.org; Fri, 20 Feb 2004 00:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3Z1-0005Of-79; Fri, 20 Feb 2004 00:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3Ye-0005Np-3W for l2vpn@optimus.ietf.org; Fri, 20 Feb 2004 00:50: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 AAA19186 for ; Fri, 20 Feb 2004 00:50:36 -0500 (EST) From: h-owashi@jcom.home.ne.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3Yb-0004eW-00 for l2vpn@ietf.org; Fri, 20 Feb 2004 00:50:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3Xe-0004cV-00 for l2vpn@ietf.org; Fri, 20 Feb 2004 00:49:39 -0500 Received: from femail23.im.home.ne.jp ([203.165.11.238]) by ietf-mx with esmtp (Exim 4.12) id 1Au3X8-0004aG-00 for l2vpn@ietf.org; Fri, 20 Feb 2004 00:49:06 -0500 Received: by femail23.im.home.ne.jp with ESMTP id <20040220054905.FNEF1948.femail23.im.home.ne.jp@smtp201.mf.home.ne.jp> for ; Fri, 20 Feb 2004 14:49:05 +0900 Received: from cj3119832-a (203-165-179-231.home.ne.jp [203.165.179.231]) by smtp201.mf.home.ne.jp (s23091800) with SMTP id i1K5n45S015619 for ; Fri, 20 Feb 2004 14:49:04 +0900 (JST) To: l2vpn@ietf.org Subject: Question about BGP NLRI of draft-ietf-l2vpn-vpls-bgp-01.txt Message-Id: <20040220144904h-owashi@h-owashi.jcom.home.ne.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.09A] ID:1D0043 Date: Fri, 20 Feb 2004 14:49:03 +0900 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dr.Kompella , Dr.Rekhter and all. I have some questions about draft-ietf-l2vpn-vpls-bgp-01.txt. In "BGP NLRI for VPLS Information (Section 3.2.1 Figure 2)", there are a new term "VE Block Size", which was not in the expired draft-ietf-l2vpn-vpls-bgp-00.txt. draft-ietf-l2vpn-vpls-bgp-01.txt Figure 2: BGP NLRI for VPLS Information +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | VE Block Offset (2 octets) | +------------------------------------+ | VE Block Size (2 octets) | <<== +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ draft-ietf-l2vpn-vpls-bgp-00.txt Figure 2: BGP NLRI for VPLS Information +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | Label-block Offset (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ | Variable TLVs (0 to N octets) | | ... | +------------------------------------+ But the new document did not describe "VE Block Size". What does "VE Block Size" mean? And what is a difference of "VE Block Size" and "VE Block Offset"? Why is "Block Size" necessary as well as "Block Offset"? How are "Size" and "Offset" used in the NLRI or BGP message? With best regards, Owashi h-owashi@jcom.home.ne.jp From exim@www1.ietf.org Fri Feb 20 11:12:31 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 LAA00198 for ; Fri, 20 Feb 2004 11:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDFz-0005MH-KI for l2vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 11:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KGC3ix020591 for l2vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 11:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDFz-0005M2-CW for l2vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 11:12: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 LAA00169 for ; Fri, 20 Feb 2004 11:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDFy-0004ny-00 for l2vpn-web-archive@ietf.org; Fri, 20 Feb 2004 11:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDEz-0004jr-00 for l2vpn-web-archive@ietf.org; Fri, 20 Feb 2004 11:11:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuDE7-0004gY-00 for l2vpn-web-archive@ietf.org; Fri, 20 Feb 2004 11:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDE0-00052V-FW; Fri, 20 Feb 2004 11:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDDE-0004yg-Lh for l2vpn@optimus.ietf.org; Fri, 20 Feb 2004 11:09: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 LAA00067 for ; Fri, 20 Feb 2004 11:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDDB-0004bw-00 for l2vpn@ietf.org; Fri, 20 Feb 2004 11:09:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDCK-0004Y6-00 for l2vpn@ietf.org; Fri, 20 Feb 2004 11:08:16 -0500 Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx with esmtp (Exim 4.12) id 1AuDBj-0004Sl-00 for l2vpn@ietf.org; Fri, 20 Feb 2004 11:07:39 -0500 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 3B9E537E5C; Fri, 20 Feb 2004 17:07:08 +0100 (CET) Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 242F537E5B; Fri, 20 Feb 2004 17:07:08 +0100 (CET) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with ESMTP id i1KG749n023880; Fri, 20 Feb 2004 17:07:07 +0100 (CET) Message-ID: <4036309B.1020007@pi.se> Date: Fri, 20 Feb 2004 17:06:51 +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: "W. Mark Townsley" Cc: Ross Callon , l3vpn@ietf.org, l2vpn@ietf.org Subject: Re: End of Last Call (Re: last call on terminology draft) References: <4.3.2.20040216154230.040f9080@zircon.juniper.net> <4033C468.8090803@cisco.com> In-Reply-To: <4033C468.8090803@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, the current 2547bis draft says "BGP/MPLS IP VPNs", I suggest that we use that term, will work it into the terminology draft. /Loa W. Mark Townsley wrote: > > Did we ever decide on the best single term for: > > RFC 2547-Style VPNs, or > BGP/MPLS VPNs, or > MPLS/BGP VPNs, or > > ...some other term? > > Thanks, > > - Mark > > Ross Callon wrote: > >> At 01:56 PM 1/20/2004 -0800, Rick Wilder wrote: >> >> >>> This begins a 2-week last-call period for >>> . >>> >>> Please let the list hear any remaining comments on this document. >>> >>> Rick >> >> >> >> The VPN Terminology Draft, , >> has now successfully completed last call. >> Ross >> >> >> > > > > -- Loa Andersson mobile +46 739 81 21 64 From exim@www1.ietf.org Sat Feb 21 13:51: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 NAA10249 for ; Sat, 21 Feb 2004 13:51: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 1AucDE-0007xs-IE for l2vpn-archive@odin.ietf.org; Sat, 21 Feb 2004 13:50:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LIoqHG030610 for l2vpn-archive@odin.ietf.org; Sat, 21 Feb 2004 13:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AucDE-0007xd-B7 for l2vpn-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 13:50:52 -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 NAA10244 for ; Sat, 21 Feb 2004 13:50:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AucDC-0007Gl-00 for l2vpn-web-archive@ietf.org; Sat, 21 Feb 2004 13:50:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AucCR-0007Ej-00 for l2vpn-web-archive@ietf.org; Sat, 21 Feb 2004 13:50:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AucBT-0007BN-00 for l2vpn-web-archive@ietf.org; Sat, 21 Feb 2004 13:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AucBQ-0007rU-P9; Sat, 21 Feb 2004 13:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AucAP-0007pD-Qz for l2vpn@optimus.ietf.org; Sat, 21 Feb 2004 13:48: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 NAA10173 for ; Sat, 21 Feb 2004 13:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AucAN-00077K-00 for l2vpn@ietf.org; Sat, 21 Feb 2004 13:47:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auc9T-00074Y-00 for l2vpn@ietf.org; Sat, 21 Feb 2004 13:46:59 -0500 Received: from av3-2-sn4.m-sp.skanova.net ([81.228.10.113]) by ietf-mx with esmtp (Exim 4.12) id 1Auc8w-00071G-00 for l2vpn@ietf.org; Sat, 21 Feb 2004 13:46:26 -0500 Received: by av3-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 3845B37EB9; Sat, 21 Feb 2004 19:45:56 +0100 (CET) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av3-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 27BED37E47 for ; Sat, 21 Feb 2004 19:45:56 +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 E0CA137E4D; Sat, 21 Feb 2004 19:45:55 +0100 (CET) Message-ID: <4037A752.9090603@pi.se> Date: Sat, 21 Feb 2004 19:45:38 +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, Vach Kompella , rick.wilder@alcatel.com Cc: Thomas Narten , Margaret Wasserman Subject: l2vpn agenda for 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 WG, a tenttive agend for the l2vpn wg has been placed at http://urax.utfors.net/~loa/l2vpn-agenda-seoul.htm kindly check that your request for agenda slots are registered. Vach, Rick and Loa -- Loa Andersson mobile +46 739 81 21 64 From exim@www1.ietf.org Fri Feb 27 10:04:11 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 KAA06219 for ; Fri, 27 Feb 2004 10:04: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 1AwjWh-00037c-My for l2vpn-archive@odin.ietf.org; Fri, 27 Feb 2004 10:03:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RF3hmm011920 for l2vpn-archive@odin.ietf.org; Fri, 27 Feb 2004 10:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwjWg-00035T-0L for l2vpn-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 10:03: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 KAA06208 for ; Fri, 27 Feb 2004 10:03:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwjWe-0001SV-00 for l2vpn-web-archive@ietf.org; Fri, 27 Feb 2004 10:03:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwjVo-0001LH-00 for l2vpn-web-archive@ietf.org; Fri, 27 Feb 2004 10:02:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwjV7-0001D1-00 for l2vpn-web-archive@ietf.org; Fri, 27 Feb 2004 10:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwjV3-0001kq-8d; Fri, 27 Feb 2004 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwjUR-0001N8-SD for l2vpn@optimus.ietf.org; Fri, 27 Feb 2004 10:01:23 -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 KAA06115 for ; Fri, 27 Feb 2004 10:01:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwjUP-00019F-00 for l2vpn@ietf.org; Fri, 27 Feb 2004 10:01:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwjTV-000122-00 for l2vpn@ietf.org; Fri, 27 Feb 2004 10:00:25 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AwjSj-0000r0-00 for l2vpn@ietf.org; Fri, 27 Feb 2004 09:59:37 -0500 Received: from ma8117exch002u.wins.lucent.com (h152-148-8-136.lucent.com [152.148.8.136]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1REx3A24134 for ; Fri, 27 Feb 2004 08:59:04 -0600 (CST) Received: by ma8117exch002u.inse.lucent.com with Internet Mail Service (5.5.2657.72) id <15S58LTB>; Fri, 27 Feb 2004 09:59:03 -0500 Message-ID: <4F9DBE266768DC46A1F17E875D371641042B043A@ma8117exch002u.inse.lucent.com> From: "Hunt, Douglas H (Douglas)" To: l2vpn@ietf.org Cc: "Hunt, Douglas H (Douglas)" Subject: Comments on draft-aissaoui-l2vpn-vpws-iw-oam-00.txt Date: Fri, 27 Feb 2004 09:59:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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 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. 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 ap! plicable 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. From exim@www1.ietf.org Sat Feb 28 08:12: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 IAA16149 for ; Sat, 28 Feb 2004 08:12: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 1Ax4GF-0003CZ-8M for l2vpn-archive@odin.ietf.org; Sat, 28 Feb 2004 08:12:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SDC7gq012303 for l2vpn-archive@odin.ietf.org; Sat, 28 Feb 2004 08:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4GE-0003CM-Ut for l2vpn-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 08:12:07 -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 IAA16146 for ; Sat, 28 Feb 2004 08:12:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4GE-0004OW-00 for l2vpn-web-archive@ietf.org; Sat, 28 Feb 2004 08:12:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4FJ-0004Jg-00 for l2vpn-web-archive@ietf.org; Sat, 28 Feb 2004 08:11:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4EL-0004ET-00 for l2vpn-web-archive@ietf.org; Sat, 28 Feb 2004 08:10:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4ED-00036h-Oe; Sat, 28 Feb 2004 08: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 1Ax4DI-000363-L1 for l2vpn@optimus.ietf.org; Sat, 28 Feb 2004 08:09: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 IAA16112 for ; Sat, 28 Feb 2004 08:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4DH-00048h-00 for l2vpn@ietf.org; Sat, 28 Feb 2004 08:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4CJ-00043i-00 for l2vpn@ietf.org; Sat, 28 Feb 2004 08:08:04 -0500 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1Ax4BM-0003ys-00 for l2vpn@ietf.org; Sat, 28 Feb 2004 08:07:04 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i1SD70cL029993; Sat, 28 Feb 2004 08:07:02 -0500 (EST) Message-ID: <40409262.F53DE382@alcatel.com> Date: Sat, 28 Feb 2004 08:06:42 -0500 From: Mustapha Aissaoui Organization: Alcatel Networks Corporaton X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hunt, Douglas H (Douglas)" CC: l2vpn@ietf.org Subject: Re: Comments on draft-aissaoui-l2vpn-vpws-iw-oam-00.txt References: <4F9DBE266768DC46A1F17E875D371641042B043A@ma8117exch002u.inse.lucent.com> 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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. 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. So, one possible way out is to refer to them as "homogeneous circuit" and "heterogeneous circuit". Let me know what you think. I will also change the terminology of "homogeneous/heterogeneous VPWS model" to "homogeneous/heterogeneous circuit OAM model". > 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 ! ap! > plicable 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". 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". 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.