From loa@pi.nu Mon May 4 08:23:34 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD113A704D; Mon, 4 May 2009 08:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNB3uYbJ-fPT; Mon, 4 May 2009 08:23:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DF89F3A6CEC; Mon, 4 May 2009 08:23:33 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 995C9D4048; Mon, 4 May 2009 17:24:52 +0200 (CEST) Message-ID: <49FF08C1.4070408@pi.nu> Date: Mon, 04 May 2009 17:24:49 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, l2vpn@ietf.org, Adrian Farrel , Ross Callon , George Swallow Subject: working group last call on draft-ietf-mpls-tp-nm-req-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 15:23:34 -0000 ALL, This is to start a two week working group last call on draft-ietf-mpls-tp-nm-req-01.txt Please send your comments to the mpls-tp mailing list. This working group last call is joint between the mpls, ccamp. Pwe3 and l2vpn. The working group lst call ends on May 19th eob. /Loa -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From yljiang@huawei.com Wed May 13 04:34:22 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377E43A6EB3 for ; Wed, 13 May 2009 04:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=0.990, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICgyXJ+QeE-I for ; Wed, 13 May 2009 04:34:21 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CA1503A6D89 for ; Wed, 13 May 2009 04:34:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJK00GIWYVQ9T@szxga04-in.huawei.com> for l2vpn@ietf.org; Wed, 13 May 2009 19:35:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJK00GPQYVQCB@szxga04-in.huawei.com> for l2vpn@ietf.org; Wed, 13 May 2009 19:35:50 +0800 (CST) Received: from j59929 ([10.70.77.59]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJK00331YVQ8O@szxml04-in.huawei.com> for l2vpn@ietf.org; Wed, 13 May 2009 19:35:50 +0800 (CST) Date: Wed, 13 May 2009 19:35:50 +0800 From: Jiang Yuan-long Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" To: "Dutta, Pranjal K (Pranjal)" Message-id: <002801c9d3be$f72fed10$3b4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_NPC4Md0M9CM/5sX2u98c2g)" X-Priority: 3 X-MSMail-priority: Normal Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 11:34:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NPC4Md0M9CM/5sX2u98c2g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Dutta, I have a few comments on this draft: 1. From the description in the draft, it seems only one PE-ID is needed for your mechanism. But in the definition of PE-ID TLV in section 4, a list of one or more PE-ID may be included, but do we really need more than one PE-ID element? Can you give some clues on its usage? IMO, this definition is also in contradiction to the prior sentence "The PE-ID TLV carries the unique identifier of a generic PW endpoint". 2. The length of the FEC-128 specific PE-ID element is given as 2 octets, should the correct length be 8? 3. Maybe the FEC-129 specific PE-ID Element needs another extra field for PE address, as AII TLVs can only be null according to RFC 4762 in section 6.1.1, while AGI TLV can only give you information on VPLS instance. 4. I think this mechanism only works properly in a scenario where the MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing msg with PE-ID, then other PEs in the VPLS will process both msgs and the result is flushing all MACs. So maybe this should be pointed out in the applicability section. 5. Some random corrections: s/ignored/ignored by/ page 6, "...So the MAC addresses that require flushing and relearning at PE-2 are only the MAC addresses those have been learned on the PW connected to PE-1." is redundant, maybe it is better to say "...So the MAC addresses that require flushing and relearning at PE-2 are only those MAC addresses learned on the PW connected to PE-1.". Thanks Yuanlong Jiang --Boundary_(ID_NPC4Md0M9CM/5sX2u98c2g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Dutta,
 
I have a few comments on this draft:
 
1. From the description in the draft, it seems only one PE-ID is needed
for your mechanism. But in the definition of PE-ID TLV in section 4,
a list of one or more PE-ID may be included, but do we really need more
than one PE-ID element? Can you give some clues on its usage?
IMO, this definition is also in contradiction to the prior sentence
"The PE-ID TLV carries the unique identifier of a generic PW endpoint". 
 
2. The length of the FEC-128 specific PE-ID element is given as 2 octets,
should the correct length be 8?
 
3. Maybe the FEC-129 specific PE-ID Element needs another extra field
for PE address, as AII TLVs can only be null according to RFC 4762 in
section 6.1.1, while AGI TLV can only give you information on VPLS
instance.
 
4. I think this mechanism only works properly in a scenario where the
MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends
out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing
msg with PE-ID, then other PEs in the VPLS will process both msgs and
the result is flushing all MACs. So maybe this should be pointed out in
the applicability section.
 
5. Some random corrections:
s/ignored/ignored by/
page 6, "...So the MAC addresses that require flushing and relearning at
PE-2 are only the MAC addresses those have been learned on the PW
connected to PE-1." is redundant, maybe it is better to say "...So the MAC
addresses that require flushing and relearning at PE-2 are only those
MAC addresses learned on the PW connected to PE-1.".
 
Thanks
 
Yuanlong Jiang
--Boundary_(ID_NPC4Md0M9CM/5sX2u98c2g)-- From yoav.cohen@nsn.com Wed May 13 05:22:15 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EA03A6BCC; Wed, 13 May 2009 05:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiKbUbiQ4lJP; Wed, 13 May 2009 05:22:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7BE9F3A6A20; Wed, 13 May 2009 05:22:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4DCNjdS027910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2009 14:23:45 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4DCNfL7015441; Wed, 13 May 2009 14:23:42 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 14:23:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [mpls] working group last call on draft-ietf-mpls-tp-nm-req-01.txt Date: Wed, 13 May 2009 14:24:46 +0200 Message-ID: <8916482DE7A7FD4D8B99B729573961E1013349C8@DEMUEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-nm-req-01.txt Thread-Index: AcnMzIfmK8Bkg/yRQU2hc3dZcfJ74gG4/7awAAUDtYA= From: "Cohen, Yoav (NSN - IL/Hod HaSharon)" To: , , , , X-OriginalArrivalTime: 13 May 2009 12:23:36.0653 (UTC) FILETIME=[A3C737D0:01C9D3C5] Cc: loa@pi.se X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 12:22:15 -0000 =20 Kam, Scott, Eric, and all, I have few LC comments on draft-ietf-mpls-tp-nm-req-01 General:=20 The separation between requirements of the MPLS-TP network elements (NEs) and from the Network Management Entity is not always clear. It would be useful to specifically note which requirements apply to NEs, etc. Section 4: 1. "Retrieval of DCN network parameters to ensure compatible functioning, e.g. packet size, timeouts, quality of service, window size, etc.; " What is the usage of "retrieval" in this context. Shouldn't the function support configuration of these parameters? Section 5.1:=20 1. "The MPLS-TP NE MUST support supervision of the OAM mechanisms that are deployed for supporting the OAM requirements defined in [3]." The requirements are too general. It is not clear what the supervision function should explicitly perform. 2. " . Supervision of looping check functions used to detect loops=20 in the data-plane forwarding path (which result in non- delivery of traffic, wasting of forwarding resources and=20 unintended self-replication of traffic);=20 . Supervision of the detection of failure in the sequence of=20 a protocol exchange (e.g. automatic protection switching=20 protocol); " Again, what is explicitly required from the supervision function? =20 Section 5.2: 1. "A Fault Cause indicates a limited interruption of the required transport function." There is no formal definition of Fault Cause. It would be useful to add the definition of Fault Cause to section 1.1. 2. "The failure declaration and clearing MUST be time stamped. The time-stamp SHALL indicate the time at which the fault cause is=20 activated at the input of the fault cause persistency (i.e. defect-to-failure integration) function, and the time at which=20 the fault cause is deactivated at the input of the fault cause persistency function. " It is not clear who is the target of this requirement i.e. MPLS-TP NE or a Management System Entity? Section 5.3.2: "An MPLS-TP NE MUST provide alarm suppression functionality that prevents the generation of superfluous alarms. " It would probably be better to note that alarms resulting from other alarms should be suppressed instead of "superfluous alarms". Section 5.3.3: "Alarm Reporting Control (ARC) supports an automatic in-service provisioning capability. " 1. Would be useful to define the functionality of the ARC 2. Would be useful to define what exactly is required by "automatic in-service provisioning". Section 6.5: " The MPLS-TP NE MUST have the flexibility to configure OAM parameters to meet their specific operational requirements, such=20 as whether (1) one-time on-demand immediately or (2) one-time on-demand pre-scheduled or (3) on-demand periodically based on a=20 specified schedule or (4) proactive on-going. " 1. It may be more appropriate to use the term "capability" instead of "flexibility". Thank you, Yoav Cohen. =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Monday, May 04, 2009 18:25 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ops.ietf.org; pwe3@ietf.org; l2vpn@ietf.org; Adrian Farrel; Ross Callon; George Swallow Subject: [mpls] working group last call on draft-ietf-mpls-tp-nm-req-01.txt ALL, This is to start a two week working group last call on draft-ietf-mpls-tp-nm-req-01.txt Please send your comments to the mpls-tp mailing list. This working group last call is joint between the mpls, ccamp. Pwe3 and l2vpn. The working group lst call ends on May 19th eob. /Loa --=20 Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13=20 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From root@core3.amsl.com Wed May 13 07:30:02 2009 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 24AB728C1B4; Wed, 13 May 2009 07:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-pbb-vpls-pe-model-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090513143002.24AB728C1B4@core3.amsl.com> Date: Wed, 13 May 2009 07:30:02 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 14:30:02 -0000 --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 : Extensions to VPLS PE model for Provider Backbone Bridging Author(s) : A. Sajassi, et al. Filename : draft-ietf-l2vpn-pbb-vpls-pe-model-00.txt Pages : 14 Date : 2009-05-12 IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-pbb-vpls-pe-model-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-l2vpn-pbb-vpls-pe-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-13072242.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 14:15:01 2009 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8771F28C147; Fri, 15 May 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515211501.8771F28C147@core3.amsl.com> Date: Fri, 15 May 2009 14:15:01 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 21:15:01 -0000 --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 : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : E. Rosen, H. Shah, G. Heron, V. Kompella Filename : draft-ietf-l2vpn-arp-mediation-11.txt Pages : 30 Date : 2009-5-15 The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-l2vpn-arp-mediation-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-15140602.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Tue May 19 06:54:28 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2C63A6F23; Tue, 19 May 2009 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPxJDLMR7-Ux; Tue, 19 May 2009 06:54:26 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9CC623A6EDB; Tue, 19 May 2009 06:54:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,215,1241409600"; d="scan'208";a="146209689" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 May 2009 09:55:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 May 2009 09:55:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: working group last call on draft-ietf-mpls-tp-nm-req-01.txt Date: Tue, 19 May 2009 15:55:52 +0200 Message-ID: In-Reply-To: <49FF08C1.4070408@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call on draft-ietf-mpls-tp-nm-req-01.txt Thread-Index: AcnMzJvcO3EVzzN3QueUZdhpnlG3nQLubINQ References: <49FF08C1.4070408@pi.nu> From: "Romascanu, Dan (Dan)" To: "Loa Andersson" , , , , , , "Adrian Farrel" , "Ross Callon" , "George Swallow" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 13:54:28 -0000 Hi, Please find below my comments to this document:=20 1. This document derives its content from the management functionality defined in the ITU-T recommendation G.7710. I suggest that it also relates as principal source of input from the IETF ' Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions' Internet-Draft - http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-man agement-07.txt .=20 2. In Section 3 I do not know how to translate this requirement: ' An MPLS-TP management network SHOULD support seamless management connectivity ...' What is a MPLS-TP management network, is this the same thing as an MCN? What 'seamless' means in this context?=20 3. I cannot make too much sense of section 4. It refers to ITU-T G.7712 which is a heavy architecture document, speaks about OSI and coexistence between OSI and IP as network layer protocols and other such things. What does this section really try to say? That in-band transport for management information SHOULD or MUST be available and that each node of the management network should be addressable, and its status observable? 4. In Section 7 - what does 'monitoring for signal degradation' mean? In general I would suggest that this document reuses and refers to the possible extent at the IPPM terminology 5. In section 7.1 - what does 'performance degradation' mean?=20 6. In section 7.2.1 - what do 'on-demand' and 'pro-active' measurement mean?=20 7. The security consideration section must add requirements on the management interface protocols which MUST have privacy and authentication capabilities so that the access to the management information is protected during day-to-day operations.=20 Dan > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Loa Andersson > Sent: Monday, May 04, 2009 6:25 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ops.ietf.org;=20 > pwe3@ietf.org; l2vpn@ietf.org; Adrian Farrel; Ross Callon;=20 > George Swallow > Subject: working group last call on draft-ietf-mpls-tp-nm-req-01.txt >=20 > ALL, >=20 > This is to start a two week working group last call on >=20 > draft-ietf-mpls-tp-nm-req-01.txt >=20 > Please send your comments to the mpls-tp mailing list. >=20 > This working group last call is joint between the mpls,=20 > ccamp. Pwe3 and l2vpn. >=20 > The working group lst call ends on May 19th eob. >=20 > /Loa >=20 >=20 > --=20 >=20 >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager phone: +46 10 717 52 13 > Ericsson /// +46 767 72 92 13=20 >=20 >=20 > email: =20 > loa.andersson@ericsson.com > =20 > loa.andersson@redback.com > loa@pi.nu >=20 >=20 >=20 From xueli@huawei.com Wed May 20 02:01:17 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD7428C364; Wed, 20 May 2009 02:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.951 X-Spam-Level: * X-Spam-Status: No, score=1.951 tagged_above=-999 required=5 tests=[AWL=1.846, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fiwRqP+UE1k; Wed, 20 May 2009 02:01:16 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DBE953A6FCB; Wed, 20 May 2009 02:00:49 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX00125QFSVD@szxga01-in.huawei.com>; Wed, 20 May 2009 17:02:16 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX00DS4QFSC0@szxga01-in.huawei.com>; Wed, 20 May 2009 17:02:16 +0800 (CST) Received: from x68103 ([10.111.12.100]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJX00DHEQFRTA@szxml06-in.huawei.com>; Wed, 20 May 2009 17:02:16 +0800 (CST) Date: Wed, 20 May 2009 17:02:15 +0800 From: Sherry Xue Subject: Some comments on draft-ietf-pwe3-segmented-pw-11 To: pwe3@ietf.org, l2vpn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZKas4lufkXv9vTue7ZgXr2nAwWw== X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 09:01:17 -0000 Hi, I have reviewed the draft-ietf-pwe3-segmented-pw-11, and have some comments, please find below. 1) Section 4, some confused about figure 2, there are two "emulated service" identifiers, between the egress of CE1 and ingress of CE2, also between the ingress of PE1 and the egress of PE4.Does some amendment should be done to avoid the reduplicate emulated service? 2) Section 4, in the penultimate paragraph, "this document describes procedures for building multi-segment pseudo wires using manual configuration of the switching point PE2", the Switching point" PE2" should be "S-PE "which will be coincident with figure 3. And the identifier of the Switch point in the sentence should be consistent with figure 3. 3) Section 4, in the last paragraph, " no control messages are exchanged yet as the S-PE PE dose not have.", there are a redundant "PE", please delete it. 4) Section 4, in the last paragraph, sentence as "first the S-PE is configured to switch a SS-PW from a specific peer to another SS-PW destined for a different peer". I have some confusion about SS-PW definition used in the MS-PW as PW segment role. SS-PW is defined as "a PW setup directly between two T-PE devices. Each PW in one direction of a SS-PW traverses one PSN tunnel that connects the two T-PEs." in the terminology section of [segmented-pw]. But SS-PW is defined "a PW setup directly between two PE devices. Each direction of an SS-PW traverses one PSN tunnel that connects the two PEs" in RFC5254. They are different, because SS-PW is terminated on different PE roles, T-PE in former case, T-PE or S-PE in latter case. IMO, SS-PW should be setup between TWO T-PE devices, there are some differences between SS-PW and PW segment. If it is right, the SS-PW could not be used the same as PW segment. So the sentence should be restructured as "first the S-PE is configured to switch a PW segment from a specific peer to another PW segment destined for a different peer...". And concerted action should be taken in the draft. 5) Section 7, in the first paragraph, the nomenclature should be identical with figure 3, such as PE2, PE3 should be amended as S-PE and T-PE, etc. 6) Section 7.4, in the second sentence, Should the"PW switching point TLV" in line 3 be "S-PE TLV"? In the fourth and fifth paragraphs, should the "PW switching point TLV" in line 1 be "S-PE TLV"? 7) Section 7.4.1, The title of section 7.4.1 should be accordant with the title of section 7.4, so "S-PE sub-TLV" may be better? 8) Section 8, the title, "MPLS-PW to PW-L2TPv3 control plane switching" may be amended as "MPLS-PW to L2TPv3-PW control plane switching" 9) Section 8.4.1, I have some confused about the session establishment. In the two example exchanges of message, I understand that the MS-PW is setup in one direction totally, and then the other direction. Dose I make a mistake? Now I have a question, take L2TPv2 PW- MPLS PW for example, whether the L2tpv3 ICRP must be send after the LDP label mapping receiving from the PE3? Should the PW switching node, map to LDP Label mapping forward and send L2TPv3 ICRP backwards simultaneity? And I have a question, which is why VCCV CC type 2 is not supported for MS-PW? I think the reason is that the P device, which is neither S-PE nor T-PE, is not responsible to inspect the VCCV message? That is right? Regards Sherry From loa@pi.nu Wed May 20 02:04:40 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A88E3A6C14; Wed, 20 May 2009 02:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC0jjQ65973r; Wed, 20 May 2009 02:04:39 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 8BB5B3A6B65; Wed, 20 May 2009 02:04:39 -0700 (PDT) Received: from [192.36.158.97] (wdhcp-158-97.verkstad.net [192.36.158.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id E1AB6D404F; Wed, 20 May 2009 11:06:13 +0200 (CEST) Message-ID: <4A13C7ED.80206@pi.nu> Date: Wed, 20 May 2009 11:05:49 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, l2vpn@ietf.org, Adrian Farrel , Ross Callon , George Swallow , Eric Gray , "Lam, Hing-Kam (Kam)" , Scott Mansfield Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-nm-req-01.txt References: <49FF08C1.4070408@pi.nu> In-Reply-To: <49FF08C1.4070408@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 May 2009 07:32:36 -0700 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 09:04:40 -0000 All, this working group last call has ended. We have seen quite a bit of comments, could the editors please compile the comments and respond to them, and also when we have agreed to resolution re-spin the draft. /Loa Loa Andersson wrote: > ALL, > > This is to start a two week working group last call on > > draft-ietf-mpls-tp-nm-req-01.txt > > Please send your comments to the mpls-tp mailing list. > > This working group last call is joint between the mpls, > ccamp. Pwe3 and l2vpn. > > The working group lst call ends on May 19th eob. > > /Loa > > -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From yljiang@huawei.com Fri May 22 19:05:04 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23E93A6C4D for ; Fri, 22 May 2009 19:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH3+1r+4JFuO for ; Fri, 22 May 2009 19:05:03 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 488C53A6B61 for ; Fri, 22 May 2009 19:05:02 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK200KH3R6UQ4@szxga02-in.huawei.com> for l2vpn@ietf.org; Sat, 23 May 2009 10:06:30 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK200G97R6UBN@szxga02-in.huawei.com> for l2vpn@ietf.org; Sat, 23 May 2009 10:06:30 +0800 (CST) Received: from j59929 ([10.70.77.59]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK2001JXR6U87@szxml06-in.huawei.com> for l2vpn@ietf.org; Sat, 23 May 2009 10:06:30 +0800 (CST) Date: Sat, 23 May 2009 10:06:29 +0800 From: Jiang Yuan-long Subject: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)" To: Shane Amante , vach.kompella@alcatel-lucent.com, mlasserre@alcatel-lucent.com Message-id: <002a01c9db4b$165a5a20$3b4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_qAuJRh9rb1DroJlM4wz3RA)" X-Priority: 3 X-MSMail-priority: Normal Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 02:05:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_qAuJRh9rb1DroJlM4wz3RA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all, After going through RFC 4762, I think there might be some improvements on the texts, as follows: 1. Section 6.1.1, the 1st paragraph, on page 8, it says: | [RFC4447] describes a generalized FEC structure that is be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. It should say: | [RFC4447] describes a generalized PWid FEC structure that can be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. [...] 2. Section 6.1.1, the last paragraph at the bottom of page 8, it says: Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs | in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. [...] I think "MAC learning table" is confused with "VSI with a MAC learning table" here. BTW, this confusion between VSI and MAC table first appears in RFC 4664, which states in Section 3.4: "[...]. Conceptually, the PE bridge module's forwarding table and the VPLS Forwarder's VSI are distinct entities. (Of course, particular implementations might combine these into a single table, but that is beyond the scope of this document.)" In fact, as the definition of VSI in RFC 4664 shows "the forwarder in a VPLS-PE is a Virtual Switching Instance (VSI)" (on page 9) so it should better say: Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs | in a VPLS terminate on VSIs each with a MAC learning tables, rather than on individual attachment circuits. [...] 3. Section 6.1.1, on page 8, it says: PW type: The allowed PW types are Ethernet (0x0005) and Ethernet tagged mode (0x004), as specified in [RFC4446]. where value '0x004' should be '0x0004', as defined in RFC 4446. The meaning for the latter is that PW type is a 15-bit value. 4. Section 6.2.2, near the top of page 11, it says: | - Remove the association between the MAC address and the AC or PW | over which this message is received. As no LDP message can be sent on the AC or PW, and the AC or PW has no meaning with regard to this removal, so it should better say: | - Remove the item corresponding to this MAC address in the forwarding | table of this VPLS instance, whichever AC or PW this MAC address is | associated with. 5. Section 8.1, at the bottom of page 13, it says: | In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. it should better say: | In a VPLS, a customer Ethernet frame without the preamble is encapsulated with a header as defined in [RFC4448]. 6. The last paragraph before Section 10.1, on page 16, it says: | For rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs. It should say: | For the rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs. 7. Section 10.1, the 1st paragraph, it says: This section describes the hub and spoke connectivity model and | describes the requirements of the bridging capable and non-bridging | MTU-s devices for supporting the spoke connections. As the prior paragraph defines MTU-s and PE-r to be distinct entities, so it should better say: This section describes the hub and spoke connectivity model and | describes the requirements of the MTU-s and the PE-r for supporting | the spoke connections. 8. section 10.2, the 2nd paragraph, on page 21, it says: In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The | mechanism described is identical for both, MTU-s and PE-r devices. The comma in the last sentence should be deleted, so it should say: In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The | mechanism described is identical for both MTU-s and PE-r devices. 9. Section 10.2.2, the 1st paragraph, on page 22, it says: [...]. The use | of other mechanisms that could provide faster detection failures is outside the scope of this document. It should say: [...]. The use | of other mechanisms that could provide faster detection of failures is outside the scope of this document. 10. Section 10.2.2, the 2nd paragraph, on page 22 and 23, it says: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List | TLV, as defined in Section 6, to all PE-rs nodes. [...] For more clarity, it should better say: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List | TLV, as defined in Section 6, to all the other PE-rs nodes. [...] 11. Two abbreviations of 'SP' appear in this document with no introduction, but they have different meanings, and the second is a typo: Section 11.1, the 1st paragraph, on page 24, it says: | [...]. The SP network consists of a core MPLS/IP network that connects many Ethernet islands. [...] It might better say: | [...]. The service provider network consists of a core MPLS/IP network that connects many Ethernet islands. [...] Section 11.2, the 1st paragraph, at the top of page 25, it says: [...]. If an island has more than one | PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs | devices for carrying the SP BPDU packets for that island. [...] It should say: [...]. If an island has more than one | PE-rs, then a dedicated full-mesh of PWs are used among these PE-rs | devices for carrying the STP BPDU packets for that island. [...] 12. Appendix A, on page 29, in the diagram of PWid FEC TLV, it might be better for all the fields' name to be consistent with RFC 4447, so: "PW TLV" should be "PWid FEC" "PWID" should be "PW ID" Appendix A, the last paragraph, on page 29, it says: | In a VPLS, we use a VCID (which, when using the PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. | Note that the VCID as specified in [RFC4447] is a service identifier, identifying a service emulating a point-to-point virtual circuit. [...] Note: 'VCID' last appeared in draft-ietf-pwe3-control-protocol-00.txt, but this field was renamed as 'PW ID' in draft-ietf-pwe3-control-protocol-01.txt, which finally evolved into RFC 4447. AGI is a field in the Generalized PWid FEC, not in the PWid FEC. So it should say: | In a VPLS, we use a VCID (which, when using the Generalized PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. | Note that the VCID, which is later renamed as 'PW ID' in [RFC4447], is a service identifier, identifying a service emulating a point-to-point virtual circuit. [...] Thanks, -Yuanlong Jiang --Boundary_(ID_qAuJRh9rb1DroJlM4wz3RA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi all,
After going through RFC 4762, I think there might be some improvements
on the texts, as follows:
 
1. Section 6.1.1, the 1st paragraph, on page 8, it says:
|   [RFC4447] describes a generalized FEC structure that is be used for
    VPLS signaling in the following manner.  We describe the assignment
    of the Generalized PWid FEC Element fields in the context of VPLS
    signaling.
It should say:
|   [RFC4447] describes a generalized PWid FEC structure that can be used for
    VPLS signaling in the following manner. We describe the assignment
    of the Generalized PWid FEC Element fields in the context of VPLS
    signaling. [...]
 
2. Section 6.1.1, the last paragraph at the bottom of page 8, it says:
   Target Attachment Individual Identifier (TAII), Source Attachment
   Individual Identifier (SAII): These are null because the mesh of PWs
|  in a VPLS terminates on MAC learning tables, rather than on  
   individual attachment circuits. [...]
 
   I think "MAC learning table" is confused with "VSI with a MAC
   learning table" here. BTW, this confusion between VSI and MAC table
   first appears in RFC 4664, which states in Section 3.4:
   "[...]. Conceptually, the PE bridge module's forwarding table and
   the VPLS Forwarder's VSI are distinct entities.  (Of course,
   particular implementations might combine these into a single table,
   but that is beyond the scope of this document.)"
   In fact, as the definition of VSI in RFC 4664 shows "the forwarder in
   a VPLS-PE is a Virtual Switching Instance (VSI)" (on page 9)
 
   so it should better say:
   Target Attachment Individual Identifier (TAII), Source Attachment
   Individual Identifier (SAII): These are null because the mesh of PWs
|  in a VPLS terminate on VSIs each with a MAC learning tables, rather than on  
   individual attachment circuits. [...]
 
3. Section 6.1.1, on page 8, it says:
   PW type: The allowed PW types are Ethernet (0x0005) and Ethernet
   tagged mode (0x004), as specified in [RFC4446].  
 
   where value '0x004' should be '0x0004', as defined in RFC 4446.
   The meaning for the latter is that PW type is a 15-bit value.
 
4. Section 6.2.2, near the top of page 11, it says:
|  -  Remove the association between the MAC address and the AC or PW
|     over which this message is received.
 
      As no LDP message can be sent on the AC or PW, and the AC or PW has
      no meaning with regard to this removal, so it should better say:
     
|  - Remove the item corresponding to this MAC address in the forwarding
|    table of this VPLS instance, whichever AC or PW this MAC address is
|    associated with.
 
5. Section 8.1, at the bottom of page 13, it says:
|  In a VPLS, a customer Ethernet frame without preamble is encapsulated
   with a header as defined in [RFC4448].
  
   it should better say:
|  In a VPLS, a customer Ethernet frame without the preamble is encapsulated
   with a header as defined in [RFC4448].
  
  
6. The last paragraph before Section 10.1, on page 16, it says:  
|  For rest of this discussion we refer to a bridging capable access
   device as MTU-s and a non-bridging capable PE as PE-r.  We refer to a
   routing and bridging capable device as PE-rs.
 
It should say:
|  For the rest of this discussion we refer to a bridging capable access
   device as MTU-s and a non-bridging capable PE as PE-r.  We refer to a
   routing and bridging capable device as PE-rs.
  
7. Section 10.1, the 1st paragraph, it says:
   This section describes the hub and spoke connectivity model and
|  describes the requirements of the bridging capable and non-bridging
|  MTU-s devices for supporting the spoke connections. 
 
As the prior paragraph defines MTU-s and PE-r to be distinct entities,
so it should better say:
 
   This section describes the hub and spoke connectivity model and
|  describes the requirements of the MTU-s and the PE-r for supporting
|  the spoke connections.
 
8. section 10.2, the 2nd paragraph, on page 21, it says:
   In this section, we describe how the redundant connections can be
   provided to avoid total loss of connectivity from the MTU-s.  The
|  mechanism described is identical for both, MTU-s and PE-r devices.
  
The comma in the last sentence should be deleted, so it should say:
 
   In this section, we describe how the redundant connections can be
   provided to avoid total loss of connectivity from the MTU-s.  The
|  mechanism described is identical for both MTU-s and PE-r devices.
 
9. Section 10.2.2, the 1st paragraph, on page 22, it says:
                                                                        [...]. The use
|  of other mechanisms that could provide faster detection failures is
   outside the scope of this document.
  
   It should say:
                                                                        [...]. The use
|  of other mechanisms that could provide faster detection of failures is
   outside the scope of this document.
  
10. Section 10.2.2, the 2nd paragraph, on page 22 and 23, it says: 
                                                 [...]. To enable faster
   convergence, the PE3-rs where the secondary PW got activated may send
   out a flush message (as explained in Section 6.2), using the MAC List
|  TLV, as defined in Section 6, to all PE-rs nodes. [...]
  
   For more clarity, it should better say:
                                                 [...]. To enable faster
   convergence, the PE3-rs where the secondary PW got activated may send
   out a flush message (as explained in Section 6.2), using the MAC List
|  TLV, as defined in Section 6, to all the other PE-rs nodes. [...]
 
11. Two abbreviations of 'SP' appear in this document with no introduction,
but they have different meanings, and the second is a typo:
 
Section 11.1, the 1st paragraph, on page 24, it says:
|                      [...]. The SP network consists of a
   core MPLS/IP network that connects many Ethernet islands. [...]
 
It might better say:
|                    [...]. The service provider network consists of a
   core MPLS/IP network that connects many Ethernet islands. [...]
 
Section 11.2, the 1st paragraph, at the top of page 25, it says:
                               [...]. If an island has more than one
|  PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs
|  devices for carrying the SP BPDU packets for that island. [...]
 
It should say:  
                               [...]. If an island has more than one
|  PE-rs, then a dedicated full-mesh of PWs are used among these PE-rs
|  devices for carrying the STP BPDU packets for that island. [...]
 
12. Appendix A, on page 29, in the diagram of PWid FEC TLV, it might be
better for all the fields' name to be consistent with RFC 4447, so:
   "PW TLV" should be "PWid FEC"
   "PWID" should be "PW ID"
 
    Appendix A, the last paragraph, on page 29, it says:
|  In a VPLS, we use a VCID (which, when using the PWid FEC, has been
   substituted with a more general identifier (AGI), to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
|  Note that the VCID as specified in [RFC4447] is a service identifier, 
   identifying a service emulating a point-to-point virtual circuit. [...]
  
  Note: 'VCID' last appeared in draft-ietf-pwe3-control-protocol-00.txt,
  but this field was renamed as 'PW ID' in draft-ietf-pwe3-control-protocol-01.txt,
  which finally evolved into RFC 4447.  AGI is a field in the Generalized
  PWid FEC, not in the PWid FEC.  So it should say:
 
|  In a VPLS, we use a VCID (which, when using the Generalized PWid FEC, has been
   substituted with a more general identifier (AGI), to address
   extending the scope of a VPLS) to identify an emulated LAN segment.
|  Note that the VCID, which is later renamed as 'PW ID' in [RFC4447], is a service identifier, 
   identifying a service emulating a point-to-point virtual circuit. [...]
 
 
  Thanks,
 
-Yuanlong Jiang
--Boundary_(ID_qAuJRh9rb1DroJlM4wz3RA)-- From phe@soapstonenetworks.com Sun May 24 11:28:27 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3DC28C15A for ; Sun, 24 May 2009 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hXtROIgXCxB for ; Sun, 24 May 2009 11:28:22 -0700 (PDT) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by core3.amsl.com (Postfix) with ESMTP id C484E28C168 for ; Sun, 24 May 2009 11:28:21 -0700 (PDT) Received: from unknown [12.230.177.130] (EHLO p01c12o141.mxlogic.net) by p01c12o141.mxlogic.net (mxl_mta-6.2.0-3) with ESMTP id a22991a4.2865896336.3899.00-502.p01c12o141.mxlogic.net (envelope-from ); Sun, 24 May 2009 12:30:02 -0600 (MDT) Received: from unknown [12.230.177.130] (EHLO smtp.soapstonenetworks.com) by p01c12o141.mxlogic.net (mxl_mta-6.2.0-3) over TLS secured channel with ESMTP id 312991a4.3463818128.3885.00-001.p01c12o141.mxlogic.net (envelope-from ); Sun, 24 May 2009 12:29:45 -0600 (MDT) Received: from corp-e2k7-mbx01.Soapstone.local ([172.24.2.72]) by cratos.Soapstone.local ([172.24.2.65]) with mapi; Sun, 24 May 2009 14:29:39 -0400 From: Peng He To: Jiang Yuan-long , Shane Amante , "vach.kompella@alcatel-lucent.com" , "mlasserre@alcatel-lucent.com" Date: Sun, 24 May 2009 14:26:57 -0400 Subject: RE: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)" Thread-Topic: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)" Thread-Index: AcnbSyOwKLOqwGgvR0yyWWGAgXZiKgBUhTuE Message-ID: References: <002a01c9db4b$165a5a20$3b4d460a@china.huawei.com> In-Reply-To: <002a01c9db4b$165a5a20$3b4d460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; S=0.200(2009052001)] X-MAIL-FROM: X-SOURCE-IP: [12.230.177.130] Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 18:28:27 -0000 Interesting. I have the same confusion as Yuan-long on item 12th in his b= elow e-mail. Regards, Peng ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] On Behalf Of Jiang Yu= an-long [yljiang@huawei.com] Sent: Friday, May 22, 2009 10:06 PM To: Shane Amante; vach.kompella@alcatel-lucent.com; mlasserre@alcatel-lucen= t.com Cc: l2vpn@ietf.org Subject: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the= Label Distribution Protocol (LDP)" Hi all, After going through RFC 4762, I think there might be some improvements on the texts, as follows: 1. Section 6.1.1, the 1st paragraph, on page 8, it says: | [RFC4447] describes a generalized FEC structure that is be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. It should say: | [RFC4447] describes a generalized PWid FEC structure that can be used f= or VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. [...] 2. Section 6.1.1, the last paragraph at the bottom of page 8, it says: Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs | in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. [...] I think "MAC learning table" is confused with "VSI with a MAC learning table" here. BTW, this confusion between VSI and MAC table first appears in RFC 4664, which states in Section 3.4: "[...]. Conceptually, the PE bridge module's forwarding table and the VPLS Forwarder's VSI are distinct entities. (Of course, particular implementations might combine these into a single table, but that is beyond the scope of this document.)" In fact, as the definition of VSI in RFC 4664 shows "the forwarder in a VPLS-PE is a Virtual Switching Instance (VSI)" (on page 9) so it should better say: Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs | in a VPLS terminate on VSIs each with a MAC learning tables, rather than= on individual attachment circuits. [...] 3. Section 6.1.1, on page 8, it says: PW type: The allowed PW types are Ethernet (0x0005) and Ethernet tagged mode (0x004), as specified in [RFC4446]. where value '0x004' should be '0x0004', as defined in RFC 4446. The meaning for the latter is that PW type is a 15-bit value. 4. Section 6.2.2, near the top of page 11, it says: | - Remove the association between the MAC address and the AC or PW | over which this message is received. As no LDP message can be sent on the AC or PW, and the AC or PW has no meaning with regard to this removal, so it should better say: | - Remove the item corresponding to this MAC address in the forwarding | table of this VPLS instance, whichever AC or PW this MAC address is | associated with. 5. Section 8.1, at the bottom of page 13, it says: | In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. it should better say: | In a VPLS, a customer Ethernet frame without the preamble is encapsulate= d with a header as defined in [RFC4448]. 6. The last paragraph before Section 10.1, on page 16, it says: | For rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs. It should say: | For the rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs. 7. Section 10.1, the 1st paragraph, it says: This section describes the hub and spoke connectivity model and | describes the requirements of the bridging capable and non-bridging | MTU-s devices for supporting the spoke connections. As the prior paragraph defines MTU-s and PE-r to be distinct entities, so it should better say: This section describes the hub and spoke connectivity model and | describes the requirements of the MTU-s and the PE-r for supporting | the spoke connections. 8. section 10.2, the 2nd paragraph, on page 21, it says: In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The | mechanism described is identical for both, MTU-s and PE-r devices. The comma in the last sentence should be deleted, so it should say: In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The | mechanism described is identical for both MTU-s and PE-r devices. 9. Section 10.2.2, the 1st paragraph, on page 22, it says: [..= .]. The use | of other mechanisms that could provide faster detection failures is outside the scope of this document. It should say: [..= .]. The use | of other mechanisms that could provide faster detection of failures is outside the scope of this document. 10. Section 10.2.2, the 2nd paragraph, on page 22 and 23, it says: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List | TLV, as defined in Section 6, to all PE-rs nodes. [...] For more clarity, it should better say: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List | TLV, as defined in Section 6, to all the other PE-rs nodes. [...] 11. Two abbreviations of 'SP' appear in this document with no introduction, but they have different meanings, and the second is a typo: Section 11.1, the 1st paragraph, on page 24, it says: | [...]. The SP network consists of a core MPLS/IP network that connects many Ethernet islands. [...] It might better say: | [...]. The service provider network consists of a core MPLS/IP network that connects many Ethernet islands. [...] Section 11.2, the 1st paragraph, at the top of page 25, it says: [...]. If an island has more than one | PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs | devices for carrying the SP BPDU packets for that island. [...] It should say: [...]. If an island has more than one | PE-rs, then a dedicated full-mesh of PWs are used among these PE-rs | devices for carrying the STP BPDU packets for that island. [...] 12. Appendix A, on page 29, in the diagram of PWid FEC TLV, it might be better for all the fields' name to be consistent with RFC 4447, so: "PW TLV" should be "PWid FEC" "PWID" should be "PW ID" Appendix A, the last paragraph, on page 29, it says: | In a VPLS, we use a VCID (which, when using the PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. | Note that the VCID as specified in [RFC4447] is a service identifier, identifying a service emulating a point-to-point virtual circuit. [...] Note: 'VCID' last appeared in draft-ietf-pwe3-control-protocol-00.txt, but this field was renamed as 'PW ID' in draft-ietf-pwe3-control-protocol= -01.txt, which finally evolved into RFC 4447. AGI is a field in the Generalized PWid FEC, not in the PWid FEC. So it should say: | In a VPLS, we use a VCID (which, when using the Generalized PWid FEC, ha= s been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. | Note that the VCID, which is later renamed as 'PW ID' in [RFC4447], is a= service identifier, identifying a service emulating a point-to-point virtual circuit. [...] Thanks, -Yuanlong Jiang From yljiang@huawei.com Sun May 24 20:28:41 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879AE3A6C60 for ; Sun, 24 May 2009 20:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7W1CrwUOyrL for ; Sun, 24 May 2009 20:28:40 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0970B3A6B6B for ; Sun, 24 May 2009 20:28:40 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK600624KEAX4@szxga01-in.huawei.com> for l2vpn@ietf.org; Mon, 25 May 2009 11:30:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK600JTZKE9EF@szxga01-in.huawei.com> for l2vpn@ietf.org; Mon, 25 May 2009 11:30:09 +0800 (CST) Received: from j59929 ([10.70.77.59]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK600ISGKE79E@szxml04-in.huawei.com> for l2vpn@ietf.org; Mon, 25 May 2009 11:30:09 +0800 (CST) Date: Mon, 25 May 2009 11:30:06 +0800 From: Jiang Yuan-long Subject: Re: Comments on RFC 4762"Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)" To: Peng He , mlasserre@alcatel-lucent.com, vach.kompella@alcatel-lucent.com, "\"Shane Amante\"" Message-id: <005401c9dce9$199510a0$3b4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01c9db4b$165a5a20$3b4d460a@china.huawei.com> Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 03:28:41 -0000 Another misleading sentence in RFC 4762, near the bottom of page 10: [...]. Note that if a PE receives a MAC Address Withdraw Message and does not understand it, it MUST ignore the message. [...] As MAC Address Withdraw Message is extended based on Address Withdraw Message defined in RFC 3036 and uses the same message type, I believe that every PE with LDP support should understand this type of message. So, maybe it should be: [...]. Note that if a PE receives a MAC Address Withdraw Message and does not understand the MAC List TLV in the message, it MUST ignore the whole message. [...] or: [...]. Note that if a PE receives a MAC Address Withdraw Message and does not understand the MAC List TLV in the message, it MUST ignore this TLV. [...] Not sure which is the intention of the text, any comments? Thanks Yuanlong Jiang ----- Original Message ----- From: "Peng He" To: "Jiang Yuan-long" ; "Shane Amante" ; ; Cc: Sent: Monday, May 25, 2009 2:26 AM Subject: RE: Comments on RFC 4762"Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)" Interesting. I have the same confusion as Yuan-long on item 12th in his below e-mail. Regards, Peng ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] On Behalf Of Jiang Yuan-long [yljiang@huawei.com] Sent: Friday, May 22, 2009 10:06 PM To: Shane Amante; vach.kompella@alcatel-lucent.com; mlasserre@alcatel-lucent.com Cc: l2vpn@ietf.org Subject: Comments on RFC 4762 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)" Hi all, After going through RFC 4762, I think there might be some improvements on the texts, as follows: 1. Section 6.1.1, the 1st paragraph, on page 8, it says: | [RFC4447] describes a generalized FEC structure that is be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. It should say: | [RFC4447] describes a generalized PWid FEC structure that can be used for VPLS signaling in the following manner. We describe the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. [...] 2. Section 6.1.1, the last paragraph at the bottom of page 8, it says: Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs | in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. [...] I think "MAC learning table" is confused with "VSI with a MAC learning table" here. BTW, this confusion between VSI and MAC table first appears in RFC 4664, which states in Section 3.4: "[...]. Conceptually, the PE bridge module's forwarding table and the VPLS Forwarder's VSI are distinct entities. (Of course, particular implementations might combine these into a single table, but that is beyond the scope of this document.)" In fact, as the definition of VSI in RFC 4664 shows "the forwarder in a VPLS-PE is a Virtual Switching Instance (VSI)" (on page 9) so it should better say: Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs | in a VPLS terminate on VSIs each with a MAC learning tables, rather than on individual attachment circuits. [...] 3. Section 6.1.1, on page 8, it says: PW type: The allowed PW types are Ethernet (0x0005) and Ethernet tagged mode (0x004), as specified in [RFC4446]. where value '0x004' should be '0x0004', as defined in RFC 4446. The meaning for the latter is that PW type is a 15-bit value. 4. Section 6.2.2, near the top of page 11, it says: | - Remove the association between the MAC address and the AC or PW | over which this message is received. As no LDP message can be sent on the AC or PW, and the AC or PW has no meaning with regard to this removal, so it should better say: | - Remove the item corresponding to this MAC address in the forwarding | table of this VPLS instance, whichever AC or PW this MAC address is | associated with. 5. Section 8.1, at the bottom of page 13, it says: | In a VPLS, a customer Ethernet frame without preamble is encapsulated with a header as defined in [RFC4448]. it should better say: | In a VPLS, a customer Ethernet frame without the preamble is encapsulated with a header as defined in [RFC4448]. 6. The last paragraph before Section 10.1, on page 16, it says: | For rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs. It should say: | For the rest of this discussion we refer to a bridging capable access device as MTU-s and a non-bridging capable PE as PE-r. We refer to a routing and bridging capable device as PE-rs. 7. Section 10.1, the 1st paragraph, it says: This section describes the hub and spoke connectivity model and | describes the requirements of the bridging capable and non-bridging | MTU-s devices for supporting the spoke connections. As the prior paragraph defines MTU-s and PE-r to be distinct entities, so it should better say: This section describes the hub and spoke connectivity model and | describes the requirements of the MTU-s and the PE-r for supporting | the spoke connections. 8. section 10.2, the 2nd paragraph, on page 21, it says: In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The | mechanism described is identical for both, MTU-s and PE-r devices. The comma in the last sentence should be deleted, so it should say: In this section, we describe how the redundant connections can be provided to avoid total loss of connectivity from the MTU-s. The | mechanism described is identical for both MTU-s and PE-r devices. 9. Section 10.2.2, the 1st paragraph, on page 22, it says: [...]. The use | of other mechanisms that could provide faster detection failures is outside the scope of this document. It should say: [...]. The use | of other mechanisms that could provide faster detection of failures is outside the scope of this document. 10. Section 10.2.2, the 2nd paragraph, on page 22 and 23, it says: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List | TLV, as defined in Section 6, to all PE-rs nodes. [...] For more clarity, it should better say: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), using the MAC List | TLV, as defined in Section 6, to all the other PE-rs nodes. [...] 11. Two abbreviations of 'SP' appear in this document with no introduction, but they have different meanings, and the second is a typo: Section 11.1, the 1st paragraph, on page 24, it says: | [...]. The SP network consists of a core MPLS/IP network that connects many Ethernet islands. [...] It might better say: | [...]. The service provider network consists of a core MPLS/IP network that connects many Ethernet islands. [...] Section 11.2, the 1st paragraph, at the top of page 25, it says: [...]. If an island has more than one | PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs | devices for carrying the SP BPDU packets for that island. [...] It should say: [...]. If an island has more than one | PE-rs, then a dedicated full-mesh of PWs are used among these PE-rs | devices for carrying the STP BPDU packets for that island. [...] 12. Appendix A, on page 29, in the diagram of PWid FEC TLV, it might be better for all the fields' name to be consistent with RFC 4447, so: "PW TLV" should be "PWid FEC" "PWID" should be "PW ID" Appendix A, the last paragraph, on page 29, it says: | In a VPLS, we use a VCID (which, when using the PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. | Note that the VCID as specified in [RFC4447] is a service identifier, identifying a service emulating a point-to-point virtual circuit. [...] Note: 'VCID' last appeared in draft-ietf-pwe3-control-protocol-00.txt, but this field was renamed as 'PW ID' in draft-ietf-pwe3-control-protocol-01.txt, which finally evolved into RFC 4447. AGI is a field in the Generalized PWid FEC, not in the PWid FEC. So it should say: | In a VPLS, we use a VCID (which, when using the Generalized PWid FEC, has been substituted with a more general identifier (AGI), to address extending the scope of a VPLS) to identify an emulated LAN segment. | Note that the VCID, which is later renamed as 'PW ID' in [RFC4447], is a service identifier, identifying a service emulating a point-to-point virtual circuit. [...] Thanks, -Yuanlong Jiang From pdutta@alcatel-lucent.com Mon May 25 22:55:52 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A09C28C164 for ; Mon, 25 May 2009 22:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.121 X-Spam-Level: X-Spam-Status: No, score=-4.121 tagged_above=-999 required=5 tests=[AWL=-1.873, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnBUOssEUT+o for ; Mon, 25 May 2009 22:55:45 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 4DE623A6ABD for ; Mon, 25 May 2009 22:55:44 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4Q5urHM005170 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 May 2009 07:57:02 +0200 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 26 May 2009 07:56:53 +0200 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 26 May 2009 11:21:17 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Jiang Yuan-long , "Dutta, Pranjal K (Pranjal)" Date: Tue, 26 May 2009 11:21:15 +0530 Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Thread-Topic: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Thread-Index: AcnTvwQvxZ3AncKQTzOQZZs/MwcA9AKAc4Cw Message-ID: References: <002801c9d3be$f72fed10$3b4d460a@china.huawei.com> In-Reply-To: <002801c9d3be$f72fed10$3b4d460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E052672DA61INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 05:55:52 -0000 --_000_C584046466ED224CA92C1BC3313B963E052672DA61INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please refer to my answer inline to your comments. Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of J= iang Yuan-long Sent: Wednesday, May 13, 2009 4:36 AM To: Dutta, Pranjal K (Pranjal) Cc: l2vpn@ietf.org Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Hi Dutta, I have a few comments on this draft: 1. From the description in the draft, it seems only one PE-ID is needed for your mechanism. But in the definition of PE-ID TLV in section 4, a list of one or more PE-ID may be included, but do we really need more than one PE-ID element? Can you give some clues on its usage? IMO, this definition is also in contradiction to the prior sentence "The PE-ID TLV carries the unique identifier of a generic PW endpoint". [Pranjal] Yes, that's correct. PE-ID TLV can accommodate a LIST of PE-ID Elemen= ts. Today implementations can send a list of FEC Elements within a FEC TLV sent in the MAC flu= sh message. A common network event may trigger failure of primary PWs for a set of VPLS instances= together, which requires to send mac flush for all those instances. Sending an individual LDP MAC flush message= per VPLS instance is sub-optimal and so MAC flush for a set of VPLS instances are bundled in a single me= ssage. Same applies to optimized MAC flush with PE-ID as well. 2. The length of the FEC-128 specific PE-ID element is given as 2 octets, should the correct length be 8? [Pranjal] That's right. It's a typo. It should have been 8 octets. We will corr= ect it in the next revision. 3. Maybe the FEC-129 specific PE-ID Element needs another extra field for PE address, as AII TLVs can only be null according to RFC 4762 in section 6.1.1, while AGI TLV can only give you information on VPLS instance. [Pranjal] RFC 4762 also specifies that use of non-null SAII and TAII would be ad= dressed in future revision. Today, FEC 129 is used in VPLS provisioned with BGP-AD where SAII/TAII= always carry valid end-point identifiers (VS-ID) as per l2vpn signaling draft below. http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non BG= P-AD deployments to replace FEC 128. But if you see AGI definition in RFC 4446 (that carries vpls-id as per= RFC 4762), only one type is allocated to be used in BGP-AD provisioned VPLS from L2 VPN signaling draft. 4. I think this mechanism only works properly in a scenario where the MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing msg with PE-ID, then other PEs in the VPLS will process both msgs and the result is flushing all MACs. So maybe this should be pointed out in the applicability section. [Pranjal] Following is stated in the section 5. Application of PE-ID TLV in Optimized MAC Flush However the inclusion of the FEC-TLV should be based on what would be the desired effect should the PE-ID not be understood by the receiver. In cases where the desired action when the PE-ID is not understood would be to behave as described in [RFC4762], then the FEC TLV SHOULD be included. In cases where the desired action when the PE-ID is not understood is to take no action, then the FEC TLV SHOULD NOT be included. Are you suggesting for more explanation in that section? 5. Some random corrections: s/ignored/ignored by/ page 6, "...So the MAC addresses that require flushing and relearning at PE-2 are only the MAC addresses those have been learned on the PW connected to PE-1." is redundant, maybe it is better to say "...So the MAC addresses that require flushing and relearning at PE-2 are only those MAC addresses learned on the PW connected to PE-1.". [Pranjal] Sure, we would address this in the next revision. Thanks Yuanlong Jiang --_000_C584046466ED224CA92C1BC3313B963E052672DA61INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

       P= lease refer to my answer inline to your comments.

 

Thanks,

Pranjal

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiang Yuan-long
Sent: Wednesday, May 13, 200= 9 4:36 AM
To: Dutta, Pranjal K (Pranja= l)
Cc: l2vpn@ietf.org
Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

 

Hi Dutta,

 

I have a few comments on this draft:<= /span>

 

1. From the description in the draft,= it seems only one PE-ID is needed

for your mechanism. But in the defini= tion of PE-ID TLV in section 4,

a list of one or more PE-ID may be included, but do we really need more

than one PE-ID element? Can you give = some clues on its usage?
IMO, this definition is also in contradiction to the prior sentence =

"The PE-ID TLV carries the uniqu= e identifier of a generic PW endpoint".  <= /p>

 

[Pranjal]

      Yes, th= at’s correct. PE-ID TLV can accommodate a LIST of PE-ID Elements. Today implementations

       c= an send a list of FEC Elements within a FEC TLV sent in the MAC flush message. A co= mmon network

       e= vent may trigger failure of primary PWs for a set of VPLS instances together, wh= ich requires to send mac flush

       f= or all those instances. Sending an individual LDP MAC flush message per VPLS instance is sub-optimal and

       s= o MAC flush for a set of VPLS instances are bundled in a  single message= . Same applies to optimized

       M= AC flush with PE-ID as well.

 

 

 

2. The length of the FEC-128 specific PE-ID element is given as 2 octets,

should the correct length be 8?<= /o:p>

 

[Pranjal]

      That= 217;s right. It’s a typo. It should have been 8 octets. We will correct it = in the next revision.

 

 

3. Maybe the FEC-129 specific PE-ID Element needs another extra field

for PE address, as AII TLVs can only = be null according to RFC 4762 in

section 6.1.1, while AGI TLV can only give you information on VPLS

instance.

 

[Pranjal]

     RFC 4762 also specifies that use of non-null SAII and TAII would be addressed in future revision.

     Today, FEC 12= 9 is used in VPLS provisioned with BGP-AD where SAII/TAII always carry valid

     end-point identifiers (VS-ID) as per l2vpn signaling draft below.

 

     http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt

 

     RFC 4762 kept= a provision for NULL SAII/TAII if FEC 129 is used non BGP-AD deployments to replace FEC= 128.

    

     But if you se= e AGI definition in RFC 4446 (that carries vpls-id as per RFC 4762), only one type is allocated to be used

     in BGP-AD pro= visioned VPLS from  L2 VPN signaling draft.

 

4. I think this mechanism only works properly in a scenario where the

MTU-s, PE-1 and PE-2 all play in harm= ony, otherwise, if MTU-s sends

out a RFC4762 compatiable flushing ms= g, while PE-1 sends out a flushing

msg with PE-ID, then other PEs in the VPLS will process both msgs and

the result is flushing all MACs. So m= aybe this should be pointed out in

the applicability section.=

 

[Pranjal]  Following is stated in the se=
ction 
 
5. Application of PE-=
ID TLV in Optimized MAC Flush

 

 

&=
nbsp;  However the inclusion of the FEC-TLV should be  
  =
 based on what would be the desired effect should the PE-ID not be&nbs=
p; 
  =
 understood by the receiver.  In cases where the desired action w=
hen  
  =
 the PE-ID is not understood would be to behave as described in  =

  =
 [RFC4762], then the FEC TLV SHOULD be included.  In cases where =
the  
  =
 desired action when the PE-ID is not understood is to take no  <=
o:p>
  =
 action, then the FEC TLV SHOULD NOT be included.
 <=
/o:p>
 Are you sug=
gesting for more explanation in that section?


 

 

5. Some random corrections:
s/ignored/ignored by/

page 6, "...So the MAC addresses that require flushing and relearning at

PE-2 are only the MAC addresses those have been learned on the PW

connected to PE-1." is redundant= , maybe it is better to say "...So the MAC

addresses that require flushing and relearning at PE-2 are only those

MAC addresses learned on the PW conne= cted to PE-1.".

 

[Pranjal] Sure, we would address this = in the next revision.

 

Thanks

 

Yuanlong Jiang

--_000_C584046466ED224CA92C1BC3313B963E052672DA61INBANSXCHMBSA_-- From yljiang@huawei.com Tue May 26 18:53:15 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9373A69EB for ; Tue, 26 May 2009 18:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.82 X-Spam-Level: X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqZKJwS5eRkL for ; Tue, 26 May 2009 18:53:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 40E973A67F5 for ; Tue, 26 May 2009 18:53:13 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKA00D5Z5B8A0@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 27 May 2009 09:54:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKA00FF95B8UI@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 27 May 2009 09:54:44 +0800 (CST) Received: from j59929 ([10.70.77.59]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKA003CF5B7DG@szxml04-in.huawei.com> for l2vpn@ietf.org; Wed, 27 May 2009 09:54:44 +0800 (CST) Date: Wed, 27 May 2009 09:54:43 +0800 From: Jiang Yuan-long Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" To: "Dutta, Pranjal K (Pranjal)" Message-id: <005901c9de6e$1b179930$3b4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_xiJ/pvgP8r5v9vLXv+OIMA)" X-Priority: 3 X-MSMail-priority: Normal References: <002801c9d3be$f72fed10$3b4d460a@china.huawei.com> Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 01:53:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_xiJ/pvgP8r5v9vLXv+OIMA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Pranjal, Thank you for the explanation on the PE-ID, it helps me to understand what is beyond the texts, I sincerely appreciate it:) Another question, section 5.2, at the bottom of page 12, it says: By default, MTU-2 should still trigger MAC flush as currently defined in [RFC4762] after the backup PW is made active by RSTP. The same text is also found in draft-ietf-pwe3-redundancy-bit. But in RFC 4762, it is not the MTU-s but the PE that should send out the flush msg. As the only description on this mechanism is at the bottom of page 22: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), [...] I wonder is there anything I missed? Best regards Yuanlong Jiang ----- Original Message ----- From: Dutta, Pranjal K (Pranjal) To: Jiang Yuan-long ; Dutta, Pranjal K (Pranjal) Cc: l2vpn@ietf.org Sent: Tuesday, May 26, 2009 1:51 PM Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Hi, Please refer to my answer inline to your comments. Thanks, Pranjal ------------------------------------------------------------------------------ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiang Yuan-long Sent: Wednesday, May 13, 2009 4:36 AM To: Dutta, Pranjal K (Pranjal) Cc: l2vpn@ietf.org Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Hi Dutta, I have a few comments on this draft: 1. From the description in the draft, it seems only one PE-ID is needed for your mechanism. But in the definition of PE-ID TLV in section 4, a list of one or more PE-ID may be included, but do we really need more than one PE-ID element? Can you give some clues on its usage? IMO, this definition is also in contradiction to the prior sentence "The PE-ID TLV carries the unique identifier of a generic PW endpoint". [Pranjal] Yes, that's correct. PE-ID TLV can accommodate a LIST of PE-ID Elements. Today implementations can send a list of FEC Elements within a FEC TLV sent in the MAC flush message. A common network event may trigger failure of primary PWs for a set of VPLS instances together, which requires to send mac flush for all those instances. Sending an individual LDP MAC flush message per VPLS instance is sub-optimal and so MAC flush for a set of VPLS instances are bundled in a single message. Same applies to optimized MAC flush with PE-ID as well. 2. The length of the FEC-128 specific PE-ID element is given as 2 octets, should the correct length be 8? [Pranjal] That's right. It's a typo. It should have been 8 octets. We will correct it in the next revision. 3. Maybe the FEC-129 specific PE-ID Element needs another extra field for PE address, as AII TLVs can only be null according to RFC 4762 in section 6.1.1, while AGI TLV can only give you information on VPLS instance. [Pranjal] RFC 4762 also specifies that use of non-null SAII and TAII would be addressed in future revision. Today, FEC 129 is used in VPLS provisioned with BGP-AD where SAII/TAII always carry valid end-point identifiers (VS-ID) as per l2vpn signaling draft below. http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non BGP-AD deployments to replace FEC 128. But if you see AGI definition in RFC 4446 (that carries vpls-id as per RFC 4762), only one type is allocated to be used in BGP-AD provisioned VPLS from L2 VPN signaling draft. 4. I think this mechanism only works properly in a scenario where the MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing msg with PE-ID, then other PEs in the VPLS will process both msgs and the result is flushing all MACs. So maybe this should be pointed out in the applicability section. [Pranjal] Following is stated in the section 5. Application of PE-ID TLV in Optimized MAC Flush However the inclusion of the FEC-TLV should be based on what would be the desired effect should the PE-ID not be understood by the receiver. In cases where the desired action when the PE-ID is not understood would be to behave as described in [RFC4762], then the FEC TLV SHOULD be included. In cases where the desired action when the PE-ID is not understood is to take no action, then the FEC TLV SHOULD NOT be included. Are you suggesting for more explanation in that section? 5. Some random corrections: s/ignored/ignored by/ page 6, "...So the MAC addresses that require flushing and relearning at PE-2 are only the MAC addresses those have been learned on the PW connected to PE-1." is redundant, maybe it is better to say "...So the MAC addresses that require flushing and relearning at PE-2 are only those MAC addresses learned on the PW connected to PE-1.". [Pranjal] Sure, we would address this in the next revision. Thanks Yuanlong Jiang --Boundary_(ID_xiJ/pvgP8r5v9vLXv+OIMA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Pranjal,
 
Thank you for the = explanation on the PE-ID, it=20 helps me to understand what is
beyond the texts, I = sincerely appreciate=20 it:)
 
Another question, section = 5.2, at the bottom of page=20 12, it says:
 
   By default, = MTU-2 should still trigger=20 MAC flush as currently 
   defined in [RFC4762] after = the=20 backup PW is made active by RSTP. 
The same text is also = found=20 in draft-ietf-pwe3-redundancy-bit.
 
But in RFC 4762, it is not = the MTU-s but the PE that=20 should send out the flush msg.
As the only description = on this mechanism is at=20 the bottom of page 22:
          &nbs= p;            = ;            =             &= nbsp; =20 [...]. To enable faster
   convergence, the PE3-rs where = the=20 secondary PW got activated may send
   out a flush message = (as=20 explained in Section 6.2), [...]
 
I wonder is there anything I = missed?
 
 
 Best = regards
 
Yuanlong Jiang
 
----- Original Message ----- =
To: Jiang Yuan-long ; Dutta,=20 Pranjal K (Pranjal)
Sent: Tuesday, May = 26, 2009 1:51 PM
Subject: RE: Comments = on=20 "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

Hi,

  =20     Please refer to my answer inline to your=20 comments.

 

Thanks,

Pranjal

 

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf=20 Of Jiang Yuan-long
Sent: Wednesday, May 13, 2009 = 4:36=20 AM
To: Dutta, = Pranjal K=20 (Pranjal)
Cc: l2vpn@ietf.org
Subject: Comments on=20 = "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

 

Hi=20 Dutta,

 

I have a few = comments=20 on this draft:

 

1. From the=20 description in the draft, it seems only one PE-ID is needed=20

for your = mechanism.=20 But in the definition of PE-ID TLV in section 4,=20

a list of = one or more=20 PE-ID may be included, but do we really need more=20

than one = PE-ID=20 element? Can you give some clues on its usage?
IMO, this definition = is also=20 in contradiction to the prior sentence =

"The PE-ID = TLV carries=20 the unique identifier of a generic PW endpoint". =20

 

[Pranjal]

     =20 Yes, that=92s correct. PE-ID TLV can accommodate a LIST of PE-ID = Elements. Today=20 implementations

      =20 can send a list of FEC Elements within a FEC TLV sent in the MAC flush = message. A common network

      =20 event may trigger failure of primary PWs for a set of VPLS instances = together,=20 which requires to send mac flush

      =20 for all those instances. Sending an individual LDP MAC flush message = per VPLS=20 instance is sub-optimal and

      =20 so MAC flush for a set of VPLS instances are bundled in a  single = message. Same applies to optimized

      =20 MAC flush with PE-ID as well.

 

 

 

2. The = length of the=20 FEC-128 specific PE-ID element is given as 2 octets,=20

should the = correct=20 length be 8?

 

[Pranjal]

     =20 That=92s right. It=92s a typo. It should have been 8 octets. We will = correct it in=20 the next revision.

 

 

3. Maybe the = FEC-129=20 specific PE-ID Element needs another extra field=20

for PE = address, as AII=20 TLVs can only be null according to RFC 4762 in=20

section = 6.1.1, while=20 AGI TLV can only give you information on VPLS=20

instance.=20

 

[Pranjal]

    =20 RFC 4762 also specifies that use of non-null SAII and TAII would be = addressed=20 in future revision.

    =20 Today, FEC 129 is used in VPLS provisioned with BGP-AD where SAII/TAII = always=20 carry valid

    =20 end-point identifiers (VS-ID) as per l2vpn signaling draft=20 below.

 

   =20  http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.t= xt

 

    =20 RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non = BGP-AD=20 deployments to replace FEC 128.

    =20

    =20 But if you see AGI definition in RFC 4446 (that carries vpls-id as per = RFC=20 4762), only one type is allocated to be used =

    =20 in BGP-AD provisioned VPLS from  L2 VPN signaling draft.=20

 

4. I think = this=20 mechanism only works properly in a scenario where the=20

MTU-s, PE-1 = and PE-2=20 all play in harmony, otherwise, if MTU-s sends=20

out a = RFC4762=20 compatiable flushing msg, while PE-1 sends out a flushing=20

msg with = PE-ID, then=20 other PEs in the VPLS will process both msgs and=20

the result = is flushing=20 all MACs. So maybe this should be pointed out in=20

the = applicability=20 section.

 

[Pranjal]  Following is stated in the section =

 
5. Application of PE-ID =
TLV in Optimized MAC Flush

 

 

   However the =
inclusion of the FEC-TLV should be  =

   based on what =
would be the desired effect should the PE-ID not be  =

   understood by =
the receiver.  In cases where the desired action when  =

   the PE-ID is =
not understood would be to behave as described in  =

   [RFC4762], =
then the FEC TLV SHOULD be included.  In cases where the  =

   desired =
action when the PE-ID is not understood is to take no  =

   action, then =
the FEC TLV SHOULD NOT be =
included.
 
 Are you suggesting for =
more explanation in that section?

 

 

5. Some = random=20 corrections:
s/ignored/ignored = by/

page 6, = "...So the MAC=20 addresses that require flushing and relearning at=20

PE-2 are = only the MAC=20 addresses those have been learned on the PW=20

connected to = PE-1." is=20 redundant, maybe it is better to say "...So the MAC=20

addresses = that require=20 flushing and relearning at PE-2 are only those=20

MAC = addresses learned=20 on the PW connected to PE-1.".

 

[Pranjal] = Sure, we=20 would address this in the next = revision.

 

Thanks

 

Yuanlong=20 = Jiang

= --Boundary_(ID_xiJ/pvgP8r5v9vLXv+OIMA)-- From pdutta@alcatel-lucent.com Fri May 29 16:34:57 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39E03A68BF for ; Fri, 29 May 2009 16:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.364 X-Spam-Level: X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=-2.255, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRAgmEeZtit0 for ; Fri, 29 May 2009 16:34:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2C2853A6829 for ; Fri, 29 May 2009 16:34:48 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n4TNaHPv006718; Fri, 29 May 2009 18:36:17 -0500 (CDT) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n4TNaEmN013558; Fri, 29 May 2009 18:36:15 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n4TNYhZD006696; Sat, 30 May 2009 07:34:43 +0800 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 30 May 2009 05:06:12 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Jiang Yuan-long Date: Sat, 30 May 2009 05:06:09 +0530 Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Thread-Topic: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Thread-Index: AcnebiBU8rXID30rQSS7rboPolTzSgCR2LVQ Message-ID: References: <002801c9d3be$f72fed10$3b4d460a@china.huawei.com> <005901c9de6e$1b179930$3b4d460a@china.huawei.com> In-Reply-To: <005901c9de6e$1b179930$3b4d460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E05267E298BINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 23:34:58 -0000 --_000_C584046466ED224CA92C1BC3313B963E05267E298BINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Both the interpretations are correct and desired flushing affect i= s same. PE3-rs can generate mac flush if it is H-VPLS aware (means it knows that it is hosting a backup= path) in case of which It is not necessary for MTU to trigger mac flush. That is possible if PW st= andby/active status signaling In implemented between MTU and PE3-rs. If PE3-rs is H-VPLS agnostic then th= e control is in MTU alone and so MTU needs to trigger mac flush towards PE3-rs. Thanks, Pranjal ________________________________ From: Jiang Yuan-long [mailto:yljiang@huawei.com] Sent: Tuesday, May 26, 2009 6:55 PM To: Dutta, Pranjal K (Pranjal) Cc: l2vpn@ietf.org Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Pranjal, Thank you for the explanation on the PE-ID, it helps me to understand what = is beyond the texts, I sincerely appreciate it:) Another question, section 5.2, at the bottom of page 12, it says: By default, MTU-2 should still trigger MAC flush as currently defined in [RFC4762] after the backup PW is made active by RSTP. The same text is also found in draft-ietf-pwe3-redundancy-bit. But in RFC 4762, it is not the MTU-s but the PE that should send out the fl= ush msg. As the only description on this mechanism is at the bottom of page 22: [...]. To enable faster convergence, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2), [...] I wonder is there anything I missed? Best regards Yuanlong Jiang ----- Original Message ----- From: Dutta, Pranjal K (Pranjal) To: Jiang Yuan-long ; Dutta, Pranjal K (Pranjal)= Cc: l2vpn@ietf.org Sent: Tuesday, May 26, 2009 1:51 PM Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Hi, Please refer to my answer inline to your comments. Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Jiang Yuan-long Sent: Wednesday, May 13, 2009 4:36 AM To: Dutta, Pranjal K (Pranjal) Cc: l2vpn@ietf.org Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt" Hi Dutta, I have a few comments on this draft: 1. From the description in the draft, it seems only one PE-ID is needed for your mechanism. But in the definition of PE-ID TLV in section 4, a list of one or more PE-ID may be included, but do we really need more than one PE-ID element? Can you give some clues on its usage? IMO, this definition is also in contradiction to the prior sentence "The PE-ID TLV carries the unique identifier of a generic PW endpoint". [Pranjal] Yes, that's correct. PE-ID TLV can accommodate a LIST of PE-ID Elemen= ts. Today implementations can send a list of FEC Elements within a FEC TLV sent in the MAC flu= sh message. A common network event may trigger failure of primary PWs for a set of VPLS instances= together, which requires to send mac flush for all those instances. Sending an individual LDP MAC flush message= per VPLS instance is sub-optimal and so MAC flush for a set of VPLS instances are bundled in a single me= ssage. Same applies to optimized MAC flush with PE-ID as well. 2. The length of the FEC-128 specific PE-ID element is given as 2 octets, should the correct length be 8? [Pranjal] That's right. It's a typo. It should have been 8 octets. We will corr= ect it in the next revision. 3. Maybe the FEC-129 specific PE-ID Element needs another extra field for PE address, as AII TLVs can only be null according to RFC 4762 in section 6.1.1, while AGI TLV can only give you information on VPLS instance. [Pranjal] RFC 4762 also specifies that use of non-null SAII and TAII would be ad= dressed in future revision. Today, FEC 129 is used in VPLS provisioned with BGP-AD where SAII/TAII= always carry valid end-point identifiers (VS-ID) as per l2vpn signaling draft below. http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non BG= P-AD deployments to replace FEC 128. But if you see AGI definition in RFC 4446 (that carries vpls-id as per= RFC 4762), only one type is allocated to be used in BGP-AD provisioned VPLS from L2 VPN signaling draft. 4. I think this mechanism only works properly in a scenario where the MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing msg with PE-ID, then other PEs in the VPLS will process both msgs and the result is flushing all MACs. So maybe this should be pointed out in the applicability section. [Pranjal] Following is stated in the section 5. Application of PE-ID TLV in Optimized MAC Flush However the inclusion of the FEC-TLV should be based on what would be the desired effect should the PE-ID not be understood by the receiver. In cases where the desired action when the PE-ID is not understood would be to behave as described in [RFC4762], then the FEC TLV SHOULD be included. In cases where the desired action when the PE-ID is not understood is to take no action, then the FEC TLV SHOULD NOT be included. Are you suggesting for more explanation in that section? 5. Some random corrections: s/ignored/ignored by/ page 6, "...So the MAC addresses that require flushing and relearning at PE-2 are only the MAC addresses those have been learned on the PW connected to PE-1." is redundant, maybe it is better to say "...So the MAC addresses that require flushing and relearning at PE-2 are only those MAC addresses learned on the PW connected to PE-1.". [Pranjal] Sure, we would address this in the next revision. Thanks Yuanlong Jiang --_000_C584046466ED224CA92C1BC3313B963E05267E298BINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

      &n= bsp;  Both the interpretations are correct and desired flushing affect is same. PE3-rs can generate

mac flush if it is H-VPLS aware (means= it knows that it is hosting a backup path) in case of which =

It is not necessary for MTU to trigger= mac flush. That is possible if PW standby/active status signaling

In implemented between MTU and PE3-rs.= If PE3-rs is H-VPLS agnostic then the control is in MTU alone

and so MTU needs to trigger mac flush towards PE3-rs.

 

Thanks,

Pranjal

 

From: Jiang Yu= an-long [mailto:yljiang@huawei.com]
Sent: Tuesday, May 26, 2009 = 6:55 PM
To: Dutta, Pranjal K (Pranjal)
Cc: l2vpn@ietf.org
Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

 

Pranjal,

 

Thank you for the explanation on the PE-ID, it helps me to understand what is=

beyond the texts, I sincerely appreciate it:)

 

Another question, section 5.2, at the bottom of page 12, it says:

 

   By default, MTU-2 should still trigger MAC flus= h as currently 
   defined in [RFC4762] after the backup PW is mad= e active by RSTP. 

The same text is also found in draft-ietf-pwe3-redundancy-bit.

 

But in RFC 4762, it is not the MTU-s but the PE that should send out the flush = msg.

As the only description on this mech= anism is at the bottom of page 22:

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      [...]. To enable faster
   convergence, the PE3-rs where the secondary PW = got activated may send
   out a flush message (as explained in Section 6.= 2), [...]

 

I wonder is there anything I missed?

 

 

 Best regards

 

Yuanlong Jiang

 

----- Original Message -----

Sent: Tuesday, May 26, 2009 1:51 PM

Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

 

Hi,

       Please refer to my answer inline to your comments.<= o:p>

 

Thanks,

Pranjal

 

From: l2vpn-bounces@ietf.org [mailto:l= 2vpn-bounces@ietf.org] On Behalf Of Jiang Yuan-long=
Sent: Wednesday, May 13, 200= 9 4:36 AM
To: Dutta, Pranjal K (Pranjal)
Cc: l2vpn@ietf.org
Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

 

Hi Dutta,

 

I have a few comments on this draft:<= /span>

 

1. From the description in the draft,= it seems only one PE-ID is needed

for your mechanism. But in the defini= tion of PE-ID TLV in section 4,

a list of one or more PE-ID may be included, but do we really need more

than one PE-ID element? Can you give = some clues on its usage?
IMO, this definition is also in contradiction to the prior sentence =

"The PE-ID TLV carries the uniqu= e identifier of a generic PW endpoint".  <= /p>

 

[Pranjal]

      Yes, that’s correct. PE-ID TLV can accommodate a LIST of PE-ID Elements. T= oday implementations

       c= an send a list of FEC Elements within a FEC TLV sent in the MAC flush message.= A common network

       e= vent may trigger failure of primary PWs for a set of VPLS instances together, wh= ich requires to send mac flush

       f= or all those instances. Sending an individual LDP MAC flush message per VPLS instance is sub-optimal and

       s= o MAC flush for a set of VPLS instances are bundled in a  single message= . Same applies to optimized

       M= AC flush with PE-ID as well.

 

 

 

2. The length of the FEC-128 specific PE-ID element is given as 2 octets,

should the correct length be 8?<= /o:p>

 

[Pranjal]

      That= 217;s right. It’s a typo. It should have been 8 octets. We will correct it = in the next revision.

 

 

3. Maybe the FEC-129 specific PE-ID Element needs another extra field

for PE address, as AII TLVs can only = be null according to RFC 4762 in

section 6.1.1, while AGI TLV can only give you information on VPLS

instance.

 

[Pranjal]

     RFC 4762 also specifies that use of non-null SAII and TAII would be addressed in future revision.

     Today, FEC 12= 9 is used in VPLS provisioned with BGP-AD where SAII/TAII always carry valid

     end-point identifiers (VS-ID) as per l2vpn signaling draft below.

 

     http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt

 

     RFC 4762 kept= a provision for NULL SAII/TAII if FEC 129 is used non BGP-AD deployments to replace FEC 128.

    

     But if you se= e AGI definition in RFC 4446 (that carries vpls-id as per RFC 4762), only one type is allocated to be used

     in BGP-AD provisioned VPLS from  L2 VPN signaling draft.

 

4. I think this mechanism only works properly in a scenario where the

MTU-s, PE-1 and PE-2 all play in harm= ony, otherwise, if MTU-s sends

out a RFC4762 compatiable flushing ms= g, while PE-1 sends out a flushing

msg with PE-ID, then other PEs in the VPLS will process both msgs and

the result is flushing all MACs. So m= aybe this should be pointed out in

the applicability section.=

 

[Pranjal]  Following is stated in the se=
ction 
 
5. Application of PE-=
ID TLV in Optimized MAC Flush

 

 

&=
nbsp;  However the inclusion of the FEC-TLV should be  
  =
 based on what would be the desired effect should the PE-ID not be&nbs=
p; 
  =
 understood by the receiver.  In cases where the desired action w=
hen  
  =
 the PE-ID is not understood would be to behave as described in  =

  =
 [RFC4762], then the FEC TLV SHOULD be included.  In cases where =
the  
  =
 desired action when the PE-ID is not understood is to take no  <=
o:p>
  =
 action, then the FEC TLV SHOULD NOT be included.
 <=
/o:p>
 Are you sug=
gesting for more explanation in that section?


 

 

5. Some random corrections:
s/ignored/ignored by/

page 6, "...So the MAC addresses that require flushing and relearning at

PE-2 are only the MAC addresses those have been learned on the PW

connected to PE-1." is redundant= , maybe it is better to say "...So the MAC

addresses that require flushing and relearning at PE-2 are only those

MAC addresses learned on the PW conne= cted to PE-1.".

 

[Pranjal] Sure, we would address this = in the next revision.

 

Thanks

 

Yuanlong Jiang

--_000_C584046466ED224CA92C1BC3313B963E05267E298BINBANSXCHMBSA_--