From l2vpn-bounces@ietf.org Tue Sep 21 18:24:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08415 for ; Tue, 21 Sep 2004 18:24:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9tAU-000061-O1 for l2vpn-web-archive@ietf.org; Tue, 21 Sep 2004 18:31:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9sub-0003Bj-9I; Tue, 21 Sep 2004 18:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9smy-0006GB-NO; Tue, 21 Sep 2004 18:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05585; Tue, 21 Sep 2004 18:07:06 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9stN-0007z9-8B; Tue, 21 Sep 2004 18:13:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2004 15:18:50 +0000 X-BrightmailFiltered: true Received: from sajassi-w2k4.cisco.com (dhcp-128-107-178-235.cisco.com [128.107.178.235]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8LM6hSJ018007; Tue, 21 Sep 2004 15:06:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20040921144023.027c7438@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Sep 2004 15:06:45 -0700 To: Per Ole Klemetsrud , Internet-Drafts@ietf.org From: Ali Sajassi In-Reply-To: References: <200409201941.PAA05329@ietf.org> <200409201941.PAA05329@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: l2vpn@ietf.org Subject: Re: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 11:22 PM 9/20/2004 +0200, Per Ole Klemetsrud wrote: >Why references to VPLS-LDP in this framework? My employer (service >provider) has deployed BGP signaled VPLS with great success, and although >many vendors have their (non technical) reasons for implementing VPLS-LDP, >I see no reason to limit the scope of documents such as these to only VPLS-LDP. The references to VPLS-LDP was given to illustrate that an end-to-end service can span across different network types - e.g, mixture of .1ad and mpls which is discussed in section 12 of that draft. However, the OAM requirements and framework shall be applied to any type of VPLS regardless of what type of signaling approach is used to setup the PWs. -Ali >If there IS a technical reason for this draft to reference VPLS-LDP, I >must have missed it, and a clarification would be welcome. > >Regards, >Per Ole Klemetsrud > From l2vpn-bounces@ietf.org Wed Sep 22 05:51:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18676 for ; Wed, 22 Sep 2004 05:51:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3sj-0002pZ-8e for l2vpn-web-archive@ietf.org; Wed, 22 Sep 2004 05:57:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3hh-0008Tl-9R; Wed, 22 Sep 2004 05:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3fh-00080P-Gy for l2vpn@megatron.ietf.org; Wed, 22 Sep 2004 05:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18156 for ; Wed, 22 Sep 2004 05:44:18 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3mF-0002gu-Hx for l2vpn@ietf.org; Wed, 22 Sep 2004 05:51:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8M9gRN05554; Wed, 22 Sep 2004 05:42:27 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Sep 2004 05:42:26 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB016968AF@zcarhxm1.corp.nortel.com> From: "Dinesh Mohan" To: "'Per Ole Klemetsrud'" Date: Wed, 22 Sep 2004 05:42:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A088.6C301BFD" X-Spam-Score: 0.5 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: "'l2vpn@ietf.org'" , "'Ali Sajassi'" Subject: RE: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-00.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4A088.6C301BFD Content-Type: text/plain Per Ole, Thank you for your review of the draft. Reference to VPLS-BGP will be added in the next version, along with other things pointed out during the 2-week WG call on the mailing list. The omission was unintentional as pointed out by Ali. Regards, Dinesh -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi Sent: Tuesday, September 21, 2004 6:07 PM To: Per Ole Klemetsrud; Internet-Drafts@ietf.org Cc: l2vpn@ietf.org Subject: Re: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-00.txt At 11:22 PM 9/20/2004 +0200, Per Ole Klemetsrud wrote: >Why references to VPLS-LDP in this framework? My employer (service >provider) has deployed BGP signaled VPLS with great success, and although >many vendors have their (non technical) reasons for implementing VPLS-LDP, >I see no reason to limit the scope of documents such as these to only VPLS-LDP. The references to VPLS-LDP was given to illustrate that an end-to-end service can span across different network types - e.g, mixture of .1ad and mpls which is discussed in section 12 of that draft. However, the OAM requirements and framework shall be applied to any type of VPLS regardless of what type of signaling approach is used to setup the PWs. -Ali >If there IS a technical reason for this draft to reference VPLS-LDP, I >must have missed it, and a clarification would be welcome. > >Regards, >Per Ole Klemetsrud > ------_=_NextPart_001_01C4A088.6C301BFD Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-00.txt

Per Ole,

Thank you for your review of the draft. Reference to = VPLS-BGP will be added in the next version, along with other things = pointed out during the 2-week WG call on the mailing list. The omission = was unintentional as pointed out by Ali.

Regards,
Dinesh
-----Original Message-----
From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Ali Sajassi
Sent: Tuesday, September 21, 2004 6:07 PM
To: Per Ole Klemetsrud; = Internet-Drafts@ietf.org
Cc: l2vpn@ietf.org
Subject: Re: I-D = ACTION:draft-ietf-l2vpn-oam-req-frmk-00.txt

At 11:22 PM 9/20/2004 +0200, Per Ole Klemetsrud = wrote:
>Why references to VPLS-LDP in this = framework?  My employer (service
>provider) has deployed BGP signaled VPLS with = great success, and although
>many vendors have their (non technical) reasons = for implementing VPLS-LDP,
>I see no reason to limit the scope of documents = such as these to only VPLS-LDP.

The references to VPLS-LDP was given to illustrate = that an end-to-end
service can span across different network = types  - e.g, mixture of .1ad and
mpls which is discussed in section 12 of that draft. = However, the OAM
requirements and framework shall be applied to any = type of VPLS regardless
of what type of signaling approach is used to setup = the PWs.

-Ali


>If there IS a technical reason for this draft to = reference VPLS-LDP, I
>must have missed it, and a clarification would = be welcome.
>
>Regards,
>Per Ole Klemetsrud
>



------_=_NextPart_001_01C4A088.6C301BFD-- From l2vpn-bounces@ietf.org Wed Sep 22 16:00:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08495 for ; Wed, 22 Sep 2004 16:00:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CADOK-0006cU-Q7 for l2vpn-web-archive@ietf.org; Wed, 22 Sep 2004 16:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CACsy-0004Vy-2h; Wed, 22 Sep 2004 15:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CACsJ-00045I-TN; Wed, 22 Sep 2004 15:33:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04277; Wed, 22 Sep 2004 15:33:57 -0400 (EDT) Message-Id: <200409221933.PAA04277@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 22 Sep 2004 15:33:57 -0400 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-ldp-05.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --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 : Virtual Private LAN Services over MPLS Author(s) : M. Lasserre, V. Kompella Filename : draft-ietf-l2vpn-vpls-ldp-05.txt Pages : 25 Date : 2004-9-22 This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling demultiplexor labels, extending [PWE3-CTRL] and rudimentary support for availability (multi-homing). It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3- ETHERNET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-05.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-ldp-05.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-ldp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-22153624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-ldp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-ldp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-22153624.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Sep 22 20:17:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28967 for ; Wed, 22 Sep 2004 20:17:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAHPX-0003Xn-Si for l2vpn-web-archive@ietf.org; Wed, 22 Sep 2004 20:24:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAHEp-00030g-HL; Wed, 22 Sep 2004 20:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAHDA-0002UC-LZ for l2vpn@megatron.ietf.org; Wed, 22 Sep 2004 20:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28633 for ; Wed, 22 Sep 2004 20:11:46 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAHJn-0003Rn-69 for l2vpn@ietf.org; Wed, 22 Sep 2004 20:18:43 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Sep 2004 17:23:28 +0000 X-BrightmailFiltered: true Received: from sajassi-w2k4.cisco.com (dhcp-171-68-147-106.cisco.com [171.68.147.106]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8N0B5wq003029; Wed, 22 Sep 2004 17:11:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Sep 2004 17:09:26 -0700 To: Loa Andersson , L2VPN , Rick Wilder , Vach Kompella From: Ali Sajassi In-Reply-To: <41383CBE.3080700@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc? 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd There are some areas of ambiguity and inaccuracies in this draft where I'd like to be addressed first. Sec 5.1, 2nd para, pg 9: ----------------------------------- "In this scenario, one issue that SPs needs to address is that different sites of a customer may have a mismatch of 802.1Q tags (either different .1q tags on each side, or .1q tag on one side, and untagged on the other side). For example, customer connectivity at one site will be tied to a port on a VPLS PE/MTU that will utilize a PW for tunneling this packet through the network. Customer connectivity at another site will be interconnected to a port on a QinQ switch that will utilize QinQ techniques (see the figure below). By mandating that "the Ethernet packet that traverses a VPLS is always a customer Ethernet packet", the [VPLS-LDP] solution naturally accommodates this need. " If the access networks are based on 802.1ad standards (formerly QinQ), then this issue has already been addressed since .1ad standard allows for VLAN tag translation at the UNI (e.g., two customer sites can have two different tags). Also the issue of port mode versus vlan mode is orthogonal to the type of PW used (e.g., tagged mode versus raw mode). In other words, in your example above, I can still have port mode service between MPLS and QinQ access and use tagged mode PW over MPLS although raw mode should be the preferred mode. Sec 5.2, 1st para, pg 10: ------------------------------------- "Providers that have already deployed VLAN based core may choose to overlay an MPLS edge on top of this existing L2 domain. In this method, provider 802.1Q tags maybe assigned to MPLS backbone links that are then used for carrying VPLS traffic. While this approach may allow for a simple transition to solve some immediate deficiencies of a pure L2 network, it still does not solve some of the underlying problems associated with protocols such as spanning tree. In this case, although MPLS may provide some scaling advantages, the limitations associated with spanning tree can still pose potential problems to the overall infrastructure. " This paragraph is not clear to me at all and I am not sure what is suggested here. I suggest if this is not viable solution, then delete this paragraph instead of suggesting something that creates more issues. Sec 5.2, 2nd para, pg 11: ------------------------------------- "Alternatively, a parallel VPLS core is built and connected to the existing 802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively treated as a super-island. Then one by one, each individual Ethernet access island is disconnected from the existing core (i.e. super- island) and connected to the VPLS core. The migration issues then become similar to those described in 5.1. " Need to mention that inter-operability aspects between .1ad network and MPLS/VPLS network shall be worked out before such migration. Sec 5.2, 3rd para, pg 11: ------------------------------------ "A third approach consists in configuring a second VPLS control plane in the existing QinQ PE, hence implementing two virtual networks over a single physical infrastructure. Once the PE/MPLS control plane is running, each customer can be separately migrated through a reconfiguration of its corresponding access ports. For increased stability, the dual control plane approach might require dedicating some links or PEs to the MPLS/VPLS network." It should be mentioned that this is only feasible when the QinQ PE can be easily upgraded (e.g., via software/firmware) to MPLS PE; otherwise, you need to forklift everything. Sec 6, 1st para, pg 11: The first paragraph talks about two instances of multi-homing but only a single instance is mentioned in the text below it. Sec 7, 3rd para, pg 13: This paragraph is not clear. Sec 7, 4th para, pg 13: I assume that the loop protection scheme that you are talking in here is the loop within the customer network and not the provider network - e.g., due mis-configuration of its loop prevention protocol or lack of one. If that is the case, then it should be clearly specified in this paragraph because having the loop within the customer network (when it is dual-homed) doesn't mean that there is a loop inside the provider network. Sec 8, pg14: It should be mentioned that in steady state (e.g., when there is no failure), there shall be no re-ordering of Ethernet packets within a VPLS instance. This can be achieved by ensuring that ECMP algorithms do inter-flow (instead of intra flow) load balancing which is typically the case - e.g., load balance among different PWs and thus different VPLS instances. Sec 13.1, pg 16: Customer tag enforcement should be done at the UNI and I don't see how a link between a CE and a PE can be shared by multiple customers. Also in the last sentence, do you mean a bridge instead of a router. The only case that I can think of is for .1q (and not .1ad since .1ad allows for tag translation). If it is for .1q, then it should be clearly stated and it should be mention that in order to enforce non-overlapping VLAN among different customer, an ACL per customer AC should be used. Sec 13.2, pg 16: There should be a distinction made between broadcast domain and mac address domain. FIB tables guarantee the separation of MAC address domains among different VPLS instances and a full-mesh of PWs per VPLS instance guarantees the separation of broadcast domains among VPLS instances. So the two toegther guarantee traffic separation between VPLS instances. The section should be modified to reflect this accordingly. Sec 15, pg 20, one-to-last para: This paragraph should be corrected - Ethernet OAM already provides trace route capability for fault isolation without the need for TTL. -Ali At 11:43 AM 9/3/2004 +0200, Loa Andersson wrote: >WG, > >in the L2VPN meeting in San Diego a L2VPN applicability >statement were discussed. The minutes says: > >"... ask the question on the mailing list and see if >there is consensus to make this a WG document. The Chairs >specifically request input from service providers with >deployment experience." > >The draft has now been updated and the current version is >draft-lasserre-l2vpn-vpls-ldp-applic-02.txt. > >Please respond to the question above, whether this should >be a l2vpn working document or not, preferably to the >mailing list, but at least to the wg chairs. A simple >yes or no is sufficent. Since this a call to see there >is consensus both positive and negative responses are >appropriate. > >Responses within in two weeks, snce the wg chairs plan >to make the consensus call the week of August 20th. > >Input from operators/service providers is encouraged. > >Note: Adopting an ID as a working document is not to > say that it covers every aspect of the problem, > but that it is a good enough starting for the > working group when solving the problem. > > >/Loa > >-- >Loa Andersson > >Principal Networking Architect >Acreo AB phone: +46 8 632 77 14 >Isafjordsgatan 22 mobile: +46 739 81 21 64 >Kista, Sweden From l2vpn-bounces@ietf.org Thu Sep 23 04:12:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20982 for ; Thu, 23 Sep 2004 04:12:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAOoq-0002OR-Lr for l2vpn-web-archive@ietf.org; Thu, 23 Sep 2004 04:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAOe7-0002WV-OL; Thu, 23 Sep 2004 04:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAObZ-00020W-Ab for l2vpn@megatron.ietf.org; Thu, 23 Sep 2004 04:05:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20559 for ; Thu, 23 Sep 2004 04:05:27 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAOiI-0002G4-Io for l2vpn@ietf.org; Thu, 23 Sep 2004 04:12:27 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i8N85PIX014047 for ; Thu, 23 Sep 2004 03:05:26 -0500 (CDT) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Sep 2004 04:05:25 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: L2VPN Date: Thu, 23 Sep 2004 04:05:22 -0400 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: 93238566e09e6e262849b4f805833007 Subject: One AFI for ATM-related addresses 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Last week, we sent the following email to the IDR mailing list. We haven't received a response yet. Since in San Diego, draft-ck-bgp-atm-nlri-00.txt was presented to the L2VPN WG, we would like to invite comments from this mailing list as well. -------------------------------------------------------------- Draft-ck-bgp-atm-nlri-00.txt proposes to use MP-BGP to exchange ATM address information between independent ATM sub-networks. In particular, it proposes to use a single AFI/SAFI combination (AFI=TBD; SAFI=VPN) and to use an "ATM Reachability Type" field in the NLRI to distinguish between different types of ATM addresses: NSAP, E.164, etc. After this draft was presented in San Diego, we received questions why there is a need for a new AFI considering that there are already existing AFIs for NSAP, E.164 and X.121. We would like to solicit input from the mailing list on this issue. In our opinion, the use of a new AFI/SAFI value for a combination of ATM addresses is justified. ATM is used as the unifying protocol for carrying Frame Relay, SMDS and other traffic. As a consequence, over time, ATM has incorporated multiple address families like X.121, SMDS-related addresses and vendor-proprietary addresses. In fact, PNNI messages use an "ATM AFI" to distinguish between these different address families, and Call Control functionality in ATM Switches generally uses a single address data base integrating different types of addresses. For this reason, as far as MP-BGP is concerned, it makes more sense to treat all addresses exchanged between ATM Switches as a single family, rather than as a collection of separate families. Or, in other words, it makes more sense to use a single AFI/SAFI value than to use multiple. As we are currently working on a new version of the draft, we would appreciate your input on whether we can move ahead with our proposal for a new AFI/SAFI for ATM addresses. Thanks, CK, Chris Metz, Peter Busschbach From l2vpn-bounces@ietf.org Thu Sep 23 05:36:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26189 for ; Thu, 23 Sep 2004 05:36:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAQ8u-0003pI-3E for l2vpn-web-archive@ietf.org; Thu, 23 Sep 2004 05:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAQ0B-0005RZ-W5; Thu, 23 Sep 2004 05:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPwE-0004wO-Ip for l2vpn@megatron.ietf.org; Thu, 23 Sep 2004 05:30:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25757 for ; Thu, 23 Sep 2004 05:30:51 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAQ2z-0003jE-67 for l2vpn@ietf.org; Thu, 23 Sep 2004 05:37:54 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i8N9NFF23160 for ; Thu, 23 Sep 2004 11:23:15 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Thu, 23 Sep 2004 11:29:17 +0200 Message-ID: <4152976C.8030509@pi.se> Date: Thu, 23 Sep 2004 11:29:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Sajassi References: <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> In-Reply-To: <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Cc: L2VPN , Rick Wilder , Vach Kompella Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc? 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Ali (and working group), thanks for these valid and valuable comments. I guess I aggree with most, and see them good input to iomprove the doc. With my wg co-chair hat on I don't see them as stoping the draft to become a wg doc. The way I see the process is that when a ID becomes a working document is when the working group takes over the revision control of the document. At that point we need the following: - an ID addressing a problem that there is rough consensus on that the working group needs to solve - a rough consensus that this ID is a good enough starting point to solve this problem After this the working group starts preparing the ID to eventually be published as an RFC, I see your comments as part of that process. I think we have that ID and therefore I've requested that the authors republish the document as: draft-ietf-l2vpn-vpls-ldp-applic-00.txt I've also told them in doing so it would be useful to incorporate and/or respond to your comments. /Loa Ali Sajassi wrote: > > > There are some areas of ambiguity and inaccuracies in this draft where > I'd like to be addressed first. > > Sec 5.1, 2nd para, pg 9: > ----------------------------------- > "In this scenario, one issue that SPs needs to address is that different > sites of a customer may have a mismatch of 802.1Q tags (either different > .1q tags on each side, or .1q tag on one side, and untagged on the other > side). For example, customer connectivity at one site will be tied to a > port on a VPLS PE/MTU that will utilize a PW for tunneling this packet > through the network. Customer connectivity at another site will be > interconnected to a port on a QinQ switch that will utilize QinQ > techniques (see the figure below). By mandating that "the Ethernet > packet that traverses a VPLS is always a customer Ethernet packet", the > [VPLS-LDP] solution naturally accommodates this need. " > > If the access networks are based on 802.1ad standards (formerly QinQ), > then this issue has already been addressed since .1ad standard allows > for VLAN tag translation at the UNI (e.g., two customer sites can have > two different tags). > > Also the issue of port mode versus vlan mode is orthogonal to the type > of PW used (e.g., tagged mode versus raw mode). In other words, in your > example above, I can still have port mode service between MPLS and QinQ > access and use tagged mode PW over MPLS although raw mode should be the > preferred mode. > > Sec 5.2, 1st para, pg 10: > ------------------------------------- > "Providers that have already deployed VLAN based core may choose to > overlay an MPLS edge on top of this existing L2 domain. In this method, > provider 802.1Q tags maybe assigned to MPLS backbone links that are then > used for carrying VPLS traffic. While this approach may allow for a > simple transition to solve some immediate deficiencies of a pure L2 > network, it still does not solve some of the underlying problems > associated with protocols such as spanning tree. In this case, although > MPLS may provide some scaling advantages, the limitations associated > with spanning tree can still pose potential problems to the overall > infrastructure. " > > This paragraph is not clear to me at all and I am not sure what is > suggested here. I suggest if this is not viable solution, then delete > this paragraph instead of suggesting something that creates more issues. > > Sec 5.2, 2nd para, pg 11: > ------------------------------------- > "Alternatively, a parallel VPLS core is built and connected to the > existing 802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively > treated as a super-island. Then one by one, each individual Ethernet > access island is disconnected from the existing core (i.e. super- > island) and connected to the VPLS core. The migration issues then become > similar to those described in 5.1. " > > Need to mention that inter-operability aspects between .1ad network and > MPLS/VPLS network shall be worked out before such migration. > > Sec 5.2, 3rd para, pg 11: > ------------------------------------ > "A third approach consists in configuring a second VPLS control plane in > the existing QinQ PE, hence implementing two virtual networks over a > single physical infrastructure. Once the PE/MPLS control plane is > running, each customer can be separately migrated through a > reconfiguration of its corresponding access ports. For increased > stability, the dual control plane approach might require dedicating some > links or PEs to the MPLS/VPLS network." > > It should be mentioned that this is only feasible when the QinQ PE can > be easily upgraded (e.g., via software/firmware) to MPLS PE; otherwise, > you need to forklift everything. > > > Sec 6, 1st para, pg 11: The first paragraph talks about two instances of > multi-homing but only a single instance is mentioned in the text below it. > > Sec 7, 3rd para, pg 13: This paragraph is not clear. > > Sec 7, 4th para, pg 13: I assume that the loop protection scheme that > you are talking in here is the loop within the customer network and not > the provider network - e.g., due mis-configuration of its loop > prevention protocol or lack of one. If that is the case, then it should > be clearly specified in this paragraph because having the loop within > the customer network (when it is dual-homed) doesn't mean that there is > a loop inside the provider network. > > Sec 8, pg14: It should be mentioned that in steady state (e.g., when > there is no failure), there shall be no re-ordering of Ethernet packets > within a VPLS instance. This can be achieved by ensuring that ECMP > algorithms do inter-flow (instead of intra flow) load balancing which is > typically the case - e.g., load balance among different PWs and thus > different VPLS instances. > > Sec 13.1, pg 16: Customer tag enforcement should be done at the UNI and > I don't see how a link between a CE and a PE can be shared by multiple > customers. Also in the last sentence, do you mean a bridge instead of a > router. The only case that I can think of is for .1q (and not .1ad since > .1ad allows for tag translation). If it is for .1q, then it should be > clearly stated and it should be mention that in order to enforce > non-overlapping VLAN among different customer, an ACL per customer AC > should be used. > > Sec 13.2, pg 16: There should be a distinction made between broadcast > domain and mac address domain. FIB tables guarantee the separation of > MAC address domains among different VPLS instances and a full-mesh of > PWs per VPLS instance guarantees the separation of broadcast domains > among VPLS instances. So the two toegther guarantee traffic separation > between VPLS instances. The section should be modified to reflect this > accordingly. > > Sec 15, pg 20, one-to-last para: This paragraph should be corrected - > Ethernet OAM already provides trace route capability for fault isolation > without the need for TTL. > > -Ali > > At 11:43 AM 9/3/2004 +0200, Loa Andersson wrote: > >> WG, >> >> in the L2VPN meeting in San Diego a L2VPN applicability >> statement were discussed. The minutes says: >> >> "... ask the question on the mailing list and see if >> there is consensus to make this a WG document. The Chairs >> specifically request input from service providers with >> deployment experience." >> >> The draft has now been updated and the current version is >> draft-lasserre-l2vpn-vpls-ldp-applic-02.txt. >> >> Please respond to the question above, whether this should >> be a l2vpn working document or not, preferably to the >> mailing list, but at least to the wg chairs. A simple >> yes or no is sufficent. Since this a call to see there >> is consensus both positive and negative responses are >> appropriate. >> >> Responses within in two weeks, snce the wg chairs plan >> to make the consensus call the week of August 20th. >> >> Input from operators/service providers is encouraged. >> >> Note: Adopting an ID as a working document is not to >> say that it covers every aspect of the problem, >> but that it is a good enough starting for the >> working group when solving the problem. >> >> >> /Loa >> >> -- >> Loa Andersson >> >> Principal Networking Architect >> Acreo AB phone: +46 8 632 77 14 >> Isafjordsgatan 22 mobile: +46 739 81 21 64 >> Kista, Sweden > > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Thu Sep 23 07:41:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03085 for ; Thu, 23 Sep 2004 07:41:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAS5J-0005ny-2N for l2vpn-web-archive@ietf.org; Thu, 23 Sep 2004 07:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CARuC-0003xo-6G; Thu, 23 Sep 2004 07:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CARq3-0003er-CV for l2vpn@megatron.ietf.org; Thu, 23 Sep 2004 07:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02511 for ; Thu, 23 Sep 2004 07:32:35 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CARwj-0005cm-T9 for l2vpn@ietf.org; Thu, 23 Sep 2004 07:39:37 -0400 Received: from LocalHost by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id EAA19982; Thu, 23 Sep 2004 04:31:59 -0700 (PDT) From: marc@riverstonenet.com (Marc Lasserre) Message-ID: To: l2vpn@ietf.org Date: Thu, 23 Sep 2004 13:31:59 +0200 X-Spam-Score: 2.4 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: YOUR EMAIL ADDRESS HAS BEEN ADDED TO MY WHITE LIST 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Your email address has been added to my Spam Fighter White List. Adding your address to the White List ensures that I will always receive email you send to me. If you aren't using All-in-One SECRETMAKER, I recommend that you examine this powerful freeware. I recommend All-in-One SECRETMAKER software to all my friends and email contacts. This compact, smart tool includes Spam Fighter, Pop-Up Killer, Banner Blocker, Cookie Eraser, History Cleaner, Privacy Protector and more. Innovative new features, with many refinements, are presently being tested. All-in-One SECRETMAKER has been downloaded and restored Internet privacy for thousands of satisfied users. More detailed information about the All-in-One SECRETMAKER can be found at the SECRETMAKER home page, located at: WWW.SECRETMAKER.COM (copy / paste the URL in to your browser) If you would like to turn email and surfing the Web into a pleasant and secure experience once again, you can download the totally free All-in-One SECRETMAKER at WWW.SECRETMAKER.COM/DOWNLOADS/ From l2vpn-bounces@ietf.org Thu Sep 23 07:41:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03107 for ; Thu, 23 Sep 2004 07:41:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAS5g-0005oG-7P for l2vpn-web-archive@ietf.org; Thu, 23 Sep 2004 07:48:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CARuC-0003xt-K5; Thu, 23 Sep 2004 07:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CARq3-0003eu-CV for l2vpn@megatron.ietf.org; Thu, 23 Sep 2004 07:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02514 for ; Thu, 23 Sep 2004 07:32:37 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CARwm-0005d4-3c for l2vpn@ietf.org; Thu, 23 Sep 2004 07:39:39 -0400 Received: from lasserretplxp by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id EAA19979; Thu, 23 Sep 2004 04:31:58 -0700 (PDT) Message-ID: <00f101c4a160$f04c4880$6501a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "Loa Andersson" , "L2VPN" , "Rick Wilder" , "Vach Kompella" , "Ali Sajassi" References: <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> Date: Thu, 23 Sep 2004 13:31:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc? 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Ali, Thanks for your valuable feedback. I will update the draft to incorporate your comments and address the ambiguities that you have raised before submitting it as a WG doc. Marc ----- Original Message ----- From: "Ali Sajassi" To: "Loa Andersson" ; "L2VPN" ; "Rick Wilder" ; "Vach Kompella" Sent: Thursday, September 23, 2004 2:09 AM Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc? > > > There are some areas of ambiguity and inaccuracies in this draft where I'd > like to be addressed first. > > Sec 5.1, 2nd para, pg 9: > ----------------------------------- > "In this scenario, one issue that SPs needs to address is that different > sites of a customer may have a mismatch of 802.1Q tags (either different > .1q tags on each side, or .1q tag on one side, and untagged on the other > side). For example, customer connectivity at one site will be tied to a > port on a VPLS PE/MTU that will utilize a PW for tunneling this packet > through the network. Customer connectivity at another site will be > interconnected to a port on a QinQ switch that will utilize QinQ > techniques (see the figure below). By mandating that "the Ethernet packet > that traverses a VPLS is always a customer Ethernet packet", the > [VPLS-LDP] solution naturally accommodates this need. " > > If the access networks are based on 802.1ad standards (formerly QinQ), > then this issue has already been addressed since .1ad standard allows for > VLAN tag translation at the UNI (e.g., two customer sites can have two > different tags). > > Also the issue of port mode versus vlan mode is orthogonal to the type of > PW used (e.g., tagged mode versus raw mode). In other words, in your > example above, I can still have port mode service between MPLS and QinQ > access and use tagged mode PW over MPLS although raw mode should be the > preferred mode. > > Sec 5.2, 1st para, pg 10: > ------------------------------------- > "Providers that have already deployed VLAN based core may choose to > overlay an MPLS edge on top of this existing L2 domain. In this method, > provider 802.1Q tags maybe assigned to MPLS backbone links that are then > used for carrying VPLS traffic. While this approach may allow for a simple > transition to solve some immediate deficiencies of a pure L2 network, it > still does not solve some of the underlying problems associated with > protocols such as spanning tree. In this case, although MPLS may provide > some scaling advantages, the limitations associated with spanning tree can > still pose potential problems to the overall infrastructure. " > > This paragraph is not clear to me at all and I am not sure what is > suggested here. I suggest if this is not viable solution, then delete this > paragraph instead of suggesting something that creates more issues. > > Sec 5.2, 2nd para, pg 11: > ------------------------------------- > "Alternatively, a parallel VPLS core is built and connected to the > existing 802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively treated > as a super-island. Then one by one, each individual Ethernet access island > is disconnected from the existing core (i.e. super- island) and connected > to the VPLS core. The migration issues then become similar to those > described in 5.1. " > > Need to mention that inter-operability aspects between .1ad network and > MPLS/VPLS network shall be worked out before such migration. > > Sec 5.2, 3rd para, pg 11: > ------------------------------------ > "A third approach consists in configuring a second VPLS control plane in > the existing QinQ PE, hence implementing two virtual networks over a > single physical infrastructure. Once the PE/MPLS control plane is running, > each customer can be separately migrated through a reconfiguration of its > corresponding access ports. For increased stability, the dual control > plane approach might require dedicating some links or PEs to the MPLS/VPLS > network." > > It should be mentioned that this is only feasible when the QinQ PE can be > easily upgraded (e.g., via software/firmware) to MPLS PE; otherwise, you > need to forklift everything. > > > Sec 6, 1st para, pg 11: The first paragraph talks about two instances of > multi-homing but only a single instance is mentioned in the text below it. > > Sec 7, 3rd para, pg 13: This paragraph is not clear. > > Sec 7, 4th para, pg 13: I assume that the loop protection scheme that you > are talking in here is the loop within the customer network and not the > provider network - e.g., due mis-configuration of its loop prevention > protocol or lack of one. If that is the case, then it should be clearly > specified in this paragraph because having the loop within the customer > network (when it is dual-homed) doesn't mean that there is a loop inside > the provider network. > > Sec 8, pg14: It should be mentioned that in steady state (e.g., when there > is no failure), there shall be no re-ordering of Ethernet packets within a > VPLS instance. This can be achieved by ensuring that ECMP algorithms do > inter-flow (instead of intra flow) load balancing which is typically the > case - e.g., load balance among different PWs and thus different VPLS > instances. > > Sec 13.1, pg 16: Customer tag enforcement should be done at the UNI and I > don't see how a link between a CE and a PE can be shared by multiple > customers. Also in the last sentence, do you mean a bridge instead of a > router. The only case that I can think of is for .1q (and not .1ad since > .1ad allows for tag translation). If it is for .1q, then it should be > clearly stated and it should be mention that in order to enforce > non-overlapping VLAN among different customer, an ACL per customer AC > should be used. > > Sec 13.2, pg 16: There should be a distinction made between broadcast > domain and mac address domain. FIB tables guarantee the separation of MAC > address domains among different VPLS instances and a full-mesh of PWs per > VPLS instance guarantees the separation of broadcast domains among VPLS > instances. So the two toegther guarantee traffic separation between VPLS > instances. The section should be modified to reflect this accordingly. > > Sec 15, pg 20, one-to-last para: This paragraph should be corrected - > Ethernet OAM already provides trace route capability for fault isolation > without the need for TTL. > > -Ali > > At 11:43 AM 9/3/2004 +0200, Loa Andersson wrote: >>WG, >> >>in the L2VPN meeting in San Diego a L2VPN applicability >>statement were discussed. The minutes says: >> >>"... ask the question on the mailing list and see if >>there is consensus to make this a WG document. The Chairs >>specifically request input from service providers with >>deployment experience." >> >>The draft has now been updated and the current version is >>draft-lasserre-l2vpn-vpls-ldp-applic-02.txt. >> >>Please respond to the question above, whether this should >>be a l2vpn working document or not, preferably to the >>mailing list, but at least to the wg chairs. A simple >>yes or no is sufficent. Since this a call to see there >>is consensus both positive and negative responses are >>appropriate. >> >>Responses within in two weeks, snce the wg chairs plan >>to make the consensus call the week of August 20th. >> >>Input from operators/service providers is encouraged. >> >>Note: Adopting an ID as a working document is not to >> say that it covers every aspect of the problem, >> but that it is a good enough starting for the >> working group when solving the problem. >> >> >>/Loa >> >>-- >>Loa Andersson >> >>Principal Networking Architect >>Acreo AB phone: +46 8 632 77 14 >>Isafjordsgatan 22 mobile: +46 739 81 21 64 >>Kista, Sweden > > > From l2vpn-bounces@ietf.org Thu Sep 23 13:45:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04193 for ; Thu, 23 Sep 2004 13:45:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXlx-0005TG-1Y for l2vpn-web-archive@ietf.org; Thu, 23 Sep 2004 13:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXaH-00033S-3b; Thu, 23 Sep 2004 13:40:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXRm-0001gt-Oo for l2vpn@megatron.ietf.org; Thu, 23 Sep 2004 13:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03382 for ; Thu, 23 Sep 2004 13:31:55 -0400 (EDT) Received: from smtp002.mail.ukl.yahoo.com ([217.12.11.33]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAXYb-0005Cy-Vx for l2vpn@ietf.org; Thu, 23 Sep 2004 13:39:02 -0400 Received: from unknown (HELO pfloyd) (jsmith4112003@202.144.106.188 with login) by smtp002.mail.ukl.yahoo.com with SMTP; 23 Sep 2004 12:08:48 -0000 Message-ID: <02e001c4a166$0fdfd540$100218ac@pfloyd> From: "John Smith" To: References: <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> <00f101c4a160$f04c4880$6501a8c0@rs.riverstonenet.com> Date: Thu, 23 Sep 2004 17:38:32 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.9 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: draft-ietf-l3vpn-bgpvpn-auto-04.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Hi, Can we use this draft to automatically discover VPLS nodes across different sites? Regards, John From l2vpn-bounces@ietf.org Thu Sep 23 19:07:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03644 for ; Thu, 23 Sep 2004 19:07:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAcng-0004i9-5V for l2vpn-web-archive@ietf.org; Thu, 23 Sep 2004 19:14:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAcg9-0006uL-0B; Thu, 23 Sep 2004 19:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAccE-0006C3-A6 for l2vpn@megatron.ietf.org; Thu, 23 Sep 2004 19:03:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03387 for ; Thu, 23 Sep 2004 19:03:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAcj6-0004cW-6W for l2vpn@ietf.org; Thu, 23 Sep 2004 19:10:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2004 16:14:43 +0000 X-BrightmailFiltered: true Received: from sajassi-w2k4.cisco.com (dhcp-128-107-178-9.cisco.com [128.107.178.9]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8NN2Ebt006117; Thu, 23 Sep 2004 16:02:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20040923155634.029063a8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Sep 2004 16:02:13 -0700 To: Loa Andersson , Ali Sajassi From: Ali Sajassi In-Reply-To: <4152976C.8030509@pi.se> References: <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> <4.3.2.7.2.20040922113652.028d7568@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: L2VPN , Rick Wilder , Vach Kompella Subject: Re: draft-lasserre-l2vpn-vpls-ldp-applic-02.txt for wg doc? 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 At 11:29 AM 9/23/2004 +0200, Loa Andersson wrote: >Ali (and working group), > >thanks for these valid and valuable comments. I guess I >aggree with most, and see them good input to iomprove the >doc. > >With my wg co-chair hat on I don't see them as stoping the >draft to become a wg doc. >The way I see the process is that when a ID becomes a working >document is when the working group takes over the revision >control of the document. At that point we need the following: > >- an ID addressing a problem that there is rough consensus > on that the working group needs to solve >- a rough consensus that this ID is a good enough starting > point to solve this problem > >After this the working group starts preparing the ID to >eventually be published as an RFC, I see your comments as >part of that process. > >I think we have that ID and therefore I've requested that >the authors republish the document as: >draft-ietf-l2vpn-vpls-ldp-applic-00.txt > >I've also told them in doing so it would be useful to >incorporate and/or respond to your comments. Yes, the issues were not show stoppers, so I am O.K. with incorporation of my comments in the next rev of this draft as WG draft. -Ali >/Loa > >Ali Sajassi wrote: > >> >>There are some areas of ambiguity and inaccuracies in this draft where >>I'd like to be addressed first. >>Sec 5.1, 2nd para, pg 9: >>----------------------------------- >>"In this scenario, one issue that SPs needs to address is that different >>sites of a customer may have a mismatch of 802.1Q tags (either different >>.1q tags on each side, or .1q tag on one side, and untagged on the other >>side). For example, customer connectivity at one site will be tied to a >>port on a VPLS PE/MTU that will utilize a PW for tunneling this packet >>through the network. Customer connectivity at another site will be >>interconnected to a port on a QinQ switch that will utilize QinQ >>techniques (see the figure below). By mandating that "the Ethernet packet >>that traverses a VPLS is always a customer Ethernet packet", the >>[VPLS-LDP] solution naturally accommodates this need. " >>If the access networks are based on 802.1ad standards (formerly QinQ), >>then this issue has already been addressed since .1ad standard allows for >>VLAN tag translation at the UNI (e.g., two customer sites can have two >>different tags). >>Also the issue of port mode versus vlan mode is orthogonal to the type of >>PW used (e.g., tagged mode versus raw mode). In other words, in your >>example above, I can still have port mode service between MPLS and QinQ >>access and use tagged mode PW over MPLS although raw mode should be the >>preferred mode. >>Sec 5.2, 1st para, pg 10: >>------------------------------------- >>"Providers that have already deployed VLAN based core may choose to >>overlay an MPLS edge on top of this existing L2 domain. In this method, >>provider 802.1Q tags maybe assigned to MPLS backbone links that are then >>used for carrying VPLS traffic. While this approach may allow for a >>simple transition to solve some immediate deficiencies of a pure L2 >>network, it still does not solve some of the underlying problems >>associated with protocols such as spanning tree. In this case, although >>MPLS may provide some scaling advantages, the limitations associated with >>spanning tree can still pose potential problems to the overall >>infrastructure. " >>This paragraph is not clear to me at all and I am not sure what is >>suggested here. I suggest if this is not viable solution, then delete >>this paragraph instead of suggesting something that creates more issues. >>Sec 5.2, 2nd para, pg 11: >>------------------------------------- >>"Alternatively, a parallel VPLS core is built and connected to the >>existing 802.1Q/Q-in-Q core. The 802.1Q/Q-in-Q core is effectively >>treated as a super-island. Then one by one, each individual Ethernet >>access island is disconnected from the existing core (i.e. super- island) >>and connected to the VPLS core. The migration issues then become similar >>to those described in 5.1. " >>Need to mention that inter-operability aspects between .1ad network and >>MPLS/VPLS network shall be worked out before such migration. >>Sec 5.2, 3rd para, pg 11: >>------------------------------------ >>"A third approach consists in configuring a second VPLS control plane in >>the existing QinQ PE, hence implementing two virtual networks over a >>single physical infrastructure. Once the PE/MPLS control plane is >>running, each customer can be separately migrated through a >>reconfiguration of its corresponding access ports. For increased >>stability, the dual control plane approach might require dedicating some >>links or PEs to the MPLS/VPLS network." >>It should be mentioned that this is only feasible when the QinQ PE can be >>easily upgraded (e.g., via software/firmware) to MPLS PE; otherwise, you >>need to forklift everything. >> >>Sec 6, 1st para, pg 11: The first paragraph talks about two instances of >>multi-homing but only a single instance is mentioned in the text below it. >>Sec 7, 3rd para, pg 13: This paragraph is not clear. >>Sec 7, 4th para, pg 13: I assume that the loop protection scheme that you >>are talking in here is the loop within the customer network and not the >>provider network - e.g., due mis-configuration of its loop prevention >>protocol or lack of one. If that is the case, then it should be clearly >>specified in this paragraph because having the loop within the customer >>network (when it is dual-homed) doesn't mean that there is a loop inside >>the provider network. >>Sec 8, pg14: It should be mentioned that in steady state (e.g., when >>there is no failure), there shall be no re-ordering of Ethernet packets >>within a VPLS instance. This can be achieved by ensuring that ECMP >>algorithms do inter-flow (instead of intra flow) load balancing which is >>typically the case - e.g., load balance among different PWs and thus >>different VPLS instances. >>Sec 13.1, pg 16: Customer tag enforcement should be done at the UNI and I >>don't see how a link between a CE and a PE can be shared by multiple >>customers. Also in the last sentence, do you mean a bridge instead of a >>router. The only case that I can think of is for .1q (and not .1ad since >>.1ad allows for tag translation). If it is for .1q, then it should be >>clearly stated and it should be mention that in order to enforce >>non-overlapping VLAN among different customer, an ACL per customer AC >>should be used. >>Sec 13.2, pg 16: There should be a distinction made between broadcast >>domain and mac address domain. FIB tables guarantee the separation of MAC >>address domains among different VPLS instances and a full-mesh of PWs per >>VPLS instance guarantees the separation of broadcast domains among VPLS >>instances. So the two toegther guarantee traffic separation between VPLS >>instances. The section should be modified to reflect this accordingly. >>Sec 15, pg 20, one-to-last para: This paragraph should be corrected - >>Ethernet OAM already provides trace route capability for fault isolation >>without the need for TTL. >>-Ali >>At 11:43 AM 9/3/2004 +0200, Loa Andersson wrote: >> >>>WG, >>> >>>in the L2VPN meeting in San Diego a L2VPN applicability >>>statement were discussed. The minutes says: >>> >>>"... ask the question on the mailing list and see if >>>there is consensus to make this a WG document. The Chairs >>>specifically request input from service providers with >>>deployment experience." >>> >>>The draft has now been updated and the current version is >>>draft-lasserre-l2vpn-vpls-ldp-applic-02.txt. >>> >>>Please respond to the question above, whether this should >>>be a l2vpn working document or not, preferably to the >>>mailing list, but at least to the wg chairs. A simple >>>yes or no is sufficent. Since this a call to see there >>>is consensus both positive and negative responses are >>>appropriate. >>> >>>Responses within in two weeks, snce the wg chairs plan >>>to make the consensus call the week of August 20th. >>> >>>Input from operators/service providers is encouraged. >>> >>>Note: Adopting an ID as a working document is not to >>> say that it covers every aspect of the problem, >>> but that it is a good enough starting for the >>> working group when solving the problem. >>> >>> >>>/Loa >>> >>>-- >>>Loa Andersson >>> >>>Principal Networking Architect >>>Acreo AB phone: +46 8 632 77 14 >>>Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>Kista, Sweden >> >> > >-- >Loa Andersson > >Principal Networking Architect >Acreo AB phone: +46 8 632 77 14 >Isafjordsgatan 22 mobile: +46 739 81 21 64 >Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se From l2vpn-bounces@ietf.org Fri Sep 24 08:28:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06123 for ; Fri, 24 Sep 2004 08:28:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CApIp-0000mm-F7 for l2vpn-web-archive@ietf.org; Fri, 24 Sep 2004 08:35:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CApAi-0005u5-4E; Fri, 24 Sep 2004 08:27:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAp9A-0005ab-Ur for l2vpn@megatron.ietf.org; Fri, 24 Sep 2004 08:25:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05863 for ; Fri, 24 Sep 2004 08:25:56 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CApG9-0000j8-EZ for l2vpn@ietf.org; Fri, 24 Sep 2004 08:33:10 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i8OCIDF14491 for ; Fri, 24 Sep 2004 14:18:13 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Fri, 24 Sep 2004 14:24:02 +0200 Message-ID: <415411E0.8000709@pi.se> Date: Fri, 24 Sep 2004 14:24:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: L2VPN Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: l2vpn meeting in Washington 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit All, The next IETF meeting is getting nearer. Some dates for IETF 61: 11 Oct 2004: WG Chair approval for initial document (Version -00) submission due by 09:00 ET 18 Oct 2004: Internet Draft Cut-off for initial document (-00) submission at 09:00 ET The L2VPN working group will meet, major issues will be l2vpn-oam-req's and p-2-mp. We will also request that all the editors for the working group documents make reports on their documents and have them updated according the latest discussion. Please your requests for agenda slots to the wg co-chairs. /Vach, Rick and Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Fri Sep 24 15:35:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08571 for ; Fri, 24 Sep 2004 15:35:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAvxS-00012w-Ua for l2vpn-web-archive@ietf.org; Fri, 24 Sep 2004 15:42:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvlE-0000Ac-CU; Fri, 24 Sep 2004 15:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvY5-0003TU-Tg for l2vpn@megatron.ietf.org; Fri, 24 Sep 2004 15:16:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07535 for ; Fri, 24 Sep 2004 15:16:04 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAvf8-0000ow-CX for l2vpn@ietf.org; Fri, 24 Sep 2004 15:23:23 -0400 Received: from default.mail.com (unknown[12.46.111.104]) by comcast.net (sccrmhc13) with SMTP id <2004092419152901600e4qd0e> (Authid: agmalis@comcast.net); Fri, 24 Sep 2004 19:15:31 +0000 Message-Id: <6.1.2.0.2.20040924151358.0820b3b0@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 15:15:24 -0400 To: Rick Wilder , "Loa Andersson" , "Vach Kompella" From: "Andrew G. Malis" In-Reply-To: <20040812143948.95230.qmail@web107.biz.mail.yahoo.com> References: <20040812143948.95230.qmail@web107.biz.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: l2vpn@ietf.org Subject: Re: arp mediation draft 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Rick, Vach, and Loa, Are we finally ready to accept ARP mediation as a WG document? I haven't seen any official pronouncements one way or the other since San Diego. Thanks, Andy ------- At 8/12/2004 07:39 AM -0700, Rick Wilder wrote: >Following the recent update to the WG charter, >draft-shah-l2vpn-arp-mediation-01.txt is clearly in scope for >the L2VPN working group, and was proposed as a WG document at the L2VPN >session >in San Diego. > >Among those present there was strong support for accepting this as a >WG document. In order to provide a opportunity for feedback from those >not present at San Diego, we will now start a 2-week discussion period >prior to finalizing a decision on re-classifying this document. > >Rick, Vach, and Loa From l2vpn-bounces@ietf.org Fri Sep 24 16:50:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18932 for ; Fri, 24 Sep 2004 16:50:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAx8b-0004PH-32 for l2vpn-web-archive@ietf.org; Fri, 24 Sep 2004 16:57:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwjD-00087K-HC; Fri, 24 Sep 2004 16:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwG6-000705-2w for l2vpn@megatron.ietf.org; Fri, 24 Sep 2004 16:01:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10806 for ; Fri, 24 Sep 2004 16:01:32 -0400 (EDT) Received: from web107.biz.mail.yahoo.com ([216.136.174.209]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAwN8-0001qg-Jl for l2vpn@ietf.org; Fri, 24 Sep 2004 16:08:52 -0400 Message-ID: <20040924200131.17906.qmail@web107.biz.mail.yahoo.com> Received: from [128.251.97.130] by web107.biz.mail.yahoo.com via HTTP; Fri, 24 Sep 2004 13:01:31 PDT Date: Fri, 24 Sep 2004 13:01:31 -0700 (PDT) From: Rick Wilder To: "Andrew G. Malis" , Rick Wilder , Loa Andersson , Vach Kompella In-Reply-To: <6.1.2.0.2.20040924151358.0820b3b0@mail.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: l2vpn@ietf.org Subject: Re: arp mediation draft 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Yes. We had a 2-week period to finalize the decision on the email list, declared it over, and I requested internet-drafts@ietf.org to republish it as a WG draft. It should show up as such any time now. Rick --- "Andrew G. Malis" wrote: > Rick, Vach, and Loa, > > Are we finally ready to accept ARP mediation as a WG document? I haven't > seen any official pronouncements one way or the other since San Diego. > > Thanks, > Andy > > ------- > > At 8/12/2004 07:39 AM -0700, Rick Wilder wrote: > > > >Following the recent update to the WG charter, > >draft-shah-l2vpn-arp-mediation-01.txt is clearly in scope for > >the L2VPN working group, and was proposed as a WG document at the L2VPN > >session > >in San Diego. > > > >Among those present there was strong support for accepting this as a > >WG document. In order to provide a opportunity for feedback from those > >not present at San Diego, we will now start a 2-week discussion period > >prior to finalizing a decision on re-classifying this document. > > > >Rick, Vach, and Loa > > > From l2vpn-bounces@ietf.org Fri Sep 24 16:53:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19325 for ; Fri, 24 Sep 2004 16:53:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxBY-0004Vu-7x for l2vpn-web-archive@ietf.org; Fri, 24 Sep 2004 17:00:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwje-0000IR-Gn; Fri, 24 Sep 2004 16:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwJo-0001AN-FQ for l2vpn@megatron.ietf.org; Fri, 24 Sep 2004 16:05:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11879 for ; Fri, 24 Sep 2004 16:05:22 -0400 (EDT) Received: from lin1-118-34-24.ciena.com ([63.118.34.24] helo=ripley.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwQr-0002DL-SR for l2vpn@ietf.org; Fri, 24 Sep 2004 16:12:42 -0400 Received: from mdmail.ciena.com (HELO mdmxb01.ciena.com) (63.118.39.25) by ripley.ciena.com with ESMTP; 24 Sep 2004 16:20:58 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB00100B5A6@w2kmaexg02.wavesmithnet.com> From: "Shah, Himanshu" To: "'Andrew G. Malis'" , Rick Wilder , Loa Andersson , Vach Kompella Date: Fri, 24 Sep 2004 16:05:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: l2vpn@ietf.org Subject: RE: arp mediation draft 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 I sent the following message on Sept 4 to L2VPN group. I guess the next step would be to re-submit the lastest draft-shah as draft-ietf-l2vpn-arp-mediation-00.txt?? /himanshu "Since there is no objection from the email list on draft-shah-l2vpn-arp-mediation-01.txt, the authors request to republish this draft as draft-ietf-l2vpn-arp-mediation-01.txt, a l2vpn WG document. thanks, himanshu" > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Friday, September 24, 2004 3:15 PM > To: Rick Wilder; Loa Andersson; Vach Kompella > Cc: l2vpn@ietf.org > Subject: Re: arp mediation draft > > > Rick, Vach, and Loa, > > Are we finally ready to accept ARP mediation as a WG > document? I haven't > seen any official pronouncements one way or the other since San Diego. > > Thanks, > Andy > > ------- > > At 8/12/2004 07:39 AM -0700, Rick Wilder wrote: > > > >Following the recent update to the WG charter, > >draft-shah-l2vpn-arp-mediation-01.txt is clearly in scope for > >the L2VPN working group, and was proposed as a WG document > at the L2VPN > >session > >in San Diego. > > > >Among those present there was strong support for accepting this as a > >WG document. In order to provide a opportunity for feedback > from those > >not present at San Diego, we will now start a 2-week > discussion period > >prior to finalizing a decision on re-classifying this document. > > > >Rick, Vach, and Loa > > From l2vpn-bounces@ietf.org Fri Sep 24 17:11:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20897 for ; Fri, 24 Sep 2004 17:11:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxSP-0004yS-Hu for l2vpn-web-archive@ietf.org; Fri, 24 Sep 2004 17:18:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAxAM-0005Hv-KQ; Fri, 24 Sep 2004 16:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwum-0008MQ-MF for l2vpn@megatron.ietf.org; Fri, 24 Sep 2004 16:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18356 for ; Fri, 24 Sep 2004 16:43:34 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAx1n-0004Cd-LH for l2vpn@ietf.org; Fri, 24 Sep 2004 16:50:55 -0400 Received: from default.mail.com (unknown[12.46.111.104]) by comcast.net (rwcrmhc12) with SMTP id <2004092420425901400n1r03e> (Authid: agmalis@comcast.net); Fri, 24 Sep 2004 20:43:01 +0000 Message-Id: <6.1.2.0.2.20040924164244.07cea2f0@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 16:42:55 -0400 To: Rick Wilder From: "Andrew G. Malis" In-Reply-To: <20040924200131.17906.qmail@web107.biz.mail.yahoo.com> References: <6.1.2.0.2.20040924151358.0820b3b0@mail.comcast.net> <20040924200131.17906.qmail@web107.biz.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Loa Andersson , l2vpn@ietf.org, Rick Wilder , Vach Kompella , "Andrew G. Malis" Subject: Re: arp mediation draft 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Rick, Thanks! Cheers, Andy ---------- At 9/24/2004 01:01 PM -0700, Rick Wilder wrote: >Yes. We had a 2-week period to finalize the decision on the email list, >declared it >over, and I requested internet-drafts@ietf.org to republish it as a WG >draft. It should >show up as such any time now. > >Rick > > >--- "Andrew G. Malis" wrote: > > > Rick, Vach, and Loa, > > > > Are we finally ready to accept ARP mediation as a WG document? I haven't > > seen any official pronouncements one way or the other since San Diego. > > > > Thanks, > > Andy > > > > ------- > > > > At 8/12/2004 07:39 AM -0700, Rick Wilder wrote: > > > > > > >Following the recent update to the WG charter, > > >draft-shah-l2vpn-arp-mediation-01.txt is clearly in scope for > > >the L2VPN working group, and was proposed as a WG document at the L2VPN > > >session > > >in San Diego. > > > > > >Among those present there was strong support for accepting this as a > > >WG document. In order to provide a opportunity for feedback from those > > >not present at San Diego, we will now start a 2-week discussion period > > >prior to finalizing a decision on re-classifying this document. > > > > > >Rick, Vach, and Loa > > > > > > From l2vpn-bounces@ietf.org Fri Sep 24 17:14:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21185 for ; Fri, 24 Sep 2004 17:14:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxVd-000544-7V for l2vpn-web-archive@ietf.org; Fri, 24 Sep 2004 17:21:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAxAU-0005Na-Ly; Fri, 24 Sep 2004 16:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwzB-0001ja-Gt for l2vpn@megatron.ietf.org; Fri, 24 Sep 2004 16:48:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18744 for ; Fri, 24 Sep 2004 16:48:07 -0400 (EDT) Received: from web108.biz.mail.yahoo.com ([216.136.174.218]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAx6E-0004MT-SM for l2vpn@ietf.org; Fri, 24 Sep 2004 16:55:27 -0400 Message-ID: <20040924204807.82072.qmail@web108.biz.mail.yahoo.com> Received: from [128.251.97.130] by web108.biz.mail.yahoo.com via HTTP; Fri, 24 Sep 2004 13:48:07 PDT Date: Fri, 24 Sep 2004 13:48:07 -0700 (PDT) From: Rick Wilder To: "Shah, Himanshu" , "'Andrew G. Malis'" , Rick Wilder , Loa Andersson , Vach Kompella In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB00100B5A6@w2kmaexg02.wavesmithnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: l2vpn@ietf.org Subject: RE: arp mediation draft 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Himanshu, The request has already gone to internet-drafts@ietf.org. I'll ask for a status. Rick --- "Shah, Himanshu" wrote: > I sent the following message on Sept 4 to L2VPN group. > I guess the next step would be to re-submit the > lastest draft-shah as draft-ietf-l2vpn-arp-mediation-00.txt?? > > /himanshu > > > "Since there is no objection from the email list on > draft-shah-l2vpn-arp-mediation-01.txt, the authors request to > republish this draft as draft-ietf-l2vpn-arp-mediation-01.txt, > a l2vpn WG document. > > thanks, > himanshu" > > > > -----Original Message----- > > From: Andrew G. Malis [mailto:andymalis@comcast.net] > > Sent: Friday, September 24, 2004 3:15 PM > > To: Rick Wilder; Loa Andersson; Vach Kompella > > Cc: l2vpn@ietf.org > > Subject: Re: arp mediation draft > > > > > > Rick, Vach, and Loa, > > > > Are we finally ready to accept ARP mediation as a WG > > document? I haven't > > seen any official pronouncements one way or the other since San Diego. > > > > Thanks, > > Andy > > > > ------- > > > > At 8/12/2004 07:39 AM -0700, Rick Wilder wrote: > > > > > > >Following the recent update to the WG charter, > > >draft-shah-l2vpn-arp-mediation-01.txt is clearly in scope for > > >the L2VPN working group, and was proposed as a WG document > > at the L2VPN > > >session > > >in San Diego. > > > > > >Among those present there was strong support for accepting this as a > > >WG document. In order to provide a opportunity for feedback > > from those > > >not present at San Diego, we will now start a 2-week > > discussion period > > >prior to finalizing a decision on re-classifying this document. > > > > > >Rick, Vach, and Loa > > > > > From l2vpn-bounces@ietf.org Mon Sep 27 04:14:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10840 for ; Mon, 27 Sep 2004 04:14:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBqmC-0000SR-BN for l2vpn-web-archive@ietf.org; Mon, 27 Sep 2004 04:22:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBqd5-0002ko-Uz; Mon, 27 Sep 2004 04:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBqbh-0002br-Mm for l2vpn@megatron.ietf.org; Mon, 27 Sep 2004 04:11:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10726 for ; Mon, 27 Sep 2004 04:11:35 -0400 (EDT) Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBqjH-0000PW-UP for l2vpn@ietf.org; Mon, 27 Sep 2004 04:19:28 -0400 Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 0601E888889 for ; Mon, 27 Sep 2004 08:11:01 +0000 (UTC) Received: from hotpop.com (unknown [61.16.170.194]) by smtp-2.hotpop.com (Postfix) with ESMTP id 566E98886B6 for ; Mon, 27 Sep 2004 08:10:47 +0000 (UTC) Message-ID: <4157C9EB.6010208@hotpop.com> Date: Mon, 27 Sep 2004 13:36:03 +0530 From: Alok User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: Re: draft-ietf-l3vpn-bgpvpn-auto-04.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Hi John, This question has kept me curious for a while too, Perhaps the WG could clarify, but the idea does seem valid, You have to "discover the end points" before you setup the LSPs. In other words "you have to know the end attachement identifiers" to vector in their direction when setting up LSPs. the NLRI as far as i understand can be anything, including the attachement identifier. [of course it could be "names" too ;)] perhaps others on the list can clarify. -thanks Hi, Can we use this draft to automatically discover VPLS nodes across different sites? Regards, John From l2vpn-bounces@ietf.org Wed Sep 29 10:42:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09708 for ; Wed, 29 Sep 2004 10:42:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCfmo-00088A-OX for l2vpn-web-archive@ietf.org; Wed, 29 Sep 2004 10:50:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCfRI-0000sa-7i; Wed, 29 Sep 2004 10:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCMOj-0007Bn-Fm; Tue, 28 Sep 2004 14:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08673; Tue, 28 Sep 2004 14:08:20 -0400 (EDT) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCMWY-0006Tl-QG; Tue, 28 Sep 2004 14:16:30 -0400 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Tue, 28 Sep 2004 14:07:42 -0400 From: Irwin Lazar To: Irwin Lazar Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3179225262_450875" X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Wed, 29 Sep 2004 10:28:14 -0400 Subject: MPLScon Call For Presentations 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3179225262_450875 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The =B3Call for Presentations=B2 for MPLScon 2005 is now available on the web at: http://www.mplscon.com/speaker/submit_pres.html MPLScon 2005 will be held on May 16-19 at the Marriott Financial Center in New York City. Please let me know if you have any questions. Submissions are due November 19, 2004. Thanks, Irwin --=20 Irwin Lazar, Conference Director, MPLScon http://www.mplscon.com ilazar@mplscon.com Phone: 703-742-9659 AIM/iChat: imlazar Skype: imlazar NEXT EVENT: May 16-19, 2005, New York City --B_3179225262_450875 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable MPLScon Call For Presentations The &= #8220;Call for Presentations” for MPLScon 2005 is now available on the= web at:

http://www.mplsco= n.com/speaker/submit_pres.html

MPLScon 2005 will be held on May 16-19 at the Marriott Financial Center in = New York City.

Please let me know if you have any questions.  Submissions are due Nov= ember 19, 2004.

Thanks,
Irwin

--
Irwin Lazar, Conference Director, MPLScon
http://www.mplscon.com
ilazar@mplscon.com
Phone: 703-742-9659
AIM/iChat: imlazar
Skype: imlazar

NEXT EVENT: May 16-19, 2005, New York City
 --B_3179225262_450875-- From l2vpn-bounces@ietf.org Thu Sep 30 09:00:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17307 for ; Thu, 30 Sep 2004 09:00:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD0gc-0006yX-E7 for l2vpn-web-archive@ietf.org; Thu, 30 Sep 2004 09:09:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD0W4-0003he-TX; Thu, 30 Sep 2004 08:58:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD0Lv-0001FU-Nz for l2vpn@megatron.ietf.org; Thu, 30 Sep 2004 08:48:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16591 for ; Thu, 30 Sep 2004 08:48:05 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD0UA-0006gx-Qr for l2vpn@ietf.org; Thu, 30 Sep 2004 08:56:39 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i8UCigr27442 for ; Thu, 30 Sep 2004 14:44:42 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Thu, 30 Sep 2004 14:46:04 +0200 Message-ID: <415C000C.9050302@pi.se> Date: Thu, 30 Sep 2004 14:46:04 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: L2VPN Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Alex Zinin Subject: wg last call - draft-ietf-l2vpn-vpls-ldp-05.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Working group, this mail is to initiate a working group last call on draft-ietf-l2vpn-vpls-ldp-05.txt. Please send comments to the l2vpn mailing list and to the working co-chairs. The last call ends end of business day October 15 PST. Loa, Rick and Vach -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Thu Sep 30 10:45:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27233 for ; Thu, 30 Sep 2004 10:45:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD2KH-0001OM-I6 for l2vpn-web-archive@ietf.org; Thu, 30 Sep 2004 10:54:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD25a-0001Ui-Ge; Thu, 30 Sep 2004 10:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD1mI-0003uz-2J for l2vpn@megatron.ietf.org; Thu, 30 Sep 2004 10:19:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24878 for ; Thu, 30 Sep 2004 10:19:23 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD1uW-0000l7-E2 for l2vpn@ietf.org; Thu, 30 Sep 2004 10:27:58 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i8UEFmr29364 for ; Thu, 30 Sep 2004 16:15:48 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Thu, 30 Sep 2004 16:17:24 +0200 Message-ID: <415C1573.4090406@pi.se> Date: Thu, 30 Sep 2004 16:17:23 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: L2VPN Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Alex Zinin Subject: draft-ietf-l2vpn-requirements-01.txt - wg last call 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Working group, this is to issue a one week working group last call on draft-ietf-l2vpn-requirements-01.txt, this draft has been through an earlier wg last call with very few comments. We are ready to request publication, but would like to give the working an opportunity to give comments, mainly because the draft have been around for som time. The last call ends on October 8th eob PST. Loa, Rick Vach -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Thu Sep 30 16:55:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01529 for ; Thu, 30 Sep 2004 16:55:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD85l-0003QS-OT for l2vpn-web-archive@ietf.org; Thu, 30 Sep 2004 17:03:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7QD-0005ok-8C; Thu, 30 Sep 2004 16:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD6zs-0005vS-CA; Thu, 30 Sep 2004 15:53:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24372; Thu, 30 Sep 2004 15:53:45 -0400 (EDT) Message-Id: <200409301953.PAA24372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 30 Sep 2004 15:53:45 -0400 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-signaling-02.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Provisioning Models and Endpoint Identifiers in L2VPN Signaling Author(s) : E. Rosen, et al. Filename : draft-ietf-l2vpn-signaling-02.txt Pages : 24 Date : 2004-9-30 There are a number of different kinds of "Provider Provisioned Layer 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different "provisioning models", i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any PW signaling protocol needs to have a method which allows each PW endpoint to identify the other; thus a PW signaling protocol will have the notion of an endpoint identifier. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each provisioning model. It discusses the way in which the endpoint identifiers are distributed by the discovery process, especially when the discovery process is based upon the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-02.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-signaling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-signaling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-30160230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-signaling-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-signaling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-30160230.I-D@ietf.org> --OtherAccess-- --NextPart--