From l2vpn-bounces@ietf.org Sun Oct 01 12:53:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU4XM-0006Dl-2x; Sun, 01 Oct 2006 12:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU4XK-00069A-R4 for l2vpn@ietf.org; Sun, 01 Oct 2006 12:51:30 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU4XJ-00069I-GW for l2vpn@ietf.org; Sun, 01 Oct 2006 12:51:30 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 9AD236434F for ; Sun, 1 Oct 2006 10:51:18 -0600 (MDT) Message-ID: <451FF208.4040506@castlepoint.net> Date: Sun, 01 Oct 2006 10:51:20 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: multipart/mixed; boundary="------------030308010409020807040904" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [Fwd: RFC 4664 on Framework for Layer 2 Virtual Private Networks (L2VPNs)] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. --------------030308010409020807040904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Congratulations folks! This looks like the first of a series of L2VPN RFC's to be published. -shane --------------030308010409020807040904 Content-Type: message/rfc822; name*0="RFC 4664 on Framework for Layer 2 Virtual Private Networks (L2VP"; name*1="Ns)" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="RFC 4664 on Framework for Layer 2 Virtual Private Networks ("; filename*1="L2VPNs)" Return-Path: Received: from megatron.ietf.org (odin.ietf.org [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id E5831644BE for ; Sat, 30 Sep 2006 15:26:08 -0600 (MDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTmKr-0005YN-Lu; Sat, 30 Sep 2006 17:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTmKo-0005Y0-CF; Sat, 30 Sep 2006 17:25:22 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTmKn-0006Mi-0c; Sat, 30 Sep 2006 17:25:22 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k8ULPKUT009982; Sat, 30 Sep 2006 14:25:20 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k8ULPKmw009981; Sat, 30 Sep 2006 14:25:20 -0700 Date: Sat, 30 Sep 2006 14:25:20 -0700 Message-Id: <200609302125.k8ULPKmw009981@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: l2vpn@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4664 on Framework for Layer 2 Virtual Private Networks (L2VPNs) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4664 Title: Framework for Layer 2 Virtual Private Networks (L2VPNs) Author: L. Andersson, Ed., E. Rosen, Ed. Status: Informational Date: September 2006 Mailbox: loa@pi.se, erosen@cisco.com Pages: 44 Characters: 97768 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-l2-framework-05.txt URL: http://www.rfc-editor.org/rfc/rfc4664.txt This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... --------------030308010409020807040904-- From l2vpn-bounces@ietf.org Sun Oct 01 13:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU4kt-0007eP-27; Sun, 01 Oct 2006 13:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU4kr-0007bF-7R for l2vpn@ietf.org; Sun, 01 Oct 2006 13:05:29 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU4kp-0000Nn-0M for l2vpn@ietf.org; Sun, 01 Oct 2006 13:05:29 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 94E206434F for ; Sun, 1 Oct 2006 11:05:24 -0600 (MDT) Message-ID: <451FF556.5090701@castlepoint.net> Date: Sun, 01 Oct 2006 11:05:26 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: IETF 67: Preliminary L2VPN WG Agenda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org The following is the preliminary L2VPN WG meeting agenda for IETF 67 in San Diego, CA. Please let Vach or I know if there are additions or corrections to this agenda: http://l2vpn.tcb.net/meetings/ietf67/l2vpn-agenda.txt FYI, we have requested a 2-hour slot, but the preliminary IETF agenda hasn't been posted, yet. When we find out our time slot, I'll update the agenda with that info. -shane & Vach From l2vpn-bounces@ietf.org Mon Oct 02 10:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOkg-0006dC-Vi; Mon, 02 Oct 2006 10:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOkf-0006bQ-NH for l2vpn@ietf.org; Mon, 02 Oct 2006 10:26:37 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOkd-0000g4-Fx for l2vpn@ietf.org; Mon, 02 Oct 2006 10:26:37 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 19CA2642D4 for ; Mon, 2 Oct 2006 08:26:33 -0600 (MDT) Message-ID: <4521219A.2070604@castlepoint.net> Date: Mon, 02 Oct 2006 08:26:34 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: l2vpn@ietf.org References: <451FF556.5090701@castlepoint.net> In-Reply-To: <451FF556.5090701@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Re: IETF 67: Preliminary L2VPN WG Agenda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Sorry for replying to my own e-mail. See below. Shane Amante wrote: > The following is the preliminary L2VPN WG meeting agenda for IETF 67 in > San Diego, CA. Please let Vach or I know if there are additions or > corrections to this agenda: > http://l2vpn.tcb.net/meetings/ietf67/l2vpn-agenda.txt > > FYI, we have requested a 2-hour slot, but the preliminary IETF agenda > hasn't been posted, yet. When we find out our time slot, I'll update > the agenda with that info. The preliminary IETF 67 agenda has been posted and the l2vpn WG is scheduled to meet on Monday, November 6, 2006, 1300-1500. -shane From l2vpn-bounces@ietf.org Tue Oct 03 17:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUroZ-0007f6-U1; Tue, 03 Oct 2006 17:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs0y-0002KR-DM for l2vpn@ietf.org; Thu, 14 Sep 2006 10:16:28 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNs0w-0003rB-51 for l2vpn@ietf.org; Thu, 14 Sep 2006 10:16:28 -0400 Received: by wx-out-0506.google.com with SMTP id t4so3136838wxc for ; Thu, 14 Sep 2006 07:16:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:subject:date:to:x-mailer:from; b=qcPZFOGSEtHq+WK5hZpHoI+nYqVD7VQbN4Vve46yUUX8owjSUQOcM2H2JJPov2ki5Is5fVXe7P202Vn4yhs2oDr61IyOUFV8OGo+X5FNuKf6Zx/0XG+WiaR5neR3Ygh9aqm9ejN2igwQ0ur9KGjtpsGTiBKiet5M8acmNoA6FvU= Received: by 10.70.98.17 with SMTP id v17mr10908198wxb; Thu, 14 Sep 2006 07:16:25 -0700 (PDT) Received: from ?10.83.15.50? ( [64.102.254.33]) by mx.gmail.com with ESMTP id h14sm12854522wxd.2006.09.14.07.16.24; Thu, 14 Sep 2006 07:16:25 -0700 (PDT) In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280378E2F3@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C280378E2F3@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-11--452441364 Message-Id: <2F72CD7A-88F0-4528-A244-051B820BBF6F@cisco.com> Date: Thu, 14 Sep 2006 10:16:24 -0400 To: "VJ Shah" X-Mailer: Apple Mail (2.752.2) From: "Thomas D. Nadeau" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Tue, 03 Oct 2006 17:28:34 -0400 Cc: l2vpn@ietf.org, A S Kiran Koushik Subject: Re: Provisioning AC in draft-nadeau-l2vpn-vpls-mib-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --Apple-Mail-11--452441364 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Can you suggest some text that would make it clearer for you? --Tom > Tom/Kiran, > > > > I went through the document and the other referenced MIBs. It was > not clear to me how to associate attachment circuits with a VPLS > service instance. Adding some text to clarify this aspect in > section 4.4 would help. > > > > VJ > > > > --Apple-Mail-11--452441364 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Can you = suggest some text that would make it clearer for you?

--Tom

; Thu, 14 Sep 2006 07:16:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:subject:date:to:x-mailer:from; b=qcPZFOGSEtHq+WK5hZpHoI+nYqVD7VQbN4Vve46yUUX8owjSUQOcM2H2JJPov2ki5Is5fVXe7P202Vn4yhs2oDr61IyOUFV8OGo+X5FNuKf6Zx/0XG+WiaR5neR3Ygh9aqm9ejN2igwQ0ur9KGjtpsGTiBKiet5M8acmNoA6FvU= Received: by 10.70.98.17 with SMTP id v17mr10908198wxb; Thu, 14 Sep 2006 07:16:25 -0700 (PDT) Received: from ?10.83.15.50? ( [64.102.254.33]) by mx.gmail.com with ESMTP id h14sm12854522wxd.2006.09.14.07.16.24; Thu, 14 Sep 2006 07:16:25 -0700 (PDT) In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280378E2F3@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C280378E2F3@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-11--452441364 Message-Id: <2F72CD7A-88F0-4528-A244-051B820BBF6F@cisco.com> Date: Thu, 14 Sep 2006 10:16:24 -0400 To: "VJ Shah" X-Mailer: Apple Mail (2.752.2) From: "Thomas D. Nadeau" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Tue, 03 Oct 2006 17:28:34 -0400 Cc: l2vpn@ietf.org, A S Kiran Koushik Subject: Re: Provisioning AC in draft-nadeau-l2vpn-vpls-mib-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --Apple-Mail-11--452441364 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Can you suggest some text that would make it clearer for you? --Tom > Tom/Kiran, > > > > I went through the document and the other referenced MIBs. It was > not clear to me how to associate attachment circuits with a VPLS > service instance. Adding some text to clarify this aspect in > section 4.4 would help. > > > > VJ > > > > --Apple-Mail-11--452441364 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Can you = suggest some text that would make it clearer for you?

--Tom

I went through the document and the other referenced MIBs. = =A0It was not clear to me how to associate attachment circuits with a = VPLS service instance.=A0 Adding some text to clarify this aspect in = section 4.4 would help.

=A0

VJ

=A0



<= /HTML>= --Apple-Mail-11--452441364-- From l2vpn-bounces@ietf.org Tue Oct 03 17:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUroa-0007fM-9y; Tue, 03 Oct 2006 17:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs6Y-0003wI-1N for l2vpn@ietf.org; Thu, 14 Sep 2006 10:22:14 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNs6W-0004tK-RU for l2vpn@ietf.org; Thu, 14 Sep 2006 10:22:14 -0400 Received: by wx-out-0506.google.com with SMTP id t4so3138619wxc for ; Thu, 14 Sep 2006 07:22:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:subject:date:to:x-mailer:from; b=caoARPnsxxIT+BWHz2Wg8Y9EM9Q3qoPrx7qaCFPIG9VAYS2IvUGezjtpTrj2wD5JhHfvx2N1uoZOrdHLVF1SG6xFFtNbAvWny4nrLOu8pfnU77Sdny27DAi+GcfW15sad3aIMXeddrwaHku3YPTPbQo7BQHZTTi7ZgdIj6tSylU= Received: by 10.70.37.12 with SMTP id k12mr12622862wxk; Thu, 14 Sep 2006 07:22:10 -0700 (PDT) Received: from ?10.83.15.50? ( [64.102.254.33]) by mx.gmail.com with ESMTP id h13sm12468168wxd.2006.09.14.07.22.09; Thu, 14 Sep 2006 07:22:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52261B19-FC22-44E5-A760-911DB016B136@cisco.com> Content-Transfer-Encoding: 7bit Date: Thu, 14 Sep 2006 10:22:08 -0400 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.752.2) From: "Thomas D. Nadeau" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Tue, 03 Oct 2006 17:28:34 -0400 Cc: Shane Amante , Vach Kompella , A Kiran Koushik S Subject: draft-size:10.0pt; font-family:Arial; = font-size: 13.3333px; ">

I went through the document and the other referenced MIBs. = =A0It was not clear to me how to associate attachment circuits with a = VPLS service instance.=A0 Adding some text to clarify this aspect in = section 4.4 would help.

=A0

VJ

=A0



<= /HTML>= --Apple-Mail-11--452441364-- From l2vpn-bounces@ietf.org Tue Oct 03 17:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUroa-0007fM-9y; Tue, 03 Oct 2006 17:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs6Y-0003wI-1N for l2vpn@ietf.org; Thu, 14 Sep 2006 10:22:14 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNs6W-0004tK-RU for l2vpn@ietf.org; Thu, 14 Sep 2006 10:22:14 -0400 Received: by wx-out-0506.google.com with SMTP id t4so3138619wxc for ; Thu, 14 Sep 2006 07:22:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:subject:date:to:x-mailer:from; b=caoARPnsxxIT+BWHz2Wg8Y9EM9Q3qoPrx7qaCFPIG9VAYS2IvUGezjtpTrj2wD5JhHfvx2N1uoZOrdHLVF1SG6xFFtNbAvWny4nrLOu8pfnU77Sdny27DAi+GcfW15sad3aIMXeddrwaHku3YPTPbQo7BQHZTTi7ZgdIj6tSylU= Received: by 10.70.37.12 with SMTP id k12mr12622862wxk; Thu, 14 Sep 2006 07:22:10 -0700 (PDT) Received: from ?10.83.15.50? ( [64.102.254.33]) by mx.gmail.com with ESMTP id h13sm12468168wxd.2006.09.14.07.22.09; Thu, 14 Sep 2006 07:22:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52261B19-FC22-44E5-A760-911DB016B136@cisco.com> Content-Transfer-Encoding: 7bit Date: Thu, 14 Sep 2006 10:22:08 -0400 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.752.2) From: "Thomas D. Nadeau" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Tue, 03 Oct 2006 17:28:34 -0400 Cc: Shane Amante , Vach Kompella , A Kiran Koushik S Subject: draft-nadeau-l2vpn-vpls-mib-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org L2VPN WG, Kiran and I have worked hard to try to incorporate all of the comments brought by the WG after we presented the draft. Many objected to the document being accepted as a WG draft until these things were incorporated. Now that most of these comments have been added, we would like to again ask that the document be accepted as a L2 VPN WG draft. --Tom nadeau-l2vpn-vpls-mib-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org L2VPN WG, Kiran and I have worked hard to try to incorporate all of the comments brought by the WG after we presented the draft. Many objected to the document being accepted as a WG draft until these things were incorporated. Now that most of these comments have been added, we would like to again ask that the document be accepted as a L2 VPN WG draft. --Tom From l2vpn-bounces@ietf.org Tue Oct 03 17:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUroa-0007fq-KZ; Tue, 03 Oct 2006 17:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS87L-00054G-Ig; Tue, 26 Sep 2006 04:16:39 -0400 Received: from [69.3.57.5] (helo=mailserver.corp.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS87L-0003Mu-5u; Tue, 26 Sep 2006 04:16:39 -0400 Received: from chmailsrv.int.mrv.com ([192.168.11.19]) by mailserver.corp.int.mrv.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TTHP10M4; Tue, 26 Sep 2006 01:16:37 -0700 Received: from zeus.yok.int.mrv.com ([172.21.9.11]) by chmailsrv.int.mrv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 01:16:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E143.60C5C9D2" Date: Tue, 26 Sep 2006 11:11:32 +0300 Message-ID: <685D66DF6DB563459D23ECD8B30C73A40CD3F1@zeus.yok.int.mrv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s Thread-Index: AcbhQ2C0b+kGgpGHTcK7Xfpa7iFlsA== From: "Asaf Henig" To: , , X-OriginalArrivalTime: 26 Sep 2006 08:16:37.0522 (UTC) FILETIME=[16534720:01C6E144] X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Tue, 03 Oct 2006 17:28:34 -0400 Cc: Subject: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E143.60C5C9D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is yet unclear from draft = http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who = is responsible to send the MAC Withdrawal message to the secondary PE-rs = when fail-over occures in an H-VPLS dual homed MTU-s scenario.=20 It is known that when a primary VC fails in a dual-homing scenario the = PE-rs connected to the secondary VC should relearn the MAC addresses = behind the MTU-s. In order to make this process faster this "secondary" = PE-rs should flush the relevant previously learned MAC addresses. For = that to happen we have two options: =20 A) The primary PE-rs would send the MAC Withdrawal message to the = secondary PE-rs (and all other PE-s) the minute it recognizes that its = VC has failed.=20 B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs = the minute it switches from primary to secondary VC. The secondary PE-rs = would be responsible to propegate this message to all other PEs in the = VPLS domain (this option is recommended by = draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). Which option is preferred ?=20 Thanks for any help. =20 Asaf Henig MRV communications ------_=_NextPart_001_01C6E143.60C5C9D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s =

It is yet unclear from draft http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt= who is responsible to send the MAC Withdrawal message to the = secondary PE-rs when fail-over occures in an H-VPLS dual homed MTU-s = scenario.

It is known that when a primary VC fails in a dual-homing scenario the = PE-rs connected to the secondary VC should relearn the MAC addresses = behind the MTU-s. In order to make this process faster this = "secondary" PE-rs should flush the relevant previously learned = MAC addresses. For that to happen we have two options:
  
A) The primary PE-rs would send the MAC Withdrawal message to the = secondary PE-rs (and all other PE-s) the minute it recognizes that its = VC has failed.
B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs = the minute it switches from primary to secondary VC. The secondary PE-rs = would be responsible to propegate this message to all other PEs in the = VPLS domain (this option is recommended by = draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt).

Which option is preferred  ?


Thanks for any help.  
Asaf Henig
MRV communications

------_=_NextPart_001_01C6E143.60C5C9D2-- From l2vpn-bounces@ietf.org Tue Oct 03 17:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrob-0007g8-0T; Tue, 03 Oct 2006 17:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrQE-0005Zz-SL; Tue, 03 Oct 2006 17:03:26 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUrQC-0004bW-3c; Tue, 03 Oct 2006 17:03:26 -0400 X-VirusChecked: Checked X-Env-Sender: yuming@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1159909399!12495253!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17694 invoked from network); 3 Oct 2006 21:03:19 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 3 Oct 2006 21:03:19 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k93KvLaG001924; Tue, 3 Oct 2006 16:57:24 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k93KvBXu001840; Tue, 3 Oct 2006 16:57:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E72F.43ACA315" Date: Tue, 3 Oct 2006 15:58:52 -0500 Message-ID: <98F5A4AA6881F445B44BB83EC09BE1830AA681F2@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A proposal about maximizing VPN service availability thread-index: AcbnLrsl1lLfV0gSTIKKc3CJMqALyQ== From: "Huang, Yuming, ALABS" To: , "Vach Kompella" , "Jari Arkko" , "Mark Townsley" , "Russ Housley" , "Alex Zinin" , , , "Rick Wilder" , "Ronald Bonica" X-Spam-Score: 0.0 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f X-Mailman-Approved-At: Tue, 03 Oct 2006 17:28:34 -0400 Cc: Subject: A proposal about maximizing VPN service availability X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E72F.43ACA315 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems to me that the current available VPN software and protocols (RFCs) are not able to handle the following situation: =20 A laptop (say with WinXP OS) has both Wifi 802.11 a/b/g and NIC (RJ-45) port. Both physical network connections are in working status, and both are talking to a router which is connected to a cable modem. A VPN client is started on the laptop. The VPN client picks RJ-45 cable physical connection (saving ip# etc.) and establishes a VPN (logical) connection to a VPN server (of certain intranet). Everything works well before the RJ-45 cable is unplugged as the laptop must be moved into another room. Although the wifi network is still connecting the laptop to the router, the VPN client stops working. On the other hand, if the RJ-45 cable is unplugged when the VPN client is started, the VPN client keeps working when the laptop moves among rooms. =20 The above sample has two physical connections on a LAN setting. Actually, average computers (desktop, laptop, notebook, etc.) nowadays have phone line (RJ-11), NIC net (RJ-45), Wifi 802.11 a/b/g, USB, Firewire (IEEE 1394), etc. which make the above sample common. =20 It's obvious that we need a VPN protocol that switches among all the physical connections on a computer (based on, say availability, speed, security level, etc.) and maintains certain security level, in order to provide maximum service availability. =20 Do we have it now? =20 If not, the following logic may help us to achieve the goal: The new VPN Client detects and monitors all the available physical connections (ip#, mac#, gateway ip#, speed, security level, etc.) on the computer the VPN runs from. The VPN Client communicates (in certain time period or based on change) with VPN server about the information using the existing encryption algorithm. The VPN client knows which physical connection it is using. If the physical connection becomes invalid and it finds (and picks if more than one) another physical connection available, then the VPN client sends a request to the VPN server via the available physical connection. The VPN sever, upon receiving the request, and does the authentication, sends back data packets to the VPN client (via new port, ip# on the computer). Given this is done quick enough, the switch is transparent to users. The VPN client may inform users about the switch. =20 On the other hand, the VPN client UI may allow users to switch among available physical connections (for fast speed, for example). =20 SAMPLE FLOW CHART:=20 - Step1. vpn client starts to run on user's PC;=20 - Step2. vpn client collects available IP#s corresponding to every physical connection;=20 - Setp3. vpn clients send data frame/packet to vpn server, including user id, pwd, token display, etc. together with the collected IP#s. Before sending out, these data are encrypted using existing encryption algorithms, for example, public/private keys.=20 - Step4. Upon authentication, negotiation about keys etc, a secure tunnel is established between user's PC and VPN server. VPN server saves all the IP#s (available on a client) sent from the client. This is the only new stuff -- all the old VPN saves/uses only ONE IP# of client PC. The tunnel is based on one (and only one) physical connection (one network interface, one ip#) on user's pc. As for which one is picked, it is determined by platform OS and VPN implementation.=20 - Setp5. User's applications based on VPN are ready to run.=20 - Setp6. If the physical connection (used by VPN) fails, VPN client knows this via many ways. Either platform OS may send out events, or VPN timeout without receiving data packets (waited by VPN). The VPN server may notice the failure too.=20 - Step7. (Similar to TCP/IP)The VPN client sends signal packet (containing say, packet# it is waiting for) to server via another still available physical connection (IP#). The signal/data is encrypted using standard VPN technologies.=20 - Step8. Upon receiving the signal, VPN server matches the VPN client IP# to the saved IP#s. Then VPN server may keep or change existing encryption parameter and send data packets to the new vpn client IP#. The IP# is the real IP# on user's PC. For VPNs that hide the real IP#, the logic applies too.=20 - Step 9. VPN client receives packets via its new (available) physical connection (new IP#).=20 =20 Given the auto switch (step6~9) is quick enough, User may not notice the physical connection failure (setp6). For all the VPNs: PPTP, L2F, L2TP, IPSec etc (both OSI level 2 (data-link layer) or 3 (network layer)), if a VPN client IP# is involved, the logic can be applied. The new VPN client and server save user's login credential, and all the ip#s corresponding to all the available connections on user's computer. When the selected connection (which is used for previous VPN connection) becomes un-available, the new VPN switches to another available connection. Basically, VPN server continues to recognizes/responds to ip packets from the same user on the same machine, regardless the IP# being used. Therefore user's application keeps working if there is at least one connection.=20 =20 =20 =20 =20 =20 =20 =20 Thanks for your attention. =20 Yuming Huang 630-810-7856 AT&T Labs =20 ------_=_NextPart_001_01C6E72F.43ACA315 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems to me that the current available VPN software = and protocols (RFCs) are not able to handle the following = situation:

 

A laptop (say with WinXP OS) has both Wifi 802.11 a/b/g and NIC (RJ-45) = port.  Both physical network = connections are in working status, and both are talking to a router which is = connected to a cable modem. A VPN client is started on the laptop. The VPN client picks = RJ-45 cable physical connection (saving ip# etc.) and establishes a VPN = (logical) connection to a VPN server (of certain intranet). Everything works well = before the RJ-45 cable is unplugged as the laptop must be moved into another = room. Although the wifi network is still connecting the laptop to the router, the VPN = client stops working. On the other hand, if the RJ-45 cable is unplugged when = the VPN client is started, the VPN client keeps working when the laptop moves = among rooms.

 

The above sample has two physical connections on a = LAN setting. Actually, average computers (desktop, laptop, notebook, etc.) = nowadays have phone line = (RJ-11), NIC net (RJ-45), Wifi 802.11 a/b/g, USB, Firewire (IEEE 1394), = etc.  which make the above sample common.

 

It’s obvious that we need a VPN protocol that = switches among all the physical connections on a computer (based on, say = availability, speed, security level, etc.) and maintains certain security level, in = order to provide maximum service availability.

 

Do we have it now?

 

If not, the following logic may help us to achieve = the goal:

The new VPN Client detects and monitors all the = available physical connections (ip#, mac#, gateway ip#, speed, security level, = etc.) on the computer the VPN runs from. The VPN Client communicates (in certain time = period or based on change) with VPN server about the information using the = existing encryption algorithm. The VPN client knows which physical connection it = is using. If the physical connection becomes invalid and it finds (and = picks if more than one) another physical connection available, then the VPN = client sends a request to the VPN server via the available physical connection. The = VPN sever, upon receiving the request, and does the authentication, sends = back data packets to the VPN client (via new port, ip# on the computer). Given = this is done quick enough, the switch is transparent to users. The VPN client = may inform users about the switch.

 

On the other hand, the VPN client UI may allow users = to switch among available physical connections (for fast speed, for = example).

 

SAMPLE FLOW CHART:

-         Step1. vpn client starts to run on user’s PC;

-         Step2. vpn client collects available IP#s corresponding to every physical = connection;

-         Setp3. vpn clients send data frame/packet to vpn server, including user id, = pwd, token display, etc. together with the collected IP#s. Before sending out, = these data are encrypted using existing encryption algorithms, for example, = public/private keys.

-         Step4. Upon authentication, negotiation about keys etc, a secure tunnel is = established between user’s PC and VPN server. VPN server saves all the IP#s (available on a client) sent from the client. This is the only new stuff = -- all the old VPN saves/uses only ONE IP# of client PC. The tunnel is based on = one (and only one) physical connection (one network interface, one ip#) on = user’s pc. As for which one is picked, it is determined by platform OS and VPN implementation.

-         Setp5. User’s applications based on VPN are ready to run. =

-         Setp6. If the physical connection (used by VPN) fails, VPN client knows this = via many ways. Either platform OS may send out events, or VPN timeout without = receiving data packets (waited by VPN). The VPN server may notice the failure too. =

-         Step7. (Similar to TCP/IP)The VPN client sends signal packet (containing say, = packet# it is waiting for) to server via another still available physical = connection (IP#). The signal/data is encrypted using standard VPN technologies. =

-         Step8. Upon receiving the signal, VPN server matches the VPN client IP# to the = saved IP#s. Then VPN server may keep or change existing encryption parameter = and send data packets to the new vpn client IP#. The IP# is the real IP# on = user's PC. For VPNs that hide the real IP#, the logic applies too. =

-         Step 9. VPN client receives packets via its new (available) physical = connection (new IP#).

 

Given the auto switch (step6~9) is quick enough, User may not notice the = physical connection failure (setp6).  For all the VPNs: PPTP, L2F, L2TP, = IPSec etc (both OSI level 2 (data-link layer) or 3 (network layer)), if a VPN = client IP# is involved, the logic can be applied. The new VPN client and server = save user's login credential, and all the ip#s corresponding to all the = available connections on user's computer. When the selected connection (which is = used for previous VPN connection) becomes un-available, the new VPN switches to = another available connection. Basically, VPN server continues to = recognizes/responds to ip packets from the same user on the same machine, regardless the IP# = being used. Therefore user's application keeps working if there is at least = one connection.

 

 

 

 

 

 

 

Thanks for your attention.

 

Yuming Huang

630-810-7856<= o:p>

AT&T Labs

 

------_=_NextPart_001_01C6E72F.43ACA315-- From l2vpn-bounces@ietf.org Wed Oct 04 08:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5TV-0002ls-Oq; Wed, 04 Oct 2006 08:03:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5TU-0002lk-Tr; Wed, 04 Oct 2006 08:03:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV5TS-00019w-6Q; Wed, 04 Oct 2006 08:03:44 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 04 Oct 2006 05:03:41 -0700 X-IronPort-AV: i="4.09,254,1157353200"; d="scan'208,217"; a="1856447290:sNHT102970462" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94C3fo7012951; Wed, 4 Oct 2006 05:03:41 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k94C3bML006551; Wed, 4 Oct 2006 05:03:37 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Oct 2006 05:03:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E7AD.1F43DB7A" Date: Wed, 4 Oct 2006 05:03:34 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB022A730C@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s Thread-Index: AcbhQ2C0b+kGgpGHTcK7Xfpa7iFlsAGaS8sw From: "Ali Sajassi \(sajassi\)" To: "Asaf Henig" , , X-OriginalArrivalTime: 04 Oct 2006 12:03:37.0274 (UTC) FILETIME=[1FA281A0:01C6E7AD] DKIM-Signature: a=rsa-sha1; q=dns; l=10514; t=1159963421; x=1160827421; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=22Ali=20Sajassi=20\(sajassi\)=22=20 |Subject:RE=3A=20Question=20regarding=20MAC=20Withdrawal=20in=20H-VPLS=20Dual-hom ed=20MTU-s=20; X=v=3Dcisco.com=3B=20h=3Dcq4r1x3EvsGu3tQE49WIjwjGpQM=3D; b=tb8leZscZP4Gi2B2rrogBGLT8KxfG3alCUlFVSMPhTPFWZ9TDfp+vG44ibwWA+CitmzxBFUu euPR9n+gbHl1FcfDTSQjWvwVUfTbrOwM+JJ6nhIyPnSdciIpiG+kKxV2; Authentication-Results: sj-dkim-8.cisco.com; header.DKIM-Signature=sajassi@cisco.com; dkim=fail ( 57 extraneous bytes; RSA-96 err: "Ali Sajassi \(sajassi\)" ; cisco.com/sjdkim8002 fail; ); header.From=sajassi@cisco.com; dkim=neutral X-Spam-Score: 0.1 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: Subject: RE: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E7AD.1F43DB7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Option (B) is the preferred one as I describe in a separate email pasted below. =20 -Ali =20 ------------ snip --------------------------------- =20 MAC flushing in vpls-ldp draft is modeled after IEEE flushing mechanism (TCN). In IEEE, when a bridge switches from failed link to the backup link, then the bridge sends out a TCN message over the newly activated link and the upstream bridge upon receiving this message, will flush all its MAC addresses (except the one received over this link) and propagates the TCN message out of its other ports (for that MSTI).=20 =20 In case of H-VPLS with u-PE dual-homing, then the following actions should be taken: =20 1) the u-PE shall initiate the MAC Withdraw message only after putting the backup link into active state and the u-PE shall send the MW message over this activated backup link. This means the u-PE shall not trigger MW upon failure detection but only upon backup link activation 2) the u-PE shall flush its own MAC address for that VPLS instance upon activation of the backup link (and NOT upon detection of the failure of its primary PW/link) 3) the n-PE shall process this message as currently described in the spec. =20 The reasons for sending MW over the activated backup link at the u-PE are: =20 1) to avoid unnecessary flooding when the u-PE is only single homed 2) to avoid unnecessary flooding when the backup link is not activate yet =20 In the next rev. of vpls-ldp draft, the above clarification should be reflected. =20 -Ali ________________________________ From: Asaf Henig [mailto:ahenig@mrv.com]=20 Sent: Tuesday, September 26, 2006 11:42 AM To: l2vpn@ietf.org; mpls@lists.ietf.org; mpls@ietf.org Subject: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s=20 =09 =09 It is yet unclear from draft http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who is responsible to send the MAC Withdrawal message to the secondary PE-rs when fail-over occures in an H-VPLS dual homed MTU-s scenario. =09 It is known that when a primary VC fails in a dual-homing scenario the PE-rs connected to the secondary VC should relearn the MAC addresses behind the MTU-s. In order to make this process faster this "secondary" PE-rs should flush the relevant previously learned MAC addresses. For that to happen we have two options: =20 A) The primary PE-rs would send the MAC Withdrawal message to the secondary PE-rs (and all other PE-s) the minute it recognizes that its VC has failed. B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs the minute it switches from primary to secondary VC. The secondary PE-rs would be responsible to propegate this message to all other PEs in the VPLS domain (this option is recommended by draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). =09 Which option is preferred ? =09 =09 Thanks for any help. =20 Asaf Henig MRV communications =09 =09 =09 =09 ------_=_NextPart_001_01C6E7AD.1F43DB7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question regarding MAC Withdrawal in H-VPLS = Dual-homed MTU-s
Option (B) is the preferred one as I = describe in a=20 separate email pasted below.
 
-Ali
 
------------ snip=20 ---------------------------------
 
MAC flushing in vpls-ldp draft is = modeled after=20 IEEE flushing mechanism (TCN). In IEEE, when a bridge switches from = failed link=20 to the backup link, then the bridge sends out a TCN message over = the newly=20 activated link and the upstream bridge upon receiving this message, will = flush=20 all its MAC addresses (except the one received over this link) and = propagates=20 the TCN message out of its other ports (for that MSTI). =
 
In case of H-VPLS with u-PE dual-homing, then = the=20 following actions should be taken:
 
1)  the u-PE shall initiate the MAC = Withdraw=20 message only after putting the backup link into active state and = the u-PE=20 shall send the MW message over this activated = backup link. This=20 means the u-PE shall not trigger MW upon failure detection but only upon = backup=20 link activation
2) the u-PE shall flush its own MAC address = for that=20 VPLS instance upon activation of the backup link (and NOT upon = detection of=20 the failure of its primary PW/link)
3) the n-PE shall process this message as = currently=20 described in the spec.
 
The reasons for sending MW over the activated = backup link at the u-PE are:
 
1) to avoid unnecessary flooding when the = u-PE is only=20 single homed
2) to avoid unnecessary flooding when the = backup link=20 is not activate yet
 
In the next rev. of vpls-ldp draft, the above = clarification should be reflected.
 
-Ali
From: Asaf Henig = [mailto:ahenig@mrv.com]=20
Sent: Tuesday, September 26, 2006 11:42 AM
To:=20 l2vpn@ietf.org; mpls@lists.ietf.org; mpls@ietf.org
Subject: = Question=20 regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s =

It is yet unclear from draft http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt= =20 who is responsible to send the MAC Withdrawal message to the secondary = PE-rs=20 when fail-over occures in an H-VPLS dual homed MTU-s = scenario.

It is=20 known that when a primary VC fails in a dual-homing scenario the PE-rs = connected to the secondary VC should relearn the MAC addresses behind = the=20 MTU-s. In order to make this process faster this "secondary" PE-rs = should=20 flush the relevant previously learned MAC addresses. For that to = happen we=20 have two options:
  
A) The primary PE-rs would send = the MAC=20 Withdrawal message to the secondary PE-rs (and all other PE-s) the = minute it=20 recognizes that its VC has failed.
B) The MTU-s itself would send = the MAC=20 Withdrawal to the secondary PE-rs the minute it switches from primary = to=20 secondary VC. The secondary PE-rs would be responsible to propegate = this=20 message to all other PEs in the VPLS domain (this option is = recommended by=20 draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt).

Which option is=20 preferred  ?


Thanks for any help.  
Asaf=20 Henig
MRV=20 communications



------_=_NextPart_001_01C6E7AD.1F43DB7A-- From l2vpn-bounces@ietf.org Wed Oct 04 09:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV75V-0000WF-1j; Wed, 04 Oct 2006 09:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV75Q-0000Nr-2b; Wed, 04 Oct 2006 09:47:00 -0400 Received: from note-back.accton.com ([64.171.8.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV6xm-0007pT-5c; Wed, 04 Oct 2006 09:39:07 -0400 To: "Asaf Henig" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Wed, 4 Oct 2006 09:51:16 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 10/04/2006 06:39:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: l2vpn@ietf.org, mpls@ietf.org, mpls@lists.ietf.org Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQpJIHdvdWxkIHRoaW5rIChBKSwgc2luY2UgTUFDIFdpdGhkcmF3IGlzIHVzZWQgYnkgYSBtZW1i ZXIgb2YgdGhlIFZQTFMgbWVzaA0KdG8gbm90aWZ5IGl0cyBuZWlnaGJvcnMgb2YgYSBjaGFuZ2Ug aW4gdG9wb2xvZ3kgLS0gZXhjZXB0IHRoYXQgdGhlIE1XDQpzaG91bGQgYmUgc2VudCBvbmx5IGFm dGVyIHN3aXRjaGluZyBvdmVyIHRvIHRoZSBzdGFuZGJ5IFZDLiBUaGUgUEUtcnMNCnNob3VsZCBi ZSBqdXN0IGFzIGF3YXJlIG9mIHRoZSBzd2l0Y2hvdmVyIGFzIHRoZSBNVFUtcy4NCg0KVGhlIGxh cmdlciBhbWJpZ3VpdHkgaGVyZSAoaW4gbXkgb3BpbmlvbikgaXMgdGhlIGxhY2sgb2Ygc3BlY2lm aWNhdGlvbg0KYXJvdW5kIGp1c3QgaG93IEgtVlBMUyBkdWFsIGhvbWluZyB3b3JrcywgaS5lLCBo b3cgdGhlIGZhaWx1cmUgaXMgZGV0ZWN0ZWQNCmFuZCB3aGF0IHRoZSB0aW1lIGxpbWl0cyBhcmUg Zm9yIHRoYXQgZGV0ZWN0aW9uIGFuZCBzdWJzZXF1ZW50IHJlY292ZXJ5Lg0KVGhhdCBwYXJ0IGlz IGN1cnJlbnRseSBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuDQoNClJlZ2FyZHMsDQpBbmlsDQoN Cg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIkFzYWYgSGVuaWciICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgPGFoZW5pZ0BtcnYuY28gICAgICAgVG86 ICAgICA8bDJ2cG5AaWV0Zi5vcmc+LCA8bXBsc0BsaXN0cy5pZXRmLm9yZz4sIDxtcGxzQGlldGYu b3JnPiAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgbT4gICAgICAgICAgICAgICAgICAg Y2M6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU3ViamVjdDogICAgIFF1ZXN0aW9uIHJlZ2FyZGluZyBNQUMgV2l0aGRyYXdhbCBpbiBILVZQ TFMgRHVhbC1ob21lZCBNVFUtcyANCiAgICAgICAgICAgICAgICAgICAgMDkvMjYvMjAwNiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgMDQ6MTEgQU0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KSXQgaXMgeWV0IHVuY2xl YXIgZnJvbSBkcmFmdA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1sMnZwbi12cGxzLWxkcC0wOS50eHQgd2hvIGlzDQpyZXNwb25zaWJsZSB0byBzZW5kIHRo ZSBNQUMgV2l0aGRyYXdhbCBtZXNzYWdlIHRvIHRoZSBzZWNvbmRhcnkgUEUtcnMgd2hlbg0KZmFp bC1vdmVyIG9jY3VyZXMgaW4gYW4gSC1WUExTIGR1YWwgaG9tZWQgTVRVLXMgc2NlbmFyaW8uDQoN Ckl0IGlzIGtub3duIHRoYXQgd2hlbiBhIHByaW1hcnkgVkMgZmFpbHMgaW4gYSBkdWFsLWhvbWlu ZyBzY2VuYXJpbyB0aGUNClBFLXJzIGNvbm5lY3RlZCB0byB0aGUgc2Vjb25kYXJ5IFZDIHNob3Vs ZCByZWxlYXJuIHRoZSBNQUMgYWRkcmVzc2VzIGJlaGluZA0KdGhlIE1UVS1zLiBJbiBvcmRlciB0 byBtYWtlIHRoaXMgcHJvY2VzcyBmYXN0ZXIgdGhpcyAic2Vjb25kYXJ5IiBQRS1ycw0Kc2hvdWxk IGZsdXNoIHRoZSByZWxldmFudCBwcmV2aW91c2x5IGxlYXJuZWQgTUFDIGFkZHJlc3Nlcy4gRm9y IHRoYXQgdG8NCmhhcHBlbiB3ZSBoYXZlIHR3byBvcHRpb25zOg0KDQpBKSBUaGUgcHJpbWFyeSBQ RS1ycyB3b3VsZCBzZW5kIHRoZSBNQUMgV2l0aGRyYXdhbCBtZXNzYWdlIHRvIHRoZSBzZWNvbmRh cnkNClBFLXJzIChhbmQgYWxsIG90aGVyIFBFLXMpIHRoZSBtaW51dGUgaXQgcmVjb2duaXplcyB0 aGF0IGl0cyBWQyBoYXMgZmFpbGVkLg0KQikgVGhlIE1UVS1zIGl0c2VsZiB3b3VsZCBzZW5kIHRo ZSBNQUMgV2l0aGRyYXdhbCB0byB0aGUgc2Vjb25kYXJ5IFBFLXJzDQp0aGUgbWludXRlIGl0IHN3 aXRjaGVzIGZyb20gcHJpbWFyeSB0byBzZWNvbmRhcnkgVkMuIFRoZSBzZWNvbmRhcnkgUEUtcnMN CndvdWxkIGJlIHJlc3BvbnNpYmxlIHRvIHByb3BlZ2F0ZSB0aGlzIG1lc3NhZ2UgdG8gYWxsIG90 aGVyIFBFcyBpbiB0aGUgVlBMUw0KZG9tYWluICh0aGlzIG9wdGlvbiBpcyByZWNvbW1lbmRlZCBi eQ0KZHJhZnQtcGR1dHRhLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDAudHh0KS4NCg0KV2hpY2gg b3B0aW9uIGlzIHByZWZlcnJlZCAgPw0KDQoNClRoYW5rcyBmb3IgYW55IGhlbHAuDQpBc2FmIEhl bmlnDQpNUlYgY29tbXVuaWNhdGlvbnMNCg0KDQoNCg0K From l2vpn-bounces@ietf.org Wed Oct 04 10:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV82c-0000ti-GR; Wed, 04 Oct 2006 10:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV82b-0000lW-7Z for l2vpn@ietf.org; Wed, 04 Oct 2006 10:48:09 -0400 Received: from smtpgate1.pacific.net.sg ([203.120.90.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV82a-0005LK-Av for l2vpn@ietf.org; Wed, 04 Oct 2006 10:48:09 -0400 Received: (qmail 17631 invoked from network); 4 Oct 2006 14:48:01 -0000 Received: from adsl89.dyn105.pacific.net.sg (HELO SGSINN00117) (210.24.105.89) by smtpgate1.pacific.net.sg with SMTP; 4 Oct 2006 14:47:58 -0000 From: "Max Ng" To: , "Asaf Henig" Date: Wed, 4 Oct 2006 22:46:29 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l2vpn@ietf.org, mpls@ietf.org, mpls@lists.ietf.org Subject: RE: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org All, I do agree that the current draft should address this to avoid ambiguity especially for implementation between vendors. On another note, the mechanism used to do dual-homing is also not specified and is currently left to individual vendor implementation. Again, what I see is vendor equipment interop issue. I'm not sure if it is the jurisdiction of IETF to state implementation mechanism or leaving it to vendor innovation, but it does certainly lead to interop issues. With the draft being progressed to the current state of "proposed standard", is it too late to address both issue? Perhaps someone familiar with the process can comment. Regards, Max -----Original Message----- From: anilr@accton.com [mailto:anilr@accton.com] Sent: Wednesday, October 04, 2006 9:51 PM To: Asaf Henig Cc: l2vpn@ietf.org; mpls@ietf.org; mpls@lists.ietf.org Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s I would think (A), since MAC Withdraw is used by a member of the VPLS mesh to notify its neighbors of a change in topology -- except that the MW should be sent only after switching over to the standby VC. The PE-rs should be just as aware of the switchover as the MTU-s. The larger ambiguity here (in my opinion) is the lack of specification around just how H-VPLS dual homing works, i.e, how the failure is detected and what the time limits are for that detection and subsequent recovery. That part is currently implementation-dependent. Regards, Anil "Asaf Henig" , , m> cc: Subject: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s 09/26/2006 04:11 AM It is yet unclear from draft http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who is responsible to send the MAC Withdrawal message to the secondary PE-rs when fail-over occures in an H-VPLS dual homed MTU-s scenario. It is known that when a primary VC fails in a dual-homing scenario the PE-rs connected to the secondary VC should relearn the MAC addresses behind the MTU-s. In order to make this process faster this "secondary" PE-rs should flush the relevant previously learned MAC addresses. For that to happen we have two options: A) The primary PE-rs would send the MAC Withdrawal message to the secondary PE-rs (and all other PE-s) the minute it recognizes that its VC has failed. B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs the minute it switches from primary to secondary VC. The secondary PE-rs would be responsible to propegate this message to all other PEs in the VPLS domain (this option is recommended by draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). Which option is preferred ? Thanks for any help. Asaf Henig MRV communications From l2vpn-bounces@ietf.org Wed Oct 04 12:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9Zj-0000IJ-7J; Wed, 04 Oct 2006 12:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9Zh-00009J-Df for l2vpn@ietf.org; Wed, 04 Oct 2006 12:26:25 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9Zf-0008Ds-Or for l2vpn@ietf.org; Wed, 04 Oct 2006 12:26:25 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA03226; Wed, 4 Oct 2006 09:26:07 -0700 (PDT) Message-ID: <030501c6e7d1$caafae50$0300a8c0@IBMT41ML> From: "Marc Lasserre" To: "Max Ng" , , "Asaf Henig" References: Date: Wed, 4 Oct 2006 18:25:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Thanks to both Ali and Pranjal for clarifying how and when MAC withdrawal messages should be generated. I will check with the RFC editor if the draft can be updated on this topic. As far as dual homing is concerned, it is covered in section 10.2 of the draft. What is not specified is which failure detection mechanism to use since it depends on the underlying technology and/or protocols being used. An example of LDP adjacency status is given, but a variety of other mechanisms can be used (e.g. STP, BFD, 802.1ag, etc) and hence are left out of scope. Cheers, Marc ----- Original Message ----- From: "Max Ng" To: ; "Asaf Henig" Cc: ; ; Sent: Wednesday, October 04, 2006 4:46 PM Subject: RE: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s > All, > > I do agree that the current draft should address this to avoid ambiguity > especially for implementation between vendors. > > On another note, the mechanism used to do dual-homing is also not > specified > and is currently left to individual vendor implementation. Again, what I > see > is vendor equipment interop issue. I'm not sure if it is the jurisdiction > of > IETF to state implementation mechanism or leaving it to vendor innovation, > but it does certainly lead to interop issues. > > With the draft being progressed to the current state of "proposed > standard", > is it too late to address both issue? Perhaps someone familiar with the > process can comment. > > Regards, > Max > > -----Original Message----- > From: anilr@accton.com [mailto:anilr@accton.com] > Sent: Wednesday, October 04, 2006 9:51 PM > To: Asaf Henig > Cc: l2vpn@ietf.org; mpls@ietf.org; mpls@lists.ietf.org > Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s > > > > I would think (A), since MAC Withdraw is used by a member of the VPLS mesh > to notify its neighbors of a change in topology -- except that the MW > should be sent only after switching over to the standby VC. The PE-rs > should be just as aware of the switchover as the MTU-s. > > The larger ambiguity here (in my opinion) is the lack of specification > around just how H-VPLS dual homing works, i.e, how the failure is detected > and what the time limits are for that detection and subsequent recovery. > That part is currently implementation-dependent. > > Regards, > Anil > > > > > > "Asaf Henig" > , > , > m> cc: > Subject: Question regarding > MAC > Withdrawal in H-VPLS Dual-homed MTU-s > 09/26/2006 > 04:11 AM > > > > > > > It is yet unclear from draft > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who > is > responsible to send the MAC Withdrawal message to the secondary PE-rs when > fail-over occures in an H-VPLS dual homed MTU-s scenario. > > It is known that when a primary VC fails in a dual-homing scenario the > PE-rs connected to the secondary VC should relearn the MAC addresses > behind > the MTU-s. In order to make this process faster this "secondary" PE-rs > should flush the relevant previously learned MAC addresses. For that to > happen we have two options: > > A) The primary PE-rs would send the MAC Withdrawal message to the > secondary > PE-rs (and all other PE-s) the minute it recognizes that its VC has > failed. > B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs > the minute it switches from primary to secondary VC. The secondary PE-rs > would be responsible to propegate this message to all other PEs in the > VPLS > domain (this option is recommended by > draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). > > Which option is preferred ? > > > Thanks for any help. > Asaf Henig > MRV communications > > > > > > > > From l2vpn-bounces@ietf.org Wed Oct 04 12:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9dP-0003k7-Qb; Wed, 04 Oct 2006 12:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9dO-0003k2-6c for l2vpn@ietf.org; Wed, 04 Oct 2006 12:30:14 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9dM-000162-QD for l2vpn@ietf.org; Wed, 04 Oct 2006 12:30:14 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA03459; Wed, 4 Oct 2006 09:30:09 -0700 (PDT) Message-ID: <032901c6e7d2$5b3eab60$0300a8c0@IBMT41ML> From: "Marc Lasserre" To: "Asaf Henig" , References: Date: Wed, 4 Oct 2006 18:30:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org It is option B as already mentioned by Ali and Pranjal. See my answer in my previous email regarding dual homing & failure detection. Cheers, Marc ----- Original Message ----- From: To: "Asaf Henig" Cc: ; ; Sent: Wednesday, October 04, 2006 3:51 PM Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s > > I would think (A), since MAC Withdraw is used by a member of the VPLS mesh > to notify its neighbors of a change in topology -- except that the MW > should be sent only after switching over to the standby VC. The PE-rs > should be just as aware of the switchover as the MTU-s. > > The larger ambiguity here (in my opinion) is the lack of specification > around just how H-VPLS dual homing works, i.e, how the failure is detected > and what the time limits are for that detection and subsequent recovery. > That part is currently implementation-dependent. > > Regards, > Anil > > > > > > "Asaf Henig" > , > , > m> cc: > Subject: Question regarding > MAC Withdrawal in H-VPLS Dual-homed MTU-s > 09/26/2006 > 04:11 AM > > > > > > > It is yet unclear from draft > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who > is > responsible to send the MAC Withdrawal message to the secondary PE-rs when > fail-over occures in an H-VPLS dual homed MTU-s scenario. > > It is known that when a primary VC fails in a dual-homing scenario the > PE-rs connected to the secondary VC should relearn the MAC addresses > behind > the MTU-s. In order to make this process faster this "secondary" PE-rs > should flush the relevant previously learned MAC addresses. For that to > happen we have two options: > > A) The primary PE-rs would send the MAC Withdrawal message to the > secondary > PE-rs (and all other PE-s) the minute it recognizes that its VC has > failed. > B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs > the minute it switches from primary to secondary VC. The secondary PE-rs > would be responsible to propegate this message to all other PEs in the > VPLS > domain (this option is recommended by > draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). > > Which option is preferred ? > > > Thanks for any help. > Asaf Henig > MRV communications > > > > > From l2vpn-bounces@ietf.org Wed Oct 04 13:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAwU-0002t9-My; Wed, 04 Oct 2006 13:54:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAwT-0002t3-H9 for l2vpn@ietf.org; Wed, 04 Oct 2006 13:54:01 -0400 Received: from note-back.accton.com ([64.171.8.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVAwR-0008S8-Ve for l2vpn@ietf.org; Wed, 04 Oct 2006 13:54:01 -0400 To: "Marc Lasserre" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Wed, 4 Oct 2006 14:06:08 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 10/04/2006 10:54:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQo+IEl0IGlzIG9wdGlvbiBCIGFzIGFscmVhZHkgbWVudGlvbmVkIGJ5IEFsaSBhbmQgUHJhbmph bC4NCg0KQXMgYWxyZWFkeSBleHBsYWluZWQgYnkgQXNhZiBhbmQgSSwgdGhhdCBtYXkgbm90IGJl IHRoZSBjb3JyZWN0IG9wdGlvbi4NCg0KPiBTZWUgbXkgYW5zd2VyIGluIG15IHByZXZpb3VzIGVt YWlsIHJlZ2FyZGluZyBkdWFsIGhvbWluZw0KPiAmIGZhaWx1cmUgZGV0ZWN0aW9uLg0KDQpZb3Vy IGFuc3dlciBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZXMgcmFpc2VkIGJ5IE1heCBhbmQgSS4g UGxlYXNlIHNlZQ0KdGhvc2UgZW1haWxzIGFnYWluIGFuZCB0cnkgdG8gYWRkcmVzcyBlYWNoIHRl Y2huaWNhbCBpc3N1ZSBhbmQgcG9pbnQNCnJhaXNlZC4NCg0KVGhpcyBiZWluZyBhbiBJRVRGIHdv cmtpbmcgZ3JvdXAsIHdlIGNvbGxlY3RpdmVseSBtYWtlIGRlY2lzaW9ucyBiYXNlZCBvbg0KY29u c2Vuc3VzIG9mIHdvcmtpbmcgZ3JvdXAgbWVtYmVycy4gVGhlIHdyaXRlcnMgZG9uJ3QgZ2V0IHRv IG1ha2UgYXJiaXRyYXJ5DQpjYWxscyB3aXRob3V0IHRlY2huaWNhbCBkaXNjdXNzaW9uIGFuZCBh Z3JlZW1lbnQgd2l0aCBvdGhlciBtZW1iZXJzIGFuZA0KdmVuZG9ycyBiYXNlZCBvbiB0aGVpciBl eHBlcmllbmNlLg0KDQpUaGFua3MsDQpBbmlsDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICJNYXJjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgIExhc3NlcnJlIiAgICAgICAgICAgIFRvOiAgICAgIkFzYWYgSGVuaWciIDxhaGVuaWdAbXJ2 LmNvbT4sIDxhbmlsckBhY2N0b24uY29tPiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgIDxtYXJjQHJpdmVyc3RvICAgICAgIGNjOiAgICAgPGwydnBuQGlldGYub3JnPiwgIkFs aSBTYWphc3NpIFwoc2FqYXNzaVwpIiA8c2FqYXNzaUBjaXNjby5jb20+LCAgDQogICAgICAgICAg ICAgICAgICAgIG5lbmV0LmNvbT4gICAgICAgICAgICAiRHV0dGEsIFByYW5qYWwiIDxwZHV0dGFA cml2ZXJzdG9uZW5ldC5jb20+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1YmplY3Q6ICAgICBSZTogUXVlc3Rp b24gcmVnYXJkaW5nIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyBEdWFsLWhvbWVkICAgDQogICAg ICAgICAgICAgICAgICAgIDEwLzA0LzIwMDYgICAgICAgICAgICBNVFUtcyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgIDEyOjMwIFBNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KDQoNCkl0IGlzIG9wdGlvbiBCIGFzIGFscmVhZHkgbWVudGlvbmVkIGJ5IEFs aSBhbmQgUHJhbmphbC4NClNlZSBteSBhbnN3ZXIgaW4gbXkgcHJldmlvdXMgZW1haWwgcmVnYXJk aW5nIGR1YWwgaG9taW5nICYgZmFpbHVyZQ0KZGV0ZWN0aW9uLg0KDQpDaGVlcnMsDQoNCk1hcmMN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IDxhbmlsckBhY2N0b24uY29tPg0K VG86ICJBc2FmIEhlbmlnIiA8YWhlbmlnQG1ydi5jb20+DQpDYzogPGwydnBuQGlldGYub3JnPjsg PG1wbHNAaWV0Zi5vcmc+OyA8bXBsc0BsaXN0cy5pZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwg T2N0b2JlciAwNCwgMjAwNiAzOjUxIFBNDQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gcmVnYXJkaW5n IE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyBEdWFsLWhvbWVkIE1UVS1zDQoNCg0KPg0KPiBJIHdv dWxkIHRoaW5rIChBKSwgc2luY2UgTUFDIFdpdGhkcmF3IGlzIHVzZWQgYnkgYSBtZW1iZXIgb2Yg dGhlIFZQTFMNCm1lc2gNCj4gdG8gbm90aWZ5IGl0cyBuZWlnaGJvcnMgb2YgYSBjaGFuZ2UgaW4g dG9wb2xvZ3kgLS0gZXhjZXB0IHRoYXQgdGhlIE1XDQo+IHNob3VsZCBiZSBzZW50IG9ubHkgYWZ0 ZXIgc3dpdGNoaW5nIG92ZXIgdG8gdGhlIHN0YW5kYnkgVkMuIFRoZSBQRS1ycw0KPiBzaG91bGQg YmUganVzdCBhcyBhd2FyZSBvZiB0aGUgc3dpdGNob3ZlciBhcyB0aGUgTVRVLXMuDQo+DQo+IFRo ZSBsYXJnZXIgYW1iaWd1aXR5IGhlcmUgKGluIG15IG9waW5pb24pIGlzIHRoZSBsYWNrIG9mIHNw ZWNpZmljYXRpb24NCj4gYXJvdW5kIGp1c3QgaG93IEgtVlBMUyBkdWFsIGhvbWluZyB3b3Jrcywg aS5lLCBob3cgdGhlIGZhaWx1cmUgaXMNCmRldGVjdGVkDQo+IGFuZCB3aGF0IHRoZSB0aW1lIGxp bWl0cyBhcmUgZm9yIHRoYXQgZGV0ZWN0aW9uIGFuZCBzdWJzZXF1ZW50IHJlY292ZXJ5Lg0KPiBU aGF0IHBhcnQgaXMgY3VycmVudGx5IGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4NCj4NCj4gUmVn YXJkcywNCj4gQW5pbA0KPg0KPg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIkFzYWYg SGVuaWciDQo+ICAgICAgICAgICAgICAgICAgICA8YWhlbmlnQG1ydi5jbyAgICAgICBUbzogICAg IDxsMnZwbkBpZXRmLm9yZz4sDQo+IDxtcGxzQGxpc3RzLmlldGYub3JnPiwgPG1wbHNAaWV0Zi5v cmc+DQo+ICAgICAgICAgICAgICAgICAgICBtPiAgICAgICAgICAgICAgICAgICBjYzoNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1YmplY3Q6ICAgICBRdWVzdGlv biByZWdhcmRpbmcNCj4gTUFDIFdpdGhkcmF3YWwgaW4gSC1WUExTIER1YWwtaG9tZWQgTVRVLXMN Cj4gICAgICAgICAgICAgICAgICAgIDA5LzI2LzIwMDYNCj4gICAgICAgICAgICAgICAgICAgIDA0 OjExIEFNDQo+DQo+DQo+DQo+DQo+DQo+DQo+IEl0IGlzIHlldCB1bmNsZWFyIGZyb20gZHJhZnQN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sMnZwbi12 cGxzLWxkcC0wOS50eHQgd2hvDQo+IGlzDQo+IHJlc3BvbnNpYmxlIHRvIHNlbmQgdGhlIE1BQyBX aXRoZHJhd2FsIG1lc3NhZ2UgdG8gdGhlIHNlY29uZGFyeSBQRS1ycw0Kd2hlbg0KPiBmYWlsLW92 ZXIgb2NjdXJlcyBpbiBhbiBILVZQTFMgZHVhbCBob21lZCBNVFUtcyBzY2VuYXJpby4NCj4NCj4g SXQgaXMga25vd24gdGhhdCB3aGVuIGEgcHJpbWFyeSBWQyBmYWlscyBpbiBhIGR1YWwtaG9taW5n IHNjZW5hcmlvIHRoZQ0KPiBQRS1ycyBjb25uZWN0ZWQgdG8gdGhlIHNlY29uZGFyeSBWQyBzaG91 bGQgcmVsZWFybiB0aGUgTUFDIGFkZHJlc3Nlcw0KPiBiZWhpbmQNCj4gdGhlIE1UVS1zLiBJbiBv cmRlciB0byBtYWtlIHRoaXMgcHJvY2VzcyBmYXN0ZXIgdGhpcyAic2Vjb25kYXJ5IiBQRS1ycw0K PiBzaG91bGQgZmx1c2ggdGhlIHJlbGV2YW50IHByZXZpb3VzbHkgbGVhcm5lZCBNQUMgYWRkcmVz c2VzLiBGb3IgdGhhdCB0bw0KPiBoYXBwZW4gd2UgaGF2ZSB0d28gb3B0aW9uczoNCj4NCj4gQSkg VGhlIHByaW1hcnkgUEUtcnMgd291bGQgc2VuZCB0aGUgTUFDIFdpdGhkcmF3YWwgbWVzc2FnZSB0 byB0aGUNCj4gc2Vjb25kYXJ5DQo+IFBFLXJzIChhbmQgYWxsIG90aGVyIFBFLXMpIHRoZSBtaW51 dGUgaXQgcmVjb2duaXplcyB0aGF0IGl0cyBWQyBoYXMNCj4gZmFpbGVkLg0KPiBCKSBUaGUgTVRV LXMgaXRzZWxmIHdvdWxkIHNlbmQgdGhlIE1BQyBXaXRoZHJhd2FsIHRvIHRoZSBzZWNvbmRhcnkg UEUtcnMNCj4gdGhlIG1pbnV0ZSBpdCBzd2l0Y2hlcyBmcm9tIHByaW1hcnkgdG8gc2Vjb25kYXJ5 IFZDLiBUaGUgc2Vjb25kYXJ5IFBFLXJzDQo+IHdvdWxkIGJlIHJlc3BvbnNpYmxlIHRvIHByb3Bl Z2F0ZSB0aGlzIG1lc3NhZ2UgdG8gYWxsIG90aGVyIFBFcyBpbiB0aGUNCj4gVlBMUw0KPiBkb21h aW4gKHRoaXMgb3B0aW9uIGlzIHJlY29tbWVuZGVkIGJ5DQo+IGRyYWZ0LXBkdXR0YS1sMnZwbi12 cGxzLWxkcC1tYWMtb3B0LTAwLnR4dCkuDQo+DQo+IFdoaWNoIG9wdGlvbiBpcyBwcmVmZXJyZWQg ID8NCj4NCj4NCj4gVGhhbmtzIGZvciBhbnkgaGVscC4NCj4gQXNhZiBIZW5pZw0KPiBNUlYgY29t bXVuaWNhdGlvbnMNCj4NCj4NCj4NCj4NCj4NCg0KDQoNCg0K From l2vpn-bounces@ietf.org Wed Oct 04 15:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCOW-0006uK-00; Wed, 04 Oct 2006 15:27:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCOT-0006uC-Vm for l2vpn@ietf.org; Wed, 04 Oct 2006 15:27:01 -0400 Received: from note-back.accton.com ([64.171.8.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCOS-0005Ly-Hh for l2vpn@ietf.org; Wed, 04 Oct 2006 15:27:01 -0400 To: "Thomas D. Nadeau" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Wed, 4 Oct 2006 15:39:10 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 10/04/2006 12:27:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: l2vpn@ietf.org, A Kiran Koushik S , Vach Kompella , Shane Amante Subject: Re: draft-nadeau-l2vpn-vpls-mib-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQpUaG9tYXMsDQoNCkluIHJldmlld2luZyB0aGUgLTAxIGRvY3VtZW50LCBpdCBzZWVtcyBzZXZl cmFsIGNvbW1lbnRzIEkgc2VudCB0byB5b3Ugb24NCnlvdXIgaW5pdGlhbCAtMDAgcHJvcG9zYWwg YXJlIG5vdCBhZGRyZXNzZWQuDQoNCkkgaG9wZSB0aGVzZSBjYW4gYmUgYWNjb21vZGF0ZWQuIEkg YmVsaWV2ZSB5b3UgYWdyZWVkIHdpdGggbW9zdCBvZiB0aGVtDQp3aGVuIHRoZXkgd2VyZSBicm91 Z2h0IHVwIG9uIHRoaXMgbGlzdC4NCg0KVGhlIG9yaWdpbmFsIGNvbW1lbnRzIGFyZSBiZWxvdywg YWxvbmcgd2l0aCBvdGhlcnMgYWRkcmVzc2luZyBzb21lIG5ldw0Kb2JqZWN0cyB5b3UndmUgYWRk ZWQgdG8gdGhlIHVwZGF0ZWQgdmVyc2lvbjoNCg0KMS4gIHZwbHNPcGVyU3RhdHVzOiBjdXJyZW50 IHZhbHVlcyBhcmUgdW5rbm93biwgdXAgb3IgZG93bi4gUHJvcG9zZSBhZGRpbmcNCmEgdmFsdWUg J3BhcnRpYWxNZXNoJyBmb3IgdGhlIGNhc2Ugd2hlbiBvbmUgb3IgbW9yZSBQVydzIGluIHRoZSBt ZXNoIGZvcg0KdGhlIGNvcnJlc3BvbmRpbmcgVlBMUyBpbnN0YW5jZSBoYXZlIGdvbmUgZG93biBh bmQgc3RheWVkIGRvd24uIFRoaXMgZmxhZ3MNCmFuIGltcG9ydGFudCBWUExTIHN0YXRlIHRvIHRo ZSBuZXR3b3JrIG1hbmFnZXIgdG8gaGVscCBkZWJ1ZyBuZXR3b3JrDQpwcm9ibGVtcywgb24gd2hp Y2ggaGUgY2FuIG1pbmUgZnVydGhlciBpbmZvcm1hdGlvbiBmcm9tIG90aGVyIE1JQnMgb25jZSBo ZQ0Ka25vd3MgaXQgZXhpc3RzLg0KDQoyLiAgdnBsc1ZwbklkOiBUaGlzIGlzIHNob3duIGFzIHJl YWQtb25seS4gV29uJ3QgdGhlIG1hbmFnZXIgd2FudCB0bw0KY29uZmlndXJlIFZQTFMgSUQ/IElm IG5vdCBoZXJlLCB0aGVuIHdoZXJlIGFuZCBob3cgaXMgaXQgY29uZmlndXJlZD8NCg0KMy4gIHZw bHNTZXJ2aWNlVHlwZTogcHJvcG9zZWQgYWRkaXRpb24gdG8gdnBsc0NvbmZpZ1RhYmxlIHRvIGlu ZGljYXRlDQp3aGV0aGVyIHRoaXMgaXMgYSBWTEFOIG9yIEV0aGVybmV0IFZQTFMgaW5zdGFuY2Uu DQoNCjQuICB2cGxzTWVzaFBlZXJDb3VudDogcHJvcG9zZWQgYWRkaXRpb24gdG8gdnBsc1N0YXR1 c1RhYmxlIHRvIGluZGljYXRlIHRoZQ0KbnVtYmVyIG9mIE1lc2ggUGVlcnMgaW4gdGhpcyBWUExT IGluc3RhbmNlLg0KDQo1LiAgdnBsc1Nwb2tlUGVlckNvdW50OiBwcm9wb3NlZCBhZGRpdGlvbiB0 byB2cGxzU3RhdHVzVGFibGUgdG8gaW5kaWNhdGUNCnRoZSBudW1iZXIgb2YgU3Bva2UgUGVlcnMg aW4gdGhpcyBWUExTIGluc3RhbmNlLg0KDQo2LiAgdnBsc0FDQmluZFRhYmxlOiBwcm9wb3NlZCB0 YWJsZSB0byBiaW5kIEF0dGFjaG1lbnQgQ2lyY3VpdHMgdG8gYSBWUExTDQppbnN0YW5jZSAoYWRk cmVzc2VzIGEgcXVlc3Rpb24gZnJvbSBWSikNCg0KNy4gIHZwbHNNYWNMZWFybmluZywgdnBsc0Rp c2NhcmRVbmtub3duRGVzdCBhbmQgdnBsc01hY0FnaW5nOiB0aGVzZSBhcmUNCmN1cnJlbnRseSBt YW5kYXRvcnkgcmVxdWlyZW1lbnRzIGluIHRoZSBNSUIgZXZlbiB0aG91Z2ggdGhleSBhcmUgbm90 IHBhcnQNCm9mIHRoZSBzdGFuZGFyZCBpdHNlbGYuIENvdWxkIHdlIHBsZWFzZSByZW1vdmUgdGhl bSBvciBwdXQgdGhlbSBpbiBhbg0Kb3B0aW9uYWwgZ3JvdXA/DQoNCjguICB2cGxzQ29uZmlnRndk RnVsbEhpZ2hXYXRlcm1hcmssIHZwbHNDb25maWdGd2RGdWxsTG93V2F0ZXJtYXJrOiBUaGVzZQ0K b2JqZWN0cyBjYW4gbGVhZCB0byBhIHN0b3JtIG9mIFNOTVAgYWxhcm1zLCB3aGljaCBpcyBhbHNv IHdoeSB3ZSBkaWQgbm90DQpwdXQgdGhlbSBpbiB0aGUgQnJpZGdlIE1JQi4gSSB3b3VsZCBwcm9w b3NlIHJlbW92aW5nIHRoZW0gYW5kLCBpZg0KbmVjZXNzYXJ5LCBhZGQgY29ycmVzcG9uZGluZyBj b3VudGVycyBvciBldmVudHMgaW4gYW4gb3B0aW9uYWwgZ3JvdXAuDQoNCjkuICB2cGxzUHdDb25m aWdUeXBlOiBUaGVyZSBpcyBubyBhdXRvZGlzY292ZXJ5IG1ldGhvZCBzcGVjaWZpZWQgYnkgdGhl DQpWUExTIHN0YW5kYXJkLiBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoaXMgb2JqZWN0Pw0KDQox MC4gdnBsc0xkcERyYWZ0MDFNSUI6IFRoaXMgaXMgYSBuZXcgY29tcG9uZW50LiBZb3Ugc2VlbSB0 byBoYXZlIGdpdmVuIHVzIDINCk1JQnMgZm9yIHRoZSBwcmljZSBvZiAxLiBXaHkgbm90IHRocm93 IHRob3NlIG9iamVjdHMgaW50byBhIHNpbmdsZSBWUExTDQpNSUI/DQoNCjExLiB2cGxzTGRwTWFj QWRkcldpdGhkcmF3OiBXaGF0J3MgdGhlIHB1cnBvc2Ugb2YgdGhpcyBvbmU/IE1BVyBpcw0KYXBw bGljYWJsZSBvbmx5IGZvciBkdWFsIGhvbWluZywgd2hpY2ggaXMgaXRzZWxmIG9wdGlvbmFsLiBC dXQgaWYNCmR1YWwtaG9taW5nIGlzIGluZGVlZCBpbXBsZW1lbnRlZCB0aGVuIE1BVyBiZWNvbWVz IG1hbmRhdG9yeSwgc28gSSBkb24ndA0KdW5kZXJzdGFuZCB0aGUgcmVhc29uIGZvciB0aGlzIG9i amVjdC4NCg0KMTIuIHZwbHNMZHBQd0JpbmRNYWNBZGRyZXNzTGltaXQ6IFdoeSBwdXQgYSBNQUMg YWRkcmVzcyBsaW1pdCBvbiBhDQpwZXItcHNldWRvd2lyZSBiYXNpcyBpbiB0aGUgc3RhbmRhcmQg TUlCPyBUaGlzIHN1cmUgbG9va3MgbGlrZSBhbg0KaW1wbGVtZW50YXRpb24gaXNzdWUgd2hpY2gg Y291bGQgYmUgaW4gYW4gZXh0ZW5zaW9uLiBXaGF0IGRvZXMgaXQgaGF2ZSB0bw0KZG8gd2l0aCBM RFA/DQoNCjEzLiB2cGxzTGRwUHdCaW5kVHlwZTogQSB1c2VmdWwgb2JqZWN0LCBidXQgb25lIHRo YXQgb3VnaHQgdG8gYmUgaW4NCnZwbHNQd0JpbmRUeXBlLiBBIHNwb2tlIFZDIChRaW5RKSBkb2Vz IG5vdCBuZWVkIExEUCBzaWduYWxsaW5nLg0KDQpJIGNhbiBzZW5kIHlvdSB0aGUgbmVjZXNzYXJ5 IE1JQiBzeW50YXgsIG9uY2Ugd2UgYWdyZWUgb24gdGhlIGFib3ZlLg0KDQpSZWdhcmRzLA0KQW5p bA0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAiVGhvbWFzIEQuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgTmFkZWF1IiAgICAgICAgICAg ICAgIFRvOiAgICAgbDJ2cG5AaWV0Zi5vcmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIDx0aG9tYXNkbmFkZWF1 QCAgICAgICBjYzogICAgIFNoYW5lIEFtYW50ZSA8c2hhbmVAY2FzdGxlcG9pbnQubmV0PiwgVmFj aCBLb21wZWxsYSAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBnbWFpbC5jb20+ ICAgICAgICAgICAgIDx2YWNoLmtvbXBlbGxhQGFsY2F0ZWwuY29tPiwgQSBLaXJhbiBLb3VzaGlr IFMgPGtrb3VzaGlrQGNpc2NvLmNvbT4gICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFN1YmplY3Q6ICAgICBkcmFmdC1uYWRlYXUtbDJ2cG4tdnBscy1taWIt MDEudHh0ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIDA5 LzE0LzIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAxMDoyMiBBTSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0K DQoNCiAgICAgICAgICAgTDJWUE4gV0csDQoNCiAgICAgICAgICAgS2lyYW4gYW5kIEkgaGF2ZSB3 b3JrZWQgaGFyZCB0byB0cnkgdG8gaW5jb3Jwb3JhdGUNCmFsbCBvZiB0aGUgY29tbWVudHMgYnJv dWdodCBieSB0aGUgV0cgYWZ0ZXIgd2UgcHJlc2VudGVkDQp0aGUgZHJhZnQuIE1hbnkgb2JqZWN0 ZWQgdG8gdGhlIGRvY3VtZW50IGJlaW5nIGFjY2VwdGVkDQphcyBhIFdHIGRyYWZ0IHVudGlsIHRo ZXNlIHRoaW5ncyB3ZXJlIGluY29ycG9yYXRlZC4gTm93DQp0aGF0IG1vc3Qgb2YgdGhlc2UgY29t bWVudHMgaGF2ZSBiZWVuIGFkZGVkLCB3ZSB3b3VsZA0KbGlrZSB0byBhZ2FpbiBhc2sgdGhhdCB0 aGUgZG9jdW1lbnQgYmUgYWNjZXB0ZWQgYXMgYQ0KTDIgVlBOIFdHIGRyYWZ0Lg0KDQogICAgICAg ICAgIC0tVG9tDQoNCg0KDQoNCg0K From l2vpn-bounces@ietf.org Wed Oct 04 16:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDNf-0006jU-Rn; Wed, 04 Oct 2006 16:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDNe-0006jP-Hs for l2vpn@ietf.org; Wed, 04 Oct 2006 16:30:14 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDNd-000872-2a for l2vpn@ietf.org; Wed, 04 Oct 2006 16:30:14 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA26332; Wed, 4 Oct 2006 13:30:05 -0700 (PDT) Message-ID: <03f901c6e7f3$df647610$0300a8c0@IBMT41ML> From: "Marc Lasserre" To: References: Date: Wed, 4 Oct 2006 22:30:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org > >> It is option B as already mentioned by Ali and Pranjal. > > As already explained by Asaf and I, that may not be the correct option. I do not see how the primary PE-rs can be aware that the secondary PW has been made active, since the PW between the MTU-s and the primary PE-rs is no longer available and no protocol is defined to convey such information. The only option possible is for the MTU-s to trigger the MAC withdrawal towards it secondary PE-rs once the secondary PW has been made active. > >> See my answer in my previous email regarding dual homing >> & failure detection. > > Your answer does not address the issues raised by Max and I. Please see > those emails again and try to address each technical issue and point > raised. Since the MTU is responsible for activating its secondary link, it is a local decision to the MTU to decide how a failure is detected and acted upon. No new protocol for VPLS has been specified for failure detection. As I said before, the means and how fast it takes to detect failures can be based upon different mechanisms (e.g. physical loss of signal, BFD, STP, loss of IGP/LDP adjacency), each with their respective failure detection times. A similar sentence could be added to the draft if it helps. Vendors can decide to implement any of such methods and hence provide product differentiation. > > This being an IETF working group, we collectively make decisions based on > consensus of working group members. The writers don't get to make > arbitrary > calls without technical discussion and agreement with other members and > vendors based on their experience. I think that I am aware of that... First of all, I have not made any arbitrary calls. Secondly, I am open to discussing any technical matters. All the different revisions of the draft have been based on WG feedback so far. > > Thanks, > Anil > > > > > "Marc > Lasserre" To: "Asaf Henig" > , > , "Ali > Sajassi \(sajassi\)" , > nenet.com> "Dutta, Pranjal" > > Subject: Re: Question > regarding MAC Withdrawal in H-VPLS Dual-homed > 10/04/2006 MTU-s > 12:30 PM > > > > > > > It is option B as already mentioned by Ali and Pranjal. > See my answer in my previous email regarding dual homing & failure > detection. > > Cheers, > > Marc > ----- Original Message ----- > From: > To: "Asaf Henig" > Cc: ; ; > Sent: Wednesday, October 04, 2006 3:51 PM > Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s > > >> >> I would think (A), since MAC Withdraw is used by a member of the VPLS > mesh >> to notify its neighbors of a change in topology -- except that the MW >> should be sent only after switching over to the standby VC. The PE-rs >> should be just as aware of the switchover as the MTU-s. >> >> The larger ambiguity here (in my opinion) is the lack of specification >> around just how H-VPLS dual homing works, i.e, how the failure is > detected >> and what the time limits are for that detection and subsequent recovery. >> That part is currently implementation-dependent. >> >> Regards, >> Anil >> >> >> >> >> >> "Asaf Henig" >> , >> , >> m> cc: >> Subject: Question regarding >> MAC Withdrawal in H-VPLS Dual-homed MTU-s >> 09/26/2006 >> 04:11 AM >> >> >> >> >> >> >> It is yet unclear from draft >> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who >> is >> responsible to send the MAC Withdrawal message to the secondary PE-rs > when >> fail-over occures in an H-VPLS dual homed MTU-s scenario. >> >> It is known that when a primary VC fails in a dual-homing scenario the >> PE-rs connected to the secondary VC should relearn the MAC addresses >> behind >> the MTU-s. In order to make this process faster this "secondary" PE-rs >> should flush the relevant previously learned MAC addresses. For that to >> happen we have two options: >> >> A) The primary PE-rs would send the MAC Withdrawal message to the >> secondary >> PE-rs (and all other PE-s) the minute it recognizes that its VC has >> failed. >> B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs >> the minute it switches from primary to secondary VC. The secondary PE-rs >> would be responsible to propegate this message to all other PEs in the >> VPLS >> domain (this option is recommended by >> draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). >> >> Which option is preferred ? >> >> >> Thanks for any help. >> Asaf Henig >> MRV communications >> >> >> >> >> > > > > > From l2vpn-bounces@ietf.org Wed Oct 04 16:56:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDm0-0004gu-Ge; Wed, 04 Oct 2006 16:55:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDlz-0004gp-KX for l2vpn@ietf.org; Wed, 04 Oct 2006 16:55:23 -0400 Received: from note-back.accton.com ([64.171.8.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDlz-00043n-1G for l2vpn@ietf.org; Wed, 04 Oct 2006 16:55:23 -0400 To: "Marc Lasserre" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Wed, 4 Oct 2006 17:07:32 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 10/04/2006 01:55:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQpNYXJjLA0KDQo+IEkgZG8gbm90IHNlZSBob3cgdGhlIHByaW1hcnkgUEUtcnMgY2FuIGJlIGF3 YXJlIHRoYXQgdGhlIHNlY29uZGFyeSBQVyBoYXMNCg0KPiBiZWVuIG1hZGUgYWN0aXZlLCBzaW5j ZSB0aGUgUFcgYmV0d2VlbiB0aGUgTVRVLXMgYW5kIHRoZSBwcmltYXJ5IFBFLXJzIGlzDQpubw0K PiBsb25nZXIgYXZhaWxhYmxlIGFuZCBubyBwcm90b2NvbCBpcyBkZWZpbmVkIHRvIGNvbnZleSBz dWNoIGluZm9ybWF0aW9uLg0KVGhlDQo+IG9ubHkgb3B0aW9uIHBvc3NpYmxlIGlzIGZvciB0aGUg TVRVLXMgdG8gdHJpZ2dlciB0aGUgTUFDIHdpdGhkcmF3YWwNCnRvd2FyZHMNCj4gaXQgc2Vjb25k YXJ5IFBFLXJzIG9uY2UgdGhlIHNlY29uZGFyeSBQVyBoYXMgYmVlbiBtYWRlIGFjdGl2ZS4NCg0K SW4gbW9zdCBwcm90b2NvbHMgd2hpY2ggYWxsb3cgYSBzdGFuZGJ5IGxpbmssIGJvdGggc2lkZXMg b2YgdGhlIHN0YW5kYnkNCmxpbmsgYXJlIGF3YXJlIHRoYXQgaXQncyBiZWVuDQpwcmVzc2VkIGlu dG8gc2VydmljZS4gTXkgc3VnZ2VzdGlvbiB3YXMgdGhpcyBiZWluZyB0aGUgY2FzZSwgdGhlIFBF LXJzDQpuZWVkcyBubyBoZWxwIGZyb20gdGhlDQpNVFUtcyBpbiBnZW5lcmF0aW5nIGEgTUFDIFdp dGhkcmF3LiBBbHNvIGlzbid0IGl0IHBvc3NpYmxlIHRoZXJlIG1heSBiZSBubw0KUFcgYmV0d2Vl biB0aGUNCk1UVS1zIGFuZCBQRS1ycywgYXMgd2l0aCBRaW5RPyBQZXJoYXBzIHlvdSBoYXZlIGEg ZGlmZmVyZW50IHNvbHV0aW9uIGluDQptaW5kIHRoYW4gSSBkbywgYnV0IHRoYXQncw0KdGhlIHJl c3VsdCBvZiBhIHBhcnRpYWxseSBzcGVjaWZpZWQgbWVjaGFuaXNtIC0tIGl0J3MgdG91Z2ggdG8g c2VlDQpzdXBwb3J0aW5nIHByb3RvY29scyB0aGUgc2FtZQ0Kd2F5IHdpdGhvdXQgYSBzaGFyZWQg dW5kZXJzdGFuZGluZyBvZiBob3cgdGhlIHdob2xlIHRoaW5nIHdvcmtzLg0KDQo+IFNpbmNlIHRo ZSBNVFUgaXMgcmVzcG9uc2libGUgZm9yIGFjdGl2YXRpbmcgaXRzIHNlY29uZGFyeSBsaW5rLCBp dCBpcyBhDQo+IGxvY2FsIGRlY2lzaW9uIHRvIHRoZSBNVFUgdG8gZGVjaWRlIGhvdyBhIGZhaWx1 cmUgaXMgZGV0ZWN0ZWQgYW5kIGFjdGVkDQo+IHVwb24uIE5vIG5ldyBwcm90b2NvbCBmb3IgVlBM UyBoYXMgYmVlbiBzcGVjaWZpZWQgZm9yIGZhaWx1cmUgZGV0ZWN0aW9uLg0KQXMNCj4gSSBzYWlk IGJlZm9yZSwgdGhlIG1lYW5zIGFuZCBob3cgZmFzdCBpdCB0YWtlcyB0byBkZXRlY3QgZmFpbHVy ZXMgY2FuIGJlDQo+IGJhc2VkIHVwb24gZGlmZmVyZW50IG1lY2hhbmlzbXMgKGUuZy4gcGh5c2lj YWwgbG9zcyBvZiBzaWduYWwsIEJGRCwgU1RQLA0KPiBsb3NzIG9mIElHUC9MRFAgYWRqYWNlbmN5 KSwgZWFjaCB3aXRoIHRoZWlyIHJlc3BlY3RpdmUgZmFpbHVyZSBkZXRlY3Rpb24NCj4gdGltZXMu IEEgc2ltaWxhciBzZW50ZW5jZSBjb3VsZCBiZSBhZGRlZCB0byB0aGUgZHJhZnQgaWYgaXQgaGVs cHMuDQpWZW5kb3JzDQo+IGNhbiBkZWNpZGUgdG8gaW1wbGVtZW50IGFueSBvZiBzdWNoIG1ldGhv ZHMgYW5kIGhlbmNlIHByb3ZpZGUgcHJvZHVjdA0KPiBkaWZmZXJlbnRpYXRpb24uDQoNCkVzc2Vu dGlhbGx5IHRoaXMgc2F5cyB0aGF0IE1UVS1zIGFuZCBQRS1ycyBtdXN0IGFsd2F5cyBiZSBmcm9t IHRoZSBzYW1lDQp2ZW5kb3IsIGFuZCB0aGF0IGR1YWwtaG9taW5nDQpjaGFyYWN0ZXJpc3RpY3Mg YXJlIHVucHJlZGljdGFibGUgYW5kIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4gWWV0LCB0aGUN CnN0YW5kYXJkIHByb3ZpZGUgYSBjb21wb25lbnQNCnRvIGhlbHAgaXQgb3V0LiBQZXJoYXBzIHRo ZXJlIGlzIGhpc3RvcnkgYmVoaW5kIHRoaXMgcmVhc29uaW5nIEkgYW0gdW5hd2FyZQ0Kb2YsIGJ1 dCBpdCBzZWVtcyBsaW1pdGluZy4NCg0KUmVnYXJkcywNCkFuaWwNCg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICAgIk1hcmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgTGFzc2VycmUiICAgICAgICAgICAgVG86ICAgICA8YW5pbHJAYWNjdG9u LmNvbT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgPG1hcmNAcml2ZXJzdG8gICAgICAgY2M6ICAgICAiQXNhZiBIZW5p ZyIgPGFoZW5pZ0BtcnYuY29tPiwgPGwydnBuQGlldGYub3JnPiwgIkR1dHRhLCBQcmFuamFsIiAN CiAgICAgICAgICAgICAgICAgICAgbmVuZXQuY29tPiAgICAgICAgICAgIDxwZHV0dGFAcml2ZXJz dG9uZW5ldC5jb20+LCAiQWxpIFNhamFzc2kgXChzYWphc3NpXCkiICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzYWphc3NpQGNp c2NvLmNvbT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgMTAvMDQvMjAwNiAgICAgICAgICAgU3ViamVjdDog ICAgIFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgTUFDIFdpdGhkcmF3YWwgaW4gSC1WUExTIER1YWwt aG9tZWQgICANCiAgICAgICAgICAgICAgICAgICAgMDQ6MzAgUE0gICAgICAgICAgICAgIE1UVS1z ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQo+DQo+PiBJdCBpcyBvcHRpb24gQiBhcyBhbHJl YWR5IG1lbnRpb25lZCBieSBBbGkgYW5kIFByYW5qYWwuDQo+DQo+IEFzIGFscmVhZHkgZXhwbGFp bmVkIGJ5IEFzYWYgYW5kIEksIHRoYXQgbWF5IG5vdCBiZSB0aGUgY29ycmVjdCBvcHRpb24uDQoN CkkgZG8gbm90IHNlZSBob3cgdGhlIHByaW1hcnkgUEUtcnMgY2FuIGJlIGF3YXJlIHRoYXQgdGhl IHNlY29uZGFyeSBQVyBoYXMNCmJlZW4gbWFkZSBhY3RpdmUsIHNpbmNlIHRoZSBQVyBiZXR3ZWVu IHRoZSBNVFUtcyBhbmQgdGhlIHByaW1hcnkgUEUtcnMgaXMNCm5vDQpsb25nZXIgYXZhaWxhYmxl IGFuZCBubyBwcm90b2NvbCBpcyBkZWZpbmVkIHRvIGNvbnZleSBzdWNoIGluZm9ybWF0aW9uLiBU aGUNCg0Kb25seSBvcHRpb24gcG9zc2libGUgaXMgZm9yIHRoZSBNVFUtcyB0byB0cmlnZ2VyIHRo ZSBNQUMgd2l0aGRyYXdhbCB0b3dhcmRzDQoNCml0IHNlY29uZGFyeSBQRS1ycyBvbmNlIHRoZSBz ZWNvbmRhcnkgUFcgaGFzIGJlZW4gbWFkZSBhY3RpdmUuDQoNCj4NCj4+IFNlZSBteSBhbnN3ZXIg aW4gbXkgcHJldmlvdXMgZW1haWwgcmVnYXJkaW5nIGR1YWwgaG9taW5nDQo+PiAmIGZhaWx1cmUg ZGV0ZWN0aW9uLg0KPg0KPiBZb3VyIGFuc3dlciBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZXMg cmFpc2VkIGJ5IE1heCBhbmQgSS4gUGxlYXNlIHNlZQ0KPiB0aG9zZSBlbWFpbHMgYWdhaW4gYW5k IHRyeSB0byBhZGRyZXNzIGVhY2ggdGVjaG5pY2FsIGlzc3VlIGFuZCBwb2ludA0KPiByYWlzZWQu DQoNClNpbmNlIHRoZSBNVFUgaXMgcmVzcG9uc2libGUgZm9yIGFjdGl2YXRpbmcgaXRzIHNlY29u ZGFyeSBsaW5rLCBpdCBpcyBhDQpsb2NhbCBkZWNpc2lvbiB0byB0aGUgTVRVIHRvIGRlY2lkZSBo b3cgYSBmYWlsdXJlIGlzIGRldGVjdGVkIGFuZCBhY3RlZA0KdXBvbi4gTm8gbmV3IHByb3RvY29s IGZvciBWUExTIGhhcyBiZWVuIHNwZWNpZmllZCBmb3IgZmFpbHVyZSBkZXRlY3Rpb24uIEFzDQoN Ckkgc2FpZCBiZWZvcmUsIHRoZSBtZWFucyBhbmQgaG93IGZhc3QgaXQgdGFrZXMgdG8gZGV0ZWN0 IGZhaWx1cmVzIGNhbiBiZQ0KYmFzZWQgdXBvbiBkaWZmZXJlbnQgbWVjaGFuaXNtcyAoZS5nLiBw aHlzaWNhbCBsb3NzIG9mIHNpZ25hbCwgQkZELCBTVFAsDQpsb3NzIG9mIElHUC9MRFAgYWRqYWNl bmN5KSwgZWFjaCB3aXRoIHRoZWlyIHJlc3BlY3RpdmUgZmFpbHVyZSBkZXRlY3Rpb24NCnRpbWVz LiBBIHNpbWlsYXIgc2VudGVuY2UgY291bGQgYmUgYWRkZWQgdG8gdGhlIGRyYWZ0IGlmIGl0IGhl bHBzLiAgVmVuZG9ycw0KDQpjYW4gZGVjaWRlIHRvIGltcGxlbWVudCBhbnkgb2Ygc3VjaCBtZXRo b2RzIGFuZCBoZW5jZSBwcm92aWRlIHByb2R1Y3QNCmRpZmZlcmVudGlhdGlvbi4NCg0KPg0KPiBU aGlzIGJlaW5nIGFuIElFVEYgd29ya2luZyBncm91cCwgd2UgY29sbGVjdGl2ZWx5IG1ha2UgZGVj aXNpb25zIGJhc2VkIG9uDQo+IGNvbnNlbnN1cyBvZiB3b3JraW5nIGdyb3VwIG1lbWJlcnMuIFRo ZSB3cml0ZXJzIGRvbid0IGdldCB0byBtYWtlDQo+IGFyYml0cmFyeQ0KPiBjYWxscyB3aXRob3V0 IHRlY2huaWNhbCBkaXNjdXNzaW9uIGFuZCBhZ3JlZW1lbnQgd2l0aCBvdGhlciBtZW1iZXJzIGFu ZA0KPiB2ZW5kb3JzIGJhc2VkIG9uIHRoZWlyIGV4cGVyaWVuY2UuDQoNCkkgdGhpbmsgdGhhdCBJ IGFtIGF3YXJlIG9mIHRoYXQuLi4gRmlyc3Qgb2YgYWxsLCBJIGhhdmUgbm90IG1hZGUgYW55DQph cmJpdHJhcnkgY2FsbHMuIFNlY29uZGx5LCBJIGFtIG9wZW4gdG8gZGlzY3Vzc2luZyBhbnkgdGVj aG5pY2FsIG1hdHRlcnMuDQpBbGwgdGhlIGRpZmZlcmVudCByZXZpc2lvbnMgb2YgdGhlIGRyYWZ0 IGhhdmUgYmVlbiBiYXNlZCBvbiBXRyBmZWVkYmFjayBzbw0KZmFyLg0KDQo+DQo+IFRoYW5rcywN Cj4gQW5pbA0KPg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIk1hcmMNCj4gICAgICAg ICAgICAgICAgICAgIExhc3NlcnJlIiAgICAgICAgICAgIFRvOiAgICAgIkFzYWYgSGVuaWciDQo+ IDxhaGVuaWdAbXJ2LmNvbT4sIDxhbmlsckBhY2N0b24uY29tPg0KPiAgICAgICAgICAgICAgICAg ICAgPG1hcmNAcml2ZXJzdG8gICAgICAgY2M6ICAgICA8bDJ2cG5AaWV0Zi5vcmc+LCAiQWxpDQo+ IFNhamFzc2kgXChzYWphc3NpXCkiIDxzYWphc3NpQGNpc2NvLmNvbT4sDQo+ICAgICAgICAgICAg ICAgICAgICBuZW5ldC5jb20+ICAgICAgICAgICAgIkR1dHRhLCBQcmFuamFsIg0KPiA8cGR1dHRh QHJpdmVyc3RvbmVuZXQuY29tPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3ViamVjdDogICAgIFJlOiBRdWVzdGlvbg0KPiByZWdhcmRpbmcgTUFDIFdpdGhkcmF3 YWwgaW4gSC1WUExTIER1YWwtaG9tZWQNCj4gICAgICAgICAgICAgICAgICAgIDEwLzA0LzIwMDYg ICAgICAgICAgICBNVFUtcw0KPiAgICAgICAgICAgICAgICAgICAgMTI6MzAgUE0NCj4NCj4NCj4N Cj4NCj4NCj4NCj4gSXQgaXMgb3B0aW9uIEIgYXMgYWxyZWFkeSBtZW50aW9uZWQgYnkgQWxpIGFu ZCBQcmFuamFsLg0KPiBTZWUgbXkgYW5zd2VyIGluIG15IHByZXZpb3VzIGVtYWlsIHJlZ2FyZGlu ZyBkdWFsIGhvbWluZyAmIGZhaWx1cmUNCj4gZGV0ZWN0aW9uLg0KPg0KPiBDaGVlcnMsDQo+DQo+ IE1hcmMNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiA8YW5pbHJAYWNj dG9uLmNvbT4NCj4gVG86ICJBc2FmIEhlbmlnIiA8YWhlbmlnQG1ydi5jb20+DQo+IENjOiA8bDJ2 cG5AaWV0Zi5vcmc+OyA8bXBsc0BpZXRmLm9yZz47IDxtcGxzQGxpc3RzLmlldGYub3JnPg0KPiBT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDQsIDIwMDYgMzo1MSBQTQ0KPiBTdWJqZWN0OiBSZTog UXVlc3Rpb24gcmVnYXJkaW5nIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyBEdWFsLWhvbWVkIE1U VS1zDQo+DQo+DQo+Pg0KPj4gSSB3b3VsZCB0aGluayAoQSksIHNpbmNlIE1BQyBXaXRoZHJhdyBp cyB1c2VkIGJ5IGEgbWVtYmVyIG9mIHRoZSBWUExTDQo+IG1lc2gNCj4+IHRvIG5vdGlmeSBpdHMg bmVpZ2hib3JzIG9mIGEgY2hhbmdlIGluIHRvcG9sb2d5IC0tIGV4Y2VwdCB0aGF0IHRoZSBNVw0K Pj4gc2hvdWxkIGJlIHNlbnQgb25seSBhZnRlciBzd2l0Y2hpbmcgb3ZlciB0byB0aGUgc3RhbmRi eSBWQy4gVGhlIFBFLXJzDQo+PiBzaG91bGQgYmUganVzdCBhcyBhd2FyZSBvZiB0aGUgc3dpdGNo b3ZlciBhcyB0aGUgTVRVLXMuDQo+Pg0KPj4gVGhlIGxhcmdlciBhbWJpZ3VpdHkgaGVyZSAoaW4g bXkgb3BpbmlvbikgaXMgdGhlIGxhY2sgb2Ygc3BlY2lmaWNhdGlvbg0KPj4gYXJvdW5kIGp1c3Qg aG93IEgtVlBMUyBkdWFsIGhvbWluZyB3b3JrcywgaS5lLCBob3cgdGhlIGZhaWx1cmUgaXMNCj4g ZGV0ZWN0ZWQNCj4+IGFuZCB3aGF0IHRoZSB0aW1lIGxpbWl0cyBhcmUgZm9yIHRoYXQgZGV0ZWN0 aW9uIGFuZCBzdWJzZXF1ZW50IHJlY292ZXJ5Lg0KPj4gVGhhdCBwYXJ0IGlzIGN1cnJlbnRseSBp bXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuDQo+Pg0KPj4gUmVnYXJkcywNCj4+IEFuaWwNCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPj4gICAgICAgICAgICAgICAgICAgICJBc2FmIEhlbmlnIg0KPj4gICAg ICAgICAgICAgICAgICAgIDxhaGVuaWdAbXJ2LmNvICAgICAgIFRvOiAgICAgPGwydnBuQGlldGYu b3JnPiwNCj4+IDxtcGxzQGxpc3RzLmlldGYub3JnPiwgPG1wbHNAaWV0Zi5vcmc+DQo+PiAgICAg ICAgICAgICAgICAgICAgbT4gICAgICAgICAgICAgICAgICAgY2M6DQo+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3ViamVjdDogICAgIFF1ZXN0aW9uIHJlZ2FyZGlu Zw0KPj4gTUFDIFdpdGhkcmF3YWwgaW4gSC1WUExTIER1YWwtaG9tZWQgTVRVLXMNCj4+ICAgICAg ICAgICAgICAgICAgICAwOS8yNi8yMDA2DQo+PiAgICAgICAgICAgICAgICAgICAgMDQ6MTEgQU0N Cj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IEl0IGlzIHlldCB1bmNsZWFyIGZyb20gZHJhZnQN Cj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbDJ2cG4t dnBscy1sZHAtMDkudHh0IHdobw0KPj4gaXMNCj4+IHJlc3BvbnNpYmxlIHRvIHNlbmQgdGhlIE1B QyBXaXRoZHJhd2FsIG1lc3NhZ2UgdG8gdGhlIHNlY29uZGFyeSBQRS1ycw0KPiB3aGVuDQo+PiBm YWlsLW92ZXIgb2NjdXJlcyBpbiBhbiBILVZQTFMgZHVhbCBob21lZCBNVFUtcyBzY2VuYXJpby4N Cj4+DQo+PiBJdCBpcyBrbm93biB0aGF0IHdoZW4gYSBwcmltYXJ5IFZDIGZhaWxzIGluIGEgZHVh bC1ob21pbmcgc2NlbmFyaW8gdGhlDQo+PiBQRS1ycyBjb25uZWN0ZWQgdG8gdGhlIHNlY29uZGFy eSBWQyBzaG91bGQgcmVsZWFybiB0aGUgTUFDIGFkZHJlc3Nlcw0KPj4gYmVoaW5kDQo+PiB0aGUg TVRVLXMuIEluIG9yZGVyIHRvIG1ha2UgdGhpcyBwcm9jZXNzIGZhc3RlciB0aGlzICJzZWNvbmRh cnkiIFBFLXJzDQo+PiBzaG91bGQgZmx1c2ggdGhlIHJlbGV2YW50IHByZXZpb3VzbHkgbGVhcm5l ZCBNQUMgYWRkcmVzc2VzLiBGb3IgdGhhdCB0bw0KPj4gaGFwcGVuIHdlIGhhdmUgdHdvIG9wdGlv bnM6DQo+Pg0KPj4gQSkgVGhlIHByaW1hcnkgUEUtcnMgd291bGQgc2VuZCB0aGUgTUFDIFdpdGhk cmF3YWwgbWVzc2FnZSB0byB0aGUNCj4+IHNlY29uZGFyeQ0KPj4gUEUtcnMgKGFuZCBhbGwgb3Ro ZXIgUEUtcykgdGhlIG1pbnV0ZSBpdCByZWNvZ25pemVzIHRoYXQgaXRzIFZDIGhhcw0KPj4gZmFp bGVkLg0KPj4gQikgVGhlIE1UVS1zIGl0c2VsZiB3b3VsZCBzZW5kIHRoZSBNQUMgV2l0aGRyYXdh bCB0byB0aGUgc2Vjb25kYXJ5IFBFLXJzDQo+PiB0aGUgbWludXRlIGl0IHN3aXRjaGVzIGZyb20g cHJpbWFyeSB0byBzZWNvbmRhcnkgVkMuIFRoZSBzZWNvbmRhcnkgUEUtcnMNCj4+IHdvdWxkIGJl IHJlc3BvbnNpYmxlIHRvIHByb3BlZ2F0ZSB0aGlzIG1lc3NhZ2UgdG8gYWxsIG90aGVyIFBFcyBp biB0aGUNCj4+IFZQTFMNCj4+IGRvbWFpbiAodGhpcyBvcHRpb24gaXMgcmVjb21tZW5kZWQgYnkN Cj4+IGRyYWZ0LXBkdXR0YS1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTAwLnR4dCkuDQo+Pg0KPj4g V2hpY2ggb3B0aW9uIGlzIHByZWZlcnJlZCAgPw0KPj4NCj4+DQo+PiBUaGFua3MgZm9yIGFueSBo ZWxwLg0KPj4gQXNhZiBIZW5pZw0KPj4gTVJWIGNvbW11bmljYXRpb25zDQo+Pg0KPj4NCj4+DQo+ Pg0KPj4NCj4NCj4NCj4NCj4NCj4NCg0KDQoNCg0K From l2vpn-bounces@ietf.org Wed Oct 04 17:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEJ6-0003Rz-4R; Wed, 04 Oct 2006 17:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEJ4-0003Ru-Bn for l2vpn@ietf.org; Wed, 04 Oct 2006 17:29:34 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVEJ1-0001uB-PC for l2vpn@ietf.org; Wed, 04 Oct 2006 17:29:34 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA00743; Wed, 4 Oct 2006 14:29:24 -0700 (PDT) Message-ID: <041001c6e7fc$28a2f1a0$0300a8c0@IBMT41ML> From: "Marc Lasserre" To: References: Date: Wed, 4 Oct 2006 23:29:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org > > Marc, > >> I do not see how the primary PE-rs can be aware that the secondary PW has > >> been made active, since the PW between the MTU-s and the primary PE-rs is > no >> longer available and no protocol is defined to convey such information. > The >> only option possible is for the MTU-s to trigger the MAC withdrawal > towards >> it secondary PE-rs once the secondary PW has been made active. > > In most protocols which allow a standby link, both sides of the standby > link are aware that it's been > pressed into service. My suggestion was this being the case, the PE-rs > needs no help from the > MTU-s in generating a MAC Withdraw. Also isn't it possible there may be no > PW between the > MTU-s and PE-rs, as with QinQ? Perhaps you have a different solution in > mind than I do, but that's > the result of a partially specified mechanism -- it's tough to see > supporting protocols the same > way without a shared understanding of how the whole thing works. > In the original question asked, the question was about whether the primary PE could generate the MW. In this case, the backup link between the MTU and the secondary PE is unknown to the primary PE. This is valid for both PW and QinQ links. The MW message is sent when the secondary link becomes active with PW and when the port is unblocked with QinQ. >> Since the MTU is responsible for activating its secondary link, it is a >> local decision to the MTU to decide how a failure is detected and acted >> upon. No new protocol for VPLS has been specified for failure detection. > As >> I said before, the means and how fast it takes to detect failures can be >> based upon different mechanisms (e.g. physical loss of signal, BFD, STP, >> loss of IGP/LDP adjacency), each with their respective failure detection >> times. A similar sentence could be added to the draft if it helps. > Vendors >> can decide to implement any of such methods and hence provide product >> differentiation. > > Essentially this says that MTU-s and PE-rs must always be from the same > vendor, and that dual-homing > characteristics are unpredictable and implementation-dependent. Yet, the > standard provide a component > to help it out. Perhaps there is history behind this reasoning I am > unaware > of, but it seems limiting. No, it does not imply that both MTU and PE devices be from the same vendor. It implies that one or more protocols be used between them. Such protocols are standard protocols. Only the ones supported by both could obvously be used. As far as performance is concerned , there would be as good and predictable as what the selected protocol can support to detect failures. If IGP/LDP or STP were to be used, detection time would be in the order of tens of seconds, with RSTP in the order of seconds and with BFD in the order of tens of msec. Cheers, Marc > > Regards, > Anil > > > > > "Marc > Lasserre" To: > , , "Dutta, Pranjal" > nenet.com> , "Ali > Sajassi \(sajassi\)" > > 10/04/2006 Subject: Re: Question > regarding MAC Withdrawal in H-VPLS Dual-homed > 04:30 PM MTU-s > > > > > > > >> >>> It is option B as already mentioned by Ali and Pranjal. >> >> As already explained by Asaf and I, that may not be the correct option. > > I do not see how the primary PE-rs can be aware that the secondary PW has > been made active, since the PW between the MTU-s and the primary PE-rs is > no > longer available and no protocol is defined to convey such information. > The > > only option possible is for the MTU-s to trigger the MAC withdrawal > towards > > it secondary PE-rs once the secondary PW has been made active. > >> >>> See my answer in my previous email regarding dual homing >>> & failure detection. >> >> Your answer does not address the issues raised by Max and I. Please see >> those emails again and try to address each technical issue and point >> raised. > > Since the MTU is responsible for activating its secondary link, it is a > local decision to the MTU to decide how a failure is detected and acted > upon. No new protocol for VPLS has been specified for failure detection. > As > > I said before, the means and how fast it takes to detect failures can be > based upon different mechanisms (e.g. physical loss of signal, BFD, STP, > loss of IGP/LDP adjacency), each with their respective failure detection > times. A similar sentence could be added to the draft if it helps. > Vendors > > can decide to implement any of such methods and hence provide product > differentiation. > >> >> This being an IETF working group, we collectively make decisions based on >> consensus of working group members. The writers don't get to make >> arbitrary >> calls without technical discussion and agreement with other members and >> vendors based on their experience. > > I think that I am aware of that... First of all, I have not made any > arbitrary calls. Secondly, I am open to discussing any technical matters. > All the different revisions of the draft have been based on WG feedback so > far. > >> >> Thanks, >> Anil >> >> >> >> >> "Marc >> Lasserre" To: "Asaf Henig" >> , >> , "Ali >> Sajassi \(sajassi\)" , >> nenet.com> "Dutta, Pranjal" >> >> Subject: Re: Question >> regarding MAC Withdrawal in H-VPLS Dual-homed >> 10/04/2006 MTU-s >> 12:30 PM >> >> >> >> >> >> >> It is option B as already mentioned by Ali and Pranjal. >> See my answer in my previous email regarding dual homing & failure >> detection. >> >> Cheers, >> >> Marc >> ----- Original Message ----- >> From: >> To: "Asaf Henig" >> Cc: ; ; >> Sent: Wednesday, October 04, 2006 3:51 PM >> Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s >> >> >>> >>> I would think (A), since MAC Withdraw is used by a member of the VPLS >> mesh >>> to notify its neighbors of a change in topology -- except that the MW >>> should be sent only after switching over to the standby VC. The PE-rs >>> should be just as aware of the switchover as the MTU-s. >>> >>> The larger ambiguity here (in my opinion) is the lack of specification >>> around just how H-VPLS dual homing works, i.e, how the failure is >> detected >>> and what the time limits are for that detection and subsequent recovery. >>> That part is currently implementation-dependent. >>> >>> Regards, >>> Anil >>> >>> >>> >>> >>> >>> "Asaf Henig" >>> , >>> , >>> m> cc: >>> Subject: Question regarding >>> MAC Withdrawal in H-VPLS Dual-homed MTU-s >>> 09/26/2006 >>> 04:11 AM >>> >>> >>> >>> >>> >>> >>> It is yet unclear from draft >>> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who >>> is >>> responsible to send the MAC Withdrawal message to the secondary PE-rs >> when >>> fail-over occures in an H-VPLS dual homed MTU-s scenario. >>> >>> It is known that when a primary VC fails in a dual-homing scenario the >>> PE-rs connected to the secondary VC should relearn the MAC addresses >>> behind >>> the MTU-s. In order to make this process faster this "secondary" PE-rs >>> should flush the relevant previously learned MAC addresses. For that to >>> happen we have two options: >>> >>> A) The primary PE-rs would send the MAC Withdrawal message to the >>> secondary >>> PE-rs (and all other PE-s) the minute it recognizes that its VC has >>> failed. >>> B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs >>> the minute it switches from primary to secondary VC. The secondary PE-rs >>> would be responsible to propegate this message to all other PEs in the >>> VPLS >>> domain (this option is recommended by >>> draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). >>> >>> Which option is preferred ? >>> >>> >>> Thanks for any help. >>> Asaf Henig >>> MRV communications >>> >>> >>> >>> >>> >> >> >> >> >> > > > > > From l2vpn-bounces@ietf.org Wed Oct 04 17:48:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEaj-0003QT-IU; Wed, 04 Oct 2006 17:47:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEai-0003QN-Eq for l2vpn@ietf.org; Wed, 04 Oct 2006 17:47:48 -0400 Received: from note-back.accton.com ([64.171.8.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVEah-0006Sn-Lw for l2vpn@ietf.org; Wed, 04 Oct 2006 17:47:48 -0400 To: "Marc Lasserre" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Wed, 4 Oct 2006 17:59:56 -0400 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 10/04/2006 02:48:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.2 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org DQo+IEluIHRoZSBvcmlnaW5hbCBxdWVzdGlvbiBhc2tlZCwgdGhlIHF1ZXN0aW9uIHdhcyBhYm91 dCB3aGV0aGVyIHRoZQ0KcHJpbWFyeQ0KPiBQRSBjb3VsZCBnZW5lcmF0ZSB0aGUgTVcuDQo+IElu IHRoaXMgY2FzZSwgdGhlIGJhY2t1cCBsaW5rIGJldHdlZW4gdGhlIE1UVSBhbmQgdGhlIHNlY29u ZGFyeSBQRSBpcw0KPiB1bmtub3duIHRvIHRoZSBwcmltYXJ5IFBFLiBUaGlzIGlzIHZhbGlkIGZv ciBib3RoIFBXIGFuZCBRaW5RIGxpbmtzLiBUaGUNCk1XDQo+IG1lc3NhZ2UgaXMgc2VudCB3aGVu IHRoZSBzZWNvbmRhcnkgbGluayBiZWNvbWVzIGFjdGl2ZSB3aXRoIFBXIGFuZCB3aGVuDQp0aGUN Cj4gcG9ydCBpcyB1bmJsb2NrZWQgd2l0aCBRaW5RLg0KDQpGYWlyIGVub3VnaCwgYW5kIG15IHBv aW50IHdhcyB0aGF0IHRoZSBQRSAoc2Vjb25kYXJ5KSBjb3VsZCBzb3VyY2UgdGhlIE1XDQpyYXRo ZXIgdGhhbiB0aGUgTVRVLg0KDQo+IE5vLCBpdCBkb2VzIG5vdCBpbXBseSB0aGF0IGJvdGggTVRV IGFuZCBQRSBkZXZpY2VzIGJlIGZyb20gdGhlIHNhbWUNCnZlbmRvci4NCj4gSXQgaW1wbGllcyB0 aGF0IG9uZSBvciBtb3JlIHByb3RvY29scyBiZSB1c2VkIGJldHdlZW4gdGhlbS4gU3VjaA0KcHJv dG9jb2xzDQo+IGFyZSBzdGFuZGFyZCBwcm90b2NvbHMuIE9ubHkgdGhlIG9uZXMgc3VwcG9ydGVk IGJ5IGJvdGggY291bGQgb2J2b3VzbHkgYmUNCg0KPiB1c2VkLiBBcyBmYXIgYXMgcGVyZm9ybWFu Y2UgaXMgY29uY2VybmVkICwgdGhlcmUgd291bGQgYmUgYXMgZ29vZCBhbmQNCj4gcHJlZGljdGFi bGUgYXMgd2hhdCB0aGUgc2VsZWN0ZWQgcHJvdG9jb2wgY2FuIHN1cHBvcnQgdG8gZGV0ZWN0IGZh aWx1cmVzLg0KSWYNCj4gSUdQL0xEUCBvciBTVFAgd2VyZSB0byBiZSB1c2VkLCBkZXRlY3Rpb24g dGltZSB3b3VsZCBiZSBpbiB0aGUgb3JkZXIgb2YNCnRlbnMNCj4gb2Ygc2Vjb25kcywgd2l0aCBS U1RQIGluIHRoZSBvcmRlciBvZiBzZWNvbmRzIGFuZCB3aXRoIEJGRCBpbiB0aGUgb3JkZXINCm9m DQo+IHRlbnMgb2YgbXNlYy4NCg0KSSdkIHJhdGhlciBoYXZlIHNwZWNpZmllZCBhIHZlcnkgbGln aHR3ZWlnaHQga2VlcGFsaXZlIHByb3RvY29sIGZvciBhDQpjb25maWd1cmF0aW9uIGFzIHNpbXBs ZSBhcyBkdWFsLWhvbWluZy4gSW4gdGhlIGFic2VuY2Ugb2YgdGhhdCwgc29tZXRoaW5nDQpsaWtl IHRoZSBhYm92ZSB2ZXJiaWFnZSB3b3VsZCBiZSB1c2VmdWwgaW4gdGhlIHN0YW5kYXJkIChpbiBh ZGRpdGlvbiB0bw0KaGFyZHdhcmUgZmFpbHVyZSBkZXRlY3Rpb24pLg0KDQpSZWdhcmRzLA0KQW5p bA0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICJNYXJjICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIExhc3NlcnJlIiAgICAgICAgICAg IFRvOiAgICAgPGFuaWxyQGFjY3Rvbi5jb20+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIDxtYXJjQHJpdmVyc3RvICAg ICAgIGNjOiAgICAgIkFzYWYgSGVuaWciIDxhaGVuaWdAbXJ2LmNvbT4sIDxsMnZwbkBpZXRmLm9y Zz4sICJEdXR0YSwgUHJhbmphbCIgDQogICAgICAgICAgICAgICAgICAgIG5lbmV0LmNvbT4gICAg ICAgICAgICA8cGR1dHRhQHJpdmVyc3RvbmVuZXQuY29tPiwgIkFsaSBTYWphc3NpIFwoc2FqYXNz aVwpIiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8c2FqYXNzaUBjaXNjby5jb20+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIDEwLzA0LzIw MDYgICAgICAgICAgIFN1YmplY3Q6ICAgICBSZTogUXVlc3Rpb24gcmVnYXJkaW5nIE1BQyBXaXRo ZHJhd2FsIGluIEgtVlBMUyBEdWFsLWhvbWVkICAgDQogICAgICAgICAgICAgICAgICAgIDA1OjI5 IFBNICAgICAgICAgICAgICBNVFUtcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQoNCg0KPg0KPiBN YXJjLA0KPg0KPj4gSSBkbyBub3Qgc2VlIGhvdyB0aGUgcHJpbWFyeSBQRS1ycyBjYW4gYmUgYXdh cmUgdGhhdCB0aGUgc2Vjb25kYXJ5IFBXDQpoYXMNCj4NCj4+IGJlZW4gbWFkZSBhY3RpdmUsIHNp bmNlIHRoZSBQVyBiZXR3ZWVuIHRoZSBNVFUtcyBhbmQgdGhlIHByaW1hcnkgUEUtcnMNCmlzDQo+ IG5vDQo+PiBsb25nZXIgYXZhaWxhYmxlIGFuZCBubyBwcm90b2NvbCBpcyBkZWZpbmVkIHRvIGNv bnZleSBzdWNoIGluZm9ybWF0aW9uLg0KPiBUaGUNCj4+IG9ubHkgb3B0aW9uIHBvc3NpYmxlIGlz IGZvciB0aGUgTVRVLXMgdG8gdHJpZ2dlciB0aGUgTUFDIHdpdGhkcmF3YWwNCj4gdG93YXJkcw0K Pj4gaXQgc2Vjb25kYXJ5IFBFLXJzIG9uY2UgdGhlIHNlY29uZGFyeSBQVyBoYXMgYmVlbiBtYWRl IGFjdGl2ZS4NCj4NCj4gSW4gbW9zdCBwcm90b2NvbHMgd2hpY2ggYWxsb3cgYSBzdGFuZGJ5IGxp bmssIGJvdGggc2lkZXMgb2YgdGhlIHN0YW5kYnkNCj4gbGluayBhcmUgYXdhcmUgdGhhdCBpdCdz IGJlZW4NCj4gcHJlc3NlZCBpbnRvIHNlcnZpY2UuIE15IHN1Z2dlc3Rpb24gd2FzIHRoaXMgYmVp bmcgdGhlIGNhc2UsIHRoZSBQRS1ycw0KPiBuZWVkcyBubyBoZWxwIGZyb20gdGhlDQo+IE1UVS1z IGluIGdlbmVyYXRpbmcgYSBNQUMgV2l0aGRyYXcuIEFsc28gaXNuJ3QgaXQgcG9zc2libGUgdGhl cmUgbWF5IGJlDQpubw0KPiBQVyBiZXR3ZWVuIHRoZQ0KPiBNVFUtcyBhbmQgUEUtcnMsIGFzIHdp dGggUWluUT8gUGVyaGFwcyB5b3UgaGF2ZSBhIGRpZmZlcmVudCBzb2x1dGlvbiBpbg0KPiBtaW5k IHRoYW4gSSBkbywgYnV0IHRoYXQncw0KPiB0aGUgcmVzdWx0IG9mIGEgcGFydGlhbGx5IHNwZWNp ZmllZCBtZWNoYW5pc20gLS0gaXQncyB0b3VnaCB0byBzZWUNCj4gc3VwcG9ydGluZyBwcm90b2Nv bHMgdGhlIHNhbWUNCj4gd2F5IHdpdGhvdXQgYSBzaGFyZWQgdW5kZXJzdGFuZGluZyBvZiBob3cg dGhlIHdob2xlIHRoaW5nIHdvcmtzLg0KPg0KDQpJbiB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gYXNr ZWQsIHRoZSBxdWVzdGlvbiB3YXMgYWJvdXQgd2hldGhlciB0aGUgcHJpbWFyeQ0KUEUgY291bGQg Z2VuZXJhdGUgdGhlIE1XLg0KSW4gdGhpcyBjYXNlLCB0aGUgYmFja3VwIGxpbmsgYmV0d2VlbiB0 aGUgTVRVIGFuZCB0aGUgc2Vjb25kYXJ5IFBFIGlzDQp1bmtub3duIHRvIHRoZSBwcmltYXJ5IFBF LiBUaGlzIGlzIHZhbGlkIGZvciBib3RoIFBXIGFuZCBRaW5RIGxpbmtzLiBUaGUgTVcNCg0KbWVz c2FnZSBpcyBzZW50IHdoZW4gdGhlIHNlY29uZGFyeSBsaW5rIGJlY29tZXMgYWN0aXZlIHdpdGgg UFcgYW5kIHdoZW4gdGhlDQoNCnBvcnQgaXMgdW5ibG9ja2VkIHdpdGggUWluUS4NCg0KPj4gU2lu Y2UgdGhlIE1UVSBpcyByZXNwb25zaWJsZSBmb3IgYWN0aXZhdGluZyBpdHMgc2Vjb25kYXJ5IGxp bmssIGl0IGlzIGENCj4+IGxvY2FsIGRlY2lzaW9uIHRvIHRoZSBNVFUgdG8gZGVjaWRlIGhvdyBh IGZhaWx1cmUgaXMgZGV0ZWN0ZWQgYW5kIGFjdGVkDQo+PiB1cG9uLiBObyBuZXcgcHJvdG9jb2wg Zm9yIFZQTFMgaGFzIGJlZW4gc3BlY2lmaWVkIGZvciBmYWlsdXJlIGRldGVjdGlvbi4NCj4gQXMN Cj4+IEkgc2FpZCBiZWZvcmUsIHRoZSBtZWFucyBhbmQgaG93IGZhc3QgaXQgdGFrZXMgdG8gZGV0 ZWN0IGZhaWx1cmVzIGNhbiBiZQ0KPj4gYmFzZWQgdXBvbiBkaWZmZXJlbnQgbWVjaGFuaXNtcyAo ZS5nLiBwaHlzaWNhbCBsb3NzIG9mIHNpZ25hbCwgQkZELCBTVFAsDQo+PiBsb3NzIG9mIElHUC9M RFAgYWRqYWNlbmN5KSwgZWFjaCB3aXRoIHRoZWlyIHJlc3BlY3RpdmUgZmFpbHVyZSBkZXRlY3Rp b24NCj4+IHRpbWVzLiBBIHNpbWlsYXIgc2VudGVuY2UgY291bGQgYmUgYWRkZWQgdG8gdGhlIGRy YWZ0IGlmIGl0IGhlbHBzLg0KPiBWZW5kb3JzDQo+PiBjYW4gZGVjaWRlIHRvIGltcGxlbWVudCBh bnkgb2Ygc3VjaCBtZXRob2RzIGFuZCBoZW5jZSBwcm92aWRlIHByb2R1Y3QNCj4+IGRpZmZlcmVu dGlhdGlvbi4NCj4NCj4gRXNzZW50aWFsbHkgdGhpcyBzYXlzIHRoYXQgTVRVLXMgYW5kIFBFLXJz IG11c3QgYWx3YXlzIGJlIGZyb20gdGhlIHNhbWUNCj4gdmVuZG9yLCBhbmQgdGhhdCBkdWFsLWhv bWluZw0KPiBjaGFyYWN0ZXJpc3RpY3MgYXJlIHVucHJlZGljdGFibGUgYW5kIGltcGxlbWVudGF0 aW9uLWRlcGVuZGVudC4gWWV0LCB0aGUNCj4gc3RhbmRhcmQgcHJvdmlkZSBhIGNvbXBvbmVudA0K PiB0byBoZWxwIGl0IG91dC4gUGVyaGFwcyB0aGVyZSBpcyBoaXN0b3J5IGJlaGluZCB0aGlzIHJl YXNvbmluZyBJIGFtDQo+IHVuYXdhcmUNCj4gb2YsIGJ1dCBpdCBzZWVtcyBsaW1pdGluZy4NCg0K Tm8sIGl0IGRvZXMgbm90IGltcGx5IHRoYXQgYm90aCBNVFUgYW5kIFBFIGRldmljZXMgYmUgZnJv bSB0aGUgc2FtZSB2ZW5kb3IuDQoNCkl0IGltcGxpZXMgdGhhdCBvbmUgb3IgbW9yZSBwcm90b2Nv bHMgYmUgdXNlZCBiZXR3ZWVuIHRoZW0uIFN1Y2ggcHJvdG9jb2xzDQphcmUgc3RhbmRhcmQgcHJv dG9jb2xzLiBPbmx5IHRoZSBvbmVzIHN1cHBvcnRlZCBieSBib3RoIGNvdWxkIG9idm91c2x5IGJl DQp1c2VkLiBBcyBmYXIgYXMgcGVyZm9ybWFuY2UgaXMgY29uY2VybmVkICwgdGhlcmUgd291bGQg YmUgYXMgZ29vZCBhbmQNCnByZWRpY3RhYmxlIGFzIHdoYXQgdGhlIHNlbGVjdGVkIHByb3RvY29s IGNhbiBzdXBwb3J0IHRvIGRldGVjdCBmYWlsdXJlcy4NCklmDQpJR1AvTERQIG9yIFNUUCB3ZXJl IHRvIGJlIHVzZWQsIGRldGVjdGlvbiB0aW1lIHdvdWxkIGJlIGluIHRoZSBvcmRlciBvZg0KdGVu cw0Kb2Ygc2Vjb25kcywgd2l0aCBSU1RQIGluIHRoZSBvcmRlciBvZiBzZWNvbmRzIGFuZCB3aXRo IEJGRCBpbiB0aGUgb3JkZXIgb2YNCnRlbnMgb2YgbXNlYy4NCg0KQ2hlZXJzLA0KTWFyYw0KDQo+ DQo+IFJlZ2FyZHMsDQo+IEFuaWwNCj4NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICJN YXJjDQo+ICAgICAgICAgICAgICAgICAgICBMYXNzZXJyZSIgICAgICAgICAgICBUbzogICAgIDxh bmlsckBhY2N0b24uY29tPg0KPiAgICAgICAgICAgICAgICAgICAgPG1hcmNAcml2ZXJzdG8gICAg ICAgY2M6ICAgICAiQXNhZiBIZW5pZyINCj4gPGFoZW5pZ0BtcnYuY29tPiwgPGwydnBuQGlldGYu b3JnPiwgIkR1dHRhLCBQcmFuamFsIg0KPiAgICAgICAgICAgICAgICAgICAgbmVuZXQuY29tPiAg ICAgICAgICAgIDxwZHV0dGFAcml2ZXJzdG9uZW5ldC5jb20+LCAiQWxpDQoNCj4gU2FqYXNzaSBc KHNhamFzc2lcKSINCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 c2FqYXNzaUBjaXNjby5jb20+DQo+ICAgICAgICAgICAgICAgICAgICAxMC8wNC8yMDA2ICAgICAg ICAgICBTdWJqZWN0OiAgICAgUmU6IFF1ZXN0aW9uDQo+IHJlZ2FyZGluZyBNQUMgV2l0aGRyYXdh bCBpbiBILVZQTFMgRHVhbC1ob21lZA0KPiAgICAgICAgICAgICAgICAgICAgMDQ6MzAgUE0gICAg ICAgICAgICAgIE1UVS1zDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+Pg0KPj4+IEl0IGlzIG9wdGlv biBCIGFzIGFscmVhZHkgbWVudGlvbmVkIGJ5IEFsaSBhbmQgUHJhbmphbC4NCj4+DQo+PiBBcyBh bHJlYWR5IGV4cGxhaW5lZCBieSBBc2FmIGFuZCBJLCB0aGF0IG1heSBub3QgYmUgdGhlIGNvcnJl Y3Qgb3B0aW9uLg0KPg0KPiBJIGRvIG5vdCBzZWUgaG93IHRoZSBwcmltYXJ5IFBFLXJzIGNhbiBi ZSBhd2FyZSB0aGF0IHRoZSBzZWNvbmRhcnkgUFcgaGFzDQo+IGJlZW4gbWFkZSBhY3RpdmUsIHNp bmNlIHRoZSBQVyBiZXR3ZWVuIHRoZSBNVFUtcyBhbmQgdGhlIHByaW1hcnkgUEUtcnMgaXMNCj4g bm8NCj4gbG9uZ2VyIGF2YWlsYWJsZSBhbmQgbm8gcHJvdG9jb2wgaXMgZGVmaW5lZCB0byBjb252 ZXkgc3VjaCBpbmZvcm1hdGlvbi4NCj4gVGhlDQo+DQo+IG9ubHkgb3B0aW9uIHBvc3NpYmxlIGlz IGZvciB0aGUgTVRVLXMgdG8gdHJpZ2dlciB0aGUgTUFDIHdpdGhkcmF3YWwNCj4gdG93YXJkcw0K Pg0KPiBpdCBzZWNvbmRhcnkgUEUtcnMgb25jZSB0aGUgc2Vjb25kYXJ5IFBXIGhhcyBiZWVuIG1h ZGUgYWN0aXZlLg0KPg0KPj4NCj4+PiBTZWUgbXkgYW5zd2VyIGluIG15IHByZXZpb3VzIGVtYWls IHJlZ2FyZGluZyBkdWFsIGhvbWluZw0KPj4+ICYgZmFpbHVyZSBkZXRlY3Rpb24uDQo+Pg0KPj4g WW91ciBhbnN3ZXIgZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWVzIHJhaXNlZCBieSBNYXggYW5k IEkuIFBsZWFzZSBzZWUNCj4+IHRob3NlIGVtYWlscyBhZ2FpbiBhbmQgdHJ5IHRvIGFkZHJlc3Mg ZWFjaCB0ZWNobmljYWwgaXNzdWUgYW5kIHBvaW50DQo+PiByYWlzZWQuDQo+DQo+IFNpbmNlIHRo ZSBNVFUgaXMgcmVzcG9uc2libGUgZm9yIGFjdGl2YXRpbmcgaXRzIHNlY29uZGFyeSBsaW5rLCBp dCBpcyBhDQo+IGxvY2FsIGRlY2lzaW9uIHRvIHRoZSBNVFUgdG8gZGVjaWRlIGhvdyBhIGZhaWx1 cmUgaXMgZGV0ZWN0ZWQgYW5kIGFjdGVkDQo+IHVwb24uIE5vIG5ldyBwcm90b2NvbCBmb3IgVlBM UyBoYXMgYmVlbiBzcGVjaWZpZWQgZm9yIGZhaWx1cmUgZGV0ZWN0aW9uLg0KPiBBcw0KPg0KPiBJ IHNhaWQgYmVmb3JlLCB0aGUgbWVhbnMgYW5kIGhvdyBmYXN0IGl0IHRha2VzIHRvIGRldGVjdCBm YWlsdXJlcyBjYW4gYmUNCj4gYmFzZWQgdXBvbiBkaWZmZXJlbnQgbWVjaGFuaXNtcyAoZS5nLiBw aHlzaWNhbCBsb3NzIG9mIHNpZ25hbCwgQkZELCBTVFAsDQo+IGxvc3Mgb2YgSUdQL0xEUCBhZGph Y2VuY3kpLCBlYWNoIHdpdGggdGhlaXIgcmVzcGVjdGl2ZSBmYWlsdXJlIGRldGVjdGlvbg0KPiB0 aW1lcy4gQSBzaW1pbGFyIHNlbnRlbmNlIGNvdWxkIGJlIGFkZGVkIHRvIHRoZSBkcmFmdCBpZiBp dCBoZWxwcy4NCj4gVmVuZG9ycw0KPg0KPiBjYW4gZGVjaWRlIHRvIGltcGxlbWVudCBhbnkgb2Yg c3VjaCBtZXRob2RzIGFuZCBoZW5jZSBwcm92aWRlIHByb2R1Y3QNCj4gZGlmZmVyZW50aWF0aW9u Lg0KPg0KPj4NCj4+IFRoaXMgYmVpbmcgYW4gSUVURiB3b3JraW5nIGdyb3VwLCB3ZSBjb2xsZWN0 aXZlbHkgbWFrZSBkZWNpc2lvbnMgYmFzZWQNCm9uDQo+PiBjb25zZW5zdXMgb2Ygd29ya2luZyBn cm91cCBtZW1iZXJzLiBUaGUgd3JpdGVycyBkb24ndCBnZXQgdG8gbWFrZQ0KPj4gYXJiaXRyYXJ5 DQo+PiBjYWxscyB3aXRob3V0IHRlY2huaWNhbCBkaXNjdXNzaW9uIGFuZCBhZ3JlZW1lbnQgd2l0 aCBvdGhlciBtZW1iZXJzIGFuZA0KPj4gdmVuZG9ycyBiYXNlZCBvbiB0aGVpciBleHBlcmllbmNl Lg0KPg0KPiBJIHRoaW5rIHRoYXQgSSBhbSBhd2FyZSBvZiB0aGF0Li4uIEZpcnN0IG9mIGFsbCwg SSBoYXZlIG5vdCBtYWRlIGFueQ0KPiBhcmJpdHJhcnkgY2FsbHMuIFNlY29uZGx5LCBJIGFtIG9w ZW4gdG8gZGlzY3Vzc2luZyBhbnkgdGVjaG5pY2FsIG1hdHRlcnMuDQo+IEFsbCB0aGUgZGlmZmVy ZW50IHJldmlzaW9ucyBvZiB0aGUgZHJhZnQgaGF2ZSBiZWVuIGJhc2VkIG9uIFdHIGZlZWRiYWNr DQpzbw0KPiBmYXIuDQo+DQo+Pg0KPj4gVGhhbmtzLA0KPj4gQW5pbA0KPj4NCj4+DQo+Pg0KPj4N Cj4+ICAgICAgICAgICAgICAgICAgICAiTWFyYw0KPj4gICAgICAgICAgICAgICAgICAgIExhc3Nl cnJlIiAgICAgICAgICAgIFRvOiAgICAgIkFzYWYgSGVuaWciDQo+PiA8YWhlbmlnQG1ydi5jb20+ LCA8YW5pbHJAYWNjdG9uLmNvbT4NCj4+ICAgICAgICAgICAgICAgICAgICA8bWFyY0ByaXZlcnN0 byAgICAgICBjYzogICAgIDxsMnZwbkBpZXRmLm9yZz4sICJBbGkNCj4+IFNhamFzc2kgXChzYWph c3NpXCkiIDxzYWphc3NpQGNpc2NvLmNvbT4sDQo+PiAgICAgICAgICAgICAgICAgICAgbmVuZXQu Y29tPiAgICAgICAgICAgICJEdXR0YSwgUHJhbmphbCINCj4+IDxwZHV0dGFAcml2ZXJzdG9uZW5l dC5jb20+DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3ViamVj dDogICAgIFJlOiBRdWVzdGlvbg0KPj4gcmVnYXJkaW5nIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBM UyBEdWFsLWhvbWVkDQo+PiAgICAgICAgICAgICAgICAgICAgMTAvMDQvMjAwNiAgICAgICAgICAg IE1UVS1zDQo+PiAgICAgICAgICAgICAgICAgICAgMTI6MzAgUE0NCj4+DQo+Pg0KPj4NCj4+DQo+ Pg0KPj4NCj4+IEl0IGlzIG9wdGlvbiBCIGFzIGFscmVhZHkgbWVudGlvbmVkIGJ5IEFsaSBhbmQg UHJhbmphbC4NCj4+IFNlZSBteSBhbnN3ZXIgaW4gbXkgcHJldmlvdXMgZW1haWwgcmVnYXJkaW5n IGR1YWwgaG9taW5nICYgZmFpbHVyZQ0KPj4gZGV0ZWN0aW9uLg0KPj4NCj4+IENoZWVycywNCj4+ DQo+PiBNYXJjDQo+PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+PiBGcm9tOiA8YW5p bHJAYWNjdG9uLmNvbT4NCj4+IFRvOiAiQXNhZiBIZW5pZyIgPGFoZW5pZ0BtcnYuY29tPg0KPj4g Q2M6IDxsMnZwbkBpZXRmLm9yZz47IDxtcGxzQGlldGYub3JnPjsgPG1wbHNAbGlzdHMuaWV0Zi5v cmc+DQo+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDQsIDIwMDYgMzo1MSBQTQ0KPj4gU3Vi amVjdDogUmU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBNQUMgV2l0aGRyYXdhbCBpbiBILVZQTFMgRHVh bC1ob21lZA0KTVRVLXMNCj4+DQo+Pg0KPj4+DQo+Pj4gSSB3b3VsZCB0aGluayAoQSksIHNpbmNl IE1BQyBXaXRoZHJhdyBpcyB1c2VkIGJ5IGEgbWVtYmVyIG9mIHRoZSBWUExTDQo+PiBtZXNoDQo+ Pj4gdG8gbm90aWZ5IGl0cyBuZWlnaGJvcnMgb2YgYSBjaGFuZ2UgaW4gdG9wb2xvZ3kgLS0gZXhj ZXB0IHRoYXQgdGhlIE1XDQo+Pj4gc2hvdWxkIGJlIHNlbnQgb25seSBhZnRlciBzd2l0Y2hpbmcg b3ZlciB0byB0aGUgc3RhbmRieSBWQy4gVGhlIFBFLXJzDQo+Pj4gc2hvdWxkIGJlIGp1c3QgYXMg YXdhcmUgb2YgdGhlIHN3aXRjaG92ZXIgYXMgdGhlIE1UVS1zLg0KPj4+DQo+Pj4gVGhlIGxhcmdl ciBhbWJpZ3VpdHkgaGVyZSAoaW4gbXkgb3BpbmlvbikgaXMgdGhlIGxhY2sgb2Ygc3BlY2lmaWNh dGlvbg0KPj4+IGFyb3VuZCBqdXN0IGhvdyBILVZQTFMgZHVhbCBob21pbmcgd29ya3MsIGkuZSwg aG93IHRoZSBmYWlsdXJlIGlzDQo+PiBkZXRlY3RlZA0KPj4+IGFuZCB3aGF0IHRoZSB0aW1lIGxp bWl0cyBhcmUgZm9yIHRoYXQgZGV0ZWN0aW9uIGFuZCBzdWJzZXF1ZW50DQpyZWNvdmVyeS4NCj4+ PiBUaGF0IHBhcnQgaXMgY3VycmVudGx5IGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4NCj4+Pg0K Pj4+IFJlZ2FyZHMsDQo+Pj4gQW5pbA0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAg ICAgICAgICAgICAgICAgIkFzYWYgSGVuaWciDQo+Pj4gICAgICAgICAgICAgICAgICAgIDxhaGVu aWdAbXJ2LmNvICAgICAgIFRvOiAgICAgPGwydnBuQGlldGYub3JnPiwNCj4+PiA8bXBsc0BsaXN0 cy5pZXRmLm9yZz4sIDxtcGxzQGlldGYub3JnPg0KPj4+ICAgICAgICAgICAgICAgICAgICBtPiAg ICAgICAgICAgICAgICAgICBjYzoNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU3ViamVjdDogICAgIFF1ZXN0aW9uIHJlZ2FyZGluZw0KPj4+IE1BQyBXaXRoZHJh d2FsIGluIEgtVlBMUyBEdWFsLWhvbWVkIE1UVS1zDQo+Pj4gICAgICAgICAgICAgICAgICAgIDA5 LzI2LzIwMDYNCj4+PiAgICAgICAgICAgICAgICAgICAgMDQ6MTEgQU0NCj4+Pg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4NCj4+PiBJdCBpcyB5ZXQgdW5jbGVhciBmcm9tIGRyYWZ0DQo+Pj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxk cC0wOS50eHQNCndobw0KPj4+IGlzDQo+Pj4gcmVzcG9uc2libGUgdG8gc2VuZCB0aGUgTUFDIFdp dGhkcmF3YWwgbWVzc2FnZSB0byB0aGUgc2Vjb25kYXJ5IFBFLXJzDQo+PiB3aGVuDQo+Pj4gZmFp bC1vdmVyIG9jY3VyZXMgaW4gYW4gSC1WUExTIGR1YWwgaG9tZWQgTVRVLXMgc2NlbmFyaW8uDQo+ Pj4NCj4+PiBJdCBpcyBrbm93biB0aGF0IHdoZW4gYSBwcmltYXJ5IFZDIGZhaWxzIGluIGEgZHVh bC1ob21pbmcgc2NlbmFyaW8gdGhlDQo+Pj4gUEUtcnMgY29ubmVjdGVkIHRvIHRoZSBzZWNvbmRh cnkgVkMgc2hvdWxkIHJlbGVhcm4gdGhlIE1BQyBhZGRyZXNzZXMNCj4+PiBiZWhpbmQNCj4+PiB0 aGUgTVRVLXMuIEluIG9yZGVyIHRvIG1ha2UgdGhpcyBwcm9jZXNzIGZhc3RlciB0aGlzICJzZWNv bmRhcnkiIFBFLXJzDQo+Pj4gc2hvdWxkIGZsdXNoIHRoZSByZWxldmFudCBwcmV2aW91c2x5IGxl YXJuZWQgTUFDIGFkZHJlc3Nlcy4gRm9yIHRoYXQgdG8NCj4+PiBoYXBwZW4gd2UgaGF2ZSB0d28g b3B0aW9uczoNCj4+Pg0KPj4+IEEpIFRoZSBwcmltYXJ5IFBFLXJzIHdvdWxkIHNlbmQgdGhlIE1B QyBXaXRoZHJhd2FsIG1lc3NhZ2UgdG8gdGhlDQo+Pj4gc2Vjb25kYXJ5DQo+Pj4gUEUtcnMgKGFu ZCBhbGwgb3RoZXIgUEUtcykgdGhlIG1pbnV0ZSBpdCByZWNvZ25pemVzIHRoYXQgaXRzIFZDIGhh cw0KPj4+IGZhaWxlZC4NCj4+PiBCKSBUaGUgTVRVLXMgaXRzZWxmIHdvdWxkIHNlbmQgdGhlIE1B QyBXaXRoZHJhd2FsIHRvIHRoZSBzZWNvbmRhcnkNClBFLXJzDQo+Pj4gdGhlIG1pbnV0ZSBpdCBz d2l0Y2hlcyBmcm9tIHByaW1hcnkgdG8gc2Vjb25kYXJ5IFZDLiBUaGUgc2Vjb25kYXJ5DQpQRS1y cw0KPj4+IHdvdWxkIGJlIHJlc3BvbnNpYmxlIHRvIHByb3BlZ2F0ZSB0aGlzIG1lc3NhZ2UgdG8g YWxsIG90aGVyIFBFcyBpbiB0aGUNCj4+PiBWUExTDQo+Pj4gZG9tYWluICh0aGlzIG9wdGlvbiBp cyByZWNvbW1lbmRlZCBieQ0KPj4+IGRyYWZ0LXBkdXR0YS1sMnZwbi12cGxzLWxkcC1tYWMtb3B0 LTAwLnR4dCkuDQo+Pj4NCj4+PiBXaGljaCBvcHRpb24gaXMgcHJlZmVycmVkICA/DQo+Pj4NCj4+ Pg0KPj4+IFRoYW5rcyBmb3IgYW55IGhlbHAuDQo+Pj4gQXNhZiBIZW5pZw0KPj4+IE1SViBjb21t dW5pY2F0aW9ucw0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0K Pg0KPg0KPg0KPg0KPg0KDQoNCg0KDQo= From l2vpn-bounces@ietf.org Wed Oct 04 17:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVElw-00036S-F4; Wed, 04 Oct 2006 17:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVElv-00036N-Jf for l2vpn@ietf.org; Wed, 04 Oct 2006 17:59:23 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVElv-00013E-0C for l2vpn@ietf.org; Wed, 04 Oct 2006 17:59:23 -0400 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA04046; Wed, 4 Oct 2006 14:59:19 -0700 (PDT) Message-ID: <041b01c6e800$56c2f860$0300a8c0@IBMT41ML> From: "Marc Lasserre" To: References: Date: Wed, 4 Oct 2006 23:59:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org > >> In the original question asked, the question was about whether the > primary >> PE could generate the MW. >> In this case, the backup link between the MTU and the secondary PE is >> unknown to the primary PE. This is valid for both PW and QinQ links. The > MW >> message is sent when the secondary link becomes active with PW and when > the >> port is unblocked with QinQ. > > Fair enough, and my point was that the PE (secondary) could source the MW > rather than the MTU. The secondary PE could only do it if it were aware of the link status, i.e. whether it has been made active. At this stage, there is no specified way to signal this fact for PW. Some colleagues and I are actually planning to submit a new draft describing such extensions - specifically applicable to dual-homed MTUs. > >> No, it does not imply that both MTU and PE devices be from the same > vendor. >> It implies that one or more protocols be used between them. Such > protocols >> are standard protocols. Only the ones supported by both could obvously be > >> used. As far as performance is concerned , there would be as good and >> predictable as what the selected protocol can support to detect failures. > If >> IGP/LDP or STP were to be used, detection time would be in the order of > tens >> of seconds, with RSTP in the order of seconds and with BFD in the order > of >> tens of msec. > > I'd rather have specified a very lightweight keepalive protocol for a > configuration as simple as dual-homing. In the absence of that, something > like the above verbiage would be useful in the standard (in addition to > hardware failure detection). Isn't BFD what you are looking for? > > Regards, > Anil > > > > > > "Marc > Lasserre" To: > , , "Dutta, Pranjal" > nenet.com> , "Ali > Sajassi \(sajassi\)" > > 10/04/2006 Subject: Re: Question > regarding MAC Withdrawal in H-VPLS Dual-homed > 05:29 PM MTU-s > > > > > > > >> >> Marc, >> >>> I do not see how the primary PE-rs can be aware that the secondary PW > has >> >>> been made active, since the PW between the MTU-s and the primary PE-rs > is >> no >>> longer available and no protocol is defined to convey such information. >> The >>> only option possible is for the MTU-s to trigger the MAC withdrawal >> towards >>> it secondary PE-rs once the secondary PW has been made active. >> >> In most protocols which allow a standby link, both sides of the standby >> link are aware that it's been >> pressed into service. My suggestion was this being the case, the PE-rs >> needs no help from the >> MTU-s in generating a MAC Withdraw. Also isn't it possible there may be > no >> PW between the >> MTU-s and PE-rs, as with QinQ? Perhaps you have a different solution in >> mind than I do, but that's >> the result of a partially specified mechanism -- it's tough to see >> supporting protocols the same >> way without a shared understanding of how the whole thing works. >> > > In the original question asked, the question was about whether the primary > PE could generate the MW. > In this case, the backup link between the MTU and the secondary PE is > unknown to the primary PE. This is valid for both PW and QinQ links. The > MW > > message is sent when the secondary link becomes active with PW and when > the > > port is unblocked with QinQ. > >>> Since the MTU is responsible for activating its secondary link, it is a >>> local decision to the MTU to decide how a failure is detected and acted >>> upon. No new protocol for VPLS has been specified for failure detection. >> As >>> I said before, the means and how fast it takes to detect failures can be >>> based upon different mechanisms (e.g. physical loss of signal, BFD, STP, >>> loss of IGP/LDP adjacency), each with their respective failure detection >>> times. A similar sentence could be added to the draft if it helps. >> Vendors >>> can decide to implement any of such methods and hence provide product >>> differentiation. >> >> Essentially this says that MTU-s and PE-rs must always be from the same >> vendor, and that dual-homing >> characteristics are unpredictable and implementation-dependent. Yet, the >> standard provide a component >> to help it out. Perhaps there is history behind this reasoning I am >> unaware >> of, but it seems limiting. > > No, it does not imply that both MTU and PE devices be from the same > vendor. > > It implies that one or more protocols be used between them. Such protocols > are standard protocols. Only the ones supported by both could obvously be > used. As far as performance is concerned , there would be as good and > predictable as what the selected protocol can support to detect failures. > If > IGP/LDP or STP were to be used, detection time would be in the order of > tens > of seconds, with RSTP in the order of seconds and with BFD in the order of > tens of msec. > > Cheers, > Marc > >> >> Regards, >> Anil >> >> >> >> >> "Marc >> Lasserre" To: >> > , , "Dutta, Pranjal" >> nenet.com> , "Ali > >> Sajassi \(sajassi\)" >> >> 10/04/2006 Subject: Re: Question >> regarding MAC Withdrawal in H-VPLS Dual-homed >> 04:30 PM MTU-s >> >> >> >> >> >> >> >>> >>>> It is option B as already mentioned by Ali and Pranjal. >>> >>> As already explained by Asaf and I, that may not be the correct option. >> >> I do not see how the primary PE-rs can be aware that the secondary PW has >> been made active, since the PW between the MTU-s and the primary PE-rs is >> no >> longer available and no protocol is defined to convey such information. >> The >> >> only option possible is for the MTU-s to trigger the MAC withdrawal >> towards >> >> it secondary PE-rs once the secondary PW has been made active. >> >>> >>>> See my answer in my previous email regarding dual homing >>>> & failure detection. >>> >>> Your answer does not address the issues raised by Max and I. Please see >>> those emails again and try to address each technical issue and point >>> raised. >> >> Since the MTU is responsible for activating its secondary link, it is a >> local decision to the MTU to decide how a failure is detected and acted >> upon. No new protocol for VPLS has been specified for failure detection. >> As >> >> I said before, the means and how fast it takes to detect failures can be >> based upon different mechanisms (e.g. physical loss of signal, BFD, STP, >> loss of IGP/LDP adjacency), each with their respective failure detection >> times. A similar sentence could be added to the draft if it helps. >> Vendors >> >> can decide to implement any of such methods and hence provide product >> differentiation. >> >>> >>> This being an IETF working group, we collectively make decisions based > on >>> consensus of working group members. The writers don't get to make >>> arbitrary >>> calls without technical discussion and agreement with other members and >>> vendors based on their experience. >> >> I think that I am aware of that... First of all, I have not made any >> arbitrary calls. Secondly, I am open to discussing any technical matters. >> All the different revisions of the draft have been based on WG feedback > so >> far. >> >>> >>> Thanks, >>> Anil >>> >>> >>> >>> >>> "Marc >>> Lasserre" To: "Asaf Henig" >>> , >>> , "Ali >>> Sajassi \(sajassi\)" , >>> nenet.com> "Dutta, Pranjal" >>> >>> Subject: Re: Question >>> regarding MAC Withdrawal in H-VPLS Dual-homed >>> 10/04/2006 MTU-s >>> 12:30 PM >>> >>> >>> >>> >>> >>> >>> It is option B as already mentioned by Ali and Pranjal. >>> See my answer in my previous email regarding dual homing & failure >>> detection. >>> >>> Cheers, >>> >>> Marc >>> ----- Original Message ----- >>> From: >>> To: "Asaf Henig" >>> Cc: ; ; >>> Sent: Wednesday, October 04, 2006 3:51 PM >>> Subject: Re: Question regarding MAC Withdrawal in H-VPLS Dual-homed > MTU-s >>> >>> >>>> >>>> I would think (A), since MAC Withdraw is used by a member of the VPLS >>> mesh >>>> to notify its neighbors of a change in topology -- except that the MW >>>> should be sent only after switching over to the standby VC. The PE-rs >>>> should be just as aware of the switchover as the MTU-s. >>>> >>>> The larger ambiguity here (in my opinion) is the lack of specification >>>> around just how H-VPLS dual homing works, i.e, how the failure is >>> detected >>>> and what the time limits are for that detection and subsequent > recovery. >>>> That part is currently implementation-dependent. >>>> >>>> Regards, >>>> Anil >>>> >>>> >>>> >>>> >>>> >>>> "Asaf Henig" >>>> , >>>> , >>>> m> cc: >>>> Subject: Question regarding >>>> MAC Withdrawal in H-VPLS Dual-homed MTU-s >>>> 09/26/2006 >>>> 04:11 AM >>>> >>>> >>>> >>>> >>>> >>>> >>>> It is yet unclear from draft >>>> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt > who >>>> is >>>> responsible to send the MAC Withdrawal message to the secondary PE-rs >>> when >>>> fail-over occures in an H-VPLS dual homed MTU-s scenario. >>>> >>>> It is known that when a primary VC fails in a dual-homing scenario the >>>> PE-rs connected to the secondary VC should relearn the MAC addresses >>>> behind >>>> the MTU-s. In order to make this process faster this "secondary" PE-rs >>>> should flush the relevant previously learned MAC addresses. For that to >>>> happen we have two options: >>>> >>>> A) The primary PE-rs would send the MAC Withdrawal message to the >>>> secondary >>>> PE-rs (and all other PE-s) the minute it recognizes that its VC has >>>> failed. >>>> B) The MTU-s itself would send the MAC Withdrawal to the secondary > PE-rs >>>> the minute it switches from primary to secondary VC. The secondary > PE-rs >>>> would be responsible to propegate this message to all other PEs in the >>>> VPLS >>>> domain (this option is recommended by >>>> draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt). >>>> >>>> Which option is preferred ? >>>> >>>> >>>> Thanks for any help. >>>> Asaf Henig >>>> MRV communications >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > > From l2vpn-bounces@ietf.org Thu Oct 05 05:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPH8-0002iX-W6; Thu, 05 Oct 2006 05:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPH8-0002iS-Eu for l2vpn@ietf.org; Thu, 05 Oct 2006 05:12:18 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVPH6-0004kE-5e for l2vpn@ietf.org; Thu, 05 Oct 2006 05:12:18 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k959BRVT025561; Thu, 5 Oct 2006 04:11:28 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Oct 2006 11:11:27 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550ACBFBF8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Thomas D. Nadeau" , l2vpn@ietf.org Date: Thu, 5 Oct 2006 11:11:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Shane Amante , Vach Kompella , A Kiran Koushik S Subject: RE: draft-nadeau-l2vpn-vpls-mib-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi.... I only did a very very quick scan of the MIB module in the document. Here are some findings (I understand this is not yet at WGLC, so understandably somethings are not yet in good shape): - Read-write objects/tables need to specify persistency behaviour This should be well know to this WG and the authors by now, and I keep encouring that people do so from the very first stages of writing a MIB document. - There is two times the copyright statement in the DESCRIPTION clause of vplsGenericDraft01MIB. - In DESCRIPTION clause of vplsConfigEntry it is stated that an active row CANNOT be changed, while in the RowStatus object of that table he states that an active row CAN be changed. That is conflicting info. - naming concepts/consistency VplsConfigEntry ::= SEQUENCE { vplsIndex Unsigned32, vplsName SnmpAdminString, vplsDescr SnmpAdminString, vplsAdminStatus INTEGER, vplsMacLearning TruthValue, vplsDiscardUnknownDest TruthValue, vplsMacAging TruthValue, vplsConfigFwdFullHighWatermark Unsigned32, vplsConfigFwdFullLowWatermark Unsigned32, vplsRowStatus RowStatus, vplsMtu Unsigned32 } I would have all those objects have a prefix of vplsConfigXxxx - same naming issue here: VplsStatusEntry ::= SEQUENCE { vplsOperStatus INTEGER, vplsVpnId VPNIdOrZero } - and here: VplsPwBindEntry ::= SEQUENCE { vplsPwIndex PwIndexType, vplsPwConfigType INTEGER, vplsPwBindRowStatus RowStatus } - the vplsModuleReadOnlyCompliance seems bogus to me. - all groups seem mandatory, but listed separately instead of being listed as MANDATORY-GROUPS - speaks about ReadOnly compliance while non of the writable objects are specified as being OK to be supported read-only I have no looked at the other MIB module in there; Please make sure that if any similar issues as above are in that module that you also address them. Hope this helps, Bert > -----Original Message----- > From: Thomas D. Nadeau [mailto:thomasdnadeau@gmail.com] > Sent: Thursday, September 14, 2006 16:22 > To: l2vpn@ietf.org > Cc: Shane Amante; Vach Kompella; A Kiran Koushik S > Subject: draft-nadeau-l2vpn-vpls-mib-01.txt > > > > L2VPN WG, > > Kiran and I have worked hard to try to incorporate > all of the comments brought by the WG after we presented > the draft. Many objected to the document being accepted > as a WG draft until these things were incorporated. Now > that most of these comments have been added, we would > like to again ask that the document be accepted as a > L2 VPN WG draft. > > --Tom > > > From l2vpn-bounces@ietf.org Tue Oct 17 16:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvJQ-0006bD-93; Tue, 17 Oct 2006 16:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCJ-00022B-2d; Tue, 17 Oct 2006 16:05:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuxr-0004iI-6P; Tue, 17 Oct 2006 15:51:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZuxq-0001sr-QG; Tue, 17 Oct 2006 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 93414175DA; Tue, 17 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZuws-0007Iu-4y; Tue, 17 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-03.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --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 : Requirements for Multicast Support in Virtual Private LAN Services Author(s) : Y. Kamite, et al. Filename : draft-ietf-l2vpn-vpls-mcast-reqts-03.txt Pages : 29 Date : 2006-10-17 This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-vpls-mcast-reqts-03.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-vpls-mcast-reqts-03.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: <2006-10-17125422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-17125422.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Mon Oct 23 10:14:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0YK-0007VT-3G; Mon, 23 Oct 2006 10:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0YJ-0007VO-HI for l2vpn@ietf.org; Mon, 23 Oct 2006 10:13:19 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0YF-0002q4-8Y for l2vpn@ietf.org; Mon, 23 Oct 2006 10:13:19 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id E59CC6436B for ; Mon, 23 Oct 2006 08:13:08 -0600 (MDT) Message-ID: <453CCDF4.40506@castlepoint.net> Date: Mon, 23 Oct 2006 08:13:08 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: IETF 67: L2VPN WG Agenda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi, The L2VPN WG during IETF 67 is meeting on: MONDAY, November 6, 2006, 1300-1500 The following is the L2VPN WG meeting agenda. Please let Vach and/or I know if there are corrections to this agenda: http://www3.ietf.org/proceedings/06nov/agenda/l2vpn.txt Since we are meeting on Monday, Vach & I request that you send us your presentations *no later* than Sunday, 11/5, by 8:00 PM PDT, in order that we can post them to the IETF Web Site in time for the meeting. Thanks! -shane & Vach From l2vpn-bounces@ietf.org Tue Oct 31 04:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeqGq-0006lO-Ea; Tue, 31 Oct 2006 04:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeqGp-0006lA-2T; Tue, 31 Oct 2006 04:50:59 -0500 Received: from mx2.lb.mrv.com ([66.43.110.200] helo=chmailqsrv.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeqGn-0005pM-HZ; Tue, 31 Oct 2006 04:50:59 -0500 Received: from chmailqsrv.int.mrv.com (127.0.0.1) by chmailqsrv.int.mrv.com (MlfMTA v3.2r1b3) id h8se2s0171se; Tue, 31 Oct 2006 01:49:29 -0800 (envelope-from ) Received: from chmailsrv.int.mrv.com ([192.168.11.19]) by chmailqsrv.int.mrv.com (SonicWALL 5.0.0.8239) with ESMTP; Tue, 31 Oct 2006 01:49:29 -0800 Received: from zeus.yok.int.mrv.com ([172.21.9.11]) by chmailsrv.int.mrv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 01:50:52 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FCD2.09A1618E" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 31 Oct 2006 11:50:46 +0200 Message-ID: <685D66DF6DB563459D23ECD8B30C73A40CD40D@zeus.yok.int.mrv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two Questions about LSP-ping/traceroute (RFC 4379) Thread-Index: Acb80gmamYYPNRFXSQ+1EveWjCsQSQ== From: "Asaf Henig" To: , , X-OriginalArrivalTime: 31 Oct 2006 09:50:52.0183 (UTC) FILETIME=[0D395270:01C6FCD2] X-Mlf-Version: 5.0.0.8239 X-Mlf-UniqueId: o200610310949290075620 X-Spam-Score: 0.5 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: Two Questions about LSP-ping/traceroute (RFC 4379) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FCD2.09A1618E Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 1) How should LSP-ping deal with PHP mode (penultimate-hop-popping) ? Suppose I am sending an mpls echo request packet to check a regular lsp = and the packet is sent with the proper label X (shimmed between L2 and = L3) and a FEC Stack TLV which includes a LDP-IpV4 sub-tlv. This packet may reach its destination, some egress LER Y, without any = shimmed label due to the use of=20 PHP mode. Section 4.2 in RFC 4379 suggest that we use Nil-FEC sub-TLV to = account for the missing Label that was popped. The question is which LSR = insert this Nil-FEC. Note that the LER that initiated the echo-request = doesn't know in advance if the label is going to be popped at the = penultimate LSR. Moreover the penultimate LSR it self cannot add this = FEC since it has no trigger to process the packet as he recieves a = regular labeled packet and simply performs a popping and forwarding = procedures. ? It is furthermore unclear wether in this case we should also use = Explicite Null label (label 0) or not?.=20 2) Checking Pseudowires (Virtual-Circuits) using mpls-Ping. Though regular mpls-ping, as mentioned in RFC 4379, supports the = checking of a pseudowire using the proper sub-tlv FECs and labels, some = vendors have decided to use VCCV (draft-ietf-pwe3-vccv) for such = checking. It is unclear to me wether Interoperability here will work. In = otherwords, if one vendor, for example, sends a regular FEC128 = mpls-echo-request packet (without signaling VCCV first) to a vendor = supporting VCCV is this packet going to be processed and would = echo-reply be sent ?. Thanks for any help. Asaf Henig=20 MRV communications. =20 =20 ------_=_NextPart_001_01C6FCD2.09A1618E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Two Questions about LSP-ping/traceroute (RFC 4379)

1) How should LSP-ping deal with PHP mode = (penultimate-hop-popping) ?

Suppose I am sending an mpls echo request packet to check a regular lsp = and the packet is sent with the proper label X (shimmed between L2 and = L3) and a FEC Stack TLV which includes a LDP-IpV4 sub-tlv.
This packet may reach its destination, some egress LER Y, without any = shimmed label due to the use of
PHP mode. Section 4.2 in RFC 4379 suggest that we use Nil-FEC sub-TLV to = account for the missing Label that was popped. The question is which LSR = insert this Nil-FEC. Note that the LER that initiated the echo-request = doesn't know in advance if the label is going to be popped at the = penultimate LSR. Moreover the penultimate LSR it self cannot add this = FEC since it has no trigger to process the packet as he recieves a = regular labeled packet and simply performs a popping and forwarding = procedures. ?
It is furthermore unclear wether in this case we should also use = Explicite Null label (label 0) or not?.

2) Checking Pseudowires (Virtual-Circuits) using mpls-Ping.

Though regular mpls-ping, as mentioned in RFC 4379, supports the = checking of a pseudowire using the proper sub-tlv FECs and labels, some = vendors have decided to use VCCV (draft-ietf-pwe3-vccv) for such = checking.
It is unclear to me wether Interoperability here will work. In = otherwords, if one vendor, for example,  sends a regular FEC128 = mpls-echo-request packet (without signaling VCCV first) to a vendor = supporting VCCV is this packet going to be processed and would = echo-reply be sent ?.

Thanks for any help.

Asaf Henig
MRV communications.     
 

------_=_NextPart_001_01C6FCD2.09A1618E--