From adrian@olddog.co.uk Tue Aug 2 02:31:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077E321F8EF7 for ; Tue, 2 Aug 2011 02:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK4NMM1ro+UP for ; Tue, 2 Aug 2011 02:31:21 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id DB1F421F8EF0 for ; Tue, 2 Aug 2011 02:31:20 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p729VOuv006915; Tue, 2 Aug 2011 10:31:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p729VLAJ006832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 10:31:22 +0100 From: "Adrian Farrel" To: References: <4E1C5B89.8070904@ripe.net> In-Reply-To: Date: Tue, 2 Aug 2011 10:31:23 +0100 Message-ID: <038c01cc50f6$f23861e0$d6a925a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDp5r/6gym1W0riGZSKSJ0MM3eLQALGr4H0lrfqYZA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 09:31:22 -0000 Hi Hideki, I have no particular reason to support any protocol version number in the document, but you said... > You should infom the reason why you have changed the protocol version > from 0 to 1 in the draft-08. > This is very important to implement PSC protocol. ...and this made me curious, Why is the value of the protocol version field in the final RFC so important? Cheers, Adrian From lufang@cisco.com Tue Aug 2 14:42:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5340911E808F for ; Tue, 2 Aug 2011 14:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWpafPuxCl1N for ; Tue, 2 Aug 2011 14:42:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4145711E8095 for ; Tue, 2 Aug 2011 14:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8534; q=dns/txt; s=iport; t=1312321386; x=1313530986; h=mime-version:subject:date:message-id:from:to; bh=zYfE091tEjx4IeKGxfVzpd+Q/qlwYTMaMlB4p2om38Y=; b=lp65JWcnUaYqMZdiL6pWsZgwRGxlsA4cCrh0TXkJQITvxZXLRQeRVjPo UOi9qhpOczM0b6Cspc6sDqVtqUhOTyL1gTJQacq9Imz1T4b6oUQmL/jcg INLzilQtxCe1iXue3E2FK0AbeJ37cwYy0pk2LttjMWYYEjffhCzQphtL7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYHAJBuOE6tJV2b/2dsb2JhbABCgk2WCY8Sd4FCAQEDEgEJEQM4IwEqBhgHVwEEGxqHTp8wgSMBnlaFY18EglCFCpAxi3I X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208,217";a="8975204" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 02 Aug 2011 21:43:02 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p72Lh2jW001671; Tue, 2 Aug 2011 21:43:02 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 16:43:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC515D.27491A44" Date: Tue, 2 Aug 2011 16:43:00 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25068BA10A@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS 2011 - October 16-19, Washington DC Thread-Index: AcxRXSYgDZfPdw35QveaJwTu2NEmcw== From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 02 Aug 2011 21:43:02.0105 (UTC) FILETIME=[275BFC90:01CC515D] Subject: [mpls] MPLS 2011 - October 16-19, Washington DC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:42:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC515D.27491A44 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Registration for MPLS 2011 (October 16-19, Omni Shoreham Hotel in Washington), the 14th annual International Conference on MPLS and related new technologies is now open at: =20 http://www.mpls2011.com/registration/attendees.htm =20 MPLS 2011 will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Scaling MPLS, Data Centers, MPLS Transport Profile, Cloud Computing, Future Networks, Mobile Backhaul, Resiliency, Network Management and Performance, Multi-layer and Optical Networks.=20 In addition, there will be two panel discussions on current topics. =20 The complete program is available at: http://www.mpls2011.com/program/technical_sessions.htm =20 The event will be followed by a Public Interop demonstration. There will also be an exhibit floor, where leading network equipment vendors will showcase their new offerings, the list of current sponsors is available at: http://www.mpls2011.com/sponsors/sponsors.htm =20 The conference hotel is the Omni Shoreham Hotel in Washington DC.=20 Please note that there are only a limited number of rooms available this year at a reduced rate. =20 =20 Please make reservations at: http://www.mpls2011.com/hotel.htm =20 Looking forward to seeing you at MPLS 2011! =20 Luyuan ------_=_NextPart_001_01CC515D.27491A44 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Registration for MPLS 2011 (October 16-19, Omni Shoreham = Hotel in Washington),  the 14th annual International Conference on = MPLS and related new technologies is now open at:

 

http://www.mp= ls2011.com/registration/attendees.htm

  

MPLS 2011 will include an extensive four day program = consisting of tutorials, technical sessions, panels, and exhibits. The key = topics to be discussed at this year's conference include: Scaling MPLS, = Data Centers, MPLS

Transport Profile, Cloud Computing, Future Networks, Mobile Backhaul,

Resiliency, Network Management and Performance, Multi-layer = and Optical Networks. 

In addition, there will be two panel discussions on current topics.

 

The complete program is available at:

http://ww= w.mpls2011.com/program/technical_sessions.htm

  

The event will be followed by a Public Interop = demonstration. There will also be an exhibit floor,

 where leading network equipment vendors will showcase = their new offerings,

 the list of current sponsors is available = at:

http://www.mpls201= 1.com/sponsors/sponsors.htm

 

The conference hotel is the Omni Shoreham Hotel in = Washington DC. 

Please note that there are only a limited number of = rooms available this year

at a reduced rate.  

 

Please make reservations at: http://www.mpls2011.com/hotel.= htm

 =

Looking forward to seeing you at MPLS 2011!

 =

Luyuan=

------_=_NextPart_001_01CC515D.27491A44-- From iesg-secretary@ietf.org Wed Aug 3 11:44:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE5211E808A; Wed, 3 Aug 2011 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo3RAk5V22-Q; Wed, 3 Aug 2011 11:43:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1D811E8090; Wed, 3 Aug 2011 11:43:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110803184359.16775.18660.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2011 11:43:59 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Packet Loss and Delay Measurement for MPLS Networks' to Proposed Standard (draft-ietf-mpls-loss-delay-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:44:00 -0000 The IESG has approved the following document: - 'Packet Loss and Delay Measurement for MPLS Networks' (draft-ietf-mpls-loss-delay-04.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ Technical Summary The ability to measure and monitor one and two-way packet loss and delay performance is a basic need of service providers delivering SLAs. These metrics are also realted to delay variation and channel throughput. This measurement capability also provides greater visibility for operators into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. This document specifies two closely-related protocols, one for packet loss measurement (LM), and one for packet delay measurement (DM). Working Group Summary This document is an MPLS working group document. It is not part of the MPLS-TP project, however the companion functionality for MPLS-based Transport Networks makes reference to this document by defining a profile. The working group has reviewed this document with this fact in mind. Document Quality The document is well reviewed in the MPLS working group Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From iesg-secretary@ietf.org Wed Aug 3 11:45:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5801111E808B; Wed, 3 Aug 2011 11:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib+nRePCtha2; Wed, 3 Aug 2011 11:45:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92311E808E; Wed, 3 Aug 2011 11:45:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110803184505.17261.50824.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2011 11:45:05 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks' to Informational RFC (draft-ietf-mpls-tp-loss-delay-profile-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:45:12 -0000 The IESG has approved the following document: - 'A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks' (draft-ietf-mpls-tp-loss-delay-profile-04.txt) as an Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ Technical Summary Procedures and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined draft-ietf-mpls-loss-delay. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. Working Group Summary This document is a MPLS working group document, and part of the MPLS-TP project. Meaning that it has been reviewed by ITU-T SG15 as part of the working group last call process. Document Quality The document is well reviewed in the MPLS working group and SG15. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From internet-drafts@ietf.org Wed Aug 3 21:11:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8DF21F8784; Wed, 3 Aug 2011 21:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5ZvdX9zqgBH; Wed, 3 Aug 2011 21:11:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3921F8779; Wed, 3 Aug 2011 21:11:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110804041115.27375.12470.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2011 21:11:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 04:11:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Linear Protection Author(s) : Stewart Bryant Eric Osborne Nurit Sprecher Annamaria Fulignoli Yaacov Weingarten Filename : draft-ietf-mpls-tp-linear-protection-09.txt Pages : 42 Date : 2011-08-03 The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-09= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-09.= txt From internet-drafts@ietf.org Thu Aug 4 07:22:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6248B21F8B82; Thu, 4 Aug 2011 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qSVeygmgTKV; Thu, 4 Aug 2011 07:22:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7964F21F8B76; Thu, 4 Aug 2011 07:22:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110804142223.24105.1606.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2011 07:22:23 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-p2mp-15.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:22:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Label Distribution Protocol Extensions for Point-to-Mult= ipoint and Multipoint-to-Multipoint Label Switched Paths Author(s) : Ina Minei IJsbrand Wijnands Kireeti Kompella Bob Thomas Filename : draft-ietf-mpls-ldp-p2mp-15.txt Pages : 39 Date : 2011-08-04 This document describes extensions to the Label Distribution Protocol for the setup of Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths in Multi-Protocol Label Switching networks. These extensions are also referred to as Multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP Label Switched Paths without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such Label Switched Paths in a receiver-initiated manner. There can be various applications for Multipoint Label Switched Paths, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled Multipoint Label Switched Path is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-15.txt From iesg-secretary@ietf.org Thu Aug 4 11:43:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2D21F8561; Thu, 4 Aug 2011 11:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlQExSj8O0Hy; Thu, 4 Aug 2011 11:43:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0871321F8571; Thu, 4 Aug 2011 11:43:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110804184305.5972.63469.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2011 11:43:05 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths' to Proposed Standard (draft-ietf-mpls-ldp-p2mp-15.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:43:06 -0000 The IESG has approved the following document: - 'Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths' (draft-ietf-mpls-ldp-p2mp-15.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-p2mp/ Technical Summary This document specifies extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. LDP with these extensions is also referred to as Multipoint LDP (mLDP). Runing mLDP will result in establishing P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be several applications for P2MP/MP2MP LSPs, but these are outside the scope of this document. Working Group Summary The document has been reviewed by the MPLS working group. There is no controversy and consensus seems good. Document Quality All major MPLS vendors have either already implements or have indicated intention to implement. Personnel Loa Andersson (loa@li.nu) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Section 1.1 Please add the following new paragraph to the end of the section. All new fields shown as "reserved" in this document MUST be set to zero on transmission and MUST be ignored on receipt. --- Section 1.2 Add to the list. FEC: Forwarding Equivalence Class --- Section 1.2 (CRC entry) s/V.42/V.42 [ITU.V42.1994]/ --- NEW 1.3. Manageability MPLS LSRs can be modeled and managed using the MIB module defined in [RFC3813]. That MIB module is fully capable of handling the one-to- many in-segment to out-segment relationships needed to support P2MP LSPs, and no further changes are required. [RFC3815] defines managed objects for LDP. The MIB module allows the modeling and management of LDP and LDP speakers for the protocol as defined in [RFC5036]. The protocol extensions defined in this document to support P2MP in LDP may require an additional MIB module or extensions to the modules defined in [RFC3815]. This is for future study, and at the time of writing no interest had been expressed in this work. Future manageability work should pay attention to the protocol extensions defined in this document, and specifically the configurable and variable elements, along with reoprting the new protocol fields that identify individual P2MP LSPs. END --- Section 5.2.2 s/RFC3036/[RFC5056] --- Section 10 s/configure/configured --- Section 14.2 Add to the start... [RFC3813] Srinivansan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004 [RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP)", RFC 3815, June 2004. From hideki.endo.es@hitachi.com Thu Aug 4 21:47:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0D21F8AD1 for ; Thu, 4 Aug 2011 21:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEf4T5ikgCmM for ; Thu, 4 Aug 2011 21:47:30 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5909721F8ABB for ; Thu, 4 Aug 2011 21:47:29 -0700 (PDT) Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id EDA4837C82; Fri, 5 Aug 2011 13:47:44 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id p754liYA028990; Fri, 5 Aug 2011 13:47:44 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p754lifP031366; Fri, 5 Aug 2011 13:47:44 +0900 X-AuditID: b753bd60-a287bba0000050a4-4f-4e3b75efaf89 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id E5B1A8B02FC; Fri, 5 Aug 2011 13:47:43 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p754lhi27242564; Fri, 5 Aug 2011 13:47:43 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Fri, 5 Aug 2011 13:47:39 +0900 References: <4E1C5B89.8070904@ripe.net> <038c01cc50f6$f23861e0$d6a925a0$@olddog.co.uk> Priority: normal Importance: normal X400-Content-Identifier: X4E3B75DD00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110805134725JBR] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 04:47:31 -0000 Hi Adrian, I'm very sorry for my late response. You are right. A protocol version number normally doesn't matter in final RFC, because previous version number is put away and the latest version is available. However, I heard from Yaacov that not only version number '1' but also '0' was availble in this draft. The version '0' is to use ACH TLVs. The version '1' is to use Optional TLVs which will be defined for the future. Unfortunately, I think this solution has big fault as a protocol. Because the version number is following ACH TLVs, it is impossible to determine whether there are ACH TLVs or Optional TLVs in a packet. I'd like to advertise the fact in WG. BR, Hideki >Hi Hideki, > >I have no particular reason to support any protocol version number in the >document, but you said... > >> You should infom the reason why you have changed the protocol version >> from 0 to 1 in the draft-08. >> This is very important to implement PSC protocol. > >...and this made me curious, > >Why is the value of the protocol version field in the final RFC so important? > >Cheers, >Adrian > > From internet-drafts@ietf.org Fri Aug 5 00:48:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EAB21F8B64; Fri, 5 Aug 2011 00:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRfuPlFcdGzV; Fri, 5 Aug 2011 00:48:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3193F21F8B55; Fri, 5 Aug 2011 00:48:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110805074812.25036.76517.idtracker@ietfa.amsl.com> Date: Fri, 05 Aug 2011 00:48:12 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:48:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP= ) MIB-based Management Overview Author(s) : Daniel King Venkatesan Mahalingam Filename : draft-ietf-mpls-tp-mib-management-overview-05.txt Pages : 27 Date : 2011-08-05 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overv= iew-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvi= ew-05.txt From daniel@olddog.co.uk Fri Aug 5 00:58:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9E721F858D for ; Fri, 5 Aug 2011 00:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmg-4k2vZSY0 for ; Fri, 5 Aug 2011 00:58:09 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8619021F8588 for ; Fri, 5 Aug 2011 00:58:09 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p757wOIW011505 for ; Fri, 5 Aug 2011 08:58:24 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p757wNZN011482 for ; Fri, 5 Aug 2011 08:58:24 +0100 From: "Daniel King" To: References: <20110805074812.25036.76517.idtracker@ietfa.amsl.com> In-Reply-To: <20110805074812.25036.76517.idtracker@ietfa.amsl.com> Date: Fri, 5 Aug 2011 08:58:18 +0100 Message-ID: <017d01cc5345$70ed7200$52c85600$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgD6Sev6XM8ZEuOmFSDfOuLTkVN5TmakgA Content-Language: en-gb Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:58:13 -0000 Hi All, Please find a new version of draft-ietf-mpls-tp-mib-management-overview below: http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-05 This new version addressed the recent last call comments, provides some readability updates, an additional reference and fixes some NITs. Br, Dan. From eosborne@cisco.com Fri Aug 5 05:38:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23F421F85AC for ; Fri, 5 Aug 2011 05:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwsctA3an4jL for ; Fri, 5 Aug 2011 05:38:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3F18C21F85A3 for ; Fri, 5 Aug 2011 05:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=2172; q=dns/txt; s=iport; t=1312547942; x=1313757542; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wzU45Dhu4rXH3fs4Jrmewo8pMr7DOWKE8IzedWJE+vI=; b=HE+yomreby8NDfMzeRcP9EsJrhyh84LL6WJvs5xNjFfvtNkyjXzhjJMJ gReWrCFLGloZtTYhlTTTf1uH+5TitwoV5RRlMu68Sqvoo9RJibcvkxx6m 9p0xbIfvUloI/4JLd+yVUJ0F/BEDCQ0eDt0pfXflvdgJBFB6vEY36kT9N E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAABnkO06tJV2c/2dsb2JhbABCmBePSneBOQcBAQEBAwEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggTB4dPoSEBnnqFZ18Eh1yQNot0 X-IronPort-AV: E=Sophos;i="4.67,323,1309737600"; d="scan'208";a="10039079" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2011 12:39:00 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p75Cd0O8004247; Fri, 5 Aug 2011 12:39:00 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Aug 2011 07:39:00 -0500 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 Date: Fri, 5 Aug 2011 07:38:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-linear-protection Thread-Index: AcxTKttLIC+4oNiKR7mqXDWCWl1i2QAQVbSg References: <4E1C5B89.8070904@ripe.net><038c01cc50f6$f23861e0$d6a925a0$@olddog.co.uk> From: "Eric Osborne (eosborne)" To: , X-OriginalArrivalTime: 05 Aug 2011 12:39:00.0158 (UTC) FILETIME=[A67B65E0:01CC536C] Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:38:48 -0000 Hi Hideki- I'm afraid you've been misinformed. Version 0 is not in use. We had talked about ACH TLVs as some point, but do not use them. Per rfc5586, "If the G-ACh message MAY be preceded by one or more ACH TLVs, then this MUST be explicitly specified in the definition of an ACH Channel Type" and we do not make that explicit specification in the draft. Version 1 is the only version which we have defined, and it uses optional TLVs below the PSC header. eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > hideki.endo.es@hitachi.com > Sent: Friday, August 05, 2011 12:48 AM > To: adrian@olddog.co.uk > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection >=20 > Hi Adrian, >=20 > I'm very sorry for my late response. >=20 > You are right. > A protocol version number normally doesn't matter in final RFC, because > previous version number is put away and the latest version is available. >=20 > However, I heard from Yaacov that > not only version number '1' but also '0' was availble in this draft. > The version '0' is to use ACH TLVs. > The version '1' is to use Optional TLVs which will be defined for the > future. >=20 > Unfortunately, I think this solution has big fault as a protocol. > Because the version number is following ACH TLVs, it is impossible to > determine whether there are ACH TLVs or Optional TLVs in a packet. >=20 > I'd like to advertise the fact in WG. >=20 > BR, > Hideki >=20 >=20 > >Hi Hideki, > > > >I have no particular reason to support any protocol version number in > >the document, but you said... > > > >> You should infom the reason why you have changed the protocol version > >> from 0 to 1 in the draft-08. > >> This is very important to implement PSC protocol. > > > >...and this made me curious, > > > >Why is the value of the protocol version field in the final RFC so > important? > > > >Cheers, > >Adrian > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From list_work@beckhaus-net.de Wed Jul 27 12:47:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33B511E8073 for ; Wed, 27 Jul 2011 12:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZu0TuFI7NdE for ; Wed, 27 Jul 2011 12:47:15 -0700 (PDT) Received: from wp062.webpack.hosteurope.de (wp062.webpack.hosteurope.de [IPv6:2a01:488:42::50ed:8445]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7911E8075 for ; Wed, 27 Jul 2011 12:47:14 -0700 (PDT) Received: from p4ff0c847.dip.t-dialin.net ([79.240.200.71] helo=[192.168.3.32]); authenticated by wp062.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1QmA4V-0000Vt-IM; Wed, 27 Jul 2011 21:47:11 +0200 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Beckhaus In-Reply-To: Date: Wed, 27 Jul 2011 21:47:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23532.1309359379@erosen-linux> <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> To: Sami Boutros X-Mailer: Apple Mail (2.1244.3) X-bounce-key: webpack.hosteurope.de; list_work@beckhaus-net.de; 1311796034; a11154d7; X-Mailman-Approved-At: Fri, 05 Aug 2011 05:52:41 -0700 Cc: mpls@ietf.org Subject: Re: [mpls] [MPLS] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:47:16 -0000 Sami, do you have any concerns regarding the 2 minutes? For the general AN = scenario (only very limited number of FECs), I could imagine also a = smaller number to get a faster recovery time. I do not see a need to get = a higher value. But I am not sure to change the RFC5036 value because of = this. Best wishes to Quebec City Thomas Am 25.07.2011 um 17:09 schrieb Sami Boutros: > Maciek, >=20 > Will the 2 mins back off be acceptable? or will you address this = aspect in your draft? and if so how? >=20 > Thanks, >=20 > Sami > At 06:16 AM 7/12/2011, Maciek Konstantynowicz wrote: >> Eric, >>=20 >> Regarding your question about handling unreachable FEC becoming = reachable again:- >>=20 >> We wrote a separate draft with a detailed description of LDP DoD = behaviours in the context of Seamless MPLS >> http://tools.ietf.org/html/draft-beckhaus-ldp-dod-00 >>=20 >> In this draft, #section-4.4.3 describes the behaviour in case = specific requested FEC is unreachable: >>=20 >> 4.4.3. Label Request Retry Procedure >>=20 >> If AN or AGN receives a "No route" Notification in response to its >> label request message, it should retry with exponential backoff >> algorithm similar to the backoff algoritm mentioned in the LDP >> session negotiation section 4.3. >> ... >> AN should follow the exponential backoff algorithm as specified in >> the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent = delays >> grow to a maximum delay of 2 minutes. >>=20 >> Maciek >>=20 >>=20 >>=20 >>=20 >> On 29 Jun 2011, at 15:56, Eric Rosen wrote: >>=20 >> > >> >> For a more long term approach we are in favour of a change to = RFC5036 by >> >> defining a new TLV which denotes the DU/DoD mode per FEC type. >> > >> > Does that mean you expect every FEC type to be able to work in both = modes? >> > If you only anticipate needing DoD for address prefix FECs, a more >> > conservative solution might be to just clarify that the negotiated = session >> > mode applies only to address prefix FECs. >> > >> > While on the topic, I do have a question about the use of DoD for = address >> > prefix FECs. >> > >> > =46rom draft-leymann-mpls-seamless-mpls-03: >> > >> > the AN will use LDP DoD to only request the label bindings >> > for the FECs corresponding to the loopback addresses of those = egress >> > nodes to which it has services configured. >> > >> > Suppose one of the configured egress nodes is down or otherwise = unreachable >> > at the time the AN asks for a label binding. How does the AN get = the label >> > binding when the egress node becomes reachable? Is the AN expected = to ask >> > periodically for the binding? Is the periodic interval expected to = be >> > configurable? The draft should say something about this. >> > >> > I don't think RFC 5036 requires the AGN to remember what the AN has = asked >> > for, so that it can reply when and if the egress becomes reachable. >> > >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From maarten.vissers@huawei.com Fri Aug 5 06:09:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6DD21F8B01 for ; Fri, 5 Aug 2011 06:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-3.886, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0PJ+mcQ3+gX for ; Fri, 5 Aug 2011 06:09:10 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id B627421F8AEE for ; Fri, 5 Aug 2011 06:09:09 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPG00K3PHVNT7@lhrga02-in.huawei.com> for mpls@ietf.org; Fri, 05 Aug 2011 14:09:24 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LPG00B9LHVNKB@lhrga02-in.huawei.com> for mpls@ietf.org; Fri, 05 Aug 2011 14:09:23 +0100 (BST) Received: from LHREML401-HUB.china.huawei.com (10.201.5.30) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 05 Aug 2011 14:09:11 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML401-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 05 Aug 2011 14:09:22 +0100 Date: Fri, 05 Aug 2011 13:09:22 +0000 From: Maarten vissers In-reply-to: X-Originating-IP: [10.202.112.227] To: "su.hui@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DHPR0VaVrOyVu1Mptrm6DA)" Content-language: en-US Accept-Language: en-GB, en-US Thread-topic: =?gb2312?B?UkU6IFttcGxzXSC08Li0OiBSZTogIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQt?= =?gb2312?Q?mpls-tp-sd-03?= Thread-index: AQHMTZHk6YoUewV010WCVjGKj1+yDpUCmuUAgAA8JQCAAEH1UIAEbyIAgAAoPDA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "mpls@ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:09:11 -0000 --Boundary_(ID_DHPR0VaVrOyVu1Mptrm6DA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgU3VodWksDQoNClBsZWFzZSBzZWUgaW5saW5loa0NCg0KRnJvbTogc3UuaHVpQHp0ZS5jb20u Y248bWFpbHRvOnN1Lmh1aUB6dGUuY29tLmNuPiBbbWFpbHRvOnN1Lmh1aUB6dGUuY29tLmNuXTxt YWlsdG86W21haWx0bzpzdS5odWlAenRlLmNvbS5jbl0+DQpTZW50OiAxIEF1Z3VzdCAyMDExIDA5 OjEwDQpUbzogTWFhcnRlbiB2aXNzZXJzDQpDYzogaHV1YmF0d29ya0BnbWFpbC5jb208bWFpbHRv Omh1dWJhdHdvcmtAZ21haWwuY29tPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz47IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPg0K U3ViamVjdDogtPC4tDogUkU6IFttcGxzXSC08Li0OiBSZTogQ29tbWVudHMgdG8gZHJhZnQtcmto ZC1tcGxzLXRwLXNkLTAzDQoNCkhpIE1hYXJ0ZW6jrA0KUGxlYXNlIHNlZSB0aGUgb25saW5loa0u DQoNClJlZ2FyZHOjrA0KU3VodWkNCg0KTWFhcnRlbiB2aXNzZXJzIDxtYWFydGVuLnZpc3NlcnNA aHVhd2VpLmNvbTxtYWlsdG86bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20+Pg0KDQoyMDExLTA3 LTI5IDIwOjI0DQoNCsrVvP7Iyw0KDQoic3UuaHVpQHp0ZS5jb20uY248bWFpbHRvOnN1Lmh1aUB6 dGUuY29tLmNuPiIgPHN1Lmh1aUB6dGUuY29tLmNuPG1haWx0bzpzdS5odWlAenRlLmNvbS5jbj4+ LCAiaHV1YmF0d29ya0BnbWFpbC5jb208bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiIgPGh1 dWJhdHdvcmtAZ21haWwuY29tPG1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4+DQoNCrOty80N Cg0KIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4+LCAibXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmc+IiA8bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJFOiBbbXBsc10gtPC4tDogUmU6ICBDb21tZW50 cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCg0KDQoNCg0KDQpTdWh1aSwNCg0KWW91ciBz b2x1dGlvbiBkb2VzIG5vdCBtZWV0IHRoZSByZXF1aXJlbWVudCB0byBwcmV2ZW50IGVudGVyaW5n IFVBVCBpbiBwcm90ZWN0ZWQgdHJhbnNwb3J0IHNlcnZpY2UgbGF5ZXIgY29ubmVjdGlvbnMgdW5k ZXIgcGFja2V0IGxvc3MgY29uZGl0aW9uczsgaS5lLiBwYWNrZXQgbG9zcyBkdWUgdG8gbm9uIGJp dCBlcnJvciBjb25kaXRpb25zIGlzIG5vdCB0YWtlbiBjYXJlIG9mLiBDdXN0b21lciB3aWxsIHN0 aWxsIGNvbXBsYWluIGFuZCB3aWxsIGFzayBoaXMvaGVyIG1vbmV5IGJhY2sgaW4gc3VjaCBjYXNl IDooLg0KW1NIXSBUaGVyZSBhcmUgdGhlcmUgcmVhc29ucyB3aGljaCBjYW4gY2F1c2UgU0Q6IGZp YmVyIGRlZmVjdCwgY29uZ2VzdGlvbiwgZXF1aXBtZW50IGRlZmVjdC4gVGhpcyBtZWNoYW5pc20g Y2FuIG9ubHkgZGVhbCB3aXRoIHRoZSBmaXJzdCByZWFzb24uIFNvbWVvbmUgdG9sZCBtZSB0aGF0 IG1vcmUgdGhhbiA5MCUgZmFpbHVyZSBhcmUgY2F1c2UgYnkgZmliZXIgZGVmZWN0IGFuZCBwb3dl ciBkZWZlY3QobWF5YmUgc29tZSBjYXJyaWVycyBjYW4gZ2l2ZSB1cyBtb3JlIGFjY3VyYXRlIG51 bWJlciksIGFuZCBpdCBpcyBpbXBvc3NpYmxlIHRvIGRldGVjdCBTRCBjYXVzZWQgYnkgY29uZ2Vz dGlvbiBvciBlcXVpcG1lbnQgZGVmZWN0IGlmIG5vIHBhY2tldCBpcyB0cmFuc21pdHRpbmcsIHNv IGlmIHRoZXJlIGlzIG5vIG90aGVyIGJldHRlciBzb2x1dGlvbiwgdGhpcyBpcyBnb29kIGVub3Vn aCBmb3IgbWUuDQpbTVZdIEJvdHRvbSBsaW5lIHF1ZXN0aW9uIGlzIGlmIHByb3RlY3Rpb24gc3dp dGNoaW5nIG9uIFBoeXNpY2FsIGxheWVyIFNEICg9ZERFRykgY29uZGl0aW9uIHNob3VsZCBwcmV2 ZW50IHNlcnZpY2UgdG8gZW50ZXIgVUFULiBJZiBpdCBpcyBhbGxvd2VkIHRvIHByZXZlbnQgZW50 ZXJpbmcgVUFUIG9ubHkgZm9yIH45MCUgb2YgcGFja2V0IGxvc3MgY2FzZXMgdGhlbiB5b3VyIHBy b3Bvc2VkIHRyaWdnZXIgY29uZGl0aW9uIG1pZ2h0IGJlIGdvb2QgZW5vdWdoLiBCdXQgdGhpcyBu ZWVkcyB0byBiZSBhZ3JlZWQgZmlyc3QuDQoNCkFuIEZFSSBhZGRzIG11Y2ggbW9yZSB0aGFuIGp1 c3QgYW5vdGhlciBtYWludGVuYW5jZSBzaWduYWwgdHlwZSBvZiBPQU0gcGFja2V0LiBJdCBtYXkg cmVxdWlyZSBjaGFuZ2VzIHRvIE9UTiBkZXZpY2VzIChpLmUuIGNvbmNlcm5pbmcgcHJvY2Vzc2lu ZyBvZiBiaXQgZXJyb3IgaW5mb3JtYXRpb24gYW5kIGNvbnNlcXVlbnQgYWN0aW9ucykgYW5kIGNo YW5nZXMgdG8gTVBMUy1UUCBkZXZpY2VzIChpLmUuIGNvbmNlcm5pbmcgcHJvY2Vzc2luZyBvZiBw YWNrZXQgbG9zcyBpbmZvcm1hdGlvbiBhbmQgY29uc2VxdWVudCBhY3Rpb25zKS4NCltTSF0gWWVz LCBpZiBvbmUgYWRkcyBhIHR5cGUgb2YgcGFja2V0LCBvbmUgbXVzdCBnZW5lcmF0ZS9yZWNlaXZl IHRoaXMgcGFja2V0LiBCdXQgc2luY2UgdGhlIG1lY2hhbmlzbSBpcyB0aGUgc2FtZSBhcyBGREks IGl0IGRvZXMgbm90IGFkZCBtdWNoIHdvcmsuDQpbTVZdIENoYW5nZXMgdG8gZXhpc3RpbmcgaGFy ZHdhcmUgYW5kIHNvZnR3YXJlIGFyZSBub3QgYXBwcmVjaWF0ZWQgaWYgdGhleSBkbyBub3QgY29t cGxldGVseSByZXNvbHZlIHRoZSBpc3N1ZS4NCg0KRkVJIHByb3BhZ2F0aW9uIGlzIG5vdCB0aGUg c2FtZSBhcyBGREkvQUlTIHByb3BhZ2F0aW9uLg0KLSAgICAgICAgICBEZWZhdWx0IEZESS9BSVMg cHJvcGFnYXRpb24gaXMgYmFzZWQgb24gZGV0ZWN0aW9uIG9mIGxvY2FsIENDL0NWIGRlZmVjdCBp biBNRVAgU2luayB3aGljaCBjb250cm9scyBpbnNlcnRpb24gb2YgRkRJL0FJUyBpbnRvIGNsaWVu dCBsYXllciBzaWduYWwgKFBXLCBzZXJ2aWNlLUxTUCwgdHJhbnNwb3J0LUxTUCkgb3IgaW50byBj bGllbnQgVENNIGxldmVsIChQU01FKS4NCk9ubHkgaWYgTUVQIFNpbmsgaXMgY29uZmlndXJlZCBu b3QgdG8gcGVyZm9ybSBDQy9DViBkZWZlY3QgZGV0ZWN0aW9uIGl0IGlzIG5lY2Vzc2FyeSB0byB1 c2UgRkRJL0FJUyBkZWZlY3QgdG8gY29udHJvbCBpbnNlcnRpb24gb2YgRkRJL0FJUzsgdGhpcyBp cyBvbmx5IG5lY2Vzc2FyeSBhdCB0cmFuc3BvcnQgc2VydmljZSBsYXllciBNRVAgZnVuY3Rpb25z IHdoZW4gU0xBIGRvZXMgbm90IHJlcXVpcmUgcHJvLWFjdGl2ZSBmYXVsdCBtb25pdG9yaW5nLiBO b3cgaXQgd2lsbCBiZSBuZWNlc3NhcnkgdG8gZ2VuZXJhdGUgRkRJL0FJUyBpbiB0aGUgY3VzdG9t ZXKhr3Mgc2lnbmFsIGJhc2VkIG9uIGRldGVjdGVkIEFJUyBkZWZlY3QuDQotICAgICAgICAgIEZF SSBwcm9wYWdhdGlvbiBhbHdheXMgcmVxdWlyZXMgZm9yd2FyZGluZyBvZiAgaW5jb21pbmcgRkVJ IGluZm9ybWF0aW9uOyBpLmUuIEZFSSBPQU0gaXMgdGVybWluYXRlZCwgRkVJIGluZm9ybWF0aW9u IGlzIGV4dHJhY3RlZCBhbmQgaW5zZXJ0ZWQgaW50byBjbGllbnQgRkVJIE9BTSBwYWNrZXQocyku IFRoZXJlIG1heSBiZSBtdWx0aXBsZSBGRUkgT0FNIHBhY2tldHMgaW5jb21pbmcgZXZlcnkgc2Vj b25kIChvbmUgZnJvbSBldmVyeSBwaHlzaWNhbCBsYXllciBsaW5rIHBhc3NlZDsgaS5lLiBldmVy eSBzZWNvbmQgbW9yZSB0aGFuIG9uZSBGRUkgT0FNIHBhY2tldCBtYXkgaGF2ZSB0byBiZSBpbnNl cnRlZCBpbnRvIHRoZSBjbGllbnQgbGF5ZXIgb3IgY2xpZW50IFBTTUUgc2lnbmFsLiBTZWUgZmln dXJlIGJlbG93Lg0KW1NIXSBJIGRvIG5vdCBzZWUgdGhlcmUgaXMgYW55IGRpZmZlcmVuY2UgYmV0 d2VlbiBGRUkgcHJvcGFnYXRpb24gYW5kIEZESSBwcm9wYWdhdGlvbi4NCkZvciBGREkgOiAgQSBN RVAgcmVjZWl2ZXMgYSBGREkgcGFja2V0IG9yIGRldGVjdHMgZmFpbHVyZSBieSBvdGhlciBPQU0g LCB0aGVuIGl0IGVudGVycyBUU0YgY29uZGl0aW9uLCB0aGVuIGNvbnNlcXVlbnQgYWN0aW9ucyBv ZiBUU0YgY29uZGl0aW9uIHdpbGwgaW5zZXJ0IEZESSBwYWNrZXQgaW4gaXRzIGNsaWVudCBsYXll ci4NCkZvciBGRUk6ICBBIE1FUCByZWNlaXZlcyBhIEZFSSBwYWNrZXQsIHRoZW4gaXQgZW50ZXJz IFRTRCBjb25kaXRpb24sIHRoZW4gY29uc2VxdWVudCBhY3Rpb25zIG9mIFRTRCBjb25kaXRpb24g d2lsbCBpbnNlcnQgRkVJIHBhY2tldCBpbiBpdHMgY2xpZW50IGxheWVyLiBBIE1FUCBvbmx5IGlu c2VydHMgb25lIHBhY2tldCBpbiBvbmUgc2Vjb25kIGluIGVhY2ggY2xpZW50IG5vIG1hdHRlciBo b3cgbXVjaCBGRUkgcGFja2V0cyBpdCByZWNlaXZlcy4NCltNVl0gVGhlIEZFSSBwcm9wYWdhdGlv biBtZXRob2QgeW91IGRlc2NyaWJlIGlzIG5vdCBhYmxlIHRvIGFjY3VtdWxhdGUgcGFja2V0IGxv c3MgYWxvbmcgYSBtdWx0aS1zZWdtZW50IHBhdGguIEUuZy4gaWYgdGhlIGNvbm5lY3Rpb24gKFBX LCBMU1AsIFBTTUUpIGNvbnNpc3RzIG9mIDEwIHNlZ21lbnRzIGFuZCBlYWNoIHNlZ21lbnQgaGFz IGUuZy4gYSAxRS03IGVycm9yIHJhdGUgdGhlbiB0aGUgdG90YWwgY29ubmVjdGlvbiB3b3VsZCBo YXZlIGEgMUUtNiBlcnJvciByYXRlLiBJZiAxRS02IHdvdWxkIGJlIHRoZSB0cmlnZ2VyIGZvciBh IHBhY2tldCBTRCBjb25kaXRpb24sIHRoZW4geW91IHdpbGwgbm90IHJlYWNoIHRoYXQgd2l0aCB5 b3VyIHNvbHV0aW9uLCBidXQgeW91IHdvdWxkIGdldCB0byB0aGF0IHdpdGggdGhlIHNvbHV0aW9u IEkgZGVzY3JpYmVkLiBXaGF0IHlvdSBkZXNjcmliZSBpcyBhIHZlcnkgbXVjaCBzaW1wbGlmaWVk IHZlcnNpb24sIHdoaWNoIGNhbiBiZSBkZXNjcmliZWQgYXM6IGlmIG9uZSBvciBtb3JlIG9mIHRo ZSBwaHlzaWNhbCBsaW5rcyBkZXRlY3RzIGEgRGVncmFkZWQgZGVmZWN0LCB0aGVuIHRoZSBwYWNr ZXQgU0QgY29uZGl0aW9uIHdpbGwgYmUgZGVjbGFyZWQuDQoNClJlZ2FyZHMsDQpNYWFydGVuDQoN Cg0KUmVnYXJkcywNCk1hYXJ0ZW4NCg== --Boundary_(ID_DHPR0VaVrOyVu1Mptrm6DA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Suhui,=

 

Please see inline=A1=AD

 <= /p>

From: su.hui@zte.com.cn [mailto:su.hui@zte.com.cn]
Sent: 1 August 2011 09:10
To: Maarten vissers
Cc: huubatwork@gmail.com= ; mpls@ietf.org; mpls-bounces@ie= tf.org
Subject: =B4= =F0=B8=B4: RE: [mpls] =B4=F0=B8=B4<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif"">: Re: Comments to draft-rkhd-mpls-tp-sd-03


Hi Maarten=A3=AC
Please see the online=A1=AD.

Regards=A3=AC
Suhui

Maarten vissers <maarten.vissers@huawei.com>

2011-07-29 20:24

=CA=D5=BC=FE=C8=CB<= /p>

"su.hui@zte.com.cn" <su.hu= i@zte.com.cn>, "huubatw= ork@gmail.com" <huubatwork@gmail.com>

=B3=AD=CB=CD

"mpl= s@ietf.org" <mpls@ietf.org= >, "mpls-bounces@ietf.org<= /a>" <mpls-bounces@ietf.or= g>

=D6=F7=CC=E2

RE: [mpls] =B4=F0=B8=B4: Re:  Comments to draft-rkhd-mpls-tp-sd-03<= /p>

 


Suhui,
 
Your solution does not meet the requirement to p= revent entering UAT in protected transport service layer connections under = packet loss conditions; i.e. packet loss due to non bit error conditions is not taken care of. Customer will still complain and wi= ll ask his/her money back in such case L.
[SH]= There are there reasons which can cause SD: fiber defect, congestion= , equipment defect. This mechanism can only deal with the first reason. Som= eone told me that more than 90% failure are cause by fiber defect and power def= ect(maybe some carriers can give us more accurate number), and it is imposs= ible to detect SD caused by congestion or equipment defect if no packet is = transmitting, so if there is no other better solution, this is good enough for me.

[MV] Bottom line question i= s if protection switching on Physical layer SD (=3DdDEG) condition should p= revent service to enter UAT. If it is allowed to prevent entering UAT only for ~90% of packet loss cases then your proposed trigger conditio= n might be good enough. But this needs to be agreed first.


An FEI adds much more than just another maintena= nce signal type of OAM packet. It may require changes to OTN devices (i.e. = concerning processing of bit error information and consequent actions) and changes to MPLS-TP devices (i.e. concerning processing of pac= ket loss information and consequent actions).
[SH]= Yes, if one adds a type of packet, one must generate/receive this pa= cket. But since the mechanism is the same as FDI, it does not add much work= .

[MV] Changes to existing ha= rdware and software are not appreciated if they do not completely resolve t= he issue.


FEI propagation is not the same as FDI/AIS propa= gation.
-          Defau= lt FDI/AIS propagation is based on detection of local CC/CV defect in MEP S= ink which controls insertion of FDI/AIS into client layer signal (PW, servi= ce-LSP, transport-LSP) or into client TCM level (PSME).
Only if MEP Sink is configured not to perform CC/CV defect detection it is = necessary to use FDI/AIS defect to control insertion of FDI/AIS; this is on= ly necessary at transport service layer MEP functions when SLA does not req= uire pro-active fault monitoring. Now it will be necessary to generate FDI/AIS in the customer=A1=AFs signal= based on detected AIS defect.
-          FEI p= ropagation always requires forwarding of  incoming FEI information; i.= e. FEI OAM is terminated, FEI information is extracted and inserted into cl= ient FEI OAM packet(s). There may be multiple FEI OAM packets incoming every second= (one from every physical layer link passed; i.e. every second more than on= e FEI OAM packet may have to be inserted into the client layer or client PS= ME signal. See figure below.
[SH]= I do not see there is any difference between FEI propagation and FDI= propagation.
F= or FDI :  A MEP receives a FDI packet or detects failure by other OAM = , then it enters TSF condition, then consequent actions of TSF condition wi= ll insert FDI packet in its client layer.
F= or FEI:  A MEP receives a FEI packet, then it enters TSD condition, th= en consequent actions of TSD condition will insert FEI packet in its client= layer. A MEP only inserts one packet in one second in each client no matter how much FEI packets it receives.

[MV] The FEI propagation me= thod you describe is not able to accumulate packet loss along a multi-segme= nt path. E.g. if the connection (PW, LSP, PSME) consists of 10 segments and each segment has e.g. a 1E-7 error rate then the total = connection would have a 1E-6 error rate. If 1E-6 would be the trigger for a= packet SD condition, then you will not reach that with your solution, but = you would get to that with the solution I described. What you describe is a very much simplified version, which ca= n be described as: if one or more of the physical links detects a Degraded = defect, then the packet SD condition will be declared.

 

Regards,<= /p>

Maarten



Regards,
Maarten

--Boundary_(ID_DHPR0VaVrOyVu1Mptrm6DA)-- From erosen@cisco.com Fri Aug 5 07:58:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B1021F85AE for ; Fri, 5 Aug 2011 07:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67+DRKRd3KfD for ; Fri, 5 Aug 2011 07:58:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2B521F85AB for ; Fri, 5 Aug 2011 07:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=2462; q=dns/txt; s=iport; t=1312556351; x=1313765951; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=hBQFJ+kgAHFlNd/b/Mt7jgfYEtT/ww7XNHeQ6tgwHWY=; b=RR2kj/aiOiXGFUpvy+DVDkaR5ilJEVm11Q/N7lFVpZZIGtiftBUzp7hX ZikBrc5LhOxtR2najDQoTkM6gEPhfeeSvICJFNIZY2OBTkEpG3lqy+YT0 1vfz95PH15/BiYgjCi0qiMekb3yEwy66/TEsSmvlInS5g53UVUN6+b1gi U=; X-IronPort-AV: E=Sophos;i="4.67,323,1309737600"; d="scan'208";a="10095878" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 05 Aug 2011 14:59:11 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p75ExAtR010740; Fri, 5 Aug 2011 14:59:10 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p75Ex9Vj006030; Fri, 5 Aug 2011 10:59:10 -0400 To: Thomas Beckhaus In-reply-to: Your message of Wed, 27 Jul 2011 21:47:10 +0200. Date: Fri, 05 Aug 2011 10:59:09 -0400 Message-ID: <6029.1312556349@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, Sami Boutros Subject: Re: [mpls] [MPLS] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:58:54 -0000 > do you have any concerns regarding the 2 minutes? For the general AN > scenario (only very limited number of FECs), I could imagine also a > smaller number to get a faster recovery time ... I am not sure to change > the RFC5036 value because of this. The backoff scheme described in RFC 5036 has to do with connection setup attempts. I assume an AN won't try to set up a TCP connection with its AGN unless it has an operational link to the AGN. The exponential backoff protects an AGN that is just coming up from getting repeatedly bombarded with connection requests at a faster rate than it can respond to. In this thread, we are discussing something entirely different. The LDP connection is already set up, the AN has already asked the AGN for a label bound to a particular FEC, and there is a routing change that affects the AGN's ability to reach the FEC. The issue is how the AGN should communicate this routing change to the AN. Generally the timeframe for communicating routing changes is very small, much smaller than two minutes, and generally information about routing changes is pushed rather than pulled. I understand that each AN only needs to know about a small number of address prefixes. So it would seem that a good solution would work as follows: - A particular AN tells AGN "I want to register to receive information about the following set of prefixes". - The AGN then pushes the current information about those prefixes to the the ANs that have registered for those prefixes. - Routing changes regarding those prefixes are pushed quickly to the ANs that have registered for those prefixes. This seems like a simple paradigm that does not require per-service configuration on the AGN, that does not require periodic polling from the ANs, and that does not suffer from slow recovery due to exponential backoff. I'm not sure why you'd want to do periodic polling when you've already set up a TCP connection. The DoD procedures in LDP were designed around the assumption that the LDP peers are already engaged in a routing protocol with each other. If the AN and the AGN, for example, were running a routing protocol between themselves, the AN would quickly learn via routing whether a given FEC is reachable via the AGN, and the AN could request a label as soon as the FEC becomes reachable. RFC5036 really assumes that even in the DoD case, routing changes get pushed. From loa@pi.nu Fri Aug 5 10:48:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2669921F8BAE; Fri, 5 Aug 2011 10:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvFVYfYBgIV4; Fri, 5 Aug 2011 10:48:14 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDD221F8BA0; Fri, 5 Aug 2011 10:48:14 -0700 (PDT) Received: from [10.154.181.21] (unknown [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 7953A514044; Fri, 5 Aug 2011 19:48:29 +0200 (CEST) Message-ID: <4E3C2D10.1030109@pi.nu> Date: Fri, 05 Aug 2011 10:49:04 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ccamp@ietf.org, "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] requirements on establishing an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:48:15 -0000 CCAMP and MPLS working groups, The CCAMP working group has a working group document draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01. The document specifies a way of establishing an associated bi-directional LSP based on single ended signaling as well as to associate two unidirectional LSPs. There is a requirement in RFC5654: 50 The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP data plane (i.e., unidirectional P2P, associated bidirectional P2P, co-routed bidirectional P2P, unidirectional P2MP) including configuration of protection functions and any associated maintenance functions. The MPLS working group owns the requirements for transport LSPs, while CCAMP owns definition of GMPLS extensions. If you have comments on the above requirements as it relates to this draft, please send you comments to the MPLS WG list. If you have comments on the proposed mechanism, please send your comments to the ccamp WG list. MPLS and CCAMP working group co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From yshen@juniper.net Fri Aug 5 12:35:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279871F0C4A; Fri, 5 Aug 2011 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04y7hyKm+jm9; Fri, 5 Aug 2011 12:35:29 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5E1F0C40; Fri, 5 Aug 2011 12:35:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxGEvnHwwqelLKrGxko2c14DqIkpE/X@postini.com; Fri, 05 Aug 2011 12:35:47 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Aug 2011 12:35:44 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 5 Aug 2011 15:35:43 -0400 From: Yimin Shen To: "Henderickx, Wim (Wim)" , Rahul Aggarwal Date: Fri, 5 Aug 2011 15:35:40 -0400 Thread-Topic: draft-shen-pwe3-endpoint-fast-protection Thread-Index: AcxL1U7fI2okDnOnToe4ryNlXmqCWgH0SkSQ Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.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 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] draft-shen-pwe3-endpoint-fast-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 19:35:30 -0000 Hi Wim, Thanks for the comments. > 1. Will this solution support revertive as well as non-revertive > behavior after failure recovery. How will it work? [yshen] Yes, it will. After the recovery of AC or egress PE, the PLR should= re-install the forwarding entry of the primary path, and switch traffic fr= om the bypass LSP back to the primary path. Of course, local reversion may = be managed by policy on the PLR. > 2. Is the goal to make this solution applicable to MS-PW as well as > dynamic MS-PW FEC129. [yshen] Yes, the new defined "protection FEC element" can support FEC 129. = MS-PW is a good suggestion.=20 > 3. In general we should add some applicability in the draft. In certain > cases and depending on the applicability you could have un-optimized > traffic flows. > 5. We should discuss the RSVP procedures in this draft in the MPLS WG. >=20 [yshen] Good suggestions. Thanks, -Yimin > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Tuesday, July 26, 2011 4:48 PM > To: Yimin Shen; Rahul Aggarwal > Cc: pwe3@ietf.org; mpls@ietf.org > Subject: draft-shen-pwe3-endpoint-fast-protection >=20 > Regarding the draft I have following remarks/questions/suggestions > since we had no discussion on the mike today. >=20 > 1. Will this solution support revertive as well as non-revertive > behavior after failure recovery. How will it work? > 2. Is the goal to make this solution applicable to MS-PW as well as > dynamic MS-PW FEC129. > 3. In general we should add some applicability in the draft. In certain > cases and depending on the applicability you could have un-optimized > traffic flows. > 5. We should discuss the RSVP procedures in this draft in the MPLS WG. >=20 > Cheers, > Wim From hideki.endo.es@hitachi.com Fri Aug 5 17:55:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC511E8080 for ; Fri, 5 Aug 2011 17:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.743 X-Spam-Level: X-Spam-Status: No, score=0.743 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5C-ohIegUiM for ; Fri, 5 Aug 2011 17:55:38 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D611E807B for ; Fri, 5 Aug 2011 17:55:38 -0700 (PDT) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 3CA8E37AC4; Sat, 6 Aug 2011 09:55:55 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id p760ttRA019144; Sat, 6 Aug 2011 09:55:55 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p760tsC4019203; Sat, 6 Aug 2011 09:55:54 +0900 X-AuditID: b753bd60-a3cafba0000019f4-61-4e3c911aae6c Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 1321D204360; Sat, 6 Aug 2011 09:55:54 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p760tsg16195614; Sat, 6 Aug 2011 09:55:54 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Sat, 6 Aug 2011 09:55:40 +0900 References: <4E1C5B89.8070904@ripe.net> <038c01cc50f6$f23861e0$d6a925a0$@olddog.co.uk> Priority: normal Importance: normal X400-Content-Identifier: X4E3C90F200000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml2811080609551469M] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 00:55:39 -0000 Hi Eric, Thank you for clarifications. I understand what you say. However, it's different from what Yaacov said. I'm confusing.. If your explanation is right status of this draft, why did you changed the version number of PSC? If the only one channel type for PSC is assigned, you don't need to change the version number, do you? BR, Hideki >Hi Hideki- > > I'm afraid you've been misinformed. Version 0 is not in use. We had >talked about ACH TLVs as some point, but do not use them. Per rfc5586, >"If the G-ACh message MAY be preceded by one or more ACH TLVs, then this >MUST be explicitly specified in the definition of an ACH Channel Type" >and we do not make that explicit specification in the draft. > > Version 1 is the only version which we have defined, and it uses >optional TLVs below the PSC header. > > > >eric > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >Of >> hideki.endo.es@hitachi.com >> Sent: Friday, August 05, 2011 12:48 AM >> To: adrian@olddog.co.uk >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection >> >> Hi Adrian, >> >> I'm very sorry for my late response. >> >> You are right. >> A protocol version number normally doesn't matter in final RFC, >because >> previous version number is put away and the latest version is >available. >> >> However, I heard from Yaacov that >> not only version number '1' but also '0' was availble in this draft. >> The version '0' is to use ACH TLVs. >> The version '1' is to use Optional TLVs which will be defined for the >> future. >> >> Unfortunately, I think this solution has big fault as a protocol. >> Because the version number is following ACH TLVs, it is impossible to >> determine whether there are ACH TLVs or Optional TLVs in a packet. >> >> I'd like to advertise the fact in WG. >> >> BR, >> Hideki >> >> >> >Hi Hideki, >> > >> >I have no particular reason to support any protocol version number in >> >the document, but you said... >> > >> >> You should infom the reason why you have changed the protocol >version >> >> from 0 to 1 in the draft-08. >> >> This is very important to implement PSC protocol. >> > >> >...and this made me curious, >> > >> >Why is the value of the protocol version field in the final RFC so >> important? >> > >> >Cheers, >> >Adrian >> > >> > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From adrian@olddog.co.uk Sat Aug 6 05:26:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494AD21F8866 for ; Sat, 6 Aug 2011 05:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRdtru5yDzdb for ; Sat, 6 Aug 2011 05:26:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1D31721F8867 for ; Sat, 6 Aug 2011 05:26:29 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p76CQm0i008128; Sat, 6 Aug 2011 13:26:48 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p76CQiZO008111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Aug 2011 13:26:45 +0100 From: "Adrian Farrel" To: Date: Sat, 6 Aug 2011 13:26:37 +0100 Message-ID: <020f01cc5434$1b1734c0$51459e40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxUNBQZ/VNwTSGsT92AZuEyoT/rJg== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] Definition of MIP and MEP (again) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 12:26:31 -0000 Hi, I'm reviewing another I-D and turned to draft-ietf-mpls-tp-rosetta-stone-04 for a definitive expansion of MIP and MEP. I found section 1.2 MEP MEG End Point MIP MEG Intermediate Point However... 3.43. Maintenance End Points (MEPs) 3.44. Maintenance Intermediate Points (MIPs) Have I got caught on formality versus the colloquial, or is this something you need to fix in the draft? Thanks, Adrian From huubatwork@gmail.com Sat Aug 6 05:35:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A121F87BC for ; Sat, 6 Aug 2011 05:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJGTiWopefOt for ; Sat, 6 Aug 2011 05:35:12 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2719621F8794 for ; Sat, 6 Aug 2011 05:35:11 -0700 (PDT) Received: by ewy19 with SMTP id 19so486130ewy.31 for ; Sat, 06 Aug 2011 05:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=D9l3npGPht+OGQaOmInMgKfNBXvIikzDKDyg/I9RqVI=; b=TikyW5bxXmQKJPQpoMsRyRr7ZmGI/ET3dmg0C0zib+iQntAmmCuhohEObE1/XCkDZv uvaBTBqG67RbGrj9ZGTKMg1B9Hv9/2S/4yjwnJt/rJHRNz5ST5r+YdIk8YVWPbAK+DXG JLSot7FheSrxnfm1QvfCpblCW4MkpS0WKokV8= Received: by 10.14.96.207 with SMTP id r55mr970244eef.63.1312634131763; Sat, 06 Aug 2011 05:35:31 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id f54sm343381eef.48.2011.08.06.05.35.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Aug 2011 05:35:29 -0700 (PDT) Message-ID: <4E3D3510.8060208@gmail.com> Date: Sat, 06 Aug 2011 14:35:28 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <020f01cc5434$1b1734c0$51459e40$@olddog.co.uk> In-Reply-To: <020f01cc5434$1b1734c0$51459e40$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org Subject: Re: [mpls] Definition of MIP and MEP (again) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 12:35:13 -0000 Hello Adrian, You wrote: > I'm reviewing another I-D and turned to draft-ietf-mpls-tp-rosetta-stone-04 for > a definitive expansion of MIP and MEP. > > I found section 1.2 > MEP MEG End Point > MIP MEG Intermediate Point This is the correct expansion. > However... > 3.43. Maintenance End Points (MEPs) This should be also MEG End Points (MEPs), or completely expanded: Maintenance Entity Group End Points (MEPs). > 3.44. Maintenance Intermediate Points (MIPs) This should be also MEG Intermediate Points (MIPs), or completely expanded: Maintenance Entity Group Intermediate Points (MIPs). > Have I got caught on formality versus the colloquial, or is this something you > need to fix in the draft? It will be fixed in the rosetta draft Best regards, Huub. From DanielC@orckit.com Sat Aug 6 23:22:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E60E21F86B9 for ; Sat, 6 Aug 2011 23:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.434 X-Spam-Level: * X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[AWL=-3.863, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do8mCD99+t5p for ; Sat, 6 Aug 2011 23:22:52 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7321F85B8 for ; Sat, 6 Aug 2011 23:22:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC54CA.D707494D" Date: Sun, 7 Aug 2011 09:23:16 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED8A38@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6IFJlOiAgQ29tbWVudHMgdG8gZHJhZnQtcmtoZA==?= =?gb2312?B?LW1wbHMtdHAtc2QtMDM=?= Thread-Index: AQHMTZHk6YoUewV010WCVjGKj1+yDpUCmuUAgAA8JQCAAEH1UIAEbyIAgAAoPDCACUhqcA== References: From: "Daniel Cohn" To: "Maarten vissers" , Cc: mpls@ietf.org, huubatwork@gmail.com Subject: Re: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 06:22:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC54CA.D707494D Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Marteen, =20 Regarding your last comment, pls note that the last SD draft revision = includes support for the scenario you describe (error rate in each link = below the SD threshold and end-to-end error rate path above the = threshold) =A8C see section 5.1. =20 Daniel =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Maarten vissers Sent: Friday, August 05, 2011 4:09 PM To: su.hui@zte.com.cn Cc: mpls@ietf.org; huubatwork@gmail.com Subject: Re: [mpls] =B4=F0=B8=B4: Re: Comments to = draft-rkhd-mpls-tp-sd-03 =20 Hi Suhui, =20 Please see inline=A1=AD =20 From: su.hui@zte.com.cn [mailto:su.hui@zte.com.cn]=20 Sent: 1 August 2011 09:10 To: Maarten vissers Cc: huubatwork@gmail.com; mpls@ietf.org; mpls-bounces@ietf.org Subject: =B4=F0=B8=B4: RE: [mpls] =B4=F0=B8=B4: Re: Comments to = draft-rkhd-mpls-tp-sd-03 Hi Maarten=A3=AC=20 Please see the online=A1=AD.=20 Regards=A3=AC=20 Suhui=20 Maarten vissers =20 2011-07-29 20:24=20 =CA=D5=BC=FE=C8=CB "su.hui@zte.com.cn" , "huubatwork@gmail.com" = =20 =B3=AD=CB=CD "mpls@ietf.org" , "mpls-bounces@ietf.org" = =20 =D6=F7=CC=E2 RE: [mpls] =B4=F0=B8=B4: Re: Comments to draft-rkhd-mpls-tp-sd-03 =20 =09 Suhui,=20 =20 Your solution does not meet the requirement to prevent entering UAT in = protected transport service layer connections under packet loss = conditions; i.e. packet loss due to non bit error conditions is not = taken care of. Customer will still complain and will ask his/her money = back in such case L.=20 [SH] There are there reasons which can cause SD: fiber defect, = congestion, equipment defect. This mechanism can only deal with the = first reason. Someone told me that more than 90% failure are cause by = fiber defect and power defect(maybe some carriers can give us more = accurate number), and it is impossible to detect SD caused by congestion = or equipment defect if no packet is transmitting, so if there is no = other better solution, this is good enough for me. [MV] Bottom line question is if protection switching on Physical layer = SD (=3DdDEG) condition should prevent service to enter UAT. If it is = allowed to prevent entering UAT only for ~90% of packet loss cases then = your proposed trigger condition might be good enough. But this needs to = be agreed first. An FEI adds much more than just another maintenance signal type of OAM = packet. It may require changes to OTN devices (i.e. concerning = processing of bit error information and consequent actions) and changes = to MPLS-TP devices (i.e. concerning processing of packet loss = information and consequent actions).=20 [SH] Yes, if one adds a type of packet, one must generate/receive this = packet. But since the mechanism is the same as FDI, it does not add much = work.=20 [MV] Changes to existing hardware and software are not appreciated if = they do not completely resolve the issue. FEI propagation is not the same as FDI/AIS propagation.=20 - Default FDI/AIS propagation is based on detection of local = CC/CV defect in MEP Sink which controls insertion of FDI/AIS into client = layer signal (PW, service-LSP, transport-LSP) or into client TCM level = (PSME).=20 Only if MEP Sink is configured not to perform CC/CV defect detection it = is necessary to use FDI/AIS defect to control insertion of FDI/AIS; this = is only necessary at transport service layer MEP functions when SLA does = not require pro-active fault monitoring. Now it will be necessary to = generate FDI/AIS in the customer=A1=AFs signal based on detected AIS = defect.=20 - FEI propagation always requires forwarding of incoming FEI = information; i.e. FEI OAM is terminated, FEI information is extracted = and inserted into client FEI OAM packet(s). There may be multiple FEI = OAM packets incoming every second (one from every physical layer link = passed; i.e. every second more than one FEI OAM packet may have to be = inserted into the client layer or client PSME signal. See figure below.=20 [SH] I do not see there is any difference between FEI propagation and = FDI propagation.=20 For FDI : A MEP receives a FDI packet or detects failure by other OAM , = then it enters TSF condition, then consequent actions of TSF condition = will insert FDI packet in its client layer.=20 For FEI: A MEP receives a FEI packet, then it enters TSD condition, = then consequent actions of TSD condition will insert FEI packet in its = client layer. A MEP only inserts one packet in one second in each client = no matter how much FEI packets it receives.=20 [MV] The FEI propagation method you describe is not able to accumulate = packet loss along a multi-segment path. E.g. if the connection (PW, LSP, = PSME) consists of 10 segments and each segment has e.g. a 1E-7 error = rate then the total connection would have a 1E-6 error rate. If 1E-6 = would be the trigger for a packet SD condition, then you will not reach = that with your solution, but you would get to that with the solution I = described. What you describe is a very much simplified version, which = can be described as: if one or more of the physical links detects a = Degraded defect, then the packet SD condition will be declared. =20 Regards, Maarten Regards,=20 Maarten=20 ------_=_NextPart_001_01CC54CA.D707494D Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Marteen,

 

Regarding your last comment, pls note that the last SD draft revision = includes support for the scenario you describe (error rate in each link = below the SD threshold and end-to-end error rate path above the = threshold) =A8C see section 5.1.

 

Daniel

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Maarten vissers
Sent: Friday, August 05, 2011 4:09 = PM
To: su.hui@zte.com.cn
Cc: mpls@ietf.org; = huubatwork@gmail.com
Subject: Re: [mpls] =B4=F0=B8=B4: Re: = Comments to draft-rkhd-mpls-tp-sd-03

 

Hi Suhui,

 

Please see inline=A1=AD

 

From:= = su.hui@zte.com.cn [mailto:su.hui@zte.com.cn]=
Sent: 1 August 2011 09:10
To: Maarten = vissers
Cc: huubatwork@gmail.com; mpls@ietf.org; mpls-bounces@ietf.org
Sub= ject: =B4=F0=B8=B4: RE: = [mpls] =B4=F0=B8=B4: Re: = Comments to = draft-rkhd-mpls-tp-sd-03


Hi = Maarten=A3=AC
Please = see the online=A1=AD.

Regards=A3=AC
Suhui<= span lang=3DEN-GB style=3D'font-size:11.0pt'> =

Maarten = vissers <maarten.vissers@huawei.com= > =

2011-07-29 = 20:24

"su.hui@zte.com.cn" <su.hui@zte.com.cn>, "huubatwork@gmail.com" = <huubatwork@gmail.com> =

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

"mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" = <mpls-bounces@ietf.org>

=D6=F7=CC=E2

RE: [mpls] = =B4=F0=B8=B4: Re: =  Comments to = draft-rkhd-mpls-tp-sd-03

 

=


Suhui,
 
Your solution does not meet the requirement to prevent entering UAT = in protected transport service layer connections under packet loss = conditions; i.e. packet loss due to non bit error conditions is not = taken care of. Customer will still complain and will ask his/her money = back in such case L.
[SH] There are = there reasons which can cause SD: fiber defect, congestion, equipment = defect. This mechanism can only deal with the first reason. Someone told = me that more than 90% failure are cause by fiber defect and power = defect(maybe some carriers can give us more accurate number), and it is = impossible to detect SD caused by congestion or equipment defect if no = packet is transmitting, so if there is no other better solution, this is = good enough for me.

[MV] Bottom line question is if protection switching on Physical layer = SD (=3DdDEG) condition should prevent service to enter UAT. If it is = allowed to prevent entering UAT only for ~90% of packet loss cases then = your proposed trigger condition might be good enough. But this needs to = be agreed first.


An FEI adds much more than just another maintenance signal type of = OAM packet. It may require changes to OTN devices (i.e. concerning = processing of bit error information and consequent actions) and changes = to MPLS-TP devices (i.e. concerning processing of packet loss = information and consequent actions).
[SH] Yes, if one = adds a type of packet, one must generate/receive this packet. But since = the mechanism is the same as FDI, it does not add much work. =

[MV] Changes to existing hardware and software are not appreciated if = they do not completely resolve the issue.


FEI propagation is not the same as FDI/AIS propagation.
-          Default FDI/AIS propagation is = based on detection of local CC/CV defect in MEP Sink which controls = insertion of FDI/AIS into client layer signal (PW, service-LSP, = transport-LSP) or into client TCM level (PSME).
Only if MEP Sink is = configured not to perform CC/CV defect detection it is necessary to use = FDI/AIS defect to control insertion of FDI/AIS; this is only necessary = at transport service layer MEP functions when SLA does not require = pro-active fault monitoring. Now it will be necessary to generate = FDI/AIS in the customer=A1=AFs signal based on detected AIS = defect. =
-          FEI propagation always requires = forwarding of  incoming FEI information; i.e. FEI OAM is = terminated, FEI information is extracted and inserted into client FEI = OAM packet(s). There may be multiple FEI OAM packets incoming every = second (one from every physical layer link passed; i.e. every second = more than one FEI OAM packet may have to be inserted into the client = layer or client PSME signal. See figure below. =
[SH] I do not = see there is any difference between FEI propagation and FDI = propagation.
For FDI :  A MEP = receives a FDI packet or detects failure by other OAM , then it enters = TSF condition, then consequent actions of TSF condition will insert FDI = packet in its client layer.
For FEI: =  A MEP receives a FEI packet, then it enters TSD condition, then = consequent actions of TSD condition will insert FEI packet in its client = layer. A MEP only inserts one packet in one second in each client no = matter how much FEI packets it receives. =

[MV] The FEI propagation method you describe is not able to accumulate = packet loss along a multi-segment path. E.g. if the connection (PW, LSP, = PSME) consists of 10 segments and each segment has e.g. a 1E-7 error = rate then the total connection would have a 1E-6 error rate. If 1E-6 = would be the trigger for a packet SD condition, then you will not reach = that with your solution, but you would get to that with the solution I = described. What you describe is a very much simplified version, which = can be described as: if one or more of the physical links detects a = Degraded defect, then the packet SD condition will be = declared.

 

Regards,

Maarten



Regards,
Maarten =

------_=_NextPart_001_01CC54CA.D707494D-- From adrian@olddog.co.uk Sun Aug 7 10:46:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E659721F86C4 for ; Sun, 7 Aug 2011 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2hr3rGetkJv for ; Sun, 7 Aug 2011 10:46:10 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 11DD121F86C0 for ; Sun, 7 Aug 2011 10:46:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p77HkPxT013713; Sun, 7 Aug 2011 18:46:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p77HkObB013701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Aug 2011 18:46:25 +0100 From: "Adrian Farrel" To: , References: <4E1C5B89.8070904@ripe.net> <038c01cc50f6$f23861e0$d6a925a0$@olddog.co.uk> In-Reply-To: Date: Sun, 7 Aug 2011 18:46:17 +0100 Message-ID: <02d301cc5529$ed7a0a00$c86e1e00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDp5r/6gym1W0riGZSKSJ0MM3eLQALGr4H0Aa8GEqoCK2pO9QIbxQyrAfRKZvKWgPtWwA== Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 17:46:11 -0000 Hi Hideki, We didn't see Yaacov's email so we can't comment. But I think I agree with Eric... If it isn't documented in a current draft or an RFC, it doesn't exist. So I think there is no definition of LP using ACH TLVs, and no version zero of the protocol. Cheers, Adrian > -----Original Message----- > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > Sent: 06 August 2011 01:56 > To: eosborne@cisco.com > Cc: adrian@olddog.co.uk; mpls@ietf.org; yaacov.weingarten@nsn.com > Subject: Re[2]: [mpls] Comments on draft-ietf-mpls-tp-linear-protection > > Hi Eric, > > Thank you for clarifications. > > I understand what you say. > However, it's different from what Yaacov said. > I'm confusing.. > > If your explanation is right status of this draft, > why did you changed the version number of PSC? > If the only one channel type for PSC is assigned, > you don't need to change the version number, do you? > > BR, > Hideki > > > >Hi Hideki- > > > > I'm afraid you've been misinformed. Version 0 is not in use. We had > >talked about ACH TLVs as some point, but do not use them. Per rfc5586, > >"If the G-ACh message MAY be preceded by one or more ACH TLVs, then this > >MUST be explicitly specified in the definition of an ACH Channel Type" > >and we do not make that explicit specification in the draft. > > > > Version 1 is the only version which we have defined, and it uses > >optional TLVs below the PSC header. > > > > > > > >eric > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >Of > >> hideki.endo.es@hitachi.com > >> Sent: Friday, August 05, 2011 12:48 AM > >> To: adrian@olddog.co.uk > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection > >> > >> Hi Adrian, > >> > >> I'm very sorry for my late response. > >> > >> You are right. > >> A protocol version number normally doesn't matter in final RFC, > >because > >> previous version number is put away and the latest version is > >available. > >> > >> However, I heard from Yaacov that > >> not only version number '1' but also '0' was availble in this draft. > >> The version '0' is to use ACH TLVs. > >> The version '1' is to use Optional TLVs which will be defined for the > >> future. > >> > >> Unfortunately, I think this solution has big fault as a protocol. > >> Because the version number is following ACH TLVs, it is impossible to > >> determine whether there are ACH TLVs or Optional TLVs in a packet. > >> > >> I'd like to advertise the fact in WG. > >> > >> BR, > >> Hideki > >> > >> > >> >Hi Hideki, > >> > > >> >I have no particular reason to support any protocol version number in > >> >the document, but you said... > >> > > >> >> You should infom the reason why you have changed the protocol > >version > >> >> from 0 to 1 in the draft-08. > >> >> This is very important to implement PSC protocol. > >> > > >> >...and this made me curious, > >> > > >> >Why is the value of the protocol version field in the final RFC so > >> important? > >> > > >> >Cheers, > >> >Adrian > >> > > >> > > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > From zhang.fei3@zte.com.cn Mon Aug 8 03:02:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8821F8A67; Mon, 8 Aug 2011 03:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.563 X-Spam-Level: X-Spam-Status: No, score=-97.563 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2fhWAGiCzkP; Mon, 8 Aug 2011 03:02:57 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DC6B321F8A57; Mon, 8 Aug 2011 03:02:55 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 152362257607178; Mon, 8 Aug 2011 18:00:27 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 22013.2631859300; Mon, 8 Aug 2011 17:57:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p789vYF5082286; Mon, 8 Aug 2011 17:57:34 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4E3C2D10.1030109@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-KeepSent: 36C297E3:BE3038EB-482578E6:0030AD20; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 8 Aug 2011 17:57:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-08 17:57:37, Serialize complete at 2011-08-08 17:57:37 Content-Type: multipart/alternative; boundary="=_alternative 0036B1BE482578E6_=" X-MAIL: mse02.zte.com.cn p789vYF5082286 Cc: "mpls@ietf.org" , ccamp@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] requirements on establishing an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 10:02:57 -0000 This is a multipart message in MIME format. --=_alternative 0036B1BE482578E6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkkgZ2F2ZSB0d28gcHJlc2VudGF0aW9ucyBpbiB0aGUgcGFzdCBJRVRGODEgbWVl dGluZywgb25lIGlzIGluIHRoZSBNUExTIFdHIA0KZGlzY3Vzc2luZyB0aGUgcmVxdWlyZW1lbnRz LCBhbmQgdGhlIG90aGVyIGlzIGluIENDQU1QIHNlc3Npb24gZGlzY3Vzc2luZyANCnRoZSBzb2x1 dGlvbi4NCg0KdGhlIHByZXNlbnRhdGlvbiBtYXRlcmlhbHMgZm9yIHJlZmVyZW5jZSBhcmUgaGVy ZS4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9tcGxzL2FnZW5kYQ0KaHR0cDovL3Rvb2xzLmll dGYub3JnL3dnL2NjYW1wL2FnZW5kYQ0KDQpUaGUgcmVxdWlyZW1lbnQgKFI1MCBpbiBSRkM1NjU0 KSBkaWQgbm90IHNwZWNpZnkgdGhlIGV4YWN0IHNvbHV0aW9uLCBhbmQgDQp0aGUgZGVmaW5pdGlv biBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggc2FpZCB0aGF0ICJU aGUgDQpmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJlY3Rpb25zIGFyZSBzZXR1cCwgbW9uaXRvcmVk LCBhbmQgcHJvdGVjdGVkIA0KaW5kZXBlbmRlbnRseSAiLg0KDQpNeSBvcGluaW9uIGFib3V0IHRo ZSByZXF1aXJlbWVudCBhbmQgZGVmaW5pdGlvbiBpcyBsaXN0ZWQgYmVsb3csIA0KDQooMSkgd2hh dCBpcyB0aGUgaW5kaWNhdGlvbiBvZiBpbmRlcGVuZGVuY2U/IEl0IG1lYW5zIHRoYXQgb25lIGRp cmVjaW9uIGNhbiANCm5vdCB0aWdnZXIgdGhlIGVzdGFibGlzaG1lbnQgb2YgdGhlIG90aGVyIGRp cmVjdGlvbj8gT3IgSXQganVzdCBtZWFucyB0aGF0IA0KdGhlcmUgYXJlIHR3byBzaWduYWxpbmcg cHJvY2VkdXJlcz8gU2luY2UgTVMtUFcgaXMgYSBraW5kIG9mIGFzc29jaWF0ZWQgDQpiaWRpcmVj dGlvbmFsIHRyYW5zcG9ydCBwYXRoLCBJIHRlbmQgdG8gaW50ZXJwcmV0YXRlIHRoZSBkZWZpbml0 aW9uIGFzIHRoZSANCnNlY29uZCBjYXNlIA0KDQpBcyB0byB0aGUgc29sdXRpb246DQoNCigyKSBT aW5jZSBNUExTLVRQIE1VU1Qgc3VwcG9ydCBhc3ltbWV0cmljIGJhbmR3aXRoIExTUHMgKFIxNCks IGNvbnNpZGVyIA0KdGhlIGZvbGxvd2luZyB0b3BvbG9neToNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMTAwTSAgICAgIDEwME0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QS0tLS0tLS0tLS1ELS0tLS0tLUINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgNTBN ICAgIC8gIDEwME0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgMTAwTSBcNjBNICAgLzEwME0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAvDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBcIEMvDQpPbmUgYmlkaXJlY3Rpb25hbCBMU1Agd2l0aCA4ME0gc3lt bWV0cmljIGJhbmR3aWR0aCBuZWVkcyB0byBiZSBzZXQgdXAgDQpiZXR3ZWVuIG5vZGUgQSBhbmQg QiwgdGhlIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIG9uIHRoZSBsaW5rcyBhcmUgDQpkZXNjcmlwdGVk Lg0KDQp0aGUgcGF0aCBhbG9uZyBbQS1ELUJdIGNhbiBub3QgbWVldCB0aGUgcmVxdWlyZW1lbnQg Zm9yIHRoZSB1bnJldmVydmVkIA0KYmFuZHdpZHRoIG9uIGxpbmtbRC0+QV0gaXMgNTBNLiBCdXQg dGhlIGNvbWJpbmF0aW9uIG9mIFtBLT5ELT5CXSBhbmQgDQpbQi0+RC0+Qy0+QV0gY2FuIA0KbWVl dCB0aGUgcmVxdWlyZW1lbnQgd2VsbC4NCg0KSW4gdGhpcyBjYXNlLCB0aGUgc2luZ2xlIHNpZGVk IHByb3Zpc2lvbmluZyB3aWxsIGJlIG1vcmUgY29udmVuaWVudCBpbiANCk1QTFMgZW52aXJvbWVu dC4NCg0KSG9wZSB0byBoZWFyIG1vcmUgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgZnJvbSBXRw0K DQpCZXN0IHJlZ2FyZHMNCg0KRmVpDQoNCg0KDQpMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IA0K t6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA4LTA2IDAxOjQ5DQoNCsrVvP7I yw0KY2NhbXBAaWV0Zi5vcmcsICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCrOty80N Cg0K1vfM4g0KW21wbHNdIHJlcXVpcmVtZW50cyBvbiBlc3RhYmxpc2hpbmcgYW4gYXNzb2NpYXRl ZCBiaS1kaXJlY3Rpb25hbCBMU1ANCg0KDQoNCg0KDQoNCkNDQU1QIGFuZCBNUExTIHdvcmtpbmcg Z3JvdXBzLA0KDQpUaGUgQ0NBTVAgd29ya2luZyBncm91cCBoYXMgYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50DQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxz cC0wMS4NCg0KVGhlIGRvY3VtZW50IHNwZWNpZmllcyBhIHdheSBvZiBlc3RhYmxpc2hpbmcgYW4g YXNzb2NpYXRlZA0KYmktZGlyZWN0aW9uYWwgTFNQIGJhc2VkIG9uIHNpbmdsZSBlbmRlZCBzaWdu YWxpbmcgYXMgd2VsbA0KYXMgdG8gYXNzb2NpYXRlIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzLiBU aGVyZSBpcyBhIHJlcXVpcmVtZW50DQppbiBSRkM1NjU0Og0KDQogICAgIDUwICBUaGUgTVBMUy1U UCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBlc3RhYmxpc2hpbmcgYWxsIHRoZQ0KICAgICAg ICAgY29ubmVjdGl2aXR5IHBhdHRlcm5zIGRlZmluZWQgZm9yIHRoZSBNUExTLVRQIGRhdGEgcGxh bmUgKGkuZS4sDQogICAgICAgICB1bmlkaXJlY3Rpb25hbCBQMlAsIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCBQMlAsIGNvLXJvdXRlZA0KICAgICAgICAgYmlkaXJlY3Rpb25hbCBQMlAsIHVuaWRp cmVjdGlvbmFsIFAyTVApIGluY2x1ZGluZyBjb25maWd1cmF0aW9uDQogICAgICAgICBvZiBwcm90 ZWN0aW9uIGZ1bmN0aW9ucyBhbmQgYW55IGFzc29jaWF0ZWQgbWFpbnRlbmFuY2UNCiAgICAgICAg IGZ1bmN0aW9ucy4NCg0KVGhlIE1QTFMgd29ya2luZyBncm91cCBvd25zIHRoZSByZXF1aXJlbWVu dHMgZm9yIHRyYW5zcG9ydCBMU1BzLCB3aGlsZQ0KQ0NBTVAgb3ducyBkZWZpbml0aW9uIG9mIEdN UExTIGV4dGVuc2lvbnMuDQoNCklmIHlvdSBoYXZlIGNvbW1lbnRzIG9uIHRoZSBhYm92ZSByZXF1 aXJlbWVudHMgYXMgaXQgcmVsYXRlcyB0byB0aGlzDQpkcmFmdCwgcGxlYXNlIHNlbmQgeW91IGNv bW1lbnRzIHRvIHRoZSBNUExTIFdHIGxpc3QuIElmIHlvdSBoYXZlDQpjb21tZW50cyBvbiB0aGUg cHJvcG9zZWQgbWVjaGFuaXNtLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQ0KY2Nh bXAgV0cgbGlzdC4NCg0KTVBMUyBhbmQgQ0NBTVAgd29ya2luZyBncm91cCBjby1jaGFpcnMNCg0K LS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h LmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdl ciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAg ICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQo= --=_alternative 0036B1BE482578E6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBnYXZlIHR3byBwcmVzZW50YXRp b25zIGluIHRoZSBwYXN0DQpJRVRGODEgbWVldGluZywgb25lIGlzIGluIHRoZSBNUExTIFdHIGRp c2N1c3NpbmcgdGhlIHJlcXVpcmVtZW50cywgYW5kDQp0aGUgb3RoZXIgaXMgaW4gQ0NBTVAgc2Vz c2lvbiBkaXNjdXNzaW5nIHRoZSBzb2x1dGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBwcmVzZW50YXRpb24gbWF0ZXJpYWxzIGZvciByZWZl cmVuY2UNCmFyZSBoZXJlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL21wbHMvYWdlbmRhPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2NhbXAv YWdlbmRhPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5U aGUgcmVxdWlyZW1lbnQgKFI1MCBpbiBSRkM1NjU0KSBkaWQNCm5vdCBzcGVjaWZ5IHRoZSBleGFj dCBzb2x1dGlvbiwgYW5kIHRoZSBkZWZpbml0aW9uIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bA0KdHJhbnNwb3J0IHBhdGggc2FpZCB0aGF0ICZxdW90O1RoZSBmb3J3YXJkIGFuZCBiYWNrd2Fy ZCBkaXJlY3Rpb25zIGFyZQ0Kc2V0dXAsIG1vbml0b3JlZCwgYW5kIHByb3RlY3RlZCBpbmRlcGVu ZGVudGx5ICZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPk15IG9waW5pb24gYWJvdXQgdGhlIHJlcXVpcmVtZW50IGFuZA0KZGVmaW5pdGlvbiBp cyBsaXN0ZWQgYmVsb3csIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+KDEpIHdoYXQgaXMgdGhlIGluZGljYXRpb24gb2YgaW5kZXBlbmRlbmNlPw0KSXQg bWVhbnMgdGhhdCBvbmUgZGlyZWNpb24gY2FuIG5vdCB0aWdnZXIgdGhlIGVzdGFibGlzaG1lbnQg b2YgdGhlIG90aGVyDQpkaXJlY3Rpb24/IE9yIEl0IGp1c3QgbWVhbnMgdGhhdCB0aGVyZSBhcmUg dHdvIHNpZ25hbGluZyBwcm9jZWR1cmVzPyBTaW5jZQ0KTVMtUFcgaXMgYSBraW5kIG9mIGFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aCwgSSB0ZW5kIHRvIGludGVycHJldGF0 ZQ0KdGhlIGRlZmluaXRpb24gYXMgdGhlIHNlY29uZCBjYXNlICZuYnNwOzwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgdG8gdGhlIHNvbHV0aW9uOjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDIpIFNpbmNl IE1QTFMtVFAgTVVTVCBzdXBwb3J0IGFzeW1tZXRyaWMNCmJhbmR3aXRoIExTUHMgKFIxNCksIGNv bnNpZGVyIHRoZSBmb2xsb3dpbmcgdG9wb2xvZ3k6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDEwME0NCiZuYnNwOyAmbmJzcDsgJm5ic3A7MTAwTTwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QS0tLS0tLS0tLS1ELS0tLS0tLUI8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcIDUwTSAmbmJzcDsNCiZuYnNwOy8gJm5ic3A7MTAwTTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAxMDBNIFw2ME0gJm5ic3A7IC8xMDBNPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFwNCiZuYnNwOyAmbmJzcDsvPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1wNCkMvPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5PbmUgYmlkaXJlY3Rpb25hbCBMU1Agd2l0aCA4 ME0gc3ltbWV0cmljDQpiYW5kd2lkdGggbmVlZHMgdG8gYmUgc2V0IHVwIGJldHdlZW4gbm9kZSBB IGFuZCBCLCB0aGUgdW5yZXNlcnZlZCBiYW5kd2lkdGgNCm9uIHRoZSBsaW5rcyBhcmUgZGVzY3Jp cHRlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRo ZSBwYXRoIGFsb25nIFtBLUQtQl0gY2FuIG5vdCBtZWV0DQp0aGUgcmVxdWlyZW1lbnQgZm9yIHRo ZSB1bnJldmVydmVkIGJhbmR3aWR0aCBvbiBsaW5rW0QtJmd0O0FdIGlzIDUwTS4gQnV0DQp0aGUg Y29tYmluYXRpb24gb2YgW0EtJmd0O0QtJmd0O0JdIGFuZCBbQi0mZ3Q7RC0mZ3Q7Qy0mZ3Q7QV0g Y2FuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bWVldCB0aGUg cmVxdWlyZW1lbnQgd2VsbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkluIHRoaXMgY2FzZSwgdGhlIHNpbmdsZSBzaWRlZCBwcm92aXNpb25pbmcNCndp bGwgYmUgbW9yZSBjb252ZW5pZW50IGluIE1QTFMgZW52aXJvbWVudC48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvcGUgdG8gaGVhciBtb3JlIGNvbW1l bnRzIG9yIHN1Z2dlc3Rpb25zDQpmcm9tIFdHPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7 PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6 ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDExLTA4LTA2IDAxOjQ5PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjYW1wQGlldGYub3JnLCAmcXVvdDttcGxz QGlldGYub3JnJnF1b3Q7DQombHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlttcGxzXSByZXF1aXJlbWVu dHMgb24gZXN0YWJsaXNoaW5nDQphbiBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExTUDwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Q0NB TVAgYW5kIE1QTFMgd29ya2luZyBncm91cHMsPGJyPg0KPGJyPg0KVGhlIENDQU1QIHdvcmtpbmcg Z3JvdXAgaGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudDxicj4NCmRyYWZ0LWlldGYtY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAxLjxicj4NCjxicj4NClRoZSBkb2N1 bWVudCBzcGVjaWZpZXMgYSB3YXkgb2YgZXN0YWJsaXNoaW5nIGFuIGFzc29jaWF0ZWQ8YnI+DQpi aS1kaXJlY3Rpb25hbCBMU1AgYmFzZWQgb24gc2luZ2xlIGVuZGVkIHNpZ25hbGluZyBhcyB3ZWxs PGJyPg0KYXMgdG8gYXNzb2NpYXRlIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzLiBUaGVyZSBpcyBh IHJlcXVpcmVtZW50PGJyPg0KaW4gUkZDNTY1NDo8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyA1 MCAmbmJzcDtUaGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBlc3RhYmxpc2hp bmcNCmFsbCB0aGU8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbm5lY3Rpdml0 eSBwYXR0ZXJucyBkZWZpbmVkIGZvciB0aGUgTVBMUy1UUA0KZGF0YSBwbGFuZSAoaS5lLiw8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVuaWRpcmVjdGlvbmFsIFAyUCwgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsDQpQMlAsIGNvLXJvdXRlZDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgYmlkaXJlY3Rpb25hbCBQMlAsIHVuaWRpcmVjdGlvbmFsIFAyTVApIGluY2x1 ZGluZw0KY29uZmlndXJhdGlvbjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb2Yg cHJvdGVjdGlvbiBmdW5jdGlvbnMgYW5kIGFueSBhc3NvY2lhdGVkDQptYWludGVuYW5jZTxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25zLjxicj4NCjxicj4NClRoZSBN UExTIHdvcmtpbmcgZ3JvdXAgb3ducyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0cmFuc3BvcnQgTFNQ cywgd2hpbGU8YnI+DQpDQ0FNUCBvd25zIGRlZmluaXRpb24gb2YgR01QTFMgZXh0ZW5zaW9ucy48 YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSBjb21tZW50cyBvbiB0aGUgYWJvdmUgcmVxdWlyZW1lbnRz IGFzIGl0IHJlbGF0ZXMgdG8gdGhpczxicj4NCmRyYWZ0LCBwbGVhc2Ugc2VuZCB5b3UgY29tbWVu dHMgdG8gdGhlIE1QTFMgV0cgbGlzdC4gSWYgeW91IGhhdmU8YnI+DQpjb21tZW50cyBvbiB0aGUg cHJvcG9zZWQgbWVjaGFuaXNtLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZTxicj4N CmNjYW1wIFdHIGxpc3QuPGJyPg0KPGJyPg0KTVBMUyBhbmQgQ0NBTVAgd29ya2luZyBncm91cCBj by1jaGFpcnM8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5j b208YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmljc3NvbiBJbmMgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAgNzE3IDUyIDEzPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOys0NiA3 NjcgNzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPg0K --=_alternative 0036B1BE482578E6_=-- From jsmith4112003@yahoo.co.uk Mon Aug 8 06:06:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955F521F8726 for ; Mon, 8 Aug 2011 06:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbPdpDFlVDt9 for ; Mon, 8 Aug 2011 06:06:11 -0700 (PDT) Received: from nm9-vm0.bullet.mail.ird.yahoo.com (nm9-vm0.bullet.mail.ird.yahoo.com [77.238.189.197]) by ietfa.amsl.com (Postfix) with SMTP id 27E1521F86AE for ; Mon, 8 Aug 2011 06:06:10 -0700 (PDT) Received: from [77.238.189.53] by nm9.bullet.mail.ird.yahoo.com with NNFMP; 08 Aug 2011 13:06:33 -0000 Received: from [212.82.108.238] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 08 Aug 2011 13:06:33 -0000 Received: from [127.0.0.1] by omp1003.mail.ird.yahoo.com with NNFMP; 08 Aug 2011 13:06:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 943364.95032.bm@omp1003.mail.ird.yahoo.com Received: (qmail 43168 invoked by uid 60001); 8 Aug 2011 13:06:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1312808793; bh=+vEAvSkXGQ8Z0f530EOM78LK0SEB66q+CUMP8nqeIxA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cKSkCvftS5VAATI7/5BaAXs1/fjI2h//G227qaZ3pM8OQo7SlXi2URsl2neK60iJ+pJaIEJzSEgfm7AGLL7b52tmcqHgDh/LN2E2F3U+qWRt+52aZJZAlN9SNbrhHcJgMrcbVLFDYIImklxAD9n7PukyyiDoHTNDXvfIrW2s/zc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bGBW3EbLZzdbKv4Io98pkR8DmR8TNz4LmIzRowD3iZ40BqDH3ZyXDo8i8jxK41iwzPN3T5URnbAdxnGIFlpc6zb1OVruWD8OZmTVWQDlUDPvxmlO8Gal6C0nXNRjbUYaTmiwoVFOq+nD7Cs8qEXc9Xz24EHWH+jTJ5xnFWVfRwU=; X-YMail-OSG: l.SxQqAVM1nSStED1bgn7usGo8KKE5FmYglhEY_gK.kW.DJ _7p6QXriv.txOC.quVJJKfGZlMrgLP2LNJIjsxmIGoPq.yTeRyko7DryQPBe 6OivtDsfKgBT4qAfj2BdYt7MMnpj0IFXZ4l8t3FNYuwq7oHfTDpLFzMuCgcm zbZNL7M.SzZOOx5Xh97DatmluU8TJAHK0EBgZConRpCMhvjnqZ68mcoQA7la P593Gl6LonrT0IfP_q1FoyoXM0PsCbKDiKQCcznFapf4HRiUYQCBMPkmUPAB TipJnm.feuPTHjKfwAYnrq4yuFz.qNBZ6liG1bKANyR_HNV4gkejxJV4vlaA uY5CGKl6RGFd3IEfR_kAkWCV10Ii590zT2UzQIi42HmFP0TPbrg.zvmPJanv Z0hEysQYumjR7mEfUFYu4sCvOaPU- Received: from [122.179.55.105] by web29812.mail.ird.yahoo.com via HTTP; Mon, 08 Aug 2011 14:06:33 BST X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.113.313619 References: <4E3C2D10.1030109@pi.nu> Message-ID: <1312808793.38082.YahooMailRC@web29812.mail.ird.yahoo.com> Date: Mon, 8 Aug 2011 14:06:33 +0100 (BST) From: John Smith To: Loa Andersson , ccamp@ietf.org, "mpls@ietf.org" In-Reply-To: <4E3C2D10.1030109@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lizhong.jin@zte.com.cn, manav.bhatia@alcatel-lucent.com Subject: Re: [mpls] requirements on establishing an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:06:11 -0000 Hi,=0A=0AIs this related to the bi-directional LSP draft that was presented= in Quebec?=0A=0Ahttp://tools.ietf.org/html/draft-bhatia-mpls-rsvp-te-bidir= ectional-lsp-01=0A=0AThe above draft discusses FRR that seems to be missing= from the ccamp wg draft?=0A=0AJohn=0A=0A=0A----- Original Message ----=0AF= rom: Loa Andersson =0ATo: ccamp@ietf.org; "mpls@ietf.org" =0ASent: Fri, 5 August, 2011 23:19:04=0ASubject: [mpls] requiremen= ts on establishing an associated bi-directional LSP=0A=0ACCAMP and MPLS wor= king groups,=0A=0AThe CCAMP working group has a working group document=0Adr= aft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01.=0A=0AThe document spec= ifies a way of establishing an associated=0Abi-directional LSP based on sin= gle ended signaling as well=0Aas to associate two unidirectional LSPs. Ther= e is a requirement=0Ain RFC5654:=0A=0A 50 The MPLS-TP control plane MUS= T support establishing all the=0A connectivity patterns defined for = the MPLS-TP data plane (i.e.,=0A unidirectional P2P, associated bidi= rectional P2P, co-routed=0A bidirectional P2P, unidirectional P2MP) = including configuration=0A of protection functions and any associate= d maintenance=0A functions.=0A=0AThe MPLS working group owns the req= uirements for transport LSPs, while=0ACCAMP owns definition of GMPLS extens= ions.=0A=0AIf you have comments on the above requirements as it relates to = this=0Adraft, please send you comments to the MPLS WG list. If you have=0Ac= omments on the proposed mechanism, please send your comments to the=0Accamp= WG list.=0A=0AMPLS and CCAMP working group co-chairs=0A=0A-- =0A=0ALoa And= ersson email: loa.andersson@ericsson.com=0ASr Strat= egy and Standards Manager loa@pi.nu=0AEricsson Inc = phone: +46 10 717 52 13=0A = +46 767 72 92 13=0A_______________________________________________= =0Ampls mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/mpls=0A From ben@niven-jenkins.co.uk Mon Aug 8 07:42:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6530921F8B04; Mon, 8 Aug 2011 07:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFuneFrphRZ3; Mon, 8 Aug 2011 07:42:45 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5294121F8B00; Mon, 8 Aug 2011 07:42:44 -0700 (PDT) Received: from dhcp184-48-6-140.sdmg.snd.wayport.net ([184.48.6.140]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QqR2m-0005ep-Io; Mon, 08 Aug 2011 15:43:05 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 8 Aug 2011 15:42:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: zhang.fei3@zte.com.cn X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "mpls@ietf.org" , ccamp@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] requirements on establishing an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 14:42:46 -0000 Fei, On 8 Aug 2011, at 10:57, zhang.fei3@zte.com.cn wrote: > Hi all=20 >=20 > I gave two presentations in the past IETF81 meeting, one is in the = MPLS WG discussing the requirements, and the other is in CCAMP session = discussing the solution.=20 >=20 > the presentation materials for reference are here.=20 > http://tools.ietf.org/wg/mpls/agenda=20 > http://tools.ietf.org/wg/ccamp/agenda=20 >=20 > The requirement (R50 in RFC5654) did not specify the exact solution, = and the definition of associated bidirectional transport path said that = "The forward and backward directions are setup, monitored, and protected = independently ".=20 I was one of the folks that pushed for inclusion of associated = bi-directional paths in RFC5654 and what I was thinking at the time was = something similar to PWs - i.e that although both ingress & egress end = points are on the same nodes the path between the ingress and egress may = differ for each direction. "independently" in the text of RFC5654 is not meant to suggest that = single sided provisioning of associated bi-directional paths is = unacceptable, it just means that you cannot assume that you can = provision the forward & backward directions of the path simultaneously = in each node (as the forward & backward directions may not traverse the = same nodes). The same is true for monitoring & protection. HTH Ben =20 >=20 > My opinion about the requirement and definition is listed below,=20 >=20 > (1) what is the indication of independence? It means that one direcion = can not tigger the establishment of the other direction? Or It just = means that there are two signaling procedures? Since MS-PW is a kind of = associated bidirectional transport path, I tend to interpretate the = definition as the second case =20 >=20 > As to the solution:=20 >=20 > (2) Since MPLS-TP MUST support asymmetric bandwith LSPs (R14), = consider the following topology:=20 > 100M 100M=20 > A----------D-------B=20 > \ 50M / 100M=20 > 100M \60M /100M=20 > \ /=20 > \ C/=20 > One bidirectional LSP with 80M symmetric bandwidth needs to be set up = between node A and B, the unreserved bandwidth on the links are = descripted.=20 >=20 > the path along [A-D-B] can not meet the requirement for the unreverved = bandwidth on link[D->A] is 50M. But the combination of [A->D->B] and = [B->D->C->A] can=20 > meet the requirement well.=20 >=20 > In this case, the single sided provisioning will be more convenient in = MPLS enviroment.=20 >=20 > Hope to hear more comments or suggestions from WG=20 >=20 > Best regards=20 >=20 > Fei=20 >=20 >=20 > Loa Andersson =20 > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > 2011-08-06 01:49 >=20 > =CA=D5=BC=FE=C8=CB > ccamp@ietf.org, "mpls@ietf.org" > =B3=AD=CB=CD > =D6=F7=CC=E2 > [mpls] requirements on establishing an associated bi-directional LSP >=20 >=20 >=20 >=20 >=20 > CCAMP and MPLS working groups, >=20 > The CCAMP working group has a working group document > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01. >=20 > The document specifies a way of establishing an associated > bi-directional LSP based on single ended signaling as well > as to associate two unidirectional LSPs. There is a requirement > in RFC5654: >=20 > 50 The MPLS-TP control plane MUST support establishing all the > connectivity patterns defined for the MPLS-TP data plane = (i.e., > unidirectional P2P, associated bidirectional P2P, co-routed > bidirectional P2P, unidirectional P2MP) including = configuration > of protection functions and any associated maintenance > functions. >=20 > The MPLS working group owns the requirements for transport LSPs, while > CCAMP owns definition of GMPLS extensions. >=20 > If you have comments on the above requirements as it relates to this > draft, please send you comments to the MPLS WG list. If you have > comments on the proposed mechanism, please send your comments to the > ccamp WG list. >=20 > MPLS and CCAMP working group co-chairs >=20 > --=20 >=20 >=20 > Loa Andersson email: = loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Mon Aug 8 11:24:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB60521F8B7A for ; Mon, 8 Aug 2011 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rbkibdubw7a for ; Mon, 8 Aug 2011 11:24:24 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 045BD21F8ADE for ; Mon, 8 Aug 2011 11:24:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTkAp8kczpHoK+tb8dfmO0y5lyB6xIgVA@postini.com; Mon, 08 Aug 2011 11:24:50 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Aug 2011 09:17:38 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 8 Aug 2011 12:17:37 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Mon, 8 Aug 2011 12:17:36 -0400 Thread-Topic: MPLS WG last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: AcvDrJhCOwxbl7gbTh6wLaZt8CCDPAUkW1CwH2oDD2A= Message-ID: 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 Subject: [mpls] MPLS WG last call on draft-ietf-mpls-ldp-ipv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 18:24:24 -0000 Working Group, This is to start a two week working group last call on draft-ietf-mpls-ldp-ipv6 ("Updates to LDP for IPv6 "). Please send comments to the mpls@ietf.org mailing list. This working group last call ends on Monday August 22nd.=20 George, Loa and Ross MPLS WG co-chairs From zhang.fei3@zte.com.cn Mon Aug 8 17:21:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15721F862F; Mon, 8 Aug 2011 17:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.197 X-Spam-Level: X-Spam-Status: No, score=-99.197 tagged_above=-999 required=5 tests=[AWL=-1.562, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtSEUHYZ8Xst; Mon, 8 Aug 2011 17:21:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7D11A21F8546; Mon, 8 Aug 2011 17:21:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131322268279496; Tue, 9 Aug 2011 08:11:11 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.4675437340; Tue, 9 Aug 2011 08:21:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p790LYcU017055; Tue, 9 Aug 2011 08:21:34 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <1312808793.38082.YahooMailRC@web29812.mail.ird.yahoo.com> To: John Smith MIME-Version: 1.0 X-KeepSent: D88DF7F3:F03DAA6A-482578E7:0001B8B7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 9 Aug 2011 08:21:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-09 08:21:34, Serialize complete at 2011-08-09 08:21:34 Content-Type: multipart/alternative; boundary="=_alternative 0001F450482578E7_=" X-MAIL: mse01.zte.com.cn p790LYcU017055 Cc: "mpls@ietf.org" , ccamp@ietf.org, ccamp-bounces@ietf.org Subject: Re: [mpls] [CCAMP] requirements on establishing an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 00:21:22 -0000 This is a multipart message in MIME format. --=_alternative 0001F450482578E7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSm9obg0KDQpGb3IgY2xhcmlmaWNhdGlvbg0KDQpJdCBpcyBhYm91dCB0aGUgcmVxdWlyZW1l bnQgYW5kIHNvbHV0aW9uIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCg0KQmVsb3cg aXMgdGhlIGxpbmsNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2Ft cC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDENCg0KVGhhbmtzDQoNCkZlaQ0K DQoNCg0KSm9obiBTbWl0aCA8anNtaXRoNDExMjAwM0B5YWhvby5jby51az4gDQq3orz+yMs6ICBj Y2FtcC1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA4LTA4IDIxOjA2DQoNCsrVvP7Iyw0KTG9hIEFu ZGVyc3NvbiA8bG9hQHBpLm51PiwgY2NhbXBAaWV0Zi5vcmcsICJtcGxzQGlldGYub3JnIiA8bXBs c0BpZXRmLm9yZz4NCrOty80NCmxpemhvbmcuamluQHp0ZS5jb20uY24sIG1hbmF2LmJoYXRpYUBh bGNhdGVsLWx1Y2VudC5jb20sIA0KZnJlZGVyaWMuam91bmF5QG9yYW5nZS1mdGdyb3VwLmNvbQ0K 1vfM4g0KUmU6IFtDQ0FNUF0gW21wbHNdIHJlcXVpcmVtZW50cyBvbiBlc3RhYmxpc2hpbmcgYW4g YXNzb2NpYXRlZCANCmJpLWRpcmVjdGlvbmFsIExTUA0KDQoNCg0KDQoNCg0KSGksDQoNCklzIHRo aXMgcmVsYXRlZCB0byB0aGUgYmktZGlyZWN0aW9uYWwgTFNQIGRyYWZ0IHRoYXQgd2FzIHByZXNl bnRlZCBpbiANClF1ZWJlYz8NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhh dGlhLW1wbHMtcnN2cC10ZS1iaWRpcmVjdGlvbmFsLWxzcC0wMQ0KDQpUaGUgYWJvdmUgZHJhZnQg ZGlzY3Vzc2VzIEZSUiB0aGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgZnJvbSB0aGUgY2NhbXAgd2cg DQpkcmFmdD8NCg0KSm9obg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLQ0KRnJvbTog TG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0KVG86IGNjYW1wQGlldGYub3JnOyAibXBsc0BpZXRm Lm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQpTZW50OiBGcmksIDUgQXVndXN0LCAyMDExIDIzOjE5OjA0 DQpTdWJqZWN0OiBbbXBsc10gcmVxdWlyZW1lbnRzIG9uIGVzdGFibGlzaGluZyBhbiBhc3NvY2lh dGVkIGJpLWRpcmVjdGlvbmFsIA0KTFNQDQoNCkNDQU1QIGFuZCBNUExTIHdvcmtpbmcgZ3JvdXBz LA0KDQpUaGUgQ0NBTVAgd29ya2luZyBncm91cCBoYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 DQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMS4N Cg0KVGhlIGRvY3VtZW50IHNwZWNpZmllcyBhIHdheSBvZiBlc3RhYmxpc2hpbmcgYW4gYXNzb2Np YXRlZA0KYmktZGlyZWN0aW9uYWwgTFNQIGJhc2VkIG9uIHNpbmdsZSBlbmRlZCBzaWduYWxpbmcg YXMgd2VsbA0KYXMgdG8gYXNzb2NpYXRlIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzLiBUaGVyZSBp cyBhIHJlcXVpcmVtZW50DQppbiBSRkM1NjU0Og0KDQogICAgNTAgIFRoZSBNUExTLVRQIGNvbnRy b2wgcGxhbmUgTVVTVCBzdXBwb3J0IGVzdGFibGlzaGluZyBhbGwgdGhlDQogICAgICAgIGNvbm5l Y3Rpdml0eSBwYXR0ZXJucyBkZWZpbmVkIGZvciB0aGUgTVBMUy1UUCBkYXRhIHBsYW5lIChpLmUu LA0KICAgICAgICB1bmlkaXJlY3Rpb25hbCBQMlAsIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBQ MlAsIGNvLXJvdXRlZA0KICAgICAgICBiaWRpcmVjdGlvbmFsIFAyUCwgdW5pZGlyZWN0aW9uYWwg UDJNUCkgaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgb2YgcHJvdGVjdGlvbiBmdW5j dGlvbnMgYW5kIGFueSBhc3NvY2lhdGVkIG1haW50ZW5hbmNlDQogICAgICAgIGZ1bmN0aW9ucy4N Cg0KVGhlIE1QTFMgd29ya2luZyBncm91cCBvd25zIHRoZSByZXF1aXJlbWVudHMgZm9yIHRyYW5z cG9ydCBMU1BzLCB3aGlsZQ0KQ0NBTVAgb3ducyBkZWZpbml0aW9uIG9mIEdNUExTIGV4dGVuc2lv bnMuDQoNCklmIHlvdSBoYXZlIGNvbW1lbnRzIG9uIHRoZSBhYm92ZSByZXF1aXJlbWVudHMgYXMg aXQgcmVsYXRlcyB0byB0aGlzDQpkcmFmdCwgcGxlYXNlIHNlbmQgeW91IGNvbW1lbnRzIHRvIHRo ZSBNUExTIFdHIGxpc3QuIElmIHlvdSBoYXZlDQpjb21tZW50cyBvbiB0aGUgcHJvcG9zZWQgbWVj aGFuaXNtLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQ0KY2NhbXAgV0cgbGlzdC4N Cg0KTVBMUyBhbmQgQ0NBTVAgd29ya2luZyBncm91cCBjby1jaGFpcnMNCg0KLS0gDQoNCkxvYSBB bmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJp Y3Nzb24uY29tDQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBs b2FAcGkubnUNCkVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0 NiAxMCA3MTcgNTIgMTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0K DQo= --=_alternative 0001F450482578E7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEpvaG48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZvciBjbGFyaWZpY2F0aW9uPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCBpcyBhYm91 dCB0aGUgcmVxdWlyZW1lbnQgYW5kIHNvbHV0aW9uDQpvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgTFNQPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5C ZWxvdyBpcyB0aGUgbGluazwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkpvaG4gU21pdGggJmx0O2pzbWl0aDQxMTIwMDNAeWFo b28uY28udWsmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj63orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wOC0wOCAyMTowNjwvZm9udD4NCjx0ZCB3 aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Mb2EgQW5kZXJzc29u ICZsdDtsb2FAcGkubnUmZ3Q7LCBjY2FtcEBpZXRmLm9yZywNCiZxdW90O21wbHNAaWV0Zi5vcmcm cXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5saXpob25nLmpp bkB6dGUuY29tLmNuLCBtYW5hdi5iaGF0aWFAYWxjYXRlbC1sdWNlbnQuY29tLA0KZnJlZGVyaWMu am91bmF5QG9yYW5nZS1mdGdyb3VwLmNvbTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0g W21wbHNdIHJlcXVpcmVtZW50cyBvbiBlc3RhYmxpc2hpbmcNCmFuIGFzc29jaWF0ZWQgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmktZGlyZWN0aW9uYWwgTFNQPC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSw8YnI+DQo8YnI+DQpJ cyB0aGlzIHJlbGF0ZWQgdG8gdGhlIGJpLWRpcmVjdGlvbmFsIExTUCBkcmFmdCB0aGF0IHdhcyBw cmVzZW50ZWQgaW4gUXVlYmVjPzxicj4NCjxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJoYXRpYS1tcGxzLXJzdnAtdGUtYmlkaXJlY3Rpb25hbC1sc3AtMDE8YnI+DQo8YnI+ DQpUaGUgYWJvdmUgZHJhZnQgZGlzY3Vzc2VzIEZSUiB0aGF0IHNlZW1zIHRvIGJlIG1pc3Npbmcg ZnJvbSB0aGUgY2NhbXAgd2cNCmRyYWZ0Pzxicj4NCjxicj4NCkpvaG48YnI+DQo8YnI+DQo8YnI+ DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS08YnI+DQpGcm9tOiBMb2EgQW5kZXJzc29uICZs dDtsb2FAcGkubnUmZ3Q7PGJyPg0KVG86IGNjYW1wQGlldGYub3JnOyAmcXVvdDttcGxzQGlldGYu b3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4NClNlbnQ6IEZyaSwgNSBBdWd1c3Qs IDIwMTEgMjM6MTk6MDQ8YnI+DQpTdWJqZWN0OiBbbXBsc10gcmVxdWlyZW1lbnRzIG9uIGVzdGFi bGlzaGluZyBhbiBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsDQpMU1A8YnI+DQo8YnI+DQpDQ0FN UCBhbmQgTVBMUyB3b3JraW5nIGdyb3Vwcyw8YnI+DQo8YnI+DQpUaGUgQ0NBTVAgd29ya2luZyBn cm91cCBoYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50PGJyPg0KZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDEuPGJyPg0KPGJyPg0KVGhlIGRvY3Vt ZW50IHNwZWNpZmllcyBhIHdheSBvZiBlc3RhYmxpc2hpbmcgYW4gYXNzb2NpYXRlZDxicj4NCmJp LWRpcmVjdGlvbmFsIExTUCBiYXNlZCBvbiBzaW5nbGUgZW5kZWQgc2lnbmFsaW5nIGFzIHdlbGw8 YnI+DQphcyB0byBhc3NvY2lhdGUgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMuIFRoZXJlIGlzIGEg cmVxdWlyZW1lbnQ8YnI+DQppbiBSRkM1NjU0Ojxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7NTAg Jm5ic3A7VGhlIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgZXN0YWJsaXNoaW5n DQphbGwgdGhlPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nvbm5lY3Rpdml0eSBw YXR0ZXJucyBkZWZpbmVkIGZvciB0aGUgTVBMUy1UUA0KZGF0YSBwbGFuZSAoaS5lLiw8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5pZGlyZWN0aW9uYWwgUDJQLCBhc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwNClAyUCwgY28tcm91dGVkPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2JpZGlyZWN0aW9uYWwgUDJQLCB1bmlkaXJlY3Rpb25hbCBQMk1QKSBpbmNsdWRpbmcN CmNvbmZpZ3VyYXRpb248YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2YgcHJvdGVj dGlvbiBmdW5jdGlvbnMgYW5kIGFueSBhc3NvY2lhdGVkDQptYWludGVuYW5jZTxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmdW5jdGlvbnMuPGJyPg0KPGJyPg0KVGhlIE1QTFMgd29y a2luZyBncm91cCBvd25zIHRoZSByZXF1aXJlbWVudHMgZm9yIHRyYW5zcG9ydCBMU1BzLCB3aGls ZTxicj4NCkNDQU1QIG93bnMgZGVmaW5pdGlvbiBvZiBHTVBMUyBleHRlbnNpb25zLjxicj4NCjxi cj4NCklmIHlvdSBoYXZlIGNvbW1lbnRzIG9uIHRoZSBhYm92ZSByZXF1aXJlbWVudHMgYXMgaXQg cmVsYXRlcyB0byB0aGlzPGJyPg0KZHJhZnQsIHBsZWFzZSBzZW5kIHlvdSBjb21tZW50cyB0byB0 aGUgTVBMUyBXRyBsaXN0LiBJZiB5b3UgaGF2ZTxicj4NCmNvbW1lbnRzIG9uIHRoZSBwcm9wb3Nl ZCBtZWNoYW5pc20sIHBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlPGJyPg0KY2NhbXAg V0cgbGlzdC48YnI+DQo8YnI+DQpNUExTIGFuZCBDQ0FNUCB3b3JraW5nIGdyb3VwIGNvLWNoYWly czxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7IGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTxicj4NClNyIFN0 cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2xvYUBwaS5udTxicj4NCkVyaWNzc29uIEluYyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgKzQ2IDc2NyA3MiA5MiAxMzxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBt YWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FN UEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0001F450482578E7_=-- From zhang.fei3@zte.com.cn Mon Aug 8 17:45:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5421F8B7C; Mon, 8 Aug 2011 17:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.806 X-Spam-Level: X-Spam-Status: No, score=-98.806 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsMH1GQPuup5; Mon, 8 Aug 2011 17:45:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE121F8B7B; Mon, 8 Aug 2011 17:45:09 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322257607178; Tue, 9 Aug 2011 08:35:03 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 85946.3927260546; Tue, 9 Aug 2011 08:45:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p790jPHG033462; Tue, 9 Aug 2011 08:45:25 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Ben Niven-Jenkins MIME-Version: 1.0 X-KeepSent: DA776520:2C21D86E-482578E7:0002FA50; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 9 Aug 2011 08:45:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-09 08:45:26, Serialize complete at 2011-08-09 08:45:26 Content-Type: multipart/alternative; boundary="=_alternative 00042373482578E7_=" X-MAIL: mse01.zte.com.cn p790jPHG033462 Cc: "mpls@ietf.org" , ccamp@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] requirements on establishing an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 00:45:11 -0000 This is a multipart message in MIME format. --=_alternative 00042373482578E7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQmVuDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIGlkZWEsIHRoaXMgd2lsbCBoZWxwIHVz IHB1c2ggdGhlIHJlbGF0ZWQgd29yayBtb3JlIA0KcXVpY2tseS4NCg0KQi5SLiA6LSkNCg0KRmVp DQoNCg0KDQpCZW4gTml2ZW4tSmVua2lucyA8YmVuQG5pdmVuLWplbmtpbnMuY28udWs+IA0KMjAx MS0wOC0wOCAyMjo0Mg0KDQrK1bz+yMsNCnpoYW5nLmZlaTNAenRlLmNvbS5jbg0Ks63LzQ0KTG9h IEFuZGVyc3NvbiA8bG9hQHBpLm51PiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPiwg DQpjY2FtcEBpZXRmLm9yZywgbXBscy1ib3VuY2VzQGlldGYub3JnDQrW98ziDQpSZTogW21wbHNd IHJlcXVpcmVtZW50cyBvbiBlc3RhYmxpc2hpbmcgYW4gYXNzb2NpYXRlZCBiaS1kaXJlY3Rpb25h bCBMU1ANCg0KDQoNCg0KDQoNCkZlaSwNCg0KT24gOCBBdWcgMjAxMSwgYXQgMTA6NTcsIHpoYW5n LmZlaTNAenRlLmNvbS5jbiB3cm90ZToNCj4gSGkgYWxsIA0KPiANCj4gSSBnYXZlIHR3byBwcmVz ZW50YXRpb25zIGluIHRoZSBwYXN0IElFVEY4MSBtZWV0aW5nLCBvbmUgaXMgaW4gdGhlIE1QTFMg DQpXRyBkaXNjdXNzaW5nIHRoZSByZXF1aXJlbWVudHMsIGFuZCB0aGUgb3RoZXIgaXMgaW4gQ0NB TVAgc2Vzc2lvbiANCmRpc2N1c3NpbmcgdGhlIHNvbHV0aW9uLiANCj4gDQo+IHRoZSBwcmVzZW50 YXRpb24gbWF0ZXJpYWxzIGZvciByZWZlcmVuY2UgYXJlIGhlcmUuIA0KPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvd2cvbXBscy9hZ2VuZGEgDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jY2Ft cC9hZ2VuZGEgDQo+IA0KPiBUaGUgcmVxdWlyZW1lbnQgKFI1MCBpbiBSRkM1NjU0KSBkaWQgbm90 IHNwZWNpZnkgdGhlIGV4YWN0IHNvbHV0aW9uLCBhbmQgDQp0aGUgZGVmaW5pdGlvbiBvZiBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGggc2FpZCB0aGF0ICJUaGUgDQpmb3J3 YXJkIGFuZCBiYWNrd2FyZCBkaXJlY3Rpb25zIGFyZSBzZXR1cCwgbW9uaXRvcmVkLCBhbmQgcHJv dGVjdGVkIA0KaW5kZXBlbmRlbnRseSAiLiANCg0KSSB3YXMgb25lIG9mIHRoZSBmb2xrcyB0aGF0 IHB1c2hlZCBmb3IgaW5jbHVzaW9uIG9mIGFzc29jaWF0ZWQgDQpiaS1kaXJlY3Rpb25hbCBwYXRo cyBpbiBSRkM1NjU0IGFuZCB3aGF0IEkgd2FzIHRoaW5raW5nIGF0IHRoZSB0aW1lIHdhcyANCnNv bWV0aGluZyBzaW1pbGFyIHRvIFBXcyAtIGkuZSB0aGF0IGFsdGhvdWdoIGJvdGggaW5ncmVzcyAm IGVncmVzcyBlbmQgDQpwb2ludHMgYXJlIG9uIHRoZSBzYW1lIG5vZGVzIHRoZSBwYXRoIGJldHdl ZW4gdGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBtYXkgDQpkaWZmZXIgZm9yIGVhY2ggZGlyZWN0aW9u Lg0KDQoiaW5kZXBlbmRlbnRseSIgaW4gdGhlIHRleHQgb2YgUkZDNTY1NCBpcyBub3QgbWVhbnQg dG8gc3VnZ2VzdCB0aGF0IHNpbmdsZSANCnNpZGVkIHByb3Zpc2lvbmluZyBvZiBhc3NvY2lhdGVk IGJpLWRpcmVjdGlvbmFsIHBhdGhzIGlzIHVuYWNjZXB0YWJsZSwgaXQgDQpqdXN0IG1lYW5zIHRo YXQgeW91IGNhbm5vdCBhc3N1bWUgdGhhdCB5b3UgY2FuIHByb3Zpc2lvbiB0aGUgZm9yd2FyZCAm IA0KYmFja3dhcmQgZGlyZWN0aW9ucyBvZiB0aGUgcGF0aCBzaW11bHRhbmVvdXNseSBpbiBlYWNo IG5vZGUgKGFzIHRoZSANCmZvcndhcmQgJiBiYWNrd2FyZCBkaXJlY3Rpb25zIG1heSBub3QgdHJh dmVyc2UgdGhlIHNhbWUgbm9kZXMpLiBUaGUgc2FtZSANCmlzIHRydWUgZm9yIG1vbml0b3Jpbmcg JiBwcm90ZWN0aW9uLg0KDQpIVEgNCkJlbg0KIA0KPiANCj4gTXkgb3BpbmlvbiBhYm91dCB0aGUg cmVxdWlyZW1lbnQgYW5kIGRlZmluaXRpb24gaXMgbGlzdGVkIGJlbG93LCANCj4gDQo+ICgxKSB3 aGF0IGlzIHRoZSBpbmRpY2F0aW9uIG9mIGluZGVwZW5kZW5jZT8gSXQgbWVhbnMgdGhhdCBvbmUg ZGlyZWNpb24gDQpjYW4gbm90IHRpZ2dlciB0aGUgZXN0YWJsaXNobWVudCBvZiB0aGUgb3RoZXIg ZGlyZWN0aW9uPyBPciBJdCBqdXN0IG1lYW5zIA0KdGhhdCB0aGVyZSBhcmUgdHdvIHNpZ25hbGlu ZyBwcm9jZWR1cmVzPyBTaW5jZSBNUy1QVyBpcyBhIGtpbmQgb2YgDQphc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGgsIEkgdGVuZCB0byBpbnRlcnByZXRhdGUgdGhlIA0KZGVm aW5pdGlvbiBhcyB0aGUgc2Vjb25kIGNhc2UgDQo+IA0KPiBBcyB0byB0aGUgc29sdXRpb246IA0K PiANCj4gKDIpIFNpbmNlIE1QTFMtVFAgTVVTVCBzdXBwb3J0IGFzeW1tZXRyaWMgYmFuZHdpdGgg TFNQcyAoUjE0KSwgY29uc2lkZXIgDQp0aGUgZm9sbG93aW5nIHRvcG9sb2d5OiANCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxMDBNICAgICAgMTAwTSANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBLS0tLS0tLS0tLUQtLS0tLS0tQiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXCA1ME0gICAgLyAgMTAwTSANCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAxMDBNIFw2ME0gICAvMTAwTSANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBcICAgIC8gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgQy8gDQo+IE9u ZSBiaWRpcmVjdGlvbmFsIExTUCB3aXRoIDgwTSBzeW1tZXRyaWMgYmFuZHdpZHRoIG5lZWRzIHRv IGJlIHNldCB1cCANCmJldHdlZW4gbm9kZSBBIGFuZCBCLCB0aGUgdW5yZXNlcnZlZCBiYW5kd2lk dGggb24gdGhlIGxpbmtzIGFyZSANCmRlc2NyaXB0ZWQuIA0KPiANCj4gdGhlIHBhdGggYWxvbmcg W0EtRC1CXSBjYW4gbm90IG1lZXQgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUgdW5yZXZlcnZlZCAN CmJhbmR3aWR0aCBvbiBsaW5rW0QtPkFdIGlzIDUwTS4gQnV0IHRoZSBjb21iaW5hdGlvbiBvZiBb QS0+RC0+Ql0gYW5kIA0KW0ItPkQtPkMtPkFdIGNhbiANCj4gbWVldCB0aGUgcmVxdWlyZW1lbnQg d2VsbC4gDQo+IA0KPiBJbiB0aGlzIGNhc2UsIHRoZSBzaW5nbGUgc2lkZWQgcHJvdmlzaW9uaW5n IHdpbGwgYmUgbW9yZSBjb252ZW5pZW50IGluIA0KTVBMUyBlbnZpcm9tZW50LiANCj4gDQo+IEhv cGUgdG8gaGVhciBtb3JlIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGZyb20gV0cgDQo+IA0KPiBC ZXN0IHJlZ2FyZHMgDQo+IA0KPiBGZWkgDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PiANCj4gt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQo+IDIwMTEtMDgtMDYgMDE6 NDkNCj4gDQo+IMrVvP7Iyw0KPiBjY2FtcEBpZXRmLm9yZywgIm1wbHNAaWV0Zi5vcmciIDxtcGxz QGlldGYub3JnPg0KPiCzrcvNDQo+INb3zOINCj4gW21wbHNdIHJlcXVpcmVtZW50cyBvbiBlc3Rh Ymxpc2hpbmcgYW4gYXNzb2NpYXRlZCBiaS1kaXJlY3Rpb25hbCBMU1ANCj4gDQo+IA0KPiANCj4g DQo+IA0KPiBDQ0FNUCBhbmQgTVBMUyB3b3JraW5nIGdyb3VwcywNCj4gDQo+IFRoZSBDQ0FNUCB3 b3JraW5nIGdyb3VwIGhhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gZHJhZnQtaWV0Zi1j Y2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDEuDQo+IA0KPiBUaGUgZG9j dW1lbnQgc3BlY2lmaWVzIGEgd2F5IG9mIGVzdGFibGlzaGluZyBhbiBhc3NvY2lhdGVkDQo+IGJp LWRpcmVjdGlvbmFsIExTUCBiYXNlZCBvbiBzaW5nbGUgZW5kZWQgc2lnbmFsaW5nIGFzIHdlbGwN Cj4gYXMgdG8gYXNzb2NpYXRlIHR3byB1bmlkaXJlY3Rpb25hbCBMU1BzLiBUaGVyZSBpcyBhIHJl cXVpcmVtZW50DQo+IGluIFJGQzU2NTQ6DQo+IA0KPiAgICAgNTAgIFRoZSBNUExTLVRQIGNvbnRy b2wgcGxhbmUgTVVTVCBzdXBwb3J0IGVzdGFibGlzaGluZyBhbGwgdGhlDQo+ICAgICAgICAgY29u bmVjdGl2aXR5IHBhdHRlcm5zIGRlZmluZWQgZm9yIHRoZSBNUExTLVRQIGRhdGEgcGxhbmUgKGku ZS4sDQo+ICAgICAgICAgdW5pZGlyZWN0aW9uYWwgUDJQLCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgUDJQLCBjby1yb3V0ZWQNCj4gICAgICAgICBiaWRpcmVjdGlvbmFsIFAyUCwgdW5pZGlyZWN0 aW9uYWwgUDJNUCkgaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24NCj4gICAgICAgICBvZiBwcm90ZWN0 aW9uIGZ1bmN0aW9ucyBhbmQgYW55IGFzc29jaWF0ZWQgbWFpbnRlbmFuY2UNCj4gICAgICAgICBm dW5jdGlvbnMuDQo+IA0KPiBUaGUgTVBMUyB3b3JraW5nIGdyb3VwIG93bnMgdGhlIHJlcXVpcmVt ZW50cyBmb3IgdHJhbnNwb3J0IExTUHMsIHdoaWxlDQo+IENDQU1QIG93bnMgZGVmaW5pdGlvbiBv ZiBHTVBMUyBleHRlbnNpb25zLg0KPiANCj4gSWYgeW91IGhhdmUgY29tbWVudHMgb24gdGhlIGFi b3ZlIHJlcXVpcmVtZW50cyBhcyBpdCByZWxhdGVzIHRvIHRoaXMNCj4gZHJhZnQsIHBsZWFzZSBz ZW5kIHlvdSBjb21tZW50cyB0byB0aGUgTVBMUyBXRyBsaXN0LiBJZiB5b3UgaGF2ZQ0KPiBjb21t ZW50cyBvbiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRz IHRvIHRoZQ0KPiBjY2FtcCBXRyBsaXN0Lg0KPiANCj4gTVBMUyBhbmQgQ0NBTVAgd29ya2luZyBn cm91cCBjby1jaGFpcnMNCj4gDQo+IC0tIA0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+IFNy IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBF cmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUy IDEzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3 NjcgNzIgOTIgMTMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0K PiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQoNCg0KDQo= --=_alternative 00042373482578E7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEJlbjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciBzaGFyaW5nIHlv dXIgaWRlYSwgdGhpcyB3aWxsDQpoZWxwIHVzIHB1c2ggdGhlIHJlbGF0ZWQgd29yayBtb3JlIHF1 aWNrbHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5C LlIuIDotKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PkJlbiBOaXZlbi1KZW5raW5zICZsdDtiZW5Abml2ZW4tamVua2lucy5jby51ayZndDs8L2I+DQo8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wOC0wOCAyMjo0 MjwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkxvYSBBbmRlcnNzb24g Jmx0O2xvYUBwaS5udSZndDssICZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsNCiZsdDttcGxzQGll dGYub3JnJmd0OywgY2NhbXBAaWV0Zi5vcmcsIG1wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+UmU6IFttcGxzXSByZXF1aXJlbWVudHMgb24gZXN0YWJsaXNoaW5nDQphbiBh c3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExTUDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+RmVpLDxicj4NCjxicj4NCk9uIDggQXVnIDIw MTEsIGF0IDEwOjU3LCB6aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyBIaSBh bGwgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZ2F2ZSB0d28gcHJlc2VudGF0aW9ucyBpbiB0aGUg cGFzdCBJRVRGODEgbWVldGluZywgb25lIGlzIGluIHRoZQ0KTVBMUyBXRyBkaXNjdXNzaW5nIHRo ZSByZXF1aXJlbWVudHMsIGFuZCB0aGUgb3RoZXIgaXMgaW4gQ0NBTVAgc2Vzc2lvbg0KZGlzY3Vz c2luZyB0aGUgc29sdXRpb24uIDxicj4NCiZndDsgPGJyPg0KJmd0OyB0aGUgcHJlc2VudGF0aW9u IG1hdGVyaWFscyBmb3IgcmVmZXJlbmNlIGFyZSBoZXJlLiA8YnI+DQomZ3Q7IGh0dHA6Ly90b29s cy5pZXRmLm9yZy93Zy9tcGxzL2FnZW5kYSA8YnI+DQomZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9y Zy93Zy9jY2FtcC9hZ2VuZGEgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSByZXF1aXJlbWVudCAo UjUwIGluIFJGQzU2NTQpIGRpZCBub3Qgc3BlY2lmeSB0aGUgZXhhY3Qgc29sdXRpb24sDQphbmQg dGhlIGRlZmluaXRpb24gb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRo IHNhaWQgdGhhdA0KJnF1b3Q7VGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkIGRpcmVjdGlvbnMgYXJl IHNldHVwLCBtb25pdG9yZWQsIGFuZCBwcm90ZWN0ZWQNCmluZGVwZW5kZW50bHkgJnF1b3Q7LiA8 YnI+DQo8YnI+DQpJIHdhcyBvbmUgb2YgdGhlIGZvbGtzIHRoYXQgcHVzaGVkIGZvciBpbmNsdXNp b24gb2YgYXNzb2NpYXRlZCBiaS1kaXJlY3Rpb25hbA0KcGF0aHMgaW4gUkZDNTY1NCBhbmQgd2hh dCBJIHdhcyB0aGlua2luZyBhdCB0aGUgdGltZSB3YXMgc29tZXRoaW5nIHNpbWlsYXINCnRvIFBX cyAtIGkuZSB0aGF0IGFsdGhvdWdoIGJvdGggaW5ncmVzcyAmYW1wOyBlZ3Jlc3MgZW5kIHBvaW50 cyBhcmUgb24NCnRoZSBzYW1lIG5vZGVzIHRoZSBwYXRoIGJldHdlZW4gdGhlIGluZ3Jlc3MgYW5k IGVncmVzcyBtYXkgZGlmZmVyIGZvciBlYWNoDQpkaXJlY3Rpb24uPGJyPg0KPGJyPg0KJnF1b3Q7 aW5kZXBlbmRlbnRseSZxdW90OyBpbiB0aGUgdGV4dCBvZiBSRkM1NjU0IGlzIG5vdCBtZWFudCB0 byBzdWdnZXN0DQp0aGF0IHNpbmdsZSBzaWRlZCBwcm92aXNpb25pbmcgb2YgYXNzb2NpYXRlZCBi aS1kaXJlY3Rpb25hbCBwYXRocyBpcyB1bmFjY2VwdGFibGUsDQppdCBqdXN0IG1lYW5zIHRoYXQg eW91IGNhbm5vdCBhc3N1bWUgdGhhdCB5b3UgY2FuIHByb3Zpc2lvbiB0aGUgZm9yd2FyZA0KJmFt cDsgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiB0aGUgcGF0aCBzaW11bHRhbmVvdXNseSBpbiBlYWNo IG5vZGUgKGFzIHRoZQ0KZm9yd2FyZCAmYW1wOyBiYWNrd2FyZCBkaXJlY3Rpb25zIG1heSBub3Qg dHJhdmVyc2UgdGhlIHNhbWUgbm9kZXMpLiBUaGUNCnNhbWUgaXMgdHJ1ZSBmb3IgbW9uaXRvcmlu ZyAmYW1wOyBwcm90ZWN0aW9uLjxicj4NCjxicj4NCkhUSDxicj4NCkJlbjxicj4NCiA8YnI+DQom Z3Q7IDxicj4NCiZndDsgTXkgb3BpbmlvbiBhYm91dCB0aGUgcmVxdWlyZW1lbnQgYW5kIGRlZmlu aXRpb24gaXMgbGlzdGVkIGJlbG93LCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKDEpIHdoYXQgaXMg dGhlIGluZGljYXRpb24gb2YgaW5kZXBlbmRlbmNlPyBJdCBtZWFucyB0aGF0IG9uZSBkaXJlY2lv bg0KY2FuIG5vdCB0aWdnZXIgdGhlIGVzdGFibGlzaG1lbnQgb2YgdGhlIG90aGVyIGRpcmVjdGlv bj8gT3IgSXQganVzdCBtZWFucw0KdGhhdCB0aGVyZSBhcmUgdHdvIHNpZ25hbGluZyBwcm9jZWR1 cmVzPyBTaW5jZSBNUy1QVyBpcyBhIGtpbmQgb2YgYXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25hbCB0 cmFuc3BvcnQgcGF0aCwgSSB0ZW5kIHRvIGludGVycHJldGF0ZSB0aGUgZGVmaW5pdGlvbiBhcw0K dGhlIHNlY29uZCBjYXNlICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgdG8gdGhlIHNv bHV0aW9uOiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKDIpIFNpbmNlIE1QTFMtVFAgTVVTVCBzdXBw b3J0IGFzeW1tZXRyaWMgYmFuZHdpdGggTFNQcyAoUjE0KSwgY29uc2lkZXINCnRoZSBmb2xsb3dp bmcgdG9wb2xvZ3k6IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxMDBNICZuYnNwOyAmbmJzcDsgJm5ic3A7MTAwTQ0KPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtB LS0tLS0tLS0tLUQtLS0tLS0tQiA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcIDUwTSAmbmJzcDsgJm5ic3A7LyAmbmJzcDsxMDBNIDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAxMDBNIFw2ME0gJm5i c3A7IC8xMDBNIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBcICZuYnNwOyAmbmJzcDsvIDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtcIEMv IDxicj4NCiZndDsgT25lIGJpZGlyZWN0aW9uYWwgTFNQIHdpdGggODBNIHN5bW1ldHJpYyBiYW5k d2lkdGggbmVlZHMgdG8gYmUgc2V0DQp1cCBiZXR3ZWVuIG5vZGUgQSBhbmQgQiwgdGhlIHVucmVz ZXJ2ZWQgYmFuZHdpZHRoIG9uIHRoZSBsaW5rcyBhcmUgZGVzY3JpcHRlZC4NCjxicj4NCiZndDsg PGJyPg0KJmd0OyB0aGUgcGF0aCBhbG9uZyBbQS1ELUJdIGNhbiBub3QgbWVldCB0aGUgcmVxdWly ZW1lbnQgZm9yIHRoZSB1bnJldmVydmVkDQpiYW5kd2lkdGggb24gbGlua1tELSZndDtBXSBpcyA1 ME0uIEJ1dCB0aGUgY29tYmluYXRpb24gb2YgW0EtJmd0O0QtJmd0O0JdDQphbmQgW0ItJmd0O0Qt Jmd0O0MtJmd0O0FdIGNhbiA8YnI+DQomZ3Q7IG1lZXQgdGhlIHJlcXVpcmVtZW50IHdlbGwuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBJbiB0aGlzIGNhc2UsIHRoZSBzaW5nbGUgc2lkZWQgcHJvdmlz aW9uaW5nIHdpbGwgYmUgbW9yZSBjb252ZW5pZW50DQppbiBNUExTIGVudmlyb21lbnQuIDxicj4N CiZndDsgPGJyPg0KJmd0OyBIb3BlIHRvIGhlYXIgbW9yZSBjb21tZW50cyBvciBzdWdnZXN0aW9u cyBmcm9tIFdHIDxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEZlaSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBMb2EgQW5kZXJz c29uICZsdDtsb2FAcGkubnUmZ3Q7IDxicj4NCiZndDsgt6K8/sjLOiAmbmJzcDttcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7IDIwMTEtMDgtMDYgMDE6NDk8YnI+DQomZ3Q7IDxicj4NCiZn dDsgytW8/sjLPGJyPg0KJmd0OyBjY2FtcEBpZXRmLm9yZywgJnF1b3Q7bXBsc0BpZXRmLm9yZyZx dW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7INb3zOI8 YnI+DQomZ3Q7IFttcGxzXSByZXF1aXJlbWVudHMgb24gZXN0YWJsaXNoaW5nIGFuIGFzc29jaWF0 ZWQgYmktZGlyZWN0aW9uYWwgTFNQPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ0NBTVAgYW5kIE1QTFMgd29ya2luZyBncm91 cHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBDQ0FNUCB3b3JraW5nIGdyb3VwIGhhcyBhIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQ8YnI+DQomZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAxLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZG9j dW1lbnQgc3BlY2lmaWVzIGEgd2F5IG9mIGVzdGFibGlzaGluZyBhbiBhc3NvY2lhdGVkPGJyPg0K Jmd0OyBiaS1kaXJlY3Rpb25hbCBMU1AgYmFzZWQgb24gc2luZ2xlIGVuZGVkIHNpZ25hbGluZyBh cyB3ZWxsPGJyPg0KJmd0OyBhcyB0byBhc3NvY2lhdGUgdHdvIHVuaWRpcmVjdGlvbmFsIExTUHMu IFRoZXJlIGlzIGEgcmVxdWlyZW1lbnQ8YnI+DQomZ3Q7IGluIFJGQzU2NTQ6PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgNTAgJm5ic3A7VGhlIE1QTFMtVFAgY29udHJvbCBwbGFu ZSBNVVNUIHN1cHBvcnQgZXN0YWJsaXNoaW5nDQphbGwgdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgY29ubmVjdGl2aXR5IHBhdHRlcm5zIGRlZmluZWQgZm9yIHRoZQ0K TVBMUy1UUCBkYXRhIHBsYW5lIChpLmUuLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHVuaWRpcmVjdGlvbmFsIFAyUCwgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpQMlAs IGNvLXJvdXRlZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJpZGlyZWN0 aW9uYWwgUDJQLCB1bmlkaXJlY3Rpb25hbCBQMk1QKQ0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb248 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvZiBwcm90ZWN0aW9uIGZ1bmN0 aW9ucyBhbmQgYW55IGFzc29jaWF0ZWQNCm1haW50ZW5hbmNlPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZnVuY3Rpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgTVBM UyB3b3JraW5nIGdyb3VwIG93bnMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdHJhbnNwb3J0IExTUHMs IHdoaWxlPGJyPg0KJmd0OyBDQ0FNUCBvd25zIGRlZmluaXRpb24gb2YgR01QTFMgZXh0ZW5zaW9u cy48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgeW91IGhhdmUgY29tbWVudHMgb24gdGhlIGFib3Zl IHJlcXVpcmVtZW50cyBhcyBpdCByZWxhdGVzIHRvIHRoaXM8YnI+DQomZ3Q7IGRyYWZ0LCBwbGVh c2Ugc2VuZCB5b3UgY29tbWVudHMgdG8gdGhlIE1QTFMgV0cgbGlzdC4gSWYgeW91IGhhdmU8YnI+ DQomZ3Q7IGNvbW1lbnRzIG9uIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20sIHBsZWFzZSBzZW5kIHlv dXIgY29tbWVudHMgdG8gdGhlPGJyPg0KJmd0OyBjY2FtcCBXRyBsaXN0Ljxicj4NCiZndDsgPGJy Pg0KJmd0OyBNUExTIGFuZCBDQ0FNUCB3b3JraW5nIGdyb3VwIGNvLWNoYWlyczxicj4NCiZndDsg PGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBMb2EgQW5kZXJz c29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmlj c3Nvbi5jb208YnI+DQomZ3Q7IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtsb2FAcGkubnU8YnI+DQomZ3Q7 IEVyaWNzc29uIEluYyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICs0 NiAxMCA3MTcgNTIgMTM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOys0NiA3NjcgNzIgOTIgMTM8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBtcGxzIG1haWxpbmcg bGlzdDxicj4NCiZndDsgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8YnI+DQo8YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00042373482578E7_=-- From eric.gray@ericsson.com Tue Aug 9 06:01:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B766421F8B6B for ; Tue, 9 Aug 2011 06:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRhpiW9QYJZl for ; Tue, 9 Aug 2011 06:01:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 31B2A21F8B5E for ; Tue, 9 Aug 2011 06:01:19 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p79D1kAr014463 for ; Tue, 9 Aug 2011 08:01:47 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 9 Aug 2011 09:01:41 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 9 Aug 2011 09:01:39 -0400 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxTiPbD+gKW3hbGTQSlR4kHi+3gdgABY8fAAMF5FIA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:01:20 -0000 Forwarding in plain text... ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 05, 2011 12:51 PM To: Pablo Frank Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: RE: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) An application label is a label in which you expect to see BOS set but whic= h isn't, followed by an entropy label which is a non-reserved label with BO= S set. Repeat as necessary. As both Curtis and I have said, in order to process the GAL payload correct= ly, the stack above the GAL should be the same whether or not an entropy la= bel is present. Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 9:02 AM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) So I read the draft but could not see the justification. In fact, I believ= e there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 and placi= ng the GAL above the entropy label, that this makes it "effectively functio= n as an application label". But this is not so. The GAL is an extra label= that would normally sit below the application label. Application labels t= hat are expecting entropy labels are identified in your proposal either exp= licitly in the LFIB or implicitly by the presence of an ELI after the AL. = In either case, it's the label(s) above the GAL that trigger entropy label = handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect the S bi= t of the application/ELI label, and according to the text, would then pop t= he next label, assuming it was an entropy label. Unfortunately, you've now= popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy label bot= h want to be the BOS. You've tried to get around it by relaxing the BOS re= striction on GAL but I think it works much more cleanly if you go the other= way. Instead of saying that Entropy labels always need to be BOS, why not= simply say that they must immediately follow the application/ELI label? T= hat way, the procedures in 4.3 always work trivially. A router that does n= ot understand or expect entropy labels doesn't need to be confused by stran= ge labels following the GAL, and the hardware implementations likely will b= e simpler (and cheaper). It also means I can build hierarchical multipath = LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake wrote: Pablo, At least wrt entropy label, the reasons why it needs to be at the bottom of= stack are detailed in the draft in some detail. The GAL is in exactly the= same place in the stack relative to the labels above it whether or not the= entropy label is used. The fact that the bottom of stack bit is not set i= n the GAL tells the egress that an entropy label is present in the stack af= ter it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Pab= lo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below the GAL? = What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flow (or En= tropy) label just feels out of place. I should only really care about a GA= L if I encounter it as a result of disposing of the labels either because t= hey've been popped or because the TTL has expired. When the PW label gets = terminated and all of a sudden, I encounter a GAL, it seems awkward because= in my mind, I have not finished terminating the PW layer. There is still = this flow label that I need to dispose of... so the hardware has to remembe= r that it saw a GAL and continue processing labels. It seems much cleaner = if we finish dealing with the multipath labels before considering whether i= t's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow label beca= use it allows the option of monitoring individual paths (assuming, of cours= e, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-= 2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.= corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorporated in t= he > fat-pw draft), then most hardware assume ACH is right after GAL. = In > this case how is the HW supposed to examine the ACH channel Type = to > decide how to process the packet? (unless you assume there is one > engine that can process all OAM packet types such as BFD, AIS, PS= C, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to go into t= he draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traff= ic when some other feature, fat-pw or other, puts a label under the PW label. The GAL goes after the PW and before the other labels. A proper multipath distribution will skip any reserved label and use = the rest of the label stack to load balance. This allows spraying acro= ss the entropy space or testing a spacific payload label stack that ha= s yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit is not = set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and should n= ot be since we would halt progress. If the hardware is broken, then the fat-pw label can be omitted but only one path through any multipath would be tested. It would stil= l work for TP, but not work in general. PW does not require TP. The fat-pw work is explicitly done for multipath because multipath is u= sed a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; p= we3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR0= 2.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label. But wi= th > > Entropy label most implementation assume a Entropy label to be = BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL should be Bo= S or > > the Entropy Label? In either case adding GAL would make the pac= ket > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was covered in = WG > email. PW, then GAL, then fat-pw (aka Flow label, which is diffe= rent > from Entropy label in MPLS). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 se= ction > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved label (v= alues > in the range 0..15) [RFC3032], but is otherwise unconstrained = by the > protocol. > > > The flow label below GAL is needed so that all data paths which t= he PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Ro= bert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-v= ccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCC= R02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just add CW a= nd use > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW= ? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware support. T= he > > hardware need not know if the label above the GAL is an MPLS la= bel or > > a PW label, just that the next label is GAL and the label over = it is > > not a SWAP. Unless we are talking about incredibly inflexible = parser > > hardware, like none I've encounted recently, there should be no > > problem noticing a GAL below the POP or PW label and then direc= ting > > the packet to OAM processing. Any remaining labels must be rem= oved > > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW case). = In this > > case TTL-expire would occur where a label swap was called for a= nd a > > GAL would be below the label containing the expired TTL. Since= LDP > > can have transient loops, this avoids having lots of packets se= nt to > > the OAM engine should such a loop occur in a LDP signaled MPLS = PSN. > > > > This yield one way to do OAM with or without CW. A GAL label i= s below > > the label for which action is taken (POP or PW termination) or = below a > > label for which TTL has expired. This method applied to LSP an= d PW. > > > > I think mandating CW would be just as good a solution, but one = that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3= -vccv-2-02.txt > > > > > > Agreed - some operators won't want to use a CW, and on that b= asis I support > > > this draft. > > > > > > Sure, it'll take a while to move away from the router alert l= abel and TTL > > > approaches, but the GAL approach is definitely better than ei= ther of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t think to= solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is to manda= te CW. > > > > > > > > While I am with you, that argument went out the window duri= ng the debates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate the use of= a CW. Hence, > > > > Luca and I came up with this solution that narrows the > > > > scope to 2 modes, one that handles the CW case and one that= doesn't while > > > > still both modes providing predictable OAM capabilities > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]= On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Ma= tthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-p= we3-vccv-2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user deployment = poll I thought, > > > >> =B3 ok the way out of this mess is to migrate towards usi= ng the CW=B2. Then I > > > >> see this proposal and wondered what am I missing. I=B9ve = still not seen the > > > >> light of why adding a fourth type will simplify matters, h= ence in the absence > > > >> of me understanding how this will simplify matter versus c= omplicate things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]= On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-p= we3-vccv-2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons that Yaak= ov has indicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Beh= alf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-p= we3-vccv-2-02.txt > > > >> > > > >> I do not support ! and I can not understand how anyone = can support it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too many alre= ady. > > > >> > > > >> I completely agree with the part that says if there is a C= W then the ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we should u= se a non-PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate the use = of TTL expiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms that have = been widely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse ONLY MP= LS-TP to have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to object as str= ongly. > > > >> However, since I don't think that PWs can be limited in th= is matter (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a limitatio= n is possible. > > > >> > > > >> I would have enthusiastically support this proposal had it= been brought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]= On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > >> > > > >> This email begins a two week poll to help assess if there = is consensus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working gr= oup draft. > > > >> > > > >> Please indicate whether or not you support adoption of thi= s draft, and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient only and= contains > > > >> information which is CONFIDENTIAL and which may be proprie= tary to ECI > > > >> Telecom. If you have received this transmission in error, = please inform us by > > > >> e-mail, phone or fax, and then delete the original and all= copies thereof. > > > >> This e-mail message is intended for the recipient only and= contains > > > >> information which is CONFIDENTIAL and which may be proprie= tary to ECI > > > >> Telecom. If you have received this transmission in error, = please inform us by > > > >> e-mail, phone or fax, and then delete the original and all= copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From internet-drafts@ietf.org Tue Aug 9 06:01:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DAD21F8B76; Tue, 9 Aug 2011 06:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssjcv18tyAfh; Tue, 9 Aug 2011 06:01:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A792B21F8B73; Tue, 9 Aug 2011 06:01:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809130128.8246.64690.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 06:01:28 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-cc-cv-rdi-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:01:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Proactive Connectivity Verification, Continuity Check an= d Remote Defect indication for MPLS Transport Profile Author(s) : Dave Allan George Swallow John Drake Filename : draft-ietf-mpls-tp-cc-cv-rdi-06.txt Pages : 22 Date : 2011-08-09 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors a label switched path for any loss-of- continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies specific extensions to BFD and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection as extended by this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-cc-cv-rdi-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-cc-cv-rdi-06.txt From eric.gray@ericsson.com Tue Aug 9 06:02:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1360721F8A64 for ; Tue, 9 Aug 2011 06:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.93 X-Spam-Level: X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf-GMxR4bzf7 for ; Tue, 9 Aug 2011 06:02:02 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5DC21F850E for ; Tue, 9 Aug 2011 06:01:58 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p79D2P4K010044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Aug 2011 08:02:26 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 9 Aug 2011 09:02:25 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 9 Aug 2011 09:02:24 -0400 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxTri13caS4WohyS8C+g0VuYP+Z9QC5lm5g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:02:04 -0000 Forwarding in plain text... ________________________________ From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 4:28 PM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Thanks John, Some PF> questions/comments below: On Fri, Aug 5, 2011 at 12:50 PM, John E Drake wrote: An application label is a label in which you expect to see BOS set = but which isn't, followed by an entropy label which is a non-reserved label= with BOS set. Repeat as necessary. PF> The term "application label" is used repeatedly through the draft but i= sn't really defined anywhere. I suggest that you and rest of the authors a= dd a definition to the text. The definition that you give above doesn't ma= ke a lot of sense to me since I don't know how to interpret "expect to see = a BOS set but which isn't". I've interpreted application label to refer to= the LSP for which the ingress LSR parsed the payload and generated an entr= opy label. I don't think the GAL (or any other reserved label) falls into= this category. I think you may have to update 4.3 to say something about = how reserved labels are skipped until you find the first non-reserved label= and pop that as your entropy label. Ugh. As both Curtis and I have said, in order to process the GAL payload= correctly, the stack above the GAL should be the same whether or not an en= tropy label is present. PF> I assume that any multi-path capable router's OAM implementation will b= e aware of (and possibly even care about) the entropy labels regardless of = where they are in the label stack. Or are you worried about transit nodes = who's OAM implementation may not be entropy-label aware? Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 9:02 AM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Renni= son@ecitele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption = of draft-nadeau-pwe3-vccv-2-02.txt) So I read the draft but could not see the justification. In fact, = I believe there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 a= nd placing the GAL above the entropy label, that this makes it "effectively= function as an application label". But this is not so. The GAL is an ext= ra label that would normally sit below the application label. Application = labels that are expecting entropy labels are identified in your proposal ei= ther explicitly in the LFIB or implicitly by the presence of an ELI after t= he AL. In either case, it's the label(s) above the GAL that trigger entrop= y label handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect = the S bit of the application/ELI label, and according to the text, would th= en pop the next label, assuming it was an entropy label. Unfortunately, yo= u've now popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy l= abel both want to be the BOS. You've tried to get around it by relaxing th= e BOS restriction on GAL but I think it works much more cleanly if you go t= he other way. Instead of saying that Entropy labels always need to be BOS,= why not simply say that they must immediately follow the application/ELI l= abel? That way, the procedures in 4.3 always work trivially. A router tha= t does not understand or expect entropy labels doesn't need to be confused = by strange labels following the GAL, and the hardware implementations likel= y will be simpler (and cheaper). It also means I can build hierarchical mu= ltipath LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake w= rote: Pablo, At least wrt entropy label, the reasons why it needs to be at the b= ottom of stack are detailed in the draft in some detail. The GAL is in exa= ctly the same place in the stack relative to the labels above it whether or= not the entropy label is used. The fact that the bottom of stack bit is n= ot set in the GAL tells the egress that an entropy label is present in the = stack after it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behal= f Of Pablo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption = of draft-nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below th= e GAL? What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flo= w (or Entropy) label just feels out of place. I should only really care ab= out a GAL if I encounter it as a result of disposing of the labels either b= ecause they've been popped or because the TTL has expired. When the PW lab= el gets terminated and all of a sudden, I encounter a GAL, it seems awkward= because in my mind, I have not finished terminating the PW layer. There i= s still this flow label that I need to dispose of... so the hardware has to= remember that it saw a GAL and continue processing labels. It seems much = cleaner if we finish dealing with the multipath labels before considering w= hether it's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow la= bel because it allows the option of monitoring individual paths (assuming, = of course, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pw= e3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEX= CHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorpora= ted in the > fat-pw draft), then most hardware assume ACH is right aft= er GAL. In > this case how is the HW supposed to examine the ACH chann= el Type to > decide how to process the packet? (unless you assume ther= e is one > engine that can process all OAM packet types such as BFD,= AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to g= o into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects O= AM traffic when some other feature, fat-pw or other, puts a label unde= r the PW label. The GAL goes after the PW and before the other labe= ls. A proper multipath distribution will skip any reserved label = and use the rest of the label stack to load balance. This allows spray= ing across the entropy space or testing a spacific payload label stack= that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit= is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and = should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omi= tted but only one path through any multipath would be tested. It wo= uld still work for TP, but not work in general. PW does not require = TP. The fat-pw work is explicitly done for multipath because multip= ath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov = Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-= pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJ= EXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label= . But with > > Entropy label most implementation assume a Entropy labe= l to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL shou= ld be BoS or > > the Entropy Label? In either case adding GAL would make= the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was cov= ered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which = is different > from Entropy label in MPLS). > > 0 1 2 = 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | PW Label = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | GAL = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | ... additional labels (ie: fat-pw) may be present = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Typ= e | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | = | > ~ VCCV Message Body = ~ > | = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > > The above would be a better choice. The VCCV is always a= fter the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved = label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-= pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved = label (values > in the range 0..15) [RFC3032], but is otherwise uncons= trained by the > protocol. > > > The flow label below GAL is needed so that all data paths= which the PW > can take are exercised by OAM (ie: LSP Ping used within V= CCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf= .org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadea= u-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@= SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just = add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach fo= r non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware sup= port. The > > hardware need not know if the label above the GAL is an= MPLS label or > > a PW label, just that the next label is GAL and the lab= el over it is > > not a SWAP. Unless we are talking about incredibly inf= lexible parser > > hardware, like none I've encounted recently, there shou= ld be no > > problem noticing a GAL below the POP or PW label and th= en directing > > the packet to OAM processing. Any remaining labels mus= t be removed > > and hopefully no implementation neglects to look for BO= S before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW = case). In this > > case TTL-expire would occur where a label swap was call= ed for and a > > GAL would be below the label containing the expired TTL= . Since LDP > > can have transient loops, this avoids having lots of pa= ckets sent to > > the OAM engine should such a loop occur in a LDP signal= ed MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL= label is below > > the label for which action is taken (POP or PW terminat= ion) or below a > > label for which TTL has expired. This method applied t= o LSP and PW. > > > > I think mandating CW would be just as good a solution, = but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nad= eau-pwe3-vccv-2-02.txt > > > > > > Agreed - some operators won't want to use a CW, and o= n that basis I support > > > this draft. > > > > > > Sure, it'll take a while to move away from the router= alert label and TTL > > > approaches, but the GAL approach is definitely better= than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t = think to solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is = to mandate CW. > > > > > > > > While I am with you, that argument went out the win= dow during the debates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate th= e use of a CW. Hence, > > > > Luca and I came up with this solution that narrows = the > > > > scope to 2 modes, one that handles the CW case and = one that doesn't while > > > > still both modes providing predictable OAM capabili= ties > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Mat= thew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user depl= oyment poll I thought, > > > >> =B3 ok the way out of this mess is to migrate tow= ards using the CW=B2. Then I > > > >> see this proposal and wondered what am I missing. = I=B9ve still not seen the > > > >> light of why adding a fourth type will simplify ma= tters, hence in the absence > > > >> of me understanding how this will simplify matter = versus complicate things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@i= etf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons t= hat Yaakov has indicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org= ] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do not support ! and I can not understand how= anyone can support it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too m= any already. > > > >> > > > >> I completely agree with the part that says if ther= e is a CW then the ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we = should use a non-PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate = the use of TTL expiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms th= at have been widely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse= ONLY MPLS-TP to have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to objec= t as strongly. > > > >> However, since I don't think that PWs can be limit= ed in this matter (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a l= imitation is possible. > > > >> > > > >> I would have enthusiastically support this proposa= l had it been brought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nade= au-pwe3-vccv-2-02.txt > > > >> > > > >> This email begins a two week poll to help assess i= f there is consensus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 wo= rking group draft. > > > >> > > > >> Please indicate whether or not you support adoptio= n of this draft, and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient = only and contains > > > >> information which is CONFIDENTIAL and which may be= proprietary to ECI > > > >> Telecom. If you have received this transmission in= error, please inform us by > > > >> e-mail, phone or fax, and then delete the original= and all copies thereof. > > > >> This e-mail message is intended for the recipient = only and contains > > > >> information which is CONFIDENTIAL and which may be= proprietary to ECI > > > >> Telecom. If you have received this transmission in= error, please inform us by > > > >> e-mail, phone or fax, and then delete the original= and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From eric.gray@ericsson.com Tue Aug 9 06:03:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20BC21F8B76 for ; Tue, 9 Aug 2011 06:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnzs6N+Wuv6C for ; Tue, 9 Aug 2011 06:03:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 24EF621F850E for ; Tue, 9 Aug 2011 06:03:02 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p79D2wQ7014704 for ; Tue, 9 Aug 2011 08:03:30 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 9 Aug 2011 09:03:26 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 9 Aug 2011 09:03:24 -0400 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxTiPoUe26kM1SWT1W+LRFFE7/ppQDC7Brw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:03:04 -0000 Forwarding in plain text... ________________________________ From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 12:02 PM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) So I read the draft but could not see the justification. In fact, I believ= e there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 and placi= ng the GAL above the entropy label, that this makes it "effectively functio= n as an application label". But this is not so. The GAL is an extra label= that would normally sit below the application label. Application labels t= hat are expecting entropy labels are identified in your proposal either exp= licitly in the LFIB or implicitly by the presence of an ELI after the AL. = In either case, it's the label(s) above the GAL that trigger entropy label = handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect the S bi= t of the application/ELI label, and according to the text, would then pop t= he next label, assuming it was an entropy label. Unfortunately, you've now= popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy label bot= h want to be the BOS. You've tried to get around it by relaxing the BOS re= striction on GAL but I think it works much more cleanly if you go the other= way. Instead of saying that Entropy labels always need to be BOS, why not= simply say that they must immediately follow the application/ELI label? T= hat way, the procedures in 4.3 always work trivially. A router that does n= ot understand or expect entropy labels doesn't need to be confused by stran= ge labels following the GAL, and the hardware implementations likely will b= e simpler (and cheaper). It also means I can build hierarchical multipath = LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake wrote: Pablo, At least wrt entropy label, the reasons why it needs to be at the b= ottom of stack are detailed in the draft in some detail. The GAL is in exa= ctly the same place in the stack relative to the labels above it whether or= not the entropy label is used. The fact that the bottom of stack bit is n= ot set in the GAL tells the egress that an entropy label is present in the = stack after it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behal= f Of Pablo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption = of draft-nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below th= e GAL? What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flo= w (or Entropy) label just feels out of place. I should only really care ab= out a GAL if I encounter it as a result of disposing of the labels either b= ecause they've been popped or because the TTL has expired. When the PW lab= el gets terminated and all of a sudden, I encounter a GAL, it seems awkward= because in my mind, I have not finished terminating the PW layer. There i= s still this flow label that I need to dispose of... so the hardware has to= remember that it saw a GAL and continue processing labels. It seems much = cleaner if we finish dealing with the multipath labels before considering w= hether it's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow la= bel because it allows the option of monitoring individual paths (assuming, = of course, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pw= e3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEX= CHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorpora= ted in the > fat-pw draft), then most hardware assume ACH is right aft= er GAL. In > this case how is the HW supposed to examine the ACH chann= el Type to > decide how to process the packet? (unless you assume ther= e is one > engine that can process all OAM packet types such as BFD,= AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to g= o into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects O= AM traffic when some other feature, fat-pw or other, puts a label unde= r the PW label. The GAL goes after the PW and before the other labe= ls. A proper multipath distribution will skip any reserved label = and use the rest of the label stack to load balance. This allows spray= ing across the entropy space or testing a spacific payload label stack= that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit= is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and = should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omi= tted but only one path through any multipath would be tested. It wo= uld still work for TP, but not work in general. PW does not require = TP. The fat-pw work is explicitly done for multipath because multip= ath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov = Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-= pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJ= EXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label= . But with > > Entropy label most implementation assume a Entropy labe= l to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL shou= ld be BoS or > > the Entropy Label? In either case adding GAL would make= the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was cov= ered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which = is different > from Entropy label in MPLS). > > 0 1 2 = 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | PW Label = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | GAL = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | ... additional labels (ie: fat-pw) may be present = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Typ= e | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | = | > ~ VCCV Message Body = ~ > | = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > > The above would be a better choice. The VCCV is always a= fter the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved = label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-= pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved = label (values > in the range 0..15) [RFC3032], but is otherwise uncons= trained by the > protocol. > > > The flow label below GAL is needed so that all data paths= which the PW > can take are exercised by OAM (ie: LSP Ping used within V= CCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf= .org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadea= u-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@= SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just = add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach fo= r non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware sup= port. The > > hardware need not know if the label above the GAL is an= MPLS label or > > a PW label, just that the next label is GAL and the lab= el over it is > > not a SWAP. Unless we are talking about incredibly inf= lexible parser > > hardware, like none I've encounted recently, there shou= ld be no > > problem noticing a GAL below the POP or PW label and th= en directing > > the packet to OAM processing. Any remaining labels mus= t be removed > > and hopefully no implementation neglects to look for BO= S before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW = case). In this > > case TTL-expire would occur where a label swap was call= ed for and a > > GAL would be below the label containing the expired TTL= . Since LDP > > can have transient loops, this avoids having lots of pa= ckets sent to > > the OAM engine should such a loop occur in a LDP signal= ed MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL= label is below > > the label for which action is taken (POP or PW terminat= ion) or below a > > label for which TTL has expired. This method applied t= o LSP and PW. > > > > I think mandating CW would be just as good a solution, = but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nad= eau-pwe3-vccv-2-02.txt > > > > > > Agreed - some operators won't want to use a CW, and o= n that basis I support > > > this draft. > > > > > > Sure, it'll take a while to move away from the router= alert label and TTL > > > approaches, but the GAL approach is definitely better= than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t = think to solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is = to mandate CW. > > > > > > > > While I am with you, that argument went out the win= dow during the debates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate th= e use of a CW. Hence, > > > > Luca and I came up with this solution that narrows = the > > > > scope to 2 modes, one that handles the CW case and = one that doesn't while > > > > still both modes providing predictable OAM capabili= ties > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Mat= thew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user depl= oyment poll I thought, > > > >> =B3 ok the way out of this mess is to migrate tow= ards using the CW=B2. Then I > > > >> see this proposal and wondered what am I missing. = I=B9ve still not seen the > > > >> light of why adding a fourth type will simplify ma= tters, hence in the absence > > > >> of me understanding how this will simplify matter = versus complicate things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@i= etf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons t= hat Yaakov has indicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org= ] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do not support ! and I can not understand how= anyone can support it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too m= any already. > > > >> > > > >> I completely agree with the part that says if ther= e is a CW then the ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we = should use a non-PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate = the use of TTL expiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms th= at have been widely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse= ONLY MPLS-TP to have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to objec= t as strongly. > > > >> However, since I don't think that PWs can be limit= ed in this matter (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a l= imitation is possible. > > > >> > > > >> I would have enthusiastically support this proposa= l had it been brought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nade= au-pwe3-vccv-2-02.txt > > > >> > > > >> This email begins a two week poll to help assess i= f there is consensus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 wo= rking group draft. > > > >> > > > >> Please indicate whether or not you support adoptio= n of this draft, and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient = only and contains > > > >> information which is CONFIDENTIAL and which may be= proprietary to ECI > > > >> Telecom. If you have received this transmission in= error, please inform us by > > > >> e-mail, phone or fax, and then delete the original= and all copies thereof. > > > >> This e-mail message is intended for the recipient = only and contains > > > >> information which is CONFIDENTIAL and which may be= proprietary to ECI > > > >> Telecom. If you have received this transmission in= error, please inform us by > > > >> e-mail, phone or fax, and then delete the original= and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From eric.gray@ericsson.com Tue Aug 9 06:03:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5721F8B7B for ; Tue, 9 Aug 2011 06:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw5FJbLbUGHP for ; Tue, 9 Aug 2011 06:03:56 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 962B721F8B9F for ; Tue, 9 Aug 2011 06:03:56 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p79D4OII010165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Aug 2011 08:04:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 9 Aug 2011 09:04:24 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 9 Aug 2011 09:04:22 -0400 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxTriM0PYye4q80SqC3V6mjP8yhMgAhceEAAJg4skA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:03:58 -0000 Forwarding in plain text... ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Saturday, August 06, 2011 8:53 AM To: Pablo Frank Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: RE: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 1:28 PM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Thanks John, Some PF> questions/comments below: On Fri, Aug 5, 2011 at 12:50 PM, John E Drake wrote: An application label is a label in which you expect to see BOS set but whic= h isn't, followed by an entropy label which is a non-reserved label with BO= S set. Repeat as necessary. PF> The term "application label" is used repeatedly through the draft but i= sn't really defined anywhere. I suggest that you and rest of the authors a= dd a definition to the text. The definition that you give above doesn't ma= ke a lot of sense to me since I don't know how to interpret "expect to see = a BOS set but which isn't". I've interpreted application label to refer to= the LSP for which the ingress LSR parsed the payload and generated an entr= opy label. I don't think the GAL (or any other reserved label) falls into= this category. I think you may have to update 4.3 to say something about = how reserved labels are skipped until you find the first non-reserved label= and pop that as your entropy label. Ugh. JD: I am told this is the way most hardware developed over the past fifte= en works - first scan stack for the label with the BOS set and then get to= work. The original text was written several years ago and the GAL materia= l added about a year ago, so there is probably some additional text editing= required. Btw, as RFC5586 indicates, there is no technical reason for th= e GAL to be BOS. As both Curtis and I have said, in order to process the GAL payload= correctly, the stack above the GAL should be the same whether or not an en= tropy label is present. PF> I assume that any multi-path capable router's OAM implementation will b= e aware of (and possibly even care about) the entropy labels regardless of = where they are in the label stack. Or are you worried about transit nodes = who's OAM implementation may not be entropy-label aware? JD: LSP Traceroute (the control plane) needs to be updated because its usa= ge of labels, as opposed to IP addresses, has some issues. The data plane,= by design, is completely oblivious to entropy labels and I am told that m= ost existing hardware does not use reserved labels in load balancing. Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 9:02 AM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Renni= son@ecitele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption = of draft-nadeau-pwe3-vccv-2-02.txt) So I read the draft but could not see the justification. In fact, = I believe there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 a= nd placing the GAL above the entropy label, that this makes it "effectively= function as an application label". But this is not so. The GAL is an ext= ra label that would normally sit below the application label. Application = labels that are expecting entropy labels are identified in your proposal ei= ther explicitly in the LFIB or implicitly by the presence of an ELI after t= he AL. In either case, it's the label(s) above the GAL that trigger entrop= y label handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect = the S bit of the application/ELI label, and according to the text, would th= en pop the next label, assuming it was an entropy label. Unfortunately, yo= u've now popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy l= abel both want to be the BOS. You've tried to get around it by relaxing th= e BOS restriction on GAL but I think it works much more cleanly if you go t= he other way. Instead of saying that Entropy labels always need to be BOS,= why not simply say that they must immediately follow the application/ELI l= abel? That way, the procedures in 4.3 always work trivially. A router tha= t does not understand or expect entropy labels doesn't need to be confused = by strange labels following the GAL, and the hardware implementations likel= y will be simpler (and cheaper). It also means I can build hierarchical mu= ltipath LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake w= rote: Pablo, At least wrt entropy label, the reasons why it needs to be at the b= ottom of stack are detailed in the draft in some detail. The GAL is in exa= ctly the same place in the stack relative to the labels above it whether or= not the entropy label is used. The fact that the bottom of stack bit is n= ot set in the GAL tells the egress that an entropy label is present in the = stack after it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behal= f Of Pablo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption = of draft-nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below th= e GAL? What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flo= w (or Entropy) label just feels out of place. I should only really care ab= out a GAL if I encounter it as a result of disposing of the labels either b= ecause they've been popped or because the TTL has expired. When the PW lab= el gets terminated and all of a sudden, I encounter a GAL, it seems awkward= because in my mind, I have not finished terminating the PW layer. There i= s still this flow label that I need to dispose of... so the hardware has to= remember that it saw a GAL and continue processing labels. It seems much = cleaner if we finish dealing with the multipath labels before considering w= hether it's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow la= bel because it allows the option of monitoring individual paths (assuming, = of course, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pw= e3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEX= CHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorpora= ted in the > fat-pw draft), then most hardware assume ACH is right aft= er GAL. In > this case how is the HW supposed to examine the ACH chann= el Type to > decide how to process the packet? (unless you assume ther= e is one > engine that can process all OAM packet types such as BFD,= AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to g= o into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects O= AM traffic when some other feature, fat-pw or other, puts a label unde= r the PW label. The GAL goes after the PW and before the other labe= ls. A proper multipath distribution will skip any reserved label = and use the rest of the label stack to load balance. This allows spray= ing across the entropy space or testing a spacific payload label stack= that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit= is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and = should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omi= tted but only one path through any multipath would be tested. It wo= uld still work for TP, but not work in general. PW does not require = TP. The fat-pw work is explicitly done for multipath because multip= ath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov = Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-= pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJ= EXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label= . But with > > Entropy label most implementation assume a Entropy labe= l to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL shou= ld be BoS or > > the Entropy Label? In either case adding GAL would make= the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was cov= ered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which = is different > from Entropy label in MPLS). > > 0 1 2 = 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | PW Label = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | GAL = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | ... additional labels (ie: fat-pw) may be present = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Typ= e | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > | = | > ~ VCCV Message Body = ~ > | = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ > > The above would be a better choice. The VCCV is always a= fter the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved = label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-= pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved = label (values > in the range 0..15) [RFC3032], but is otherwise uncons= trained by the > protocol. > > > The flow label below GAL is needed so that all data paths= which the PW > can take are exercised by OAM (ie: LSP Ping used within V= CCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf= .org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadea= u-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@= SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just = add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach fo= r non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware sup= port. The > > hardware need not know if the label above the GAL is an= MPLS label or > > a PW label, just that the next label is GAL and the lab= el over it is > > not a SWAP. Unless we are talking about incredibly inf= lexible parser > > hardware, like none I've encounted recently, there shou= ld be no > > problem noticing a GAL below the POP or PW label and th= en directing > > the packet to OAM processing. Any remaining labels mus= t be removed > > and hopefully no implementation neglects to look for BO= S before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW = case). In this > > case TTL-expire would occur where a label swap was call= ed for and a > > GAL would be below the label containing the expired TTL= . Since LDP > > can have transient loops, this avoids having lots of pa= ckets sent to > > the OAM engine should such a loop occur in a LDP signal= ed MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL= label is below > > the label for which action is taken (POP or PW terminat= ion) or below a > > label for which TTL has expired. This method applied t= o LSP and PW. > > > > I think mandating CW would be just as good a solution, = but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nad= eau-pwe3-vccv-2-02.txt > > > > > > Agreed - some operators won't want to use a CW, and o= n that basis I support > > > this draft. > > > > > > Sure, it'll take a while to move away from the router= alert label and TTL > > > approaches, but the GAL approach is definitely better= than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t = think to solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is = to mandate CW. > > > > > > > > While I am with you, that argument went out the win= dow during the debates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate th= e use of a CW. Hence, > > > > Luca and I came up with this solution that narrows = the > > > > scope to 2 modes, one that handles the CW case and = one that doesn't while > > > > still both modes providing predictable OAM capabili= ties > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Mat= thew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user depl= oyment poll I thought, > > > >> =B3 ok the way out of this mess is to migrate tow= ards using the CW=B2. Then I > > > >> see this proposal and wondered what am I missing. = I=B9ve still not seen the > > > >> light of why adding a fourth type will simplify ma= tters, hence in the absence > > > >> of me understanding how this will simplify matter = versus complicate things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@i= etf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons t= hat Yaakov has indicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org= ] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-= nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do not support ! and I can not understand how= anyone can support it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too m= any already. > > > >> > > > >> I completely agree with the part that says if ther= e is a CW then the ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we = should use a non-PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate = the use of TTL expiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms th= at have been widely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse= ONLY MPLS-TP to have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to objec= t as strongly. > > > >> However, since I don't think that PWs can be limit= ed in this matter (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a l= imitation is possible. > > > >> > > > >> I would have enthusiastically support this proposa= l had it been brought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@i= etf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nade= au-pwe3-vccv-2-02.txt > > > >> > > > >> This email begins a two week poll to help assess i= f there is consensus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 wo= rking group draft. > > > >> > > > >> Please indicate whether or not you support adoptio= n of this draft, and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient = only and contains > > > >> information which is CONFIDENTIAL and which may be= proprietary to ECI > > > >> Telecom. If you have received this transmission in= error, please inform us by > > > >> e-mail, phone or fax, and then delete the original= and all copies thereof. > > > >> This e-mail message is intended for the recipient = only and contains > > > >> information which is CONFIDENTIAL and which may be= proprietary to ECI > > > >> Telecom. If you have received this transmission in= error, please inform us by > > > >> e-mail, phone or fax, and then delete the original= and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From eric.gray@ericsson.com Tue Aug 9 06:05:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CE921F8B98 for ; Tue, 9 Aug 2011 06:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJFCb4bnO7EP for ; Tue, 9 Aug 2011 06:05:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1F421F8B9F for ; Tue, 9 Aug 2011 06:05:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p79D5lBf015048 for ; Tue, 9 Aug 2011 08:05:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 9 Aug 2011 09:05:18 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 9 Aug 2011 09:05:17 -0400 Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Thread-Index: AcxVrQ5SNJJvNhaYQAat/5L/ZIkPJQA596zg Message-ID: 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 Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:05:27 -0000 Forwarding in plain text... ________________________________ From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com]=20 Sent: Monday, August 08, 2011 5:25 AM To: draft-ietf-mpls-tp-te-mib@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Hi Venkat & all,=20 =20 I've read the draft and have a question and then some comments. I'm happy = to be of assistance with any of what follows, and/or with working on other = MIB drafts that we need to fill out the gaps identified in draft-ietf-mpls-= tp-mib-management-overview. =20 =20 MPLS-TP Identifiers: I understand that one of the purposes of this draft is to allow configurati= on using MPLS-TP identifiers. Presumably, there are at least three ways th= is could be accomplished: 1. Define a brand new tunnel table for MPLS-TP, based on the mplsTunnel= Table, but with the MPLS-TP identifiers as indices. 2. Redefine the existing mplsTunnelTable indexing, adding GlobalID and = ICC for ingress and egress nodes, and using 0 as "not used" values to allow= back-compatibility. 3. Create a separate set of tables which maps the old identifiers to th= e new MPLS-TP identifiers. This draft takes the third strategy, but it's not immediately clear to me w= hy this is preferable to the other two. (2) seems the least complicated bec= ause it does away extra mapping and inverse mapping tables. It's also diff= icult to guarantee that local identifiers (which don't have configuration o= r signalling significance) will not change in the case of graceful restart = or configuration replay. Was option (3) chosen to avoid back-compatibility= issues, or for other reasons? =20 A comment on tunnels: I'd like to clarify how unidirectional, associated bidirectional and co-rou= ted bidirectional paths are modelled in the MIB, and how exactly the MPLS-T= P identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. My prefe= rence is as follows. =20 * Unidirectional LSPs in MPLS-TP are very similar to "normal" MPLS,= but with different identifiers. Tunnels of this type do not have any entr= ies in the mplsTunnelExtTable. =20 * In associated bidirectional LSPs, the transport directions are se= t up and monitored independently, so each transport direction should be a s= eparate row in the mplsTunnelTable. =20 * In co-routed bidirectional LSPs, both transport directions are se= t up and monitored together. This means we should have only one row in the= mplsTunnelTable to represent a tunnel of this type. This is not how the d= raft is currently structured, where the example in Section 9 creates two ro= ws in the mplsTunnelTable. =20 About gaps: Lastly, I think the MIB is still missing some configuration that we'll need= in order to satisfy MPLS-TP requirements. These include * Bidirectional tunnels with asymmetric resource requirements * OAM configuration. Presumably this will be a reference to yet-to= -be-defined OAM MIBs so that tunnels can be easily assigned OAM profiles. =20 Let me know if I can be of further assistance. =20 Cheers, Spike =20 =20 ________________________________ * To: i-d-announce at ietf.org =20 * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt=20 * From: internet-drafts at ietf.org = =20 * Date: Fri, 17 Jun 2011 07:24:45 -0700=20 * Cc: mpls at ietf.org =20 * Delivered-to: mpls at ietfa.amsl.com =20 * List-archive: =20 * List-help: =20 * List-id: Multi-Protocol Label Switching WG =20 * List-post: =20 * List-subscribe: , =20 * List-unsubscribe: , ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. =20 Title : MPLS-TP Traffic Engineering (TE) Management Infor= mation Base (MIB) Author(s) : Venkatesan Mahalingam Kannan KV Sampath Huawei Technologies Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-00.txt Pages : 39 Date : 2011-06-17 =20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt ________________________________ * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's State= ment about IPR related to draft-ietf-mpls-loss-delay-03 =20 * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's S= tatement about IPR related to RFC 5919 =20 * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's= Statement about IPR related to draft-ietf-mpls-loss-delay-03 =20 * Next by thread: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-0= 0.txt =20 * Index(es):=20 * Date =20 * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not= imply endorsement by the IETF. From jcucchiara@mindspring.com Tue Aug 9 07:39:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5614021F8764 for ; Tue, 9 Aug 2011 07:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7GGt+J30ljW for ; Tue, 9 Aug 2011 07:39:44 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 138E421F8500 for ; Tue, 9 Aug 2011 07:39:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AmDNya/EoT2PLaG2fL8vjjmCQNYy+WikIePenKabUsOPWV8Sb3ZSaVryV/wNOpEj; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QqnTY-0007xd-Kd; Tue, 09 Aug 2011 10:40:12 -0400 Message-ID: <30d001cc56a2$3e764210$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Eric Gray" , References: Date: Tue, 9 Aug 2011 10:40:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26543d9fc61dcb82a15419abfb2660a89bcd480e0e5d2f5ffe94350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:39:45 -0000 Spike, Wanted to comment on your 3 suggestions for indexing. Suggestion #1 is also my preference. This is the most straightforward and least complex design in my opinion. Additionally, the CLI, Web, NMS, etc could display both MPLS Tunnels and MPLS-TP Tunnels in the same table if wanted. So the complexity of the mapping is not in the MIB (or agent). Suggestion #2 is not allowed because redefining indices is not allowed in the SMI. (We had a few emails about this during the time that the MIB was being adopted by the WG.) Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same table. While this goal may have some benefits, the design to accomplish the goal is more complex than #1 as you point out. I have asked the authors to ensure that there are no backwards compatibility issues with the design so that the MPLS Tunnel Table is already populated and then MPLS-TP Tunnel indices are created such that they do not conflict with already existing tunnel indices. In a nutshell, the problem I have with this design is that there are 2 ways of creating indices for the same Table, one which is legacy and has been around since 2004 and now a second way. There may be a #4 Suggestion which is to implement design #1 but also have an additional (optional?) table which is a superset of Tunnels, this could be indexed by a type field. Thanks, -Joan ----- Original Message ----- From: "Eric Gray" To: Sent: Tuesday, August 09, 2011 9:05 AM Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt > Forwarding in plain text... > > ________________________________ > > From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] > Sent: Monday, August 08, 2011 5:25 AM > To: draft-ietf-mpls-tp-te-mib@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt > > > > Hi Venkat & all, > > > > I've read the draft and have a question and then some comments. I'm happy > to be of assistance with any of what follows, and/or with working on other > MIB drafts that we need to fill out the gaps identified in > draft-ietf-mpls-tp-mib-management-overview. > > > > > > MPLS-TP Identifiers: > > I understand that one of the purposes of this draft is to allow > configuration using MPLS-TP identifiers. Presumably, there are at least > three ways this could be accomplished: > > 1. Define a brand new tunnel table for MPLS-TP, based on the > mplsTunnelTable, but with the MPLS-TP identifiers as indices. > > 2. Redefine the existing mplsTunnelTable indexing, adding GlobalID and > ICC for ingress and egress nodes, and using 0 as "not used" values to > allow back-compatibility. > > 3. Create a separate set of tables which maps the old identifiers to > the new MPLS-TP identifiers. > > This draft takes the third strategy, but it's not immediately clear to me > why this is preferable to the other two. (2) seems the least complicated > because it does away extra mapping and inverse mapping tables. It's also > difficult to guarantee that local identifiers (which don't have > configuration or signalling significance) will not change in the case of > graceful restart or configuration replay. Was option (3) chosen to avoid > back-compatibility issues, or for other reasons? > > > > A comment on tunnels: > > I'd like to clarify how unidirectional, associated bidirectional and > co-routed bidirectional paths are modelled in the MIB, and how exactly the > MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. > My preference is as follows. > > > > * Unidirectional LSPs in MPLS-TP are very similar to "normal" > MPLS, but with different identifiers. Tunnels of this type do not have > any entries in the mplsTunnelExtTable. > > > > * In associated bidirectional LSPs, the transport directions are > set up and monitored independently, so each transport direction should be > a separate row in the mplsTunnelTable. > > > > * In co-routed bidirectional LSPs, both transport directions are > set up and monitored together. This means we should have only one row in > the mplsTunnelTable to represent a tunnel of this type. This is not how > the draft is currently structured, where the example in Section 9 creates > two rows in the mplsTunnelTable. > > > > About gaps: > > Lastly, I think the MIB is still missing some configuration that we'll > need in order to satisfy MPLS-TP requirements. These include > > * Bidirectional tunnels with asymmetric resource requirements > > * OAM configuration. Presumably this will be a reference to > yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM > profiles. > > > > Let me know if I can be of further assistance. > > > > Cheers, > > Spike > > > > > > ________________________________ > > * To: i-d-announce at ietf.org > * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt > * From: internet-drafts at ietf.org > * Date: Fri, 17 Jun 2011 07:24:45 -0700 > * Cc: mpls at ietf.org > * Delivered-to: mpls at ietfa.amsl.com > * List-archive: > * List-help: > * List-id: Multi-Protocol Label Switching WG > * List-post: > * List-subscribe: , > > * List-unsubscribe: , > > > ________________________________ > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiprotocol Label > Switching Working Group of the IETF. > > Title : MPLS-TP Traffic Engineering (TE) Management > Information Base (MIB) > Author(s) : Venkatesan Mahalingam > Kannan KV Sampath > Huawei Technologies > Thomas D. Nadeau > Filename : draft-ietf-mpls-tp-te-mib-00.txt > Pages : 39 > Date : 2011-06-17 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects of Tunnels, Identifiers, > Label Switch Router and Textual conventions for Multiprotocol Label > Switching (MPLS) based Transport Profile (TP). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt > ________________________________ > > > * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's > Statement about IPR related to draft-ietf-mpls-loss-delay-03 > > * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's > Statement about IPR related to RFC 5919 > > * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., > Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 > > * Next by thread: [mpls] I-D Action: > draft-ietf-mpls-ldp-ip-pw-capability-00.txt > > * Index(es): > > * Date > > * Thread > > > > Note: Messages sent to this list are the opinions of the senders and do > not imply endorsement by the IETF. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From iesg-secretary@ietf.org Tue Aug 9 07:43:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005721F89BA; Tue, 9 Aug 2011 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu2JyRMuqXLv; Tue, 9 Aug 2011 07:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E721F8AAC; Tue, 9 Aug 2011 07:43:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809144341.5393.9055.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 07:43:41 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' to Proposed Standard (draft-ietf-mpls-tp-cc-cv-rdi-06.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:43:42 -0000 The IESG has approved the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' (draft-ietf-mpls-tp-cc-cv-rdi-06.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ Technical Summary MPLS LSPs (emulating traditional transport circuits) are expected to deliver the same the capabilities for monitoring cnnections as in earlier types of transport networks. This document describes and specifies, as required in RFC 5860, Continuity Check (CC), proactive Connection Verfication (CV), and Remoted Defect Indication (RDI). This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) for for these functions for pseudowires (PWs), Label Switched Paths (LSPs), and Sub-Path Maintenance Entities (SPMEs) between two Maintenance Entity Group End Points (MEPs). CC and Proactive CV are functions used to detect loss of continuity (LOC), and unintended connectivity between two MEPs. RDI is an indicator that is transmitted by a MEP to communicate to its peer MEP that a signal fail condition exists. This document specifies the BFD extension and behavior to satisfy the CC, the proactive CV monitoring, and the RDI functional requirements for both co-routed and associated bi-directional LSPs. The document describes a number of encapsulations. Procedures for uni-directional LSPs are for further study. The mechanisms specified in this document are restricted to BFD asynchronous mode. Working Group Summary This document is a MPLS working group document, and part of the joint IETF / ITU-T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. The document was discussed and last-called in the MPLS and BFD WGs. Document Quality The document is well reviewed in the MPLS working group,the ITU-T and the BFD working group. A number of vendors have committed to implement and there is believed to be at least one early implementation. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Please try to set the figures so that they don't break over a page. From tnadeau@lucidvision.com Tue Aug 9 07:46:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8BE21F8BB8 for ; Tue, 9 Aug 2011 07:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3biBI0D8NOB for ; Tue, 9 Aug 2011 07:46:38 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A193C21F8AFB for ; Tue, 9 Aug 2011 07:46:37 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2CAC41D66CAB; Tue, 9 Aug 2011 10:47:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau X-Priority: 3 In-Reply-To: <30d001cc56a2$3e764210$6601a8c0@JoanPC> Date: Tue, 9 Aug 2011 10:47:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> To: "Joan Cucchiara" X-Mailer: Apple Mail (2.1244.3) Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:46:39 -0000 On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >=20 > Spike, >=20 > Wanted to comment on your 3 suggestions for indexing. >=20 > Suggestion #1 is also my preference. This is the most = straightforward and least complex > design in my opinion. Additionally, the CLI, Web, NMS, etc could = display both MPLS > Tunnels and MPLS-TP Tunnels in the same table if wanted. So the = complexity of the > mapping is not in the MIB (or agent). That is the idea we were after. We want a new table that shows = "TP tunnels"=20 as a (proper) subset of those defined globally. That is, the indexing = "extends" those in the MplsTunnelTable. > Suggestion #2 is not allowed because redefining indices is not allowed = in the SMI. > (We had a few emails about this during the time that the MIB was being = adopted by the WG.) Spot on. The only way to take this approach is to deprecate = RFC3811, 12, and 13 as=20 well as the GMPLS and PWE3 MIB RFCs that are also based on these. > Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same = table. > While this goal may have some benefits, the design to accomplish the = goal is more complex than #1 > as you point out. I have asked the authors to ensure that there are = no backwards compatibility issues > with the design so that the MPLS Tunnel Table is already populated > and then MPLS-TP Tunnel indices are created such that they do not = conflict with already > existing tunnel indices. In a nutshell, the problem I have with = this design is that there are 2 ways of creating indices > for the same Table, one which is legacy and has been around since 2004 = and now a second way. Don't you get both "existing at the same time in the same table" = by using the 'extends' relationship? > There may be a #4 Suggestion which is to implement design #1 but also = have an additional (optional?) table > which is a superset of Tunnels, this could be indexed by a type field. The MIB provides mapping tables *in addition to* the basic table = that extends the MplsTunnelTable. This is provided as a convenience for the E/NMS to speed table = traversal/manipulation. --Tom >=20 > Thanks, > -Joan >=20 >=20 > ----- Original Message ----- From: "Eric Gray" = > To: > Sent: Tuesday, August 09, 2011 9:05 AM > Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 >=20 >> Forwarding in plain text... >>=20 >> ________________________________ >>=20 >> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >> Sent: Monday, August 08, 2011 5:25 AM >> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >> Cc: mpls@ietf.org >> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >>=20 >>=20 >> Hi Venkat & all, >>=20 >>=20 >>=20 >> I've read the draft and have a question and then some comments. I'm = happy to be of assistance with any of what follows, and/or with working = on other MIB drafts that we need to fill out the gaps identified in = draft-ietf-mpls-tp-mib-management-overview. >>=20 >>=20 >>=20 >>=20 >>=20 >> MPLS-TP Identifiers: >>=20 >> I understand that one of the purposes of this draft is to allow = configuration using MPLS-TP identifiers. Presumably, there are at least = three ways this could be accomplished: >>=20 >> 1. Define a brand new tunnel table for MPLS-TP, based on the = mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>=20 >> 2. Redefine the existing mplsTunnelTable indexing, adding = GlobalID and ICC for ingress and egress nodes, and using 0 as "not used" = values to allow back-compatibility. >>=20 >> 3. Create a separate set of tables which maps the old identifiers = to the new MPLS-TP identifiers. >>=20 >> This draft takes the third strategy, but it's not immediately clear = to me why this is preferable to the other two. (2) seems the least = complicated because it does away extra mapping and inverse mapping = tables. It's also difficult to guarantee that local identifiers (which = don't have configuration or signalling significance) will not change in = the case of graceful restart or configuration replay. Was option (3) = chosen to avoid back-compatibility issues, or for other reasons? >>=20 >>=20 >>=20 >> A comment on tunnels: >>=20 >> I'd like to clarify how unidirectional, associated bidirectional and = co-routed bidirectional paths are modelled in the MIB, and how exactly = the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB = fields. My preference is as follows. >>=20 >>=20 >>=20 >> * Unidirectional LSPs in MPLS-TP are very similar to "normal" = MPLS, but with different identifiers. Tunnels of this type do not have = any entries in the mplsTunnelExtTable. >>=20 >>=20 >>=20 >> * In associated bidirectional LSPs, the transport directions = are set up and monitored independently, so each transport direction = should be a separate row in the mplsTunnelTable. >>=20 >>=20 >>=20 >> * In co-routed bidirectional LSPs, both transport directions = are set up and monitored together. This means we should have only one = row in the mplsTunnelTable to represent a tunnel of this type. This is = not how the draft is currently structured, where the example in Section = 9 creates two rows in the mplsTunnelTable. >>=20 >>=20 >>=20 >> About gaps: >>=20 >> Lastly, I think the MIB is still missing some configuration that = we'll need in order to satisfy MPLS-TP requirements. These include >>=20 >> * Bidirectional tunnels with asymmetric resource requirements >>=20 >> * OAM configuration. Presumably this will be a reference to = yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM = profiles. >>=20 >>=20 >>=20 >> Let me know if I can be of further assistance. >>=20 >>=20 >>=20 >> Cheers, >>=20 >> Spike >>=20 >>=20 >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> * To: i-d-announce at ietf.org >> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >> * From: internet-drafts at ietf.org = >> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >> * Cc: mpls at ietf.org >> * Delivered-to: mpls at ietfa.amsl.com >> * List-archive: >> * List-help: >> * List-id: Multi-Protocol Label Switching WG >> * List-post: >> * List-subscribe: , = >> * List-unsubscribe: , = >>=20 >> ________________________________ >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Multiprotocol Label = Switching Working Group of the IETF. >>=20 >> Title : MPLS-TP Traffic Engineering (TE) Management = Information Base (MIB) >> Author(s) : Venkatesan Mahalingam >> Kannan KV Sampath >> Huawei Technologies >> Thomas D. Nadeau >> Filename : draft-ietf-mpls-tp-te-mib-00.txt >> Pages : 39 >> Date : 2011-06-17 >>=20 >> This memo defines a portion of the Management Information Base (MIB) >> for use with network management protocols in the Internet community. >> In particular, it describes managed objects of Tunnels, Identifiers, >> Label Switch Router and Textual conventions for Multiprotocol Label >> Switching (MPLS) based Transport Profile (TP). >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >> ________________________________ >>=20 >>=20 >> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's = Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to RFC 5919 = >> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >> * Next by thread: [mpls] I-D Action: = draft-ietf-mpls-ldp-ip-pw-capability-00.txt = >> * Index(es): >>=20 >> * Date = >> * Thread = >>=20 >>=20 >> Note: Messages sent to this list are the opinions of the senders and = do not imply endorsement by the IETF. >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From swallow@cisco.com Tue Aug 9 08:14:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4570021F8C4B for ; Tue, 9 Aug 2011 08:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=-1.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW2gztE8f42F for ; Tue, 9 Aug 2011 08:14:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9671521F8C48 for ; Tue, 9 Aug 2011 08:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=1214; q=dns/txt; s=iport; t=1312902905; x=1314112505; h=date:subject:from:to:message-id:mime-version; bh=iNN04H6Xht2n4099cM3zMm3RzN78Wm53Y4vrR9A1n5A=; b=AOVwWMuCpkpyAjLmIvvdW3RSlGEv3F05gtNq5K1GrYLZUp9IZgeTAhRC O2trMu+HHICHc7wBSk6s8H4qqhdwKbJg/hCkl9RMPOIuYlOqCYzskq9jr l8EO3jy2JIen1KKITElfWIGOJ8DtPkTXUt3FLPCcPD8gMVyE3Dayjz9Se 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0GAJxOQU6tJV2c/2dsb2JhbABCgk2VVY45YHeBNwsBAQMSASpOAQsBAoEYAQQ1pjGBIwGecoZGBJMFhRKLdQ X-IronPort-AV: E=Sophos;i="4.67,343,1309737600"; d="scan'208,217";a="11325545" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2011 15:15:04 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p79FF4aD017842 for ; Tue, 9 Aug 2011 15:15:04 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 10:15:03 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Aug 2011 15:15:04 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 09 Aug 2011 11:15:03 -0400 From: George Swallow To: Message-ID: Thread-Topic: Fault OAM and terminology Thread-Index: AcxWpxzSu0SA7KQKm0qtETswgogszA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395733303_171552835" X-OriginalArrivalTime: 09 Aug 2011 15:15:03.0814 (UTC) FILETIME=[1D4EEA60:01CC56A7] Subject: [mpls] Fault OAM and terminology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 15:14:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395733303_171552835 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All - Maarten Vissers has pointed out in the IETF last call that the terminology use of the words defect and fault in the draft are the reverse of what is currently prevalent in the ITU and the transport industry. I plan to align the terminology unless I hear strong objections. ...George --B_3395733303_171552835 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Fault OAM and terminology All -
Maarten Vissers has pointed out in the IETF last call that the terminology = use of the words defect and fault in the draft are the reverse of what is cu= rrently prevalent in the ITU and the transport industry.  I plan to ali= gn the terminology unless I hear strong objections.

...George --B_3395733303_171552835-- From swallow@cisco.com Tue Aug 9 09:23:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CC821F867A for ; Tue, 9 Aug 2011 09:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msgd8cUXyKWD for ; Tue, 9 Aug 2011 09:23:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1284321F871E for ; Tue, 9 Aug 2011 09:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=28982; q=dns/txt; s=iport; t=1312907025; x=1314116625; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=38dAYXe4izwDuomPbQQUQy8+tJRblnuZQ67rzEpRz9o=; b=XXzvhPlcRj6+RPOasYx+PSHMR3+OTlmNKfGMIGgPVz2uzedSqAyvp6eX +0bjkawWAdZ269ZWmqMAFl+I37Qpa+8p3O5/dHryjhl42DQ7zAhZc9WSm 8uXYWMwTcsT/yswfEyQKzHu1oM60HDBLO7QJDs72sgUtP0Fdt0Z8ZtHLR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAFJeQU6tJXG9/2dsb2JhbABCgk2VE459YXeBQAEBAQECAQEBAQ8BFBYxCwUHAgQBCBEEAQEBIAciDAEeCQgBAQQOBRkJh0sEoAYBnm0ChkQEhy2JSoIOhRKLdQ X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208,217";a="11356302" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 09 Aug 2011 16:23:33 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p79GNXYb012931; Tue, 9 Aug 2011 16:23:33 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 11:23:32 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Aug 2011 16:23:32 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 09 Aug 2011 12:23:29 -0400 From: George Swallow To: Alexander Vainshtein Message-ID: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8B6/z8MARWNTqm In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395737411_171788778" X-OriginalArrivalTime: 09 Aug 2011 16:23:32.0670 (UTC) FILETIME=[AE6095E0:01CC56B0] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:23:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395737411_171788778 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 7/18/11 11:15 AM, "Alexander Vainshtein" wrote: > George, > Lots of thanks for your response, and apologies for a delayed reaction. > =20 > I would like to present to you and the WG my reading of your responses, a= nd my > conclusions. > =20 > Regarding my comment about effect of FRR (or segment protection) on AIS/L= DI, > your response includes two statements: > 1. The draft only applies to =B3the operation of PWs, bi-directional = LSPs > and sections and LSP 1:1 and 1+1 protection as that is the current scope = of > MPLS-TP=B2 >=20 GS> Agree that my statement in the email is stronger than the text in the draft. > a. This seems to imply that FRR and segment protection are out of s= cope. >=20 > b. To the best of my understanding, the draft does not explicitly st= ate > that LSPs protected by FRR are out of scope. GS> Correct. > c. It only says =B3Fault OAM messages are applicable to Bidirectional > Co-Routed LSPs and to Multi-Segment Pseudowires=B2 > d. One could possibly imply that any actions (like FRR in link-and-n= ode > protection mode) that break co-routed nature of a bidirectional LSP are b= eyond > the scope of the draft (not sure about the scope MPLS-TP). However: > i. It= is > not clear (at least, to me) why bi-directionality is so important for the > draft which only defines downstream messages GS> Yes. AIS and LKR certainly apply. And I suppose some use could be made of LDI to switch between feeds of non-continuous traffic. But I don=B9t want to expand the scope of the document to cover this as we have an immediate need for the transport profile, and other applications are not well explored at this time. > ii. IMH= O an > explicit statement of this kind (preferably in the Applicability Statemen= t > section) would make the life of a potential reader much easier. >=20 GS> perhaps, but I do not want to limit future applicability. >=20 > 2. The draft states that =B3action based on the receipt of an LDI fla= g is > optional=B2: > 1. I=B9ve scanned the draft for the word =B3OPTIONAL=B2, (case-insensitive) and= did > not find this statement. Did I miss something? GS> Yes. Section 6 =B3 The following items are optional to implement. =20 2. Support of receiving the L-flag.=B2 > b. The text that I=B9ve found in Section 2.3 of the draft and that lo= oks > relevant states: =B3If the CC function is disabled, a MEP SHOULD generate A= IS > messages toward any client when either the AIS or LCK indication is rais= ed.=B2 > IMHO this is not OPTIONAL, it is RECOMMENDED >=20 GS> This does not say anything about the receipt to LDI! In fact it goes o= n to say =B3Note that the L-flag is not automatically propagated, i.e. the rules of Section 2.1.1 apply, that is the L-flag is not set until a fault has been declared.=B2 > c. The quoted text in the draft contains a couple of types (I=B9ve re= moved > them). >=20 GS> Thanks. One more though LCK -> LKR. ...George > =20 > Regarding my comment about association between links and LSPs that pass t= hru > these links =AD I think that the text to which you refer clarifies this iss= ue. > =20 >=20 > Regards, > Sasha > =20 >=20 > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, July 08, 2011 10:48 PM > To: Alexander Vainshtein; Loa Andersson > Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > =20 >=20 > Sasha - >=20 > On 3/1/11 7:36 AM, "Alexander Vainshtein" > wrote: > Loa, and all, > I have two LC comments on the draft. in question. They both refer to issu= es > I've raised in private discussions with George and Matthew and which, to = the > best of my understanding, have not been resolved in the -03 version. >=20 > My first issue deals with potential dangers of sending fault OAM messages= in > conjunction with certain protection mechanisms. >=20 > The example I've presented to George and Matthew deals with the situatio= n > when the LSP in question employs Facility FRR for node protection. >=20 > The topology is shown below: >=20 >=20 > |------| |-----| |-----| |-----| |-----| > | A |<--->| B |<--->| C |<--->| D |<--->| E | > |------| |-----| |-----| |-----| |-----| > \ / > \ / > \ / > \ / > \ / > \ / > \ |------| / > \| C' |/ > |------| >=20 > The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs i= n the > rest of the nodes. > If the link BC is broken, the link-level MEP at C detects that and initia= tes > (I'll skip the details) insertion of AIS (with LDI flag set after some > stabilization) into the LSP. These AIS/LDI packets will be captured by th= e LSP > MEP in D. > I believe you mean E here. >=20 > Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this= LSP, > starting at B and terminated at D, D would be the merge point. Note that = C > would not be aware of this action, and D would not aware of AIS insertion > undertaken by C. > As a consequence, E would receive both AIS/LDI generated by C and valid > traffic coming thru bypass. > The current draft is limited to the operation of PWs, bi-directional LSPs= and > sections and LSP 1:1 and 1+1 protection as that is the current scope of > MPLS-TP. The draft states that action based on the receipt of an LDI fl= ag is > optional. In this situation you would clearly want to ignore the flag. = The > only other affect is to suppress alarms. But as there is no alarm to > suppress, that will have no effect. >=20 > This is definitely not healthy, and the draft does not define any ways to > avoid that. > If you would like to begin a draft on applying AIS to other types of LSPs= , > that would be much appreciated. >=20 > The text in the draft that deals with protection seems to refer to link > protection rather than to LSP protection. > I agree that that is not clear. I=B9ve updated section 2 para 3 with, =B3Whe= n a > server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP > fails,....=B2 >=20 > IMHO the same problem would appear in the case of segment protection if a= link > in the middle of a segment is broken, so this issue is not limited just t= o > FRR. >=20 > My second issue deals with association between links and LSPs that pass t= hru > these links. Ability to insert Fault OAM messages into all the LSPs cross= ing a > certain link may be compromised IMHO in the case LSPs that use labels fro= m the > per-platform space. It is not clear from the draft how the LSR that has > detected a link failure could decide whether Fault OAM messages should be > inserted in a transit LSP (which it perceives as an ILM table entry) or n= ot - > because the actual LSP could be running thru a different link. The proble= m > would presumably disappear if per-interface label space were used; but RF= C > 5960 does not restrict MPLS-TP from using per-platform label space. > The issue is not per platform labels per se, but to the binding of PWs an= d > LSPs to specific links (which includes hierarchical LSPs). I=B9ve updated > section 2 para 3 with =B3Fault OAM messages are generated by intermediate n= odes > where a bidir-LSP is switched and bound to specific server layers based u= pon > static configuration or signaling. >=20 > ...George=20 >=20 > I apologize for sending these comments so late in the LC. >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > Loa Andersson > Sent: Thursday, February 03, 2011 1:37 PM > To: mpls-tp@ietf.org; mpls@ietf.org > Cc: ahmpls-tp@lists.itu.int > Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 >=20 > Working Group, >=20 > this is to start a four week working group last call > on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). >=20 > Please send comments to the mpls-tp@ietf.org mailing list. >=20 > This working group last call ends on February 28, 2011. >=20 >=20 >=20 > Loa, George and Ross >=20 > MPLS wg co-chairs >=20 > -- >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI Tel= ecom. > If you have received this transmission in error, please inform us by e-ma= il, > phone or fax, and then delete the original and all copies thereof. >=20 --B_3395737411_171788778 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03


On 7/18/11 11:15 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:
George,
Lots of thanks for your response, and apologies for a delayed reaction.
 
I would like to present to you and the WG my reading of your responses, and= my conclusions.
 
Regarding my comment about effect of FRR (or segment protection) on AIS/LDI= , your response includes two statements:
1.       The draft only applies to “the operation of PWs= , bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is= the current scope of MPLS-TP”

= GS> Agree that my statement in the email is = stronger than the text in the draft.

a.     = ;  This seems to imply that FRR and segment protection are out of = scope.


GS> Correct.

c.     = ;  It only says “Fault OAM messages are applic= able to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires= ”
d.      One could possibly imply that any actions = (like FRR in link-and-node protection mode) that break co-routed nature of a= bidirectional LSP are beyond the scope of the draft (not sure about the sco= pe MPLS-TP). However:
            &nb= sp;            &= nbsp;            = ;            &nb= sp;            i= .      It is not clear (at least, to me) why bi-dir= ectionality is so important for the draft which only defines downstream mess= ages

GS> Yes.   AIS and LKR certainly apply. =  And I suppose some use could be made of LDI to switch between feeds of= non-continuous traffic.  But I don’t want to expand the scope of= the document to cover this as we have an immediate need for the transport p= rofile, and other applications are not well explored at this time.
    &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;     ii.      IMHO an exp= licit statement of this kind (preferably in the Applicability Statement sect= ion) would make the life of a potential reader much easier.

GS> perhaps, but I do not want to lim= it future applicability.

2.       = ;The draft states that “action based on the receipt of an LDI flag is optional”:<= BR>
  1. I’ve scann= ed the draft for the word “OPTIONAL”, (case-insensitive) and did= not find this statement. Did I miss something?

GS> Yes.  Section 6

    “ The following items are optional to impleme= nt.
   
   2.  Support of receiving the L-flag.”

b.     = ; The text that I’ve found in Section 2.3 of the draft  and = that looks relevant states: “If the CC function is disab= led, a MEP SHOULD generate AIS messages toward any client when either the AI= S or LCK indication is  raised.”  IMHO this is not OPTIONAL, it is RECOMMENDED

GS> This does not say anything about = the receipt to LDI!  In fact it goes on to say “Note that the L-f= lag is not automatically propagated, i.e.
   the rules of Section 2.1.1 apply, that is the L-flag is n= ot set until a fault has been declared.”
c.     = ;  The quoted text in the draft contains a couple of types (I̵= 7;ve removed them).

GS> Thanks.  One more though LCK= -> LKR.

...George
<= SPAN STYLE=3D'font-size:11pt'>
Regarding my comment about association between links and LSPs that pass thru these links R= 11; I think that the text to which you refer clarifies this issue.



From: George Swallow [mailto:swallow@cisco.com]
Sent: Friday, July 08, 2011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:
Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages i= n conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situa= tion when the LSP in question employs Facility FRR for node protection.

The topology is shown below:


|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
|  A   |<--->|  B  |<--->|  C &nb= sp;|<--->|  D  |<--->|  E  |
|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
            &nb= sp;   \          = ;            /             &nb= sp;    \         = ;           /
            &nb= sp;     \        = ;          /
            &nb= sp;      \       = ;         /
            &nb= sp;       \      = ;        /
            &nb= sp;        \     = ;       /
            &nb= sp;         \ |------| /
            &nb= sp;          \|  &nbs= p;C' |/
            &nb= sp;           |------= |

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D &= nbsp;and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiate= s (I'll skip the details) insertion of AIS (with LDI flag set after some sta= bilization) into the LSP. These AIS/LDI packets will be captured by the LSP = MEP in D.
I believe you mean E here.

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for = this LSP, starting at B and terminated at D, D would be the merge point. Not= e that C would not be aware of this action, and D would not aware of AIS ins= ertion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid tra= ffic coming thru bypass.
The current draft is limited to the operation of PWs,= bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is = the current scope of MPLS-TP.  The draft  states that action based= on the receipt of an LDI flag is optional.  In this situation you woul= d clearly want to ignore the flag.  The only other affect is to suppres= s alarms.  But as there is no alarm to suppress, that will have no effe= ct.

This is definitely not healthy, and the draft does not define any ways to a= void that.
If you would like to begin a draft on applying AIS to= other types of LSPs, that would be much appreciated.

The text in the draft that deals with protection seems to refer to link pro= tection rather than to LSP protection.
I agree that that is not clear.  I’ve upda= ted section 2 para 3 with, “When a server layer, (e.g. a link or bidir= ectional LSP) used by the bidir-LSP fails,....”

IMHO the same problem would appear in the case of segment protection if a l= ink in the middle of a segment is broken, so this issue is not limited just = to FRR.

My second issue deals with association between links and LSPs that pass thr= u these links. Ability to insert Fault OAM messages into all the LSPs crossi= ng a certain link may be compromised IMHO in the case LSPs that use labels f= rom the per-platform space. It is not clear from the draft how the LSR that = has detected a link failure could decide whether Fault OAM messages should b= e inserted in a transit LSP (which it perceives as an ILM table entry) or no= t - because the actual LSP could be running thru a different link. The probl= em would presumably disappear if per-interface label space were used; but RF= C 5960 does not restrict MPLS-TP from using per-platform label space.
The issue is not per platform labels per se, but to t= he binding of PWs and LSPs to specific links (which includes hierarchical LS= Ps).  I’ve updated section 2 para 3 with “Fault OAM message= s are generated by intermediate nodes where a bidir-LSP is switched and boun= d to specific server layers based upon static configuration or signaling.
...George

I apologize for sending these comments so late in the LC.

Regards,
     Sasha

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] O= n Behalf Of Loa Andersson
Sent: Thursday, February 03, 2011 1:37 PM
To: mpls-tp@ietf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

Please send comments to the mpls-tp@ietf.org= mailing list.

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson           &= nbsp;            = ; email: loa.andersson@ericsson.co= m
Sr Strategy and Standards Manager        = ;    loa@pi.nu
Ericsson Inc           &n= bsp;            =   phone: +46 10 717 52 13
            &nb= sp;            &= nbsp;            = ;        +46 767 72 92 13



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.or= g/mailman/listinfo/mpls-tp
This e-mail message is intended for the recipient only and con= tains information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform us b= y e-mail, phone or fax, and then delete the original and all copies thereof.=

--B_3395737411_171788778-- From swallow@cisco.com Tue Aug 9 13:05:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C03811E80D7 for ; Tue, 9 Aug 2011 13:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvXi0Dto1ts3 for ; Tue, 9 Aug 2011 13:05:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 40D0111E807E for ; Tue, 9 Aug 2011 13:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=25091; q=dns/txt; s=iport; t=1312920358; x=1314129958; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=gWXuZLDgAschb8bDkyxT1tUb6OdYkUI8+MRNY3F1zpk=; b=mmCI5HhKBs/kySpY4YX0mp98PyNva4PjOlDRQ5SIaEB9Kf+l57fEyL5b +OACa9pZA3iJw6flkocwVSfM8ABCmSWHmB26eChgJYcWej7gKk0Eht1Qp IN3VXLiS59UJVm3ps+fFYyW3kjFiJlvbi3Dwrz05rcKi7VR/mC1LyBpbM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAALCRQU6tJXG+/2dsb2JhbABCgk2VFI59YXeBQAEBAQECARIBFBY8BQ0BCBEEAQEBIAdNCQgBAQQOBRkJh0ufHQGeXYZGBIcti1iFEot1 X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208,217";a="11464892" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 09 Aug 2011 20:05:57 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p79K5vDR010265; Tue, 9 Aug 2011 20:05:57 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 15:05:57 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Aug 2011 20:05:56 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 09 Aug 2011 16:05:54 -0400 From: George Swallow To: Alexander Vainshtein Message-ID: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8B6/z8MARWNTqmAAfEj04= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395750755_172573690" X-OriginalArrivalTime: 09 Aug 2011 20:05:57.0356 (UTC) FILETIME=[C06E12C0:01CC56CF] Cc: mpls@ietf.org Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:05:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395750755_172573690 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sasha - See inline. On 7/18/11 11:15 AM, "Alexander Vainshtein" wrote: > George, > Lots of thanks for your response, and apologies for a delayed reaction. > =20 > I would like to present to you and the WG my reading of your responses, a= nd my > conclusions. > =20 > Regarding my comment about effect of FRR (or segment protection) on AIS/L= DI, > your response includes two statements: > 1. The draft only applies to =B3the operation of PWs, bi-directional = LSPs > and sections and LSP 1:1 and 1+1 protection as that is the current scope = of > MPLS-TP=B2 >=20 GS> Agree that my statement in the email is stronger than the text in the draft. > a. This seems to imply that FRR and segment protection are out of s= cope. >=20 > b. To the best of my understanding, the draft does not explicitly st= ate > that LSPs protected by FRR are out of scope. GS> Correct. > c. It only says =B3Fault OAM messages are applicable to Bidirectional > Co-Routed LSPs and to Multi-Segment Pseudowires=B2 > d. One could possibly imply that any actions (like FRR in link-and-n= ode > protection mode) that break co-routed nature of a bidirectional LSP are b= eyond > the scope of the draft (not sure about the scope MPLS-TP). However: > i. It= is > not clear (at least, to me) why bi-directionality is so important for the > draft which only defines downstream messages GS> Yes. AIS and LKR certainly apply. And I suppose some use could be made of LDI to switch between feeds of non-continuous traffic. But I don=B9t want to expand the scope of the document to cover this as we have an immediate need for the transport profile, and other applications are not well explored at this time. > ii. IMH= O an > explicit statement of this kind (preferably in the Applicability Statemen= t > section) would make the life of a potential reader much easier. >=20 GS> perhaps, but I do not want to limit future applicability. >=20 > 2. The draft states that =B3action based on the receipt of an LDI fla= g is > optional=B2: > 1. I=B9ve scanned the draft for the word =B3OPTIONAL=B2, (case-insensitive) and= did > not find this statement. Did I miss something? GS> Yes. Section 6 =B3 The following items are optional to implement. =20 2. Support of receiving the L-flag.=B2 > b. The text that I=B9ve found in Section 2.3 of the draft and that lo= oks > relevant states: =B3If the CC function is disabled, a MEP SHOULD generate A= IS > messages toward any client when either the AIS or LCK indication is rais= ed.=B2 > IMHO this is not OPTIONAL, it is RECOMMENDED >=20 GS> This does not say anything about the receipt to LDI! In fact it goes o= n to say =B3Note that the L-flag is not automatically propagated, i.e. the rules of Section 2.1.1 apply, that is the L-flag is not set until a fault has been declared.=B2 > c. The quoted text in the draft contains a couple of types (I=B9ve re= moved > them). >=20 GS> Thanks. One more though LCK -> LKR. ...George > =20 > Regarding my comment about association between links and LSPs that pass t= hru > these links =AD I think that the text to which you refer clarifies this iss= ue. > =20 >=20 > Regards, > Sasha > =20 >=20 > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, July 08, 2011 10:48 PM > To: Alexander Vainshtein; Loa Andersson > Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > =20 >=20 > Sasha - >=20 > On 3/1/11 7:36 AM, "Alexander Vainshtein" > wrote: > Loa, and all, > I have two LC comments on the draft. in question. They both refer to issu= es > I've raised in private discussions with George and Matthew and which, to = the > best of my understanding, have not been resolved in the -03 version. >=20 > My first issue deals with potential dangers of sending fault OAM messages= in > conjunction with certain protection mechanisms. >=20 > The example I've presented to George and Matthew deals with the situatio= n > when the LSP in question employs Facility FRR for node protection. >=20 > The topology is shown below: >=20 >=20 > |------| |-----| |-----| |-----| |-----| > | A |<--->| B |<--->| C |<--->| D |<--->| E | > |------| |-----| |-----| |-----| |-----| > \ / > \ / > \ / > \ / > \ / > \ / > \ |------| / > \| C' |/ > |------| >=20 > The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs i= n the > rest of the nodes. > If the link BC is broken, the link-level MEP at C detects that and initia= tes > (I'll skip the details) insertion of AIS (with LDI flag set after some > stabilization) into the LSP. These AIS/LDI packets will be captured by th= e LSP > MEP in D. > I believe you mean E here. >=20 > Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this= LSP, > starting at B and terminated at D, D would be the merge point. Note that = C > would not be aware of this action, and D would not aware of AIS insertion > undertaken by C. > As a consequence, E would receive both AIS/LDI generated by C and valid > traffic coming thru bypass. > The current draft is limited to the operation of PWs, bi-directional LSPs= and > sections and LSP 1:1 and 1+1 protection as that is the current scope of > MPLS-TP. The draft states that action based on the receipt of an LDI fl= ag is > optional. In this situation you would clearly want to ignore the flag. = The > only other affect is to suppress alarms. But as there is no alarm to > suppress, that will have no effect. >=20 > This is definitely not healthy, and the draft does not define any ways to > avoid that. > If you would like to begin a draft on applying AIS to other types of LSPs= , > that would be much appreciated. >=20 > The text in the draft that deals with protection seems to refer to link > protection rather than to LSP protection. > I agree that that is not clear. I=B9ve updated section 2 para 3 with, =B3Whe= n a > server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP > fails,....=B2 >=20 > IMHO the same problem would appear in the case of segment protection if a= link > in the middle of a segment is broken, so this issue is not limited just t= o > FRR. >=20 > My second issue deals with association between links and LSPs that pass t= hru > these links. Ability to insert Fault OAM messages into all the LSPs cross= ing a > certain link may be compromised IMHO in the case LSPs that use labels fro= m the > per-platform space. It is not clear from the draft how the LSR that has > detected a link failure could decide whether Fault OAM messages should be > inserted in a transit LSP (which it perceives as an ILM table entry) or n= ot - > because the actual LSP could be running thru a different link. The proble= m > would presumably disappear if per-interface label space were used; but RF= C > 5960 does not restrict MPLS-TP from using per-platform label space. > The issue is not per platform labels per se, but to the binding of PWs an= d > LSPs to specific links (which includes hierarchical LSPs). I=B9ve updated > section 2 para 3 with =B3Fault OAM messages are generated by intermediate n= odes > where a bidir-LSP is switched and bound to specific server layers based u= pon > static configuration or signaling. >=20 > ...George=20 >=20 > I apologize for sending these comments so late in the LC. >=20 > Regards, > Sasha >=20 --B_3395750755_172573690 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Sasha -=

See inline.


On 7/18/11 11:15 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:
George,
Lots of thanks for your response, and apologies for a delayed reaction.
 
I would like to present to you and the WG my reading of your responses, and= my conclusions.
 
Regarding my comment about effect of FRR (or segment protection) on AIS/LDI= , your response includes two statements:
1.       The draft only applies to “the operation of PWs= , bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is= the current scope of MPLS-TP”

= GS> Agree that my statement in the email is = stronger than the text in the draft.

a.     = ;  This seems to imply that FRR and segment protection are out of = scope.


GS> Correct.

c.     = ;  It only says “Fault OAM messages are applic= able to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires= ”
d.      One could possibly imply that any actions = (like FRR in link-and-node protection mode) that break co-routed nature of a= bidirectional LSP are beyond the scope of the draft (not sure about the sco= pe MPLS-TP). However:
            &nb= sp;            &= nbsp;            = ;            &nb= sp;            i= .      It is not clear (at least, to me) why bi-dir= ectionality is so important for the draft which only defines downstream mess= ages

GS> Yes.   AIS and LKR certainly apply. =  And I suppose some use could be made of LDI to switch between feeds of= non-continuous traffic.  But I don’t want to expand the scope of= the document to cover this as we have an immediate need for the transport p= rofile, and other applications are not well explored at this time.
    &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;     ii.      IMHO an exp= licit statement of this kind (preferably in the Applicability Statement sect= ion) would make the life of a potential reader much easier.

GS> perhaps, but I do not want to lim= it future applicability.

2.       = ;The draft states that “action based on the receipt of an LDI flag is optional”:<= BR>
  1. I’ve scann= ed the draft for the word “OPTIONAL”, (case-insensitive) and did= not find this statement. Did I miss something?

GS> Yes.  Section 6

    “ The following items are optional to impleme= nt.
   
   2.  Support of receiving the L-flag.”

b.     = ; The text that I’ve found in Section 2.3 of the draft  and = that looks relevant states: “If the CC function is disab= led, a MEP SHOULD generate AIS messages toward any client when either the AI= S or LCK indication is  raised.”  IMHO this is not OPTIONAL, it is RECOMMENDED

GS> This does not say anything about = the receipt to LDI!  In fact it goes on to say “Note that the L-f= lag is not automatically propagated, i.e.
   the rules of Section 2.1.1 apply, that is the L-flag is n= ot set until a fault has been declared.”
c.     = ;  The quoted text in the draft contains a couple of types (I̵= 7;ve removed them).

GS> Thanks.  One more though LCK= -> LKR.

...George
<= SPAN STYLE=3D'font-size:11pt'>
Regarding my comment about association between links and LSPs that pass thru these links R= 11; I think that the text to which you refer clarifies this issue.



From: George Swallow [mailto:swallow@cisco.com]
Sent: Friday, July 08, 2011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:
Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages i= n conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situa= tion when the LSP in question employs Facility FRR for node protection.

The topology is shown below:


|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
|  A   |<--->|  B  |<--->|  C &nb= sp;|<--->|  D  |<--->|  E  |
|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
            &nb= sp;   \          = ;            /             &nb= sp;    \         = ;           /
            &nb= sp;     \        = ;          /
            &nb= sp;      \       = ;         /
            &nb= sp;       \      = ;        /
            &nb= sp;        \     = ;       /
            &nb= sp;         \ |------| /
            &nb= sp;          \|  &nbs= p;C' |/
            &nb= sp;           |------= |

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D &= nbsp;and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiate= s (I'll skip the details) insertion of AIS (with LDI flag set after some sta= bilization) into the LSP. These AIS/LDI packets will be captured by the LSP = MEP in D.
I believe you mean E here.

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for = this LSP, starting at B and terminated at D, D would be the merge point. Not= e that C would not be aware of this action, and D would not aware of AIS ins= ertion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid tra= ffic coming thru bypass.
The current draft is limited to the operation of PWs,= bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is = the current scope of MPLS-TP.  The draft  states that action based= on the receipt of an LDI flag is optional.  In this situation you woul= d clearly want to ignore the flag.  The only other affect is to suppres= s alarms.  But as there is no alarm to suppress, that will have no effe= ct.

This is definitely not healthy, and the draft does not define any ways to a= void that.
If you would like to begin a draft on applying AIS to= other types of LSPs, that would be much appreciated.

The text in the draft that deals with protection seems to refer to link pro= tection rather than to LSP protection.
I agree that that is not clear.  I’ve upda= ted section 2 para 3 with, “When a server layer, (e.g. a link or bidir= ectional LSP) used by the bidir-LSP fails,....”

IMHO the same problem would appear in the case of segment protection if a l= ink in the middle of a segment is broken, so this issue is not limited just = to FRR.

My second issue deals with association between links and LSPs that pass thr= u these links. Ability to insert Fault OAM messages into all the LSPs crossi= ng a certain link may be compromised IMHO in the case LSPs that use labels f= rom the per-platform space. It is not clear from the draft how the LSR that = has detected a link failure could decide whether Fault OAM messages should b= e inserted in a transit LSP (which it perceives as an ILM table entry) or no= t - because the actual LSP could be running thru a different link. The probl= em would presumably disappear if per-interface label space were used; but RF= C 5960 does not restrict MPLS-TP from using per-platform label space.
The issue is not per platform labels per se, but to t= he binding of PWs and LSPs to specific links (which includes hierarchical LS= Ps).  I’ve updated section 2 para 3 with “Fault OAM message= s are generated by intermediate nodes where a bidir-LSP is switched and boun= d to specific server layers based upon static configuration or signaling.
...George

I apologize for sending these comments so late in the LC.

Regards,
     Sasha

--B_3395750755_172573690-- From Alexander.Vainshtein@ecitele.com Tue Aug 9 14:24:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C870611E808E for ; Tue, 9 Aug 2011 14:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlSuwiglHIa7 for ; Tue, 9 Aug 2011 14:24:29 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC011E808B for ; Tue, 9 Aug 2011 14:24:28 -0700 (PDT) X-AuditID: 93eaf2e8-b7ce7ae000000a69-24-4e419ede5c6f Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 32.85.02665.EDE914E4; Tue, 9 Aug 2011 23:55:58 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 10 Aug 2011 00:23:58 +0300 From: Alexander Vainshtein To: George Swallow Date: Wed, 10 Aug 2011 00:20:10 +0300 Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8B6/z8MARWNTqmAApe6Vo= Message-ID: References: , In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD438ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLsWRmVeSWpSXmKPExsUy+dWnL7r35jn6GUxfKWnxb+4cZovDXXcZ LZ4+c7G4tXQlq8XtKU2MDqwerc/2snpM+b2R1WPJkp9MHrOmt7EFsEQ1MNok5uXllySWpCqk pBYn2yoFFGWWJSZXKilkptgqGSopFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8 lMy8dFslz2B/XQsLU0tdQyU7NWVDY2uukIzMYoVU3dzEzByF3NTi4sT0VAWgSMIW5oy9q+6z FGz8wVgxrT2ngfHYRcYuRk4OCQETiR2Pt7BB2GISF+6tB7K5OIQEdjJKXL14kgnCmcIo0bDu OxNIFZuArcSm1XfBOkQE1CTeLZnBClLELDCTUeLe0jfMXYwcHCwCqhLNV/JBaoQFnCRm3p7M BBIWEXCWWDA5GaLVT+LIoqPMIDavQKBE45wrYLaQQJHEsQXXwWxOAX2JZ78Pgx3KCHTc91Nr wE5gFhCXuPVkPhPE0QISS/acZ4awRSVePv7HClEvKnGnfT0jyFpmgXyJtp9MEKsEJU7OfMIC US4pcXDFDZYJjGKzkEydhdAxC0kHRImBxPtz85khbG2JZQtfQ9n6Ehu/nGVEFl/AyL6KUTIz p6AkKTfdwEg3v7RELzU5syQ1J1UvOT93EyMkWb3YwXj7jOYhRgEORiUeXkYOBz8h1sSy4src Q4ySHExKorx9Sxz9hPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwPpkFlONNSaysSi3Kh0m5AkN/ IrMUd3I+MAHnlcQbGxjg5iiJ83Ynv/EVEkgHJs7s1NSC1CKYOTIcHEoSvOdA1gsWpaanVqRl 5pQgpJk4OEHO4AE64wRIDW9xQWJucWY6RP4UozHH2o8fjzJynHv15SijEEtefl6qlDjvPZBS AZDSjNI8uGmgLFb/////V4ziwGAQ5j0FUsUDzIBw814BrWICWlV/xwFkFTArwaWkGhh1AqUM JutqT63Lu+3mbu1js/9JuMFDf75Vtwu5y9x6p8w6t3IB38EtbkYCBhHZgWeiS17eN2mWZ3Xr FvwTpXjR5uHS3eWKT7OlUvfdLNlmtEJfJbmk5PltOePrRbJBH2KucviqB6x+u6aw7uNBk0u9 fx17Tv/nbflg5lM8JSDUsnuzx5SGBCWW4oxEQy3mouJEAIL5cZc9BAAA Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:24:30 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD438ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable George, Lots of thanks for a very detailed response. One more comment: I understand that you do not want to limit future applicability. But IMHO and FWIW this could be part of the explicit applicability statement= - distinguishing the cases where you claim applicability today and other c= ase where applicability is FFS. Regards, Sasha ________________________________ From: George Swallow [swallow@cisco.com] Sent: Tuesday, August 09, 2011 7:23 PM To: Alexander Vainshtein Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 On 7/18/11 11:15 AM, "Alexander Vainshtein" > wrote: George, Lots of thanks for your response, and apologies for a delayed reaction. I would like to present to you and the WG my reading of your responses, and= my conclusions. Regarding my comment about effect of FRR (or segment protection) on AIS/LDI,= your response includes two statements: 1. The draft only applies to =93the operation of PWs, bi-directional L= SPs and sections and LSP 1:1 and 1+1 protection as that is the current scope= of MPLS-TP=94 GS> Agree that my statement in the email is stronger than the text in the dr= aft. a. This seems to imply that FRR and segment protection are out of scop= e. b. To the best of my understanding, the draft does not explicitly state= that LSPs protected by FRR are out of scope. GS> Correct. c. It only says =93Fault OAM messages are applicable to Bidirectional= Co-Routed LSPs and to Multi-Segment Pseudowires=94 d. One could possibly imply that any actions (like FRR in link-and-node= protection mode) that break co-routed nature of a bidirectional LSP are bey= ond the scope of the draft (not sure about the scope MPLS-TP). However: i. It is= not clear (at least, to me) why bi-directionality is so important for the d= raft which only defines downstream messages GS> Yes. AIS and LKR certainly apply. And I suppose some use could be mad= e of LDI to switch between feeds of non-continuous traffic. But I don=92t w= ant to expand the scope of the document to cover this as we have an immediat= e need for the transport profile, and other applications are not well explor= ed at this time. ii. IMHO an= explicit statement of this kind (preferably in the Applicability Statement= section) would make the life of a potential reader much easier. GS> perhaps, but I do not want to limit future applicability. 2. The draft states that =93action based on the receipt of an LDI flag= is optional=94: 1. I=92ve scanned the draft for the word =93OPTIONAL=94, (case-insensitive= ) and did not find this statement. Did I miss something? GS> Yes. Section 6 =93 The following items are optional to implement. 2. Support of receiving the L-flag.=94 b. The text that I=92ve found in Section 2.3 of the draft and that loo= ks relevant states: =93If the CC function is disabled, a MEP SHOULD generate= AIS messages toward any client when either the AIS or LCK indication is ra= ised.=94 IMHO this is not OPTIONAL, it is RECOMMENDED GS> This does not say anything about the receipt to LDI! In fact it goes on= to say =93Note that the L-flag is not automatically propagated, i.e. the rules of Section 2.1.1 apply, that is the L-flag is not set until a f= ault has been declared.=94 c. The quoted text in the draft contains a couple of types (I=92ve rem= oved them). GS> Thanks. One more though LCK -> LKR. ...George Regarding my comment about association between links and LSPs that pass thru= these links =96 I think that the text to which you refer clarifies this iss= ue. Regards, Sasha From: George Swallow [mailto:swallow@cisco.com] Sent: Friday, July 08, 2011 10:48 PM To: Alexander Vainshtein; Loa Andersson Cc: mpls-tp@ietf.org; mpl= s@ietf.org; BOCCI Matthew Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Sasha - On 3/1/11 7:36 AM, "Alexander Vainshtein" > wrote: Loa, and all, I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version. My first issue deals with potential dangers of sending fault OAM messages in= conjunction with certain protection mechanisms. The example I've presented to George and Matthew deals with the situation w= hen the LSP in question employs Facility FRR for node protection. The topology is shown below: |------| |-----| |-----| |-----| |-----| | A |<--->| B |<--->| C |<--->| D |<--->| E | |------| |-----| |-----| |-----| |-----| \ / \ / \ / \ / \ / \ / \ |------| / \| C' |/ |------| The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs in t= he rest of the nodes. If the link BC is broken, the link-level MEP at C detects that and initiates= (I'll skip the details) insertion of AIS (with LDI flag set after some stab= ilization) into the LSP. These AIS/LDI packets will be captured by the LSP M= EP in D. I believe you mean E here. Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this LS= P, starting at B and terminated at D, D would be the merge point. Note that= C would not be aware of this action, and D would not aware of AIS insertion= undertaken by C. As a consequence, E would receive both AIS/LDI generated by C and valid traf= fic coming thru bypass. The current draft is limited to the operation of PWs, bi-directional LSPs an= d sections and LSP 1:1 and 1+1 protection as that is the current scope of MP= LS-TP. The draft states that action based on the receipt of an LDI flag is= optional. In this situation you would clearly want to ignore the flag. Th= e only other affect is to suppress alarms. But as there is no alarm to supp= ress, that will have no effect. This is definitely not healthy, and the draft does not define any ways to av= oid that. If you would like to begin a draft on applying AIS to other types of LSPs, t= hat would be much appreciated. The text in the draft that deals with protection seems to refer to link prot= ection rather than to LSP protection. I agree that that is not clear. I=92ve updated section 2 para 3 with, =93Wh= en a server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP= fails,....=94 IMHO the same problem would appear in the case of segment protection if a li= nk in the middle of a segment is broken, so this issue is not limited just t= o FRR. My second issue deals with association between links and LSPs that pass thru= these links. Ability to insert Fault OAM messages into all the LSPs crossin= g a certain link may be compromised IMHO in the case LSPs that use labels fr= om the per-platform space. It is not clear from the draft how the LSR that h= as detected a link failure could decide whether Fault OAM messages should be= inserted in a transit LSP (which it perceives as an ILM table entry) or not= - because the actual LSP could be running thru a different link. The proble= m would presumably disappear if per-interface label space were used; but RFC= 5960 does not restrict MPLS-TP from using per-platform label space. The issue is not per platform labels per se, but to the binding of PWs and L= SPs to specific links (which includes hierarchical LSPs). I=92ve updated se= ction 2 para 3 with =93Fault OAM messages are generated by intermediate node= s where a bidir-LSP is switched and bound to specific server layers based up= on static configuration or signaling. ...George I apologize for sending these comments so late in the LC. Regards, Sasha -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, February 03, 2011 1:37 PM To: mpls-tp@ietf.org; mpl= s@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD438ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
George,
Lots of thanks for a very detailed response.
 
One more comment:
 
I understand that you do not want to limit future applicability.
But IMHO and FWIW this could be part of the explicit applicability stat= ement  - distinguishing the cases where you claim applicability today a= nd other case where applicability is FFS.
 
Regards,
     Sasha
 
From: George Swall= ow [swallow@cisco.com]
Sent: Tuesday, August 09, 2011 7:23 PM
To: Alexander Vainshtein
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
Alexander.Vain= shtein@ecitele.com> wrote:
George,
Lots of thanks for your response, and apologies for a delayed reaction.
 
I would like to present to you and the WG my reading of your responses, and= my conclusions.
 
Regarding my comment about effect of FRR (or segment protection) on AIS/LDI,= your response includes two statements:
1.       The draft only applies to =93<= /font>the operation= of PWs, bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is the current scope of MPLS-TP=94

GS> Agree that my statement in the email is stronger than the text= in the draft.
a.      &= nbsp;This seems to imply that FRR and segment protection are out of scope.
b.      To the best of my understanding, the d= raft does not explicitly state that LSPs protected by FRR are out of scope.

GS> Correct.
c.      &= nbsp;It only says =93Fault OAM messages are applicable to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires=94
d.      One could possibly imply that any actions (= like FRR in link-and-node protection mode) that break co-routed nature of a= bidirectional LSP are beyond the scope of the draft (not sure about the sco= pe MPLS-TP). However:
            &nbs= p;            &n= bsp;            =             &nbs= p;            i.=      It is not clear (at least, to me) why bi-dire= ctionality is so important for the draft which only defines downstream messa= ges

GS> Yes.   AIS and LKR certainly app= ly.  And I suppose some use could be made of LDI to switch between feed= s of non-continuous traffic.  But I don=92t want to expand the scope of the document to cover this as we have an immediate need for th= e transport profile, and other applications are not well explored at this ti= me.
     &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;   ii.      IMHO an explicit sta= tement of this kind (preferably in the Applicability Statement section) would make the life of a potential reader much easier.

GS> perhaps, but I do not want to limit future applicability.
<= br> 2.      = ; The draft states that =93action based on the receipt of an LDI flag is optional=94:
  1. I=92ve scanned the draft for the word =93O= PTIONAL=94, (case-insensitive) and did not find this statement. Did I miss s= omething?

GS> Yes.  Section 6

    =93 The following items are optional to implement.    
   2.  Support of receiving the L-flag.=94
b.      T= he text that I=92ve found in Section 2.3 of the draft  and that looks r= elevant states: =93If the CC function is disabled, a MEP SHOULD generate AIS messages toward any= client when either the AIS or LCK indication is  raised.= =94  IMHO this is not OPTIONAL, it is RECOMMENDED

GS> This does not say anything about the receipt to LDI!  In= fact it goes on to say =93Note that the L-flag is not automatically propaga= ted, i.e.
   the rules of Section 2.1.1 apply, that is the L-flag is no= t set until a fault has been declared.=94
c.      &= nbsp;The quoted text in the draft contains a couple of types (I=92ve removed= them).

GS> Thanks.  One more though LCK -> LKR.

...George

Regarding my comment about association between links and LSPs that pass thru these links= =96 I think that the text to which you refer clarifies this issue.


Regards,
     Sasha
 

From: George Swallow [mailto:swallow@cisco.com]
Sent: Friday, July 08, 2011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainsh= tein@ecitele.com> wrote:
Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages in= conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situat= ion when the LSP in question employs Facility FRR for node protection.

The topology is shown below:


|------|     |-----|     |-----| &nb= sp;   |-----|     |-----|
|  A   |<--->|  B  |<--->|  C &nbs= p;|<--->|  D  |<--->|  E  |
|------|     |-----|     |-----| &nb= sp;   |-----|     |-----|
            &nbs= p;   \          =             /             &nbs= p;    \         =            /
            &nbs= p;     \        =           /
            &nbs= p;      \       =          /
            &nbs= p;       \      =         /
            &nbs= p;        \     =        /
            &nbs= p;         \ |------| /
            &nbs= p;          \|   = ;C' |/
            &nbs= p;           |------|=

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D &n= bsp;and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiates= (I'll skip the details) insertion of AIS (with LDI flag set after some stab= ilization) into the LSP. These AIS/LDI packets will be captured by the LSP M= EP in D.
I believe you mean E here.

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for t= his LSP, starting at B and terminated at D, D would be the merge point. Note= that C would not be aware of this action, and D would not aware of AIS inse= rtion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid traf= fic coming thru bypass.
The current draft is limited to the operation of PWs= , bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as tha= t is the current scope of MPLS-TP.  The draft  states that action= based on the receipt of an LDI flag is optional.  In this situation you would clearly want to ignore the flag.  Th= e only other affect is to suppress alarms.  But as there is no alarm to= suppress, that will have no effect.

This is definitely not healthy, and the draft does not define any ways to av= oid that.
If you would like to begin a draft on applying AIS t= o other types of LSPs, that would be much appreciated.

The text in the draft that deals with protection seems to refer to link prot= ection rather than to LSP protection.
I agree that that is not clear.  I=92ve updated= section 2 para 3 with, =93When a server layer, (e.g. a link or bidirectiona= l LSP) used by the bidir-LSP fails,....=94

IMHO the same problem would appear in the case of segment protection if a li= nk in the middle of a segment is broken, so this issue is not limited just t= o FRR.

My second issue deals with association between links and LSPs that pass thru= these links. Ability to insert Fault OAM messages into all the LSPs crossin= g a certain link may be compromised IMHO in the case LSPs that use labels fr= om the per-platform space. It is not clear from the draft how the LSR that has detected a link failure co= uld decide whether Fault OAM messages should be inserted in a transit LSP (w= hich it perceives as an ILM table entry) or not - because the actual LSP cou= ld be running thru a different link. The problem would presumably disappear if per-interface label space w= ere used; but RFC 5960 does not restrict MPLS-TP from using per-platform lab= el space.
The issue is not per platform labels per se, but to= the binding of PWs and LSPs to specific links (which includes hierarchical= LSPs).  I=92ve updated section 2 para 3 with =93Fault OAM messages are= generated by intermediate nodes where a bidir-LSP is switched and bound to specific server layers based upon static configura= tion or signaling.

...George

I apologize for sending these comments so late in the LC.

Regards,
     Sasha

-----Original Message-----
From: mpls-tp-bounces@ietf.org [ma= ilto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Thursday, February 03, 2011 1:37 PM
To: mpls-tp@ietf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

Please send comments to the mpls-tp@ietf.org mailing list.

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson           &n= bsp;            =  email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager        =     loa@pi.nu
Ericsson Inc           &nb= sp;            &= nbsp; phone: +46 10 717 52 13
            &nbs= p;            &n= bsp;            =         +46 767 72 92 13



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
= https://www.ietf.org/mailman/listinfo/mpls-tp
This e-mail message is intended for the recipient only and= contains information which is CONFIDENTIAL and which may be proprietary to= ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and t= hen delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD438ILPTMAIL02e_-- From swallow@cisco.com Tue Aug 9 15:14:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CF221F86AF for ; Tue, 9 Aug 2011 15:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVB6CgBPHvHb for ; Tue, 9 Aug 2011 15:14:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5921F8B9D for ; Tue, 9 Aug 2011 15:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=34625; q=dns/txt; s=iport; t=1312928072; x=1314137672; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=h6bDhh6DGEsp29kY3hp4lv6+FFUvjzF534yu99DzaaI=; b=laIpaQUOCBaSKSN664P8koMElsh0XweOk0Jj7ccTsVbGmWqU4VtzRboE u0nT+86D0Na4UDCWt32qm/pLgZiYrvEMfnEivrJBS5nf+PyfwPBnnuFjC jFCdp0h8hfzq7Ykntbm/SxxknotmQVGORudPAuT6XYg+gW0O77u20Yj9b 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAAWxQU6tJV2b/2dsb2JhbABCgk2VFY58YXeBQAEBAQECAQEBAQ8BFBYxCwUHAgQBCBEEAQEBIAEGIgwBHgkIAgQOBRkJh0sEoCMBnkYChkQEhy6JTIIOhRKLdQ X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208,217";a="11507076" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2011 22:14:31 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p79MEUSZ014405; Tue, 9 Aug 2011 22:14:30 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 17:14:30 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Aug 2011 22:14:30 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 09 Aug 2011 18:14:28 -0400 From: George Swallow To: Alexander Vainshtein Message-ID: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8B6/z8MARWNTqmAApe6VoAAeMgKg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395758468_173016600" X-OriginalArrivalTime: 09 Aug 2011 22:14:30.0732 (UTC) FILETIME=[B5F5D8C0:01CC56E1] Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 22:14:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395758468_173016600 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable OK, I=B9ll add something on FFS. ...George On 8/9/11 5:20 PM, "Alexander Vainshtein" wrote: > George, > Lots of thanks for a very detailed response. > =20 > One more comment: > =20 > I understand that you do not want to limit future applicability. > But IMHO and FWIW this could be part of the explicit applicability statem= ent > - distinguishing the cases where you claim applicability today and other = case > where applicability is FFS. > =20 > Regards, > Sasha > =20 >=20 > From: George Swallow [swallow@cisco.com] > Sent: Tuesday, August 09, 2011 7:23 PM > To: Alexander Vainshtein > Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 >=20 >=20 >=20 >=20 > On 7/18/11 11:15 AM, "Alexander Vainshtein" > wrote: >=20 >> George, >> Lots of thanks for your response, and apologies for a delayed reaction. >> =20 >> I would like to present to you and the WG my reading of your responses, = and >> my conclusions. >> =20 >> Regarding my comment about effect of FRR (or segment protection) on AIS/= LDI, >> your response includes two statements: >> 1. The draft only applies to =B3the operation of PWs, bi-directional= LSPs >> and sections and LSP 1:1 and 1+1 protection as that is the current scope= of >> MPLS-TP=B2 >>=20 > GS> Agree that my statement in the email is stronger than the text in the > draft. >=20 >> a. This seems to imply that FRR and segment protection are out of >> scope. >>=20 >> b. To the best of my understanding, the draft does not explicitly s= tate >> that LSPs protected by FRR are out of scope. >=20 > GS> Correct. >=20 >> c. It only says =B3Fault OAM messages are applicable to Bidirectiona= l >> Co-Routed LSPs and to Multi-Segment Pseudowires=B2 >> d. One could possibly imply that any actions (like FRR in link-and-= node >> protection mode) that break co-routed nature of a bidirectional LSP are >> beyond the scope of the draft (not sure about the scope MPLS-TP). Howeve= r: >> i. I= t is >> not clear (at least, to me) why bi-directionality is so important for th= e >> draft which only defines downstream messages >=20 > GS> Yes. AIS and LKR certainly apply. And I suppose some use could be = made > of LDI to switch between feeds of non-continuous traffic. But I don=B9t wa= nt to > expand the scope of the document to cover this as we have an immediate ne= ed > for the transport profile, and other applications are not well explored a= t > this time. >=20 >> ii. IMH= O an >> explicit statement of this kind (preferably in the Applicability Stateme= nt >> section) would make the life of a potential reader much easier. >>=20 > GS> perhaps, but I do not want to limit future applicability. >>=20 >> 2. The draft states that =B3action based on the receipt of an LDI fl= ag is >> optional=B2: >> 1. I=B9ve scanned the draft for the word =B3OPTIONAL=B2, (case-insensitive) an= d did >> not find this statement. Did I miss something? >=20 > GS> Yes. Section 6 >=20 > =B3 The following items are optional to implement. > =20 > 2. Support of receiving the L-flag.=B2 >=20 >> b. The text that I=B9ve found in Section 2.3 of the draft and that l= ooks >> relevant states: =B3If the CC function is disabled, a MEP SHOULD generate = AIS >> messages toward any client when either the AIS or LCK indication is rai= sed.=B2 >> IMHO this is not OPTIONAL, it is RECOMMENDED >>=20 > GS> This does not say anything about the receipt to LDI! In fact it goes= on > to say =B3Note that the L-flag is not automatically propagated, i.e. > the rules of Section 2.1.1 apply, that is the L-flag is not set until = a > fault has been declared.=B2 >=20 >> c. The quoted text in the draft contains a couple of types (I=B9ve >> removed them). >>=20 > GS> Thanks. One more though LCK -> LKR. >=20 > ...George >>=20 >> Regarding my comment about association between links and LSPs that pass = thru >> these links =AD I think that the text to which you refer clarifies this is= sue. >>=20 >>=20 >> Regards, >> Sasha >> =20 >>=20 >> From: George Swallow [mailto:swallow@cisco.com] >> Sent: Friday, July 08, 2011 10:48 PM >> To: Alexander Vainshtein; Loa Andersson >> Cc: mpls-tp@ietf.org = ; >> mpls@ietf.org ; BOCC= I >> Matthew >> Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 >>=20 >>=20 >> Sasha - >>=20 >> On 3/1/11 7:36 AM, "Alexander Vainshtein" > > wrote: >> Loa, and all, >> I have two LC comments on the draft. in question. They both refer to iss= ues >> I've raised in private discussions with George and Matthew and which, to= the >> best of my understanding, have not been resolved in the -03 version. >>=20 >> My first issue deals with potential dangers of sending fault OAM message= s in >> conjunction with certain protection mechanisms. >>=20 >> The example I've presented to George and Matthew deals with the situati= on >> when the LSP in question employs Facility FRR for node protection. >>=20 >> The topology is shown below: >>=20 >>=20 >> |------| |-----| |-----| |-----| |-----| >> | A |<--->| B |<--->| C |<--->| D |<--->| E | >> |------| |-----| |-----| |-----| |-----| >> \ / >> \ / >> \ / >> \ / >> \ / >> \ / >> \ |------| / >> \| C' |/ >> |------| >>=20 >> The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs = in >> the rest of the nodes. >> If the link BC is broken, the link-level MEP at C detects that and initi= ates >> (I'll skip the details) insertion of AIS (with LDI flag set after some >> stabilization) into the LSP. These AIS/LDI packets will be captured by t= he >> LSP MEP in D. >> I believe you mean E here. >>=20 >> Meanwhile, B could operate a node protection bypass (B-->C'-->D) for thi= s >> LSP, starting at B and terminated at D, D would be the merge point. Note= that >> C would not be aware of this action, and D would not aware of AIS insert= ion >> undertaken by C. >> As a consequence, E would receive both AIS/LDI generated by C and valid >> traffic coming thru bypass. >> The current draft is limited to the operation of PWs, bi-directional LSP= s and >> sections and LSP 1:1 and 1+1 protection as that is the current scope of >> MPLS-TP. The draft states that action based on the receipt of an LDI f= lag >> is optional. In this situation you would clearly want to ignore the fla= g. >> The only other affect is to suppress alarms. But as there is no alarm t= o >> suppress, that will have no effect. >>=20 >> This is definitely not healthy, and the draft does not define any ways t= o >> avoid that. >> If you would like to begin a draft on applying AIS to other types of LSP= s, >> that would be much appreciated. >>=20 >> The text in the draft that deals with protection seems to refer to link >> protection rather than to LSP protection. >> I agree that that is not clear. I=B9ve updated section 2 para 3 with, =B3Wh= en a >> server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP >> fails,....=B2 >>=20 >> IMHO the same problem would appear in the case of segment protection if = a >> link in the middle of a segment is broken, so this issue is not limited = just >> to FRR. >>=20 >> My second issue deals with association between links and LSPs that pass = thru >> these links. Ability to insert Fault OAM messages into all the LSPs cros= sing >> a certain link may be compromised IMHO in the case LSPs that use labels = from >> the per-platform space. It is not clear from the draft how the LSR that = has >> detected a link failure could decide whether Fault OAM messages should b= e >> inserted in a transit LSP (which it perceives as an ILM table entry) or = not - >> because the actual LSP could be running thru a different link. The probl= em >> would presumably disappear if per-interface label space were used; but R= FC >> 5960 does not restrict MPLS-TP from using per-platform label space. >> The issue is not per platform labels per se, but to the binding of PWs a= nd >> LSPs to specific links (which includes hierarchical LSPs). I=B9ve updated >> section 2 para 3 with =B3Fault OAM messages are generated by intermediate = nodes >> where a bidir-LSP is switched and bound to specific server layers based = upon >> static configuration or signaling. >>=20 >> ...George=20 >>=20 >> I apologize for sending these comments so late in the LC. >>=20 >> Regards, >> Sasha >>=20 >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Thursday, February 03, 2011 1:37 PM >> To: mpls-tp@ietf.org = ; >> mpls@ietf.org >> Cc: ahmpls-tp@lists.itu.int >> >> Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 >>=20 >> Working Group, >>=20 >> this is to start a four week working group last call >> on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). >>=20 >> Please send comments to the mpls-tp@ietf.org >> mailing list. >>=20 >> This working group last call ends on February 28, 2011. >>=20 >>=20 >>=20 >> Loa, George and Ross >>=20 >> MPLS wg co-chairs >>=20 >> -- >>=20 >> Loa Andersson email: loa.andersson@ericsson.com >> >> Sr Strategy and Standards Manager loa@pi.nu >> >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us by >> e-mail, phone or fax, and then delete the original and all copies thereo= f. >>=20 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI Tel= ecom. > If you have received this transmission in error, please inform us by e-ma= il, > phone or fax, and then delete the original and all copies thereof. >=20 --B_3395758468_173016600 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 OK, I&#= 8217;ll add something on FFS.

...George


On 8/9/11 5:20 PM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:

George,
Lots of thanks for a very detailed response.
 
One more comment:
 
I understand that you do not want to limit future applicability.
But IMHO and FWIW this could be part of the explicit applicability statemen= t  - distinguishing the cases where you claim applicability today and o= ther case where applicability is FFS.
 
Regards,
     Sasha
 
From: George Swallow [swall= ow@cisco.com]
Sent: Tuesday, August 09, 2011 7:23 PM
To: Alexander Vainshtein
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03


On 7/18/11 11:15 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com <https://mail.ecitele.com/= OWA/UrlBlockedError.aspx> > wrote:

George,
Lots of thanks for your response, and apologies for a delayed reaction.
 
I would like to present to you and the WG my reading of your responses, and= my conclusions.
 
Regarding my comment about effect of FRR (or segment protection) on AIS/LDI= , your response includes two statements:
1.       The draft only applies to “the operation of PWs= , bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is= the current scope of MPLS-TP”

= GS> Agree that my statement in the email is = stronger than the text in the draft.

a.     = ;  This seems to imply that FRR and segment protection are out of = scope.


GS> Correct.

c.     = ;  It only says “Fault OAM messages are applic= able to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires= ”
d.      One could possibly imply that any actions = (like FRR in link-and-node protection mode) that break co-routed nature of a= bidirectional LSP are beyond the scope of the draft (not sure about the sco= pe MPLS-TP). However:
            &nb= sp;            &= nbsp;            = ;            &nb= sp;            i= .      It is not clear (at least, to me) why bi-dir= ectionality is so important for the draft which only defines downstream mess= ages

GS> Yes.   AIS and LKR certainly apply. =  And I suppose some use could be made of LDI to switch between feeds of= non-continuous traffic.  But I don’t want to expand the scope of= the document to cover this as we have an immediate need for the transport p= rofile, and other applications are not well explored at this time.
    &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    ii.      IMHO an explicit = statement of this kind (preferably in the Applicability Statement section) w= ould make the life of a potential reader much easier.

GS> perhaps, but I do not want to lim= it future applicability.

2.       = ;The draft states that “action based on the receipt of an LDI flag is optional”:<= BR>
  1. I’ve scann= ed the draft for the word “OPTIONAL”, (case-insensitive) and did= not find this statement. Did I miss something?

GS> Yes.  Section 6

    “ The following items are optional to impleme= nt.
   
   2.  Support of receiving the L-flag.”

b.     = ; The text that I’ve found in Section 2.3 of the draft  and = that looks relevant states: “If the CC function is disab= led, a MEP SHOULD generate AIS messages toward any client when either the AI= S or LCK indication is  raised.”  IMHO this is not OPTIONAL, it is RECOMMENDED

GS> This does not say anything about = the receipt to LDI!  In fact it goes on to say “Note that the L-f= lag is not automatically propagated, i.e.
   the rules of Section 2.1.1 apply, that is the L-flag is n= ot set until a fault has been declared.”
c.     = ;  The quoted text in the draft contains a couple of types (I̵= 7;ve removed them).

GS> Thanks.  One more though LCK= -> LKR.

...George
<= SPAN STYLE=3D'font-size:11pt'>
Regarding my comment about association between links and LSPs that pass thru these links R= 11; I think that the text to which you refer clarifies this issue.



From: George Swallow [mailto:swallow@cisco.com]
Sent: Friday, July 08, 2011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc: mpls-tp@ietf.org <https://mail.ecitele.com/OWA= /UrlBlockedError.aspx> ; mpls@ietf.org &l= t;https://mail.e= citele.com/OWA/UrlBlockedError.aspx> ; BOCCI Matthew
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com <https://mail.ecitele.com/OW= A/UrlBlockedError.aspx> > wrote:
Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages i= n conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situa= tion when the LSP in question employs Facility FRR for node protection.

The topology is shown below:


|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
|  A   |<--->|  B  |<--->|  C &nb= sp;|<--->|  D  |<--->|  E  |
|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
            &nb= sp;   \          = ;            /             &nb= sp;    \         = ;           /
            &nb= sp;     \        = ;          /
            &nb= sp;      \       = ;         /
            &nb= sp;       \      = ;        /
            &nb= sp;        \     = ;       /
            &nb= sp;         \ |------| /
            &nb= sp;          \|  &nbs= p;C' |/
            &nb= sp;           |------= |

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D &= nbsp;and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiate= s (I'll skip the details) insertion of AIS (with LDI flag set after some sta= bilization) into the LSP. These AIS/LDI packets will be captured by the LSP = MEP in D.
I believe you mean E here.

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for = this LSP, starting at B and terminated at D, D would be the merge point. Not= e that C would not be aware of this action, and D would not aware of AIS ins= ertion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid tra= ffic coming thru bypass.
The current draft is limited to the operation of PWs,= bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is = the current scope of MPLS-TP.  The draft  states that action based= on the receipt of an LDI flag is optional.  In this situation you woul= d clearly want to ignore the flag.  The only other affect is to suppres= s alarms.  But as there is no alarm to suppress, that will have no effe= ct.

This is definitely not healthy, and the draft does not define any ways to a= void that.
If you would like to begin a draft on applying AIS to= other types of LSPs, that would be much appreciated.

The text in the draft that deals with protection seems to refer to link pro= tection rather than to LSP protection.
I agree that that is not clear.  I’ve upda= ted section 2 para 3 with, “When a server layer, (e.g. a link or bidir= ectional LSP) used by the bidir-LSP fails,....”

IMHO the same problem would appear in the case of segment protection if a l= ink in the middle of a segment is broken, so this issue is not limited just = to FRR.

My second issue deals with association between links and LSPs that pass thr= u these links. Ability to insert Fault OAM messages into all the LSPs crossi= ng a certain link may be compromised IMHO in the case LSPs that use labels f= rom the per-platform space. It is not clear from the draft how the LSR that = has detected a link failure could decide whether Fault OAM messages should b= e inserted in a transit LSP (which it perceives as an ILM table entry) or no= t - because the actual LSP could be running thru a different link. The probl= em would presumably disappear if per-interface label space were used; but RF= C 5960 does not restrict MPLS-TP from using per-platform label space.
The issue is not per platform labels per se, but to t= he binding of PWs and LSPs to specific links (which includes hierarchical LS= Ps).  I’ve updated section 2 para 3 with “Fault OAM message= s are generated by intermediate nodes where a bidir-LSP is switched and boun= d to specific server layers based upon static configuration or signaling.
...George

I apologize for sending these comments so late in the LC.

Regards,
     Sasha

-----Original Message-----
From: mpls-tp-bounces@ietf.org <<= a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx">https://mail.ecit= ele.com/OWA/UrlBlockedError.aspx>  [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersso= n
Sent: Thursday, February 03, 2011 1:37 PM
To: mpls-tp@ietf.org <https://mail.ecitele.com/OWA/UrlBlo= ckedError.aspx> ; mpls@ietf.org <https://mail.ecitele.= com/OWA/UrlBlockedError.aspx>
Cc: ahmpls-tp@lists.itu.int <https://mail.ecitele.= com/OWA/UrlBlockedError.aspx>
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

Please send comments to the mpls-tp@ietf.org= <https://mai= l.ecitele.com/OWA/UrlBlockedError.aspx>  mailing list.

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson           &= nbsp;            = ; email: loa.andersson@ericsson.co= m <https:= //mail.ecitele.com/OWA/UrlBlockedError.aspx>
Sr Strategy and Standards Manager        = ;    loa@pi.nu <https://mail.ecitele.com/OWA/= UrlBlockedError.aspx>
Ericsson Inc           &n= bsp;            =   phone: +46 10 717 52 13
            &nb= sp;            &= nbsp;            = ;        +46 767 72 92 13



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org <https://mail.ecitele.com/OWA/UrlBlocked= Error.aspx>
https://www.ietf.or= g/mailman/listinfo/mpls-tp
This e-mail message is intended for the recipient only and con= tains information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform us b= y e-mail, phone or fax, and then delete the original and all copies thereof.=


This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If y= ou have received this transmission in error, please inform us by e-mail, pho= ne or fax, and then delete the original and all copies thereof.

--B_3395758468_173016600-- From Alexander.Vainshtein@ecitele.com Tue Aug 9 21:27:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8BA21F8560 for ; Tue, 9 Aug 2011 21:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtT6wWdbLs-3 for ; Tue, 9 Aug 2011 21:27:27 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54121F8520 for ; Tue, 9 Aug 2011 21:27:25 -0700 (PDT) X-AuditID: 93eaf2e8-b7ce7ae000000a69-d0-4e420204e3b4 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id ED.08.02665.402024E4; Wed, 10 Aug 2011 06:59:00 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 10 Aug 2011 07:27:00 +0300 From: Alexander Vainshtein To: George Swallow Date: Wed, 10 Aug 2011 07:27:19 +0300 Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8B6/z8MARWNTqmAApe6VoAAeMgKgAM/dCW Message-ID: References: , In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD439ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLsWRmVeSWpSXmKPExsUy+dWnL7qsTE5+Bq+/s1j8mzuH2eJw111G i6fPXCxuLV3JanF7ShOjA6tH67O9rB5Tfm9k9Viy5CeTx6zpbWwBLFENjDaJeXn5JYklqQop qcXJtkoBRZllicmVSgqZKbZKhkoKBTmJyam5qXkltkqJBQWpeSlKdlwKGMAGqCwzTyE1Lzk/ JTMv3VbJM9hf18LC1FLXUMlOTdnQ2JorJCOzWCFVNzcxM0chN7W4ODE9VQEokrCFOWPK/JVs BSsXM1WsnvuUpYFx+Q/GLkZODgkBE4mH0yeyQ9hiEhfurWcDsYUEdjJKbFpq2MXIBWRPYZS4 f/oFC0iCTcBWYtPqu2BFIgJqEu+WzGAFKWIWmMkocW/pG2aQBIuAqsSKhV2sILawgJPEzNuT mboYOYAanCUWTE6GMKMklrxMA6ngFQiUmPvvADPE3hKJOzdvgd3GKaAvcfbuMbApjEC3fT+1 hgnEZhYQl7j1ZD4TxM0CEkv2nGeGsEUlXj7+B1UvKnGnfT0jRH2+xJZPN1ggdglKnJz5hAWi XlLi4IobLBMYxWYhGTsLScssJC0QcQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRWjZGZO QUlSbrqBkW5+aYleanJmSWpOql5yfu4mRkjCerGD8fYZzUOMAhyMSjy8F+Y7+gmxJpYVV+Ye YpTkYFIS5RVnd/IT4kvKT6nMSCzOiC8qzUktPsQowcGsJMJbfw6onDclsbIqtSgfJuUKDP+J zFLcyfnAJJxXEm9sYICboyTO2538xldIIB2YPLNTUwtSi2DmyHBwKEnw8nIArRcsSk1PrUjL zClBSDNxcIKcwQN0hjTIibzFBYm5xZnpEPlTjMYcaz9+PMrIce7Vl6OMQix5+XmpUuK8USDj BEBKM0rz4KaBMln9////XzGKA4NBmNcLpIoHmAXh5r0CWsUE8vEdB5BVwMwEl5JqYPSYccp+ huHx6UeunFJ6NTNHUzrD5viqR24/Hv31d/3KLJbs1mT7bF3XXO0zh/lvNi7hefpXcqFBVs5l yc1+KuFOCmFuCUej1H03Zy1dXmPaISVTuD3G59KF2p/GXJoB22T7j+/efi/lT8mHqYE/jab3 tp54XX7RNeXj18Wxnfxy3ls+y2/oWKfEUpyRaKjFXFScCAA4wL6vPwQAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 04:27:28 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD439ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable George, Lots of thanks for a prompt response! Sounds good to me. Regards, Sasha ________________________________ From: George Swallow [swallow@cisco.com] Sent: Wednesday, August 10, 2011 1:14 AM To: Alexander Vainshtein Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 OK, I=92ll add something on FFS. ...George On 8/9/11 5:20 PM, "Alexander Vainshtein" > wrote: George, Lots of thanks for a very detailed response. One more comment: I understand that you do not want to limit future applicability. But IMHO and FWIW this could be part of the explicit applicability statement= - distinguishing the cases where you claim applicability today and other c= ase where applicability is FFS. Regards, Sasha ________________________________ From: George Swallow [swallow@cisco.com] Sent: Tuesday, August 09, 2011 7:23 PM To: Alexander Vainshtein Cc: mpls-tp@ietf.org; mpl= s@ietf.org; BOCCI Matthew= ; Loa Andersson Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 On 7/18/11 11:15 AM, "Alexander Vainshtein" > wrote: George, Lots of thanks for your response, and apologies for a delayed reaction. I would like to present to you and the WG my reading of your responses, and= my conclusions. Regarding my comment about effect of FRR (or segment protection) on AIS/LDI,= your response includes two statements: 1. The draft only applies to =93the operation of PWs, bi-directional L= SPs and sections and LSP 1:1 and 1+1 protection as that is the current scope= of MPLS-TP=94 GS> Agree that my statement in the email is stronger than the text in the dr= aft. a. This seems to imply that FRR and segment protection are out of scop= e. b. To the best of my understanding, the draft does not explicitly state= that LSPs protected by FRR are out of scope. GS> Correct. c. It only says =93Fault OAM messages are applicable to Bidirectional= Co-Routed LSPs and to Multi-Segment Pseudowires=94 d. One could possibly imply that any actions (like FRR in link-and-node= protection mode) that break co-routed nature of a bidirectional LSP are bey= ond the scope of the draft (not sure about the scope MPLS-TP). However: i. It is= not clear (at least, to me) why bi-directionality is so important for the d= raft which only defines downstream messages GS> Yes. AIS and LKR certainly apply. And I suppose some use could be mad= e of LDI to switch between feeds of non-continuous traffic. But I don=92t w= ant to expand the scope of the document to cover this as we have an immediat= e need for the transport profile, and other applications are not well explor= ed at this time. ii. IMHO an= explicit statement of this kind (preferably in the Applicability Statement= section) would make the life of a potential reader much easier. GS> perhaps, but I do not want to limit future applicability. 2. The draft states that =93action based on the receipt of an LDI flag= is optional=94: 1. I=92ve scanned the draft for the word =93OPTIONAL=94, (case-insensitive= ) and did not find this statement. Did I miss something? GS> Yes. Section 6 =93 The following items are optional to implement. 2. Support of receiving the L-flag.=94 b. The text that I=92ve found in Section 2.3 of the draft and that loo= ks relevant states: =93If the CC function is disabled, a MEP SHOULD generate= AIS messages toward any client when either the AIS or LCK indication is ra= ised.=94 IMHO this is not OPTIONAL, it is RECOMMENDED GS> This does not say anything about the receipt to LDI! In fact it goes on= to say =93Note that the L-flag is not automatically propagated, i.e. the rules of Section 2.1.1 apply, that is the L-flag is not set until a f= ault has been declared.=94 c. The quoted text in the draft contains a couple of types (I=92ve rem= oved them). GS> Thanks. One more though LCK -> LKR. ...George Regarding my comment about association between links and LSPs that pass thru= these links =96 I think that the text to which you refer clarifies this iss= ue. Regards, Sasha From: George Swallow [mailto:swallow@cisco.com] Sent: Friday, July 08, 2011 10:48 PM To: Alexander Vainshtein; Loa Andersson Cc: mpls-tp@ietf.org ; mpls@ietf.org ; BOCCI Matthew Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Sasha - On 3/1/11 7:36 AM, "Alexander Vainshtein" > wrote: Loa, and all, I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version. My first issue deals with potential dangers of sending fault OAM messages in= conjunction with certain protection mechanisms. The example I've presented to George and Matthew deals with the situation w= hen the LSP in question employs Facility FRR for node protection. The topology is shown below: |------| |-----| |-----| |-----| |-----| | A |<--->| B |<--->| C |<--->| D |<--->| E | |------| |-----| |-----| |-----| |-----| \ / \ / \ / \ / \ / \ / \ |------| / \| C' |/ |------| The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs in t= he rest of the nodes. If the link BC is broken, the link-level MEP at C detects that and initiates= (I'll skip the details) insertion of AIS (with LDI flag set after some stab= ilization) into the LSP. These AIS/LDI packets will be captured by the LSP M= EP in D. I believe you mean E here. Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this LS= P, starting at B and terminated at D, D would be the merge point. Note that= C would not be aware of this action, and D would not aware of AIS insertion= undertaken by C. As a consequence, E would receive both AIS/LDI generated by C and valid traf= fic coming thru bypass. The current draft is limited to the operation of PWs, bi-directional LSPs an= d sections and LSP 1:1 and 1+1 protection as that is the current scope of MP= LS-TP. The draft states that action based on the receipt of an LDI flag is= optional. In this situation you would clearly want to ignore the flag. Th= e only other affect is to suppress alarms. But as there is no alarm to supp= ress, that will have no effect. This is definitely not healthy, and the draft does not define any ways to av= oid that. If you would like to begin a draft on applying AIS to other types of LSPs, t= hat would be much appreciated. The text in the draft that deals with protection seems to refer to link prot= ection rather than to LSP protection. I agree that that is not clear. I=92ve updated section 2 para 3 with, =93Wh= en a server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP= fails,....=94 IMHO the same problem would appear in the case of segment protection if a li= nk in the middle of a segment is broken, so this issue is not limited just t= o FRR. My second issue deals with association between links and LSPs that pass thru= these links. Ability to insert Fault OAM messages into all the LSPs crossin= g a certain link may be compromised IMHO in the case LSPs that use labels fr= om the per-platform space. It is not clear from the draft how the LSR that h= as detected a link failure could decide whether Fault OAM messages should be= inserted in a transit LSP (which it perceives as an ILM table entry) or not= - because the actual LSP could be running thru a different link. The proble= m would presumably disappear if per-interface label space were used; but RFC= 5960 does not restrict MPLS-TP from using per-platform label space. The issue is not per platform labels per se, but to the binding of PWs and L= SPs to specific links (which includes hierarchical LSPs). I=92ve updated se= ction 2 para 3 with =93Fault OAM messages are generated by intermediate node= s where a bidir-LSP is switched and bound to specific server layers based up= on static configuration or signaling. ...George I apologize for sending these comments so late in the LC. Regards, Sasha -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-b= ounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, February 03, 2011 1:37 PM To: mpls-tp@ietf.org ; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mai= ling list. This working group last call ends on February 28, 2011. Loa, George and Ross MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD439ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
George,
Lots of thanks for a prompt response! So= unds good to me.
 
Regards,
     Sasha
 
From: George Swall= ow [swallow@cisco.com]
Sent: Wednesday, August 10, 2011 1:14 AM
To: Alexander Vainshtein
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
Alexander.Vainsh= tein@ecitele.com> wrote:
G= eorge,
Lots of thanks for a very detailed response.
 
One more comment:
 
I understand that you do not want to limit future applicability.
But IMHO and FWIW this could be part of the explicit applicability statement=  - distinguishing the cases where you claim applicability today and ot= her case where applicability is FFS.
 
Regards,
     Sasha
 
From: Geo= rge Swallow [swallow@cisco.com]
Sent: Tuesday, August 09, 2011 7:23 PM
To: Alexander Vainshtein
Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew; Loa Andersson
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03



On 7/18/11 11:15 AM, "Alexander Vainshtein" <Alexander.Vain= shtein@ecitele.com <https://mail.ecitele.com/OWA/UrlBlockedError.= aspx> > wrote:
George,
Lots of thanks for your response, and apologies for a delayed reaction.
 
I would like to present to you and the WG my reading of your responses, and= my conclusions.
 
Regarding my comment about effect of FRR (or segment protection) on AIS/LDI,= your response includes two statements:
1.       The draft only applies to =93<= /font>the operation= of PWs, bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is the current scope of MPLS-TP=94

GS> Agree that my statement in the email is stronger than the text= in the draft.
a.      &= nbsp;This seems to imply that FRR and segment protection are out of scope.
b.      To the best of my understanding, the d= raft does not explicitly state that LSPs protected by FRR are out of scope.

GS> Correct.
c.      &= nbsp;It only says =93Fault OAM messages are applicable to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires=94
d.      One could possibly imply that any actions (= like FRR in link-and-node protection mode) that break co-routed nature of a= bidirectional LSP are beyond the scope of the draft (not sure about the sco= pe MPLS-TP). However:
            &nbs= p;            &n= bsp;            =             &nbs= p;            i.=      It is not clear (at least, to me) why bi-dire= ctionality is so important for the draft which only defines downstream messa= ges

GS> Yes.   AIS and LKR certainly app= ly.  And I suppose some use could be made of LDI to switch between feed= s of non-continuous traffic.  But I don=92t want to expand the scope of the document to cover this as we have an immediate need for th= e transport profile, and other applications are not well explored at this ti= me.
     &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;  ii.      IMHO an explicit statement= of this kind (preferably in the Applicability Statement section) would make the life of a potential reader much easier.

GS> perhaps, but I do not want to limit future applicability.
<= br> 2.      = ; The draft states that =93action based on the receipt of an LDI flag is optional=94:
  1. I=92ve scanned the draft for the word =93O= PTIONAL=94, (case-insensitive) and did not find this statement. Did I miss s= omething?

GS> Yes.  Section 6

    =93 The following items are optional to implement.    
   2.  Support of receiving the L-flag.=94
b.      T= he text that I=92ve found in Section 2.3 of the draft  and that looks r= elevant states: =93If the CC function is disabled, a MEP SHOULD generate AIS messages toward any= client when either the AIS or LCK indication is  raised.= =94  IMHO this is not OPTIONAL, it is RECOMMENDED

GS> This does not say anything about the receipt to LDI!  In= fact it goes on to say =93Note that the L-flag is not automatically propaga= ted, i.e.
   the rules of Section 2.1.1 apply, that is the L-flag is no= t set until a fault has been declared.=94
c.      &= nbsp;The quoted text in the draft contains a couple of types (I=92ve removed= them).

GS> Thanks.  One more though LCK -> LKR.

...George

Regarding my comment about association between links and LSPs that pass thru these links= =96 I think that the text to which you refer clarifies this issue.


Regards,
     Sasha
 

From: George Swallow [mailto:swallow@cisco.com]
Sent: Friday, July 08, 2011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc: mpls-tp@ietf.org <https://mail.ecitele.com/OWA/UrlBlockedError.as= px> ; mpls@ietf.org <https://mail.ecitele.com/OWA/UrlBlockedError.a= spx> ; BOCCI Matthew
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainsh= tein@ecitele.com <https://mail.ecitele.com/OWA/UrlBlockedError.as= px> > wrote:
Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages in= conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situat= ion when the LSP in question employs Facility FRR for node protection.

The topology is shown below:


|------|     |-----|     |-----| &nb= sp;   |-----|     |-----|
|  A   |<--->|  B  |<--->|  C &nbs= p;|<--->|  D  |<--->|  E  |
|------|     |-----|     |-----| &nb= sp;   |-----|     |-----|
            &nbs= p;   \          =             /             &nbs= p;    \         =            /
            &nbs= p;     \        =           /
            &nbs= p;      \       =          /
            &nbs= p;       \      =         /
            &nbs= p;        \     =        /
            &nbs= p;         \ |------| /
            &nbs= p;          \|   = ;C' |/
            &nbs= p;           |------|=

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D &n= bsp;and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiates= (I'll skip the details) insertion of AIS (with LDI flag set after some stab= ilization) into the LSP. These AIS/LDI packets will be captured by the LSP M= EP in D.
I believe you mean E here.

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for t= his LSP, starting at B and terminated at D, D would be the merge point. Note= that C would not be aware of this action, and D would not aware of AIS inse= rtion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid traf= fic coming thru bypass.
The current draft is limited to the operation of PWs= , bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as tha= t is the current scope of MPLS-TP.  The draft  states that action= based on the receipt of an LDI flag is optional.  In this situation you would clearly want to ignore the flag.  Th= e only other affect is to suppress alarms.  But as there is no alarm to= suppress, that will have no effect.

This is definitely not healthy, and the draft does not define any ways to av= oid that.
If you would like to begin a draft on applying AIS t= o other types of LSPs, that would be much appreciated.

The text in the draft that deals with protection seems to refer to link prot= ection rather than to LSP protection.
I agree that that is not clear.  I=92ve updated= section 2 para 3 with, =93When a server layer, (e.g. a link or bidirectiona= l LSP) used by the bidir-LSP fails,....=94

IMHO the same problem would appear in the case of segment protection if a li= nk in the middle of a segment is broken, so this issue is not limited just t= o FRR.

My second issue deals with association between links and LSPs that pass thru= these links. Ability to insert Fault OAM messages into all the LSPs crossin= g a certain link may be compromised IMHO in the case LSPs that use labels fr= om the per-platform space. It is not clear from the draft how the LSR that has detected a link failure co= uld decide whether Fault OAM messages should be inserted in a transit LSP (w= hich it perceives as an ILM table entry) or not - because the actual LSP cou= ld be running thru a different link. The problem would presumably disappear if per-interface label space w= ere used; but RFC 5960 does not restrict MPLS-TP from using per-platform lab= el space.
The issue is not per platform labels per se, but to= the binding of PWs and LSPs to specific links (which includes hierarchical= LSPs).  I=92ve updated section 2 para 3 with =93Fault OAM messages are= generated by intermediate nodes where a bidir-LSP is switched and bound to specific server layers based upon static configura= tion or signaling.

...George

I apologize for sending these comments so late in the LC.

Regards,
     Sasha

-----Original Message-----
From: mpls-tp-bounces@ietf.org <https://mail.ecitele.com/OWA/UrlBlocked= Error.aspx>  [mailto= :mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Thursday, February 03, 2011 1:37 PM
To: mpls-tp@ietf.org <https://mail.ecitele.com/OWA/UrlBlocked= Error.aspx> ; mpls@ietf.org <https://mail.ecitele.com/OWA/UrlBlockedError.a= spx>
Cc: ahmpls-tp@lists.itu.int <https://mail.ecitele.com/OWA/Url= BlockedError.aspx>
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

Please send comments to the mpls-tp@ietf.org <https://mail.ecitele.com/OWA/UrlBlockedError.as= px>  mailing list.

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson           &n= bsp;            =  email: loa.andersson@ericsson.com <https://mail.ecitele.com/OWA/UrlBlock= edError.aspx>
Sr Strategy and Standards Manager        =     loa@pi.nu <https://mail.ecitele.com/O= WA/UrlBlockedError.aspx>
Ericsson Inc           &nb= sp;            &= nbsp; phone: +46 10 717 52 13
            &nbs= p;            &n= bsp;            =         +46 767 72 92 13



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org <https://mail.ecitele.com/OWA/UrlBlockedErro= r.aspx>
= https://www.ietf.org/mailman/listinfo/mpls-tp
This e-mail message is intended for the recipient only and= contains information which is CONFIDENTIAL and which may be proprietary to= ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and t= hen delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD439ILPTMAIL02e_-- From iesg-secretary@ietf.org Wed Aug 10 03:36:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8EF21F86B9; Wed, 10 Aug 2011 03:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSA-WPqie2tf; Wed, 10 Aug 2011 03:36:14 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C685A21F85DE; Wed, 10 Aug 2011 03:36:13 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2DBAF7B800A; Wed, 10 Aug 2011 12:38:04 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1BC9A6C8005; Wed, 10 Aug 2011 12:38:04 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 12:01:35 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 02:16:59 +0200 Received: from omfeda05.si.francetelecom.fr ([10.98.3.82]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 16:44:50 +0200 Received: from omfeda10.si.francetelecom.fr (unknown [10.98.77.162]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 9ED9918004B; Tue, 9 Aug 2011 16:44:50 +0200 (CEST) Received: from omfeda10.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfeda10.si.francetelecom.fr (ESMTP service) with SMTP id 9247F3743EA; Tue, 9 Aug 2011 16:44:50 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 30AAB37416C; Tue, 9 Aug 2011 16:44:50 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD5F21F8B87; Tue, 9 Aug 2011 07:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312901024; bh=vXILpg+5jnwF3glnXgbToixot5N2BDh/iJmKPkcH1vI=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=mabBgJcWHjgr+CB2p6aQcNbL0XT4EgjK1asNTVsdwWoCqcigNnzfIzxpOusvp9Z5Z b1SIjbyDDmiYwQFXWuyI3WMxR2W+vbNwnQFiYytb9D+B8OXJ7qjGgN/Cf7H0vE1JtD MrWAhoe3SQT+3Pdw2hEQvVh9AFVnIdc1k8k1CehE= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005721F89BA; Tue, 9 Aug 2011 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu2JyRMuqXLv; Tue, 9 Aug 2011 07:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E721F8AAC; Tue, 9 Aug 2011 07:43:41 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809144341.5393.9055.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 07:43:41 -0700 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.143315 X-OriginalArrivalTime: 09 Aug 2011 14:44:50.0823 (UTC) FILETIME=[E4AE7170:01CC56A2] Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' to Proposed Standard (draft-ietf-mpls-tp-cc-cv-rdi-06.txt) X-BeenThere: mpls@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 10:36:18 -0000 The IESG has approved the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' (draft-ietf-mpls-tp-cc-cv-rdi-06.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ Technical Summary MPLS LSPs (emulating traditional transport circuits) are expected to deliver the same the capabilities for monitoring cnnections as in earlier types of transport networks. This document describes and specifies, as required in RFC 5860, Continuity Check (CC), proactive Connection Verfication (CV), and Remoted Defect Indication (RDI). This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) for for these functions for pseudowires (PWs), Label Switched Paths (LSPs), and Sub-Path Maintenance Entities (SPMEs) between two Maintenance Entity Group End Points (MEPs). CC and Proactive CV are functions used to detect loss of continuity (LOC), and unintended connectivity between two MEPs. RDI is an indicator that is transmitted by a MEP to communicate to its peer MEP that a signal fail condition exists. This document specifies the BFD extension and behavior to satisfy the CC, the proactive CV monitoring, and the RDI functional requirements for both co-routed and associated bi-directional LSPs. The document describes a number of encapsulations. Procedures for uni-directional LSPs are for further study. The mechanisms specified in this document are restricted to BFD asynchronous mode. Working Group Summary This document is a MPLS working group document, and part of the joint IETF / ITU-T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. The document was discussed and last-called in the MPLS and BFD WGs. Document Quality The document is well reviewed in the MPLS working group,the ITU-T and the BFD working group. A number of vendors have committed to implement and there is believed to be at least one early implementation. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Please try to set the figures so that they don't break over a page. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From iesg-secretary@ietf.org Wed Aug 10 03:51:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C74121F869D; Wed, 10 Aug 2011 03:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0akvn75cFxV; Wed, 10 Aug 2011 03:51:02 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 476E121F8698; Wed, 10 Aug 2011 03:50:59 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DCFC38F0006; Wed, 10 Aug 2011 12:52:18 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id B66B29B0014; Wed, 10 Aug 2011 12:52:10 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 12:02:08 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 02:17:21 +0200 Received: from omfedm06.si.francetelecom.fr ([10.98.84.130]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 16:45:05 +0200 Received: from omfedm11.si.francetelecom.fr (unknown [10.98.62.19]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1B28627C072; Tue, 9 Aug 2011 16:45:05 +0200 (CEST) Received: from omfedm11.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with SMTP id 0B1B83B43EA; Tue, 9 Aug 2011 16:45:05 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id A55113B43E0; Tue, 9 Aug 2011 16:45:04 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8BF21F8B8A; Tue, 9 Aug 2011 07:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312901025; bh=vXILpg+5jnwF3glnXgbToixot5N2BDh/iJmKPkcH1vI=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=DJBDZtKG/aApEg7Dgv5V7ZRi+MHbOJlsdAnWP2sxSuxNoAO7cPyRR4IgpqhA4UFSa qqIztwNiNTebfEBQ9rRO8IsqFSBDpOV6U8RloWgQyjsHhxpo/vfpHPVb1Qr3fAv0ty 9ijtj6/nAIvRvIj1GURJajKjgiUEjluC2vNDu+RA= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005721F89BA; Tue, 9 Aug 2011 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu2JyRMuqXLv; Tue, 9 Aug 2011 07:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E721F8AAC; Tue, 9 Aug 2011 07:43:41 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809144341.5393.9055.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 07:43:41 -0700 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.143315 X-OriginalArrivalTime: 09 Aug 2011 14:45:05.0276 (UTC) FILETIME=[ED4BCBC0:01CC56A2] Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' to Proposed Standard (draft-ietf-mpls-tp-cc-cv-rdi-06.txt) X-BeenThere: mpls@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 10:51:03 -0000 The IESG has approved the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' (draft-ietf-mpls-tp-cc-cv-rdi-06.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ Technical Summary MPLS LSPs (emulating traditional transport circuits) are expected to deliver the same the capabilities for monitoring cnnections as in earlier types of transport networks. This document describes and specifies, as required in RFC 5860, Continuity Check (CC), proactive Connection Verfication (CV), and Remoted Defect Indication (RDI). This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) for for these functions for pseudowires (PWs), Label Switched Paths (LSPs), and Sub-Path Maintenance Entities (SPMEs) between two Maintenance Entity Group End Points (MEPs). CC and Proactive CV are functions used to detect loss of continuity (LOC), and unintended connectivity between two MEPs. RDI is an indicator that is transmitted by a MEP to communicate to its peer MEP that a signal fail condition exists. This document specifies the BFD extension and behavior to satisfy the CC, the proactive CV monitoring, and the RDI functional requirements for both co-routed and associated bi-directional LSPs. The document describes a number of encapsulations. Procedures for uni-directional LSPs are for further study. The mechanisms specified in this document are restricted to BFD asynchronous mode. Working Group Summary This document is a MPLS working group document, and part of the joint IETF / ITU-T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. The document was discussed and last-called in the MPLS and BFD WGs. Document Quality The document is well reviewed in the MPLS working group,the ITU-T and the BFD working group. A number of vendors have committed to implement and there is believed to be at least one early implementation. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Please try to set the figures so that they don't break over a page. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From jcucchiara@mindspring.com Wed Aug 10 07:25:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2019A21F8698 for ; Wed, 10 Aug 2011 07:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSX0W0iVbzas for ; Wed, 10 Aug 2011 07:25:43 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 916D521F85F2 for ; Wed, 10 Aug 2011 07:25:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cY9WWVZ0luzz5Y/vdc6cajxB2fAxCFigaqnfGYZc8Yx4XNE9mKf5e3uDkZ78tNPG; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qr9ja-0006HO-Nr; Wed, 10 Aug 2011 10:26:14 -0400 Message-ID: <008701cc5769$75314e90$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Thomas Nadeau" References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> Date: Wed, 10 Aug 2011 10:26:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26544e7a6156bf0202375578d164aa0ff27b86936b69e59fefa2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 14:25:45 -0000 ----- Original Message ----- From: "Thomas Nadeau" To: "Joan Cucchiara" Cc: Sent: Tuesday, August 09, 2011 10:47 AM Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt > > On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: > >> >> Spike, >> >> Wanted to comment on your 3 suggestions for indexing. >> >> Suggestion #1 is also my preference. This is the most straightforward >> and least complex >> design in my opinion. Additionally, the CLI, Web, NMS, etc could >> display both MPLS >> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the >> complexity of the >> mapping is not in the MIB (or agent). > > That is the idea we were after. We want a new table that shows "TP > tunnels" > as a (proper) subset of those defined globally. That is, the indexing > "extends" those in > the MplsTunnelTable. > >> Suggestion #2 is not allowed because redefining indices is not allowed in >> the SMI. >> (We had a few emails about this during the time that the MIB was being >> adopted by the WG.) > > Spot on. The only way to take this approach is to deprecate RFC3811, 12, > and 13 as > well as the GMPLS and PWE3 MIB RFCs that are also based on these. > >> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same >> table. >> While this goal may have some benefits, the design to accomplish the goal >> is more complex than #1 >> as you point out. I have asked the authors to ensure that there are no >> backwards compatibility issues >> with the design so that the MPLS Tunnel Table is already populated >> and then MPLS-TP Tunnel indices are created such that they do not >> conflict with already >> existing tunnel indices. In a nutshell, the problem I have with this >> design is that there are 2 ways of creating indices >> for the same Table, one which is legacy and has been around since 2004 >> and now a second way. > > Don't you get both "existing at the same time in the same table" by using > the 'extends' relationship? > > >> There may be a #4 Suggestion which is to implement design #1 but also >> have an additional (optional?) table >> which is a superset of Tunnels, this could be indexed by a type field. > > The MIB provides mapping tables *in addition to* the basic table that > extends the MplsTunnelTable. > This is provided as a convenience for the E/NMS to speed table > traversal/manipulation. > Tom, That wasn't clear (at least to me), could this be clarified in next rev? Also, may be more beneficial to make these mapping tables optional -- not every vendor will need to implement them, since they are for E/NMS. Thanks, -Joan > --Tom > > >> >> Thanks, >> -Joan >> >> >> ----- Original Message ----- From: "Eric Gray" >> To: >> Sent: Tuesday, August 09, 2011 9:05 AM >> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >> >> >>> Forwarding in plain text... >>> >>> ________________________________ >>> >>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>> Sent: Monday, August 08, 2011 5:25 AM >>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>> Cc: mpls@ietf.org >>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>> >>> >>> >>> Hi Venkat & all, >>> >>> >>> >>> I've read the draft and have a question and then some comments. I'm >>> happy to be of assistance with any of what follows, and/or with working >>> on other MIB drafts that we need to fill out the gaps identified in >>> draft-ietf-mpls-tp-mib-management-overview. >>> >>> >>> >>> >>> >>> MPLS-TP Identifiers: >>> >>> I understand that one of the purposes of this draft is to allow >>> configuration using MPLS-TP identifiers. Presumably, there are at least >>> three ways this could be accomplished: >>> >>> 1. Define a brand new tunnel table for MPLS-TP, based on the >>> mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>> >>> 2. Redefine the existing mplsTunnelTable indexing, adding GlobalID >>> and ICC for ingress and egress nodes, and using 0 as "not used" values >>> to allow back-compatibility. >>> >>> 3. Create a separate set of tables which maps the old identifiers to >>> the new MPLS-TP identifiers. >>> >>> This draft takes the third strategy, but it's not immediately clear to >>> me why this is preferable to the other two. (2) seems the least >>> complicated because it does away extra mapping and inverse mapping >>> tables. It's also difficult to guarantee that local identifiers (which >>> don't have configuration or signalling significance) will not change in >>> the case of graceful restart or configuration replay. Was option (3) >>> chosen to avoid back-compatibility issues, or for other reasons? >>> >>> >>> >>> A comment on tunnels: >>> >>> I'd like to clarify how unidirectional, associated bidirectional and >>> co-routed bidirectional paths are modelled in the MIB, and how exactly >>> the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB >>> fields. My preference is as follows. >>> >>> >>> >>> * Unidirectional LSPs in MPLS-TP are very similar to "normal" >>> MPLS, but with different identifiers. Tunnels of this type do not have >>> any entries in the mplsTunnelExtTable. >>> >>> >>> >>> * In associated bidirectional LSPs, the transport directions are >>> set up and monitored independently, so each transport direction should >>> be a separate row in the mplsTunnelTable. >>> >>> >>> >>> * In co-routed bidirectional LSPs, both transport directions are >>> set up and monitored together. This means we should have only one row >>> in the mplsTunnelTable to represent a tunnel of this type. This is not >>> how the draft is currently structured, where the example in Section 9 >>> creates two rows in the mplsTunnelTable. >>> >>> >>> >>> About gaps: >>> >>> Lastly, I think the MIB is still missing some configuration that we'll >>> need in order to satisfy MPLS-TP requirements. These include >>> >>> * Bidirectional tunnels with asymmetric resource requirements >>> >>> * OAM configuration. Presumably this will be a reference to >>> yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM >>> profiles. >>> >>> >>> >>> Let me know if I can be of further assistance. >>> >>> >>> >>> Cheers, >>> >>> Spike >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> * To: i-d-announce at ietf.org >>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>> * From: internet-drafts at ietf.org >>> >>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>> * Cc: mpls at ietf.org >>> * Delivered-to: mpls at ietfa.amsl.com >>> * List-archive: >>> * List-help: >>> * List-id: Multi-Protocol Label Switching WG >>> * List-post: >>> * List-subscribe: , >>> >>> * List-unsubscribe: , >>> >>> >>> ________________________________ >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Multiprotocol Label >>> Switching Working Group of the IETF. >>> >>> Title : MPLS-TP Traffic Engineering (TE) Management >>> Information Base (MIB) >>> Author(s) : Venkatesan Mahalingam >>> Kannan KV Sampath >>> Huawei Technologies >>> Thomas D. Nadeau >>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>> Pages : 39 >>> Date : 2011-06-17 >>> >>> This memo defines a portion of the Management Information Base (MIB) >>> for use with network management protocols in the Internet community. >>> In particular, it describes managed objects of Tunnels, Identifiers, >>> Label Switch Router and Textual conventions for Multiprotocol Label >>> Switching (MPLS) based Transport Profile (TP). >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>> ________________________________ >>> >>> >>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's >>> Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>> >>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., >>> Ltd's Statement about IPR related to RFC 5919 >>> >>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., >>> Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>> >>> * Next by thread: [mpls] I-D Action: >>> draft-ietf-mpls-ldp-ip-pw-capability-00.txt >>> >>> * Index(es): >>> >>> * Date >>> >>> * Thread >>> >>> >>> >>> Note: Messages sent to this list are the opinions of the senders and do >>> not imply endorsement by the IETF. >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Wed Aug 10 07:57:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEFD21F8A36 for ; Wed, 10 Aug 2011 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsGWdl2XvOFb for ; Wed, 10 Aug 2011 07:57:42 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8616D21F84F6 for ; Wed, 10 Aug 2011 07:57:42 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 171C71D6AFCF; Wed, 10 Aug 2011 10:58:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau X-Priority: 3 In-Reply-To: <008701cc5769$75314e90$6601a8c0@JoanPC> Date: Wed, 10 Aug 2011 10:58:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> To: "Joan Cucchiara" X-Mailer: Apple Mail (2.1244.3) Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 14:57:44 -0000 On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >=20 > ----- Original Message ----- From: "Thomas Nadeau" = > To: "Joan Cucchiara" > Cc: > Sent: Tuesday, August 09, 2011 10:47 AM > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 >=20 >>=20 >> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>=20 >>>=20 >>> Spike, >>>=20 >>> Wanted to comment on your 3 suggestions for indexing. >>>=20 >>> Suggestion #1 is also my preference. This is the most = straightforward and least complex >>> design in my opinion. Additionally, the CLI, Web, NMS, etc could = display both MPLS >>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the = complexity of the >>> mapping is not in the MIB (or agent). >>=20 >> That is the idea we were after. We want a new table that shows "TP = tunnels" >> as a (proper) subset of those defined globally. That is, the indexing = "extends" those in >> the MplsTunnelTable. >>=20 >>> Suggestion #2 is not allowed because redefining indices is not = allowed in the SMI. >>> (We had a few emails about this during the time that the MIB was = being adopted by the WG.) >>=20 >> Spot on. The only way to take this approach is to deprecate RFC3811, = 12, and 13 as >> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>=20 >>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same = table. >>> While this goal may have some benefits, the design to accomplish the = goal is more complex than #1 >>> as you point out. I have asked the authors to ensure that there are = no backwards compatibility issues >>> with the design so that the MPLS Tunnel Table is already populated >>> and then MPLS-TP Tunnel indices are created such that they do not = conflict with already >>> existing tunnel indices. In a nutshell, the problem I have with = this design is that there are 2 ways of creating indices >>> for the same Table, one which is legacy and has been around since = 2004 and now a second way. >>=20 >> Don't you get both "existing at the same time in the same table" by = using the 'extends' relationship? >>=20 >>=20 >>> There may be a #4 Suggestion which is to implement design #1 but = also have an additional (optional?) table >>> which is a superset of Tunnels, this could be indexed by a type = field. >>=20 >> The MIB provides mapping tables *in addition to* the basic table that = extends the MplsTunnelTable. >> This is provided as a convenience for the E/NMS to speed table = traversal/manipulation. >>=20 >=20 > Tom, >=20 > That wasn't clear (at least to me), could this be clarified in next = rev? Yes, of course! 8) > Also, may be more beneficial to make these mapping tables optional -- = not every vendor will need to > implement them, since they are for E/NMS. That is possible, but as you know is up to the working group. It = is my personal preference as a vendor of management applications,=20 to avoid optional things where possible, as they are unlikely to ever = get implemented on devices and make things more difficult for=20 applications. --Tom >=20 > Thanks, > -Joan >=20 >=20 >=20 >> --Tom >>=20 >>=20 >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>> ----- Original Message ----- From: "Eric Gray" = >>> To: >>> Sent: Tuesday, August 09, 2011 9:05 AM >>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>=20 >>>=20 >>>> Forwarding in plain text... >>>>=20 >>>> ________________________________ >>>>=20 >>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>> Sent: Monday, August 08, 2011 5:25 AM >>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>> Cc: mpls@ietf.org >>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>=20 >>>>=20 >>>>=20 >>>> Hi Venkat & all, >>>>=20 >>>>=20 >>>>=20 >>>> I've read the draft and have a question and then some comments. = I'm happy to be of assistance with any of what follows, and/or with = working on other MIB drafts that we need to fill out the gaps identified = in draft-ietf-mpls-tp-mib-management-overview. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> MPLS-TP Identifiers: >>>>=20 >>>> I understand that one of the purposes of this draft is to allow = configuration using MPLS-TP identifiers. Presumably, there are at least = three ways this could be accomplished: >>>>=20 >>>> 1. Define a brand new tunnel table for MPLS-TP, based on the = mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>>>=20 >>>> 2. Redefine the existing mplsTunnelTable indexing, adding = GlobalID and ICC for ingress and egress nodes, and using 0 as "not used" = values to allow back-compatibility. >>>>=20 >>>> 3. Create a separate set of tables which maps the old = identifiers to the new MPLS-TP identifiers. >>>>=20 >>>> This draft takes the third strategy, but it's not immediately clear = to me why this is preferable to the other two. (2) seems the least = complicated because it does away extra mapping and inverse mapping = tables. It's also difficult to guarantee that local identifiers (which = don't have configuration or signalling significance) will not change in = the case of graceful restart or configuration replay. Was option (3) = chosen to avoid back-compatibility issues, or for other reasons? >>>>=20 >>>>=20 >>>>=20 >>>> A comment on tunnels: >>>>=20 >>>> I'd like to clarify how unidirectional, associated bidirectional = and co-routed bidirectional paths are modelled in the MIB, and how = exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto = MIB fields. My preference is as follows. >>>>=20 >>>>=20 >>>>=20 >>>> * Unidirectional LSPs in MPLS-TP are very similar to = "normal" MPLS, but with different identifiers. Tunnels of this type do = not have any entries in the mplsTunnelExtTable. >>>>=20 >>>>=20 >>>>=20 >>>> * In associated bidirectional LSPs, the transport = directions are set up and monitored independently, so each transport = direction should be a separate row in the mplsTunnelTable. >>>>=20 >>>>=20 >>>>=20 >>>> * In co-routed bidirectional LSPs, both transport = directions are set up and monitored together. This means we should have = only one row in the mplsTunnelTable to represent a tunnel of this type. = This is not how the draft is currently structured, where the example in = Section 9 creates two rows in the mplsTunnelTable. >>>>=20 >>>>=20 >>>>=20 >>>> About gaps: >>>>=20 >>>> Lastly, I think the MIB is still missing some configuration that = we'll need in order to satisfy MPLS-TP requirements. These include >>>>=20 >>>> * Bidirectional tunnels with asymmetric resource = requirements >>>>=20 >>>> * OAM configuration. Presumably this will be a reference = to yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM = profiles. >>>>=20 >>>>=20 >>>>=20 >>>> Let me know if I can be of further assistance. >>>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>> Spike >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ________________________________ >>>>=20 >>>> * To: i-d-announce at ietf.org >>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>> * From: internet-drafts at ietf.org = >>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>> * Cc: mpls at ietf.org >>>> * Delivered-to: mpls at ietfa.amsl.com >>>> * List-archive: >>>> * List-help: >>>> * List-id: Multi-Protocol Label Switching WG >>>> * List-post: >>>> * List-subscribe: , = >>>> * List-unsubscribe: , = >>>>=20 >>>> ________________________________ >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Multiprotocol Label = Switching Working Group of the IETF. >>>>=20 >>>> Title : MPLS-TP Traffic Engineering (TE) Management = Information Base (MIB) >>>> Author(s) : Venkatesan Mahalingam >>>> Kannan KV Sampath >>>> Huawei Technologies >>>> Thomas D. Nadeau >>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>> Pages : 39 >>>> Date : 2011-06-17 >>>>=20 >>>> This memo defines a portion of the Management Information Base = (MIB) >>>> for use with network management protocols in the Internet = community. >>>> In particular, it describes managed objects of Tunnels, = Identifiers, >>>> Label Switch Router and Textual conventions for Multiprotocol Label >>>> Switching (MPLS) based Transport Profile (TP). >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> = http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>> ________________________________ >>>>=20 >>>>=20 >>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to RFC 5919 = >>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>> * Next by thread: [mpls] I-D Action: = draft-ietf-mpls-ldp-ip-pw-capability-00.txt = >>>> * Index(es): >>>>=20 >>>> * Date = >>>> * Thread = >>>>=20 >>>>=20 >>>> Note: Messages sent to this list are the opinions of the senders = and do not imply endorsement by the IETF. >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls=20 >=20 >=20 From rcallon@juniper.net Wed Aug 10 08:30:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E7521F85A7 for ; Wed, 10 Aug 2011 08:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06OOFxIT+Aqg for ; Wed, 10 Aug 2011 08:30:56 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 674D221F8593 for ; Wed, 10 Aug 2011 08:30:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTkKkTotdCAelHrqlXreTBuUzgeCWKSWw@postini.com; Wed, 10 Aug 2011 08:31:27 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 10 Aug 2011 08:31:18 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 10 Aug 2011 11:31:17 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 10 Aug 2011 11:31:17 -0400 Thread-Topic: Additional author for draft-ietf-mpls-tp-itu-t-identifiers Thread-Index: AcxXbWp263hF0t/YRcylI8HP899wFg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {939ED2FB-5194-4AB9-9AC7-9FF94DB3571D} x-cr-hashedpuzzle: ANvO C0FK DDCo DboU E0w6 E9QR FEA8 FFF6 FN9K FbA4 GOOa Hdd1 Hiw9 JsAm JsFa Jvp3; 1; bQBwAGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {939ED2FB-5194-4AB9-9AC7-9FF94DB3571D}; cgBjAGEAbABsAG8AbgBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Wed, 10 Aug 2011 14:54:38 GMT; QQBkAGQAaQB0AGkAbwBuAGEAbAAgAGEAdQB0AGgAbwByACAAZgBvAHIAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBwAGwAcwAtAHQAcAAtAGkAdAB1AC0AdAAtAGkAZABlAG4AdABpAGYAaQBlAHIAcwA= acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2E1DE4591EMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] Additional author for draft-ietf-mpls-tp-itu-t-identifiers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 15:30:56 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2E1DE4591EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to ensure consistency between draft-ietf-mpls-tp-itu-t-identifiers= and draft-ietf-mpls-tp-identifiers, and specifically to have an author in = common between the two drafts, Eric Gray has been appointed as author/edito= r of draft-ietf-mpls-tp-itu-t-identifiers with the agreement of the co-auth= ors (Rolf, Huub and Malcolm). Ross, Loa, and George (as MPLS co-chairs) --_000_DF7F294AF4153D498141CBEFADB17704C2E1DE4591EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In order to ensure consistency between draft-ietf-mpls-tp-itu-t-identi= fiers and draft-ietf-mpls-tp-identifiers, and specifically to have an autho= r in common between the two drafts, Eric Gray has been appointed as author/= editor of draft-ietf-mpls-tp-itu-t-identifiers with the agreement of the co-authors (Rolf, Huub and Malcolm).
 
Ross, Loa, and George
(as MPLS co-chairs)
 
 --_000_DF7F294AF4153D498141CBEFADB17704C2E1DE4591EMBX01WFjnprn_-- From iesg-secretary@ietf.org Wed Aug 10 09:19:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F117621F858D; Wed, 10 Aug 2011 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiQ0TRXYc4a2; Wed, 10 Aug 2011 09:19:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1821F859F; Wed, 10 Aug 2011 09:19:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110810161907.12605.47565.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2011 09:19:07 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS-TP Linear Protection' to Proposed Standard (draft-ietf-mpls-tp-linear-protection-09.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 16:19:08 -0000 The IESG has approved the following document: - 'MPLS-TP Linear Protection' (draft-ietf-mpls-tp-linear-protection-09.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/ Technical Summary The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection. Linear protection provides rapid and simple protection switching. In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network. It can protect against a defect in an intermediate node, a span, a transport path segment, or an end-to-end transport path. Working Group Summary This document has been carefully reviewed by the MPLS WG as well as by ITU-T SG15. A summary of the resolution of the many comments received has been posted to the MPLS WG email list. Document Quality Multiple implementations are in progress. Personnel Ross Callon (rcallon@juniper.net) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From RCosta@ptinovacao.pt Wed Aug 10 11:22:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380A221F856B for ; Wed, 10 Aug 2011 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqAeaw0lR3xw for ; Wed, 10 Aug 2011 11:22:50 -0700 (PDT) Received: from owa.ptinovacao.pt (webmail.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id B25AA21F8AAC for ; Wed, 10 Aug 2011 11:22:48 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Wed, 10 Aug 2011 19:23:13 +0100 From: Rui Costa To: Rolf Winter , "mpls@ietf.org" Date: Wed, 10 Aug 2011 19:23:12 +0100 Thread-Topic: new version of the per-interface MIP draft Thread-Index: AcxAZUHe1PZf+IEdRiimifl0q6Q95QWNnAVw Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED4E0B008D@INOAVREX11.ptin.corpPT.com> References: <791AD3077F94194BB2BDD13565B6295D1CFC4580@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1CFC4580@DAPHNIS.office.hd> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] new version of the per-interface MIP draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 18:22:52 -0000 Hi,=09 1. In point 4, by the end of page 6, "Figure 2 depicts OAM using per-interf= ace MIPs and MEPs": don't you actually mean "per-node"?=09 2. In "6.1. ID-based Solution", by the end: how does a node know an OAM me= ssage was "intended for its upstream neighbor's outgoing MIP"?=09 Thanks. Regards,=09 Rui=09 -----Original Message-----=09 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rol= f Winter=09 Sent: ter=E7a-feira, 12 de Julho de 2011 08:28=09 To: mpls@ietf.org=09 Subject: [mpls] new version of the per-interface MIP draft=09 Hi WG,=09 we have submitted a new version of the per-interface MIP draft (http://tool= s.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04). In this new version t= hings have changed significantly based on your valuable feedback. We would = very much appreciate more feedback on this new version of the document. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Wed Aug 10 18:35:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29921F8BB1; Wed, 10 Aug 2011 18:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXGPsE+aR0lM; Wed, 10 Aug 2011 18:35:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6CB21F8BA4; Wed, 10 Aug 2011 18:35:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811013556.11211.77631.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2011 18:35:56 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-on-demand-cv-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 01:35:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS On-demand Connectivity Verification and Route Traci= ng Author(s) : Nitin Bahadur Rahul Aggarwal Sami Boutros Eric Gray Filename : draft-ietf-mpls-tp-on-demand-cv-06.txt Pages : 21 Date : 2011-08-10 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-06.txt From eric.gray@ericsson.com Thu Aug 11 04:02:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBC621F8888 for ; Thu, 11 Aug 2011 04:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Rirwqq0o4C for ; Thu, 11 Aug 2011 04:02:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 10AA121F8880 for ; Thu, 11 Aug 2011 04:02:52 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7BB3FIN022255; Thu, 11 Aug 2011 06:03:17 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 11 Aug 2011 07:03:10 -0400 From: Eric Gray To: binny jeshan , "mpls@ietf.org" Date: Thu, 11 Aug 2011 07:03:09 -0400 Thread-Topic: Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 Thread-Index: AcxAZ8Iuor4OYFULT7mPiL+c0YrKTgXrKqiA Message-ID: References: In-Reply-To: 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_C0AC8FAB6849AB4FADACCC70A949E2F11172EB3ED5EUSAACMS0701e_" MIME-Version: 1.0 Cc: Ross Callon , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 11:02:53 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F11172EB3ED5EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Binny, We discussed this in detail. Superficially, this seemed like a great i= dea, with precedents in the CC/CV/RDI draft. The issues we ran into include: 1) the Static PW ID TLV is already a sub-TLV; there are issues and a very undesirable precedent associated with creating a sub-TLV for a sub-TLV. 2) the flexibility associated with inheriting the type code also poses a ri= sk; we cannot know in advance what other AGI types might be invented in the future, and whether or not it would make sense in then existing TP implementations to support generally the new type(s) as part of the Static PW Identifier Sub-TLV. What we decided to do was to change the name of the field to "Service Identifier" - which will be an unsigned integer and which may contain a typ= e 0x01 AGI, for example. Because it is an unsigned integer, it may also be used to contain anything smaller than 64 bits. The flexibility to support other AGI types still exists, should it beco= me necessary to do so. In that event, we could define additional Static PW Sub-TLV type(s) to support any AGI type(s) that make sense at that time. Thanks for your thoughtful and thought-provoking input! We appreciate your putting time into reviewing our draft... -- Eric ________________________________ From: binny jeshan [mailto:binnyjeshan@gmail.com] Sent: Tuesday, July 12, 2011 3:46 AM To: mpls@ietf.org Cc: draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; Ross Callon; George Swa= llow; MPLS-TP ad hoc team; Loa Andersson; Binny Jeshan Subject: Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 Dear Authors, In the new draft version 05, in section 2.3.2 (Static Pseudowire Sub-TLV), = AGI is not made up in a TLV format (when comparing RFC 4446 section 3.4; RF= C 4447 Section 5.3.2). I had raised this question during the review, but i am not understanding th= e reason behind why this is still not built in as a TLV, but 'always' a 2 w= ord format (a normal 7byte+1pad L2VPN ID). Kindly clarify Thanks for the time, Binny. On 17 June 2011 11:34, binny jeshan > wrote: Hello, In this new draft version section 2.3.2., where the AGI field is newly adde= d, my question is - shouldn't the AGI Type and Length also be included in t= he FEC TLV structure? Also, wouldn't it be clear if the usage of EXP bits in (PHB consideration) = is also explicitly defined somewhere around the responder procedures? Thanks, Binny. On 17 June 2011 01:30, Loa Andersson > wrote: Working Group. the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID after wg last call and published version -04 of the document. A document detailing how the comments have been addressed will be found at: http://www.pi.nu/~loa/comments-on-03.xls This is to start a working group call to verify that all comments been adequately addressed. Please send your comments to the mpls working group mailing list before June 24th. Loa on behalf of the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C0AC8FAB6849AB4FADACCC70A949E2F11172EB3ED5EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Binny,
 
  &n= bsp; We discussed this in detail. =20 Superficially, this seemed like a great idea,
with precedents in the CC/CV/RDI draft.
 
  &n= bsp; The issues we ran into=20 include:
1) the Static PW ID TLV is already a sub-TLV; ther= e are=20 issues and a very
  &n= bsp; undesirable precedent associated with= creating a=20 sub-TLV for a sub-TLV.
2) the flexibility associated with inheriting the = type code=20 also poses a risk;
  &n= bsp; we cannot know in advance what other = AGI types=20 might be invented in
  &n= bsp; the future, and whether or not it wou= ld make=20 sense in then existing TP
    implementations to support gene= rally the=20 new type(s) as part of the
    Static PW Identifier=20 Sub-TLV.
 
  &n= bsp; What we decided to do was to change t= he name of=20 the field to "Service
Identifier" - which will be an unsigned integer an= d which=20 may contain a type
0x01 AGI, for example.  Because it is an unsi= gned=20 integer, it may also be
used to contain anything smaller than 64=20 bits.
 
  &n= bsp; The flexibility to support other AGI = types still=20 exists, should it become
necessary to do so.  In that event, we could = define=20 additional Static PW
Sub-TLV type(s) to support any AGI type(s) that ma= ke sense=20 at that time.
 
  &n= bsp; Thanks for your thoughtful and though= t-provoking=20 input! We appreciate
your putting time into reviewing our=20 draft...
 
--
= Eric<= BR>
From: binny jeshan=20 [mailto:binnyjeshan@gmail.com]
Sent: Tuesday, July 12, 2011 3:46= =20 AM
To: mpls@ietf.org
Cc:=20 draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; Ross Callon; George Swallow= ;=20 MPLS-TP ad hoc team; Loa Andersson; Binny Jeshan
Subject: Need=20 clarification on draft-ietf-mpls-tp-on-demand-cv-05

Dear Authors,

In the new draft version 05, in section 2.3= .2=20 (Static Pseudowire Sub-TLV), AGI is not made up in a TLV format (when compa= ring=20 RFC 4446 section 3.4; RFC 4447 Section 5.3.2).

I had raised this=20 question during the review, but i am not understanding the reason behind wh= y=20 this is still not built in as a TLV, but 'always' a 2 word format (a normal= =20 7byte+1pad L2VPN ID).

Kindly clarify

Thanks for the=20 time,
Binny.

On 17 June 2011 11:34, binny jeshan <binnyjeshan@gmail.com>= =20 wrote:
Hello,

In=20 this new draft version section 2.3.2., where the AGI field is newly added= , my=20 question is - shouldn't the AGI Type and Length also be included in the F= EC=20 TLV structure?

Also, wouldn't it be clear if the usage of EXP bits= in=20 (PHB consideration) is also explicitly defined somewhere around the respo= nder=20 procedures?

Thanks,
Binny.


On 17 June 2011 01:30, Loa Andersson <loa@pi.nu&= gt;=20 wrote:
Working=20 Group.

the authors of draft-ietf-mpls-tp-on-demand-cv have updat= ed=20 the ID
after wg last call and published version -04 of the=20 document.

A document detailing how the comments have been addres= sed=20 will be
found at:
http://www.pi.nu/~loa/comments-on-03.xls

Thi= s is to=20 start a working group call to verify that all comments
been adequate= ly=20 addressed. Please send your comments to the
mpls working group maili= ng=20 list before June 24th.

Loa
on behalf of the MPLS wg=20 co-chairs

--


Loa Andersson &nb= sp;=20                     &= nbsp;=20 email: loa.andersson@ericsson.com
Sr Strategy and Stand= ards=20 Manager            loa@pi.nu
Ericsson Inc       &nbs= p;=20                  phone: +4= 6 10=20 717 52 13
                &n= bsp;=20                     &= nbsp;=20     +46 767 72 92=20 13
_______________________________________________
mpls mailing=20 list
mpls@ietf.org<= /A>
https://www.ietf.org/mailman/listinfo/mpls


--_000_C0AC8FAB6849AB4FADACCC70A949E2F11172EB3ED5EUSAACMS0701e_-- From iesg-secretary@ietf.org Thu Aug 11 06:45:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAF021F89C1; Thu, 11 Aug 2011 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yto609-XFMzV; Thu, 11 Aug 2011 06:45:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15921F877D; Thu, 11 Aug 2011 06:45:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811134542.25435.61281.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 06:45:42 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:45:42 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. From Rolf.Winter@neclab.eu Thu Aug 11 07:04:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4B721F855B for ; Thu, 11 Aug 2011 07:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-B9SmVLz9oU for ; Thu, 11 Aug 2011 07:04:03 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CE8EE21F8559 for ; Thu, 11 Aug 2011 07:04:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BDA2D28000332; Thu, 11 Aug 2011 16:04:36 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTIeoum7kwkV; Thu, 11 Aug 2011 16:04:36 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9DF3E28000330; Thu, 11 Aug 2011 16:04:26 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 16:04:26 +0200 From: Rolf Winter To: Rui Costa , "mpls@ietf.org" Thread-Topic: new version of the per-interface MIP draft Thread-Index: AcxAZUHe1PZf+IEdRiimifl0q6Q95QWNnAVwAGSUEaA= Date: Thu, 11 Aug 2011 14:04:26 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D048DA0@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D1CFC4580@DAPHNIS.office.hd> <52981DB05D3C5247A12D0AEE309F3CC201ED4E0B008D@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4E0B008D@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] new version of the per-interface MIP draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 14:04:03 -0000 Hi Rui, Thanks for your comments. Do you have an opinion on which option to go for?= More inline: > 1. In point 4, by the end of page 6, "Figure 2 depicts OAM using per- > interface MIPs and MEPs": don't you actually mean "per-node"? Good catch. You're absolutely right. > 2. In "6.1. ID-based Solution", by the end: how does a node know an > OAM message was "intended for its upstream neighbor's outgoing MIP"? The last bullet point (in fact all bullet points) first state the requireme= nt and then how it is handled. The rational here is that this situation sho= uld never arise, i.e. the downstream node should not even receive an OAM me= ssage that was intended for the upstream outgoing MIP (which is not present= since we are talking about a per-node MIP node). The reason is that the TT= L is addressing the node. That means the at the upstream node the TTL expir= es. The MIP will detect an ID mismatch and should discard the packet. There= fore, the packet should not even make it to the downstream node. I think I = need to do some rewording to make this more clear. Thanks again, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 From ietf-ipr@ietf.org Thu Aug 11 08:06:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32E21F8781; Thu, 11 Aug 2011 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fHVAajF-vSB; Thu, 11 Aug 2011 08:06:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CB21F86AD; Thu, 11 Aug 2011 08:06:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: kireeti@juniper.net, jdrake@juniper.net, shane@level3.net, wim.henderickx@alcatel-lucent.com, lucyyong@huawei.com, X-Test-IDTracker: no Message-ID: <20110811150645.23230.58406.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 08:06:45 -0700 Cc: mpls@ietf.org, housley@vigilsec.com, rcallon@juniper.net, stbryant@cisco.com, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-entropy-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:06:46 -0000 Dear Kireeti Kompella, John Drake, Shane Amante, Wim Henderickx, Lucy Yong: An IPR disclosure that pertains to your Internet-Draft entitled "The Use of Entropy Labels in MPLS Forwarding" (draft-ietf-mpls-entropy-label) was subm= itted to the IETF Secretariat on 2011-08-11 and has been posted on the "IETF Page= of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1605/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mp= ls- entropy-label-00.""); The IETF Secretariat From jcucchiara@mindspring.com Thu Aug 11 08:49:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9EE21F8B82 for ; Thu, 11 Aug 2011 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCBx5CwXRE6j for ; Thu, 11 Aug 2011 08:49:04 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDD221F8B80 for ; Thu, 11 Aug 2011 08:49:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L/BQozGCzQ3IFlUw7qJZQ8r2n240Vqim50iVc8tBd0qXg/lGNLhVy6WwswCjEV1Y; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QrXVq-0001un-Au; Thu, 11 Aug 2011 11:49:38 -0400 Message-ID: <01c501cc583e$462ccea0$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Thomas Nadeau" References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> Date: Thu, 11 Aug 2011 11:49:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26542c754900c24808ac6224ffd776e2a3f8a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:49:05 -0000 Tom, Thank you for adding additional info about how the mappping tables should/could be used. Of course, what working group wants is fine by me wrt making the mapping tables optional or not. I have considered your preference and think that keeping the mapping tables with the agent may be reasonable for larger devices which should have the resources to support them and have an E/NMS to take advantage of these tables. Thanks, -Joan ----- Original Message ----- From: "Thomas Nadeau" To: "Joan Cucchiara" Cc: Sent: Wednesday, August 10, 2011 10:58 AM Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: > > ----- Original Message ----- From: "Thomas Nadeau" > > To: "Joan Cucchiara" > Cc: > Sent: Tuesday, August 09, 2011 10:47 AM > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt > > >> >> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >> >>> >>> Spike, >>> >>> Wanted to comment on your 3 suggestions for indexing. >>> >>> Suggestion #1 is also my preference. This is the most straightforward >>> and least complex >>> design in my opinion. Additionally, the CLI, Web, NMS, etc could >>> display both MPLS >>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the >>> complexity of the >>> mapping is not in the MIB (or agent). >> >> That is the idea we were after. We want a new table that shows "TP >> tunnels" >> as a (proper) subset of those defined globally. That is, the indexing >> "extends" those in >> the MplsTunnelTable. >> >>> Suggestion #2 is not allowed because redefining indices is not allowed >>> in the SMI. >>> (We had a few emails about this during the time that the MIB was being >>> adopted by the WG.) >> >> Spot on. The only way to take this approach is to deprecate RFC3811, 12, >> and 13 as >> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >> >>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same >>> table. >>> While this goal may have some benefits, the design to accomplish the >>> goal is more complex than #1 >>> as you point out. I have asked the authors to ensure that there are no >>> backwards compatibility issues >>> with the design so that the MPLS Tunnel Table is already populated >>> and then MPLS-TP Tunnel indices are created such that they do not >>> conflict with already >>> existing tunnel indices. In a nutshell, the problem I have with this >>> design is that there are 2 ways of creating indices >>> for the same Table, one which is legacy and has been around since 2004 >>> and now a second way. >> >> Don't you get both "existing at the same time in the same table" by using >> the 'extends' relationship? >> >> >>> There may be a #4 Suggestion which is to implement design #1 but also >>> have an additional (optional?) table >>> which is a superset of Tunnels, this could be indexed by a type field. >> >> The MIB provides mapping tables *in addition to* the basic table that >> extends the MplsTunnelTable. >> This is provided as a convenience for the E/NMS to speed table >> traversal/manipulation. >> > > Tom, > > That wasn't clear (at least to me), could this be clarified in next rev? Yes, of course! 8) > Also, may be more beneficial to make these mapping tables optional -- not > every vendor will need to > implement them, since they are for E/NMS. That is possible, but as you know is up to the working group. It is my personal preference as a vendor of management applications, to avoid optional things where possible, as they are unlikely to ever get implemented on devices and make things more difficult for applications. --Tom > > Thanks, > -Joan > > > >> --Tom >> >> >>> >>> Thanks, >>> -Joan >>> >>> >>> ----- Original Message ----- From: "Eric Gray" >>> To: >>> Sent: Tuesday, August 09, 2011 9:05 AM >>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>> >>> >>>> Forwarding in plain text... >>>> >>>> ________________________________ >>>> >>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>> Sent: Monday, August 08, 2011 5:25 AM >>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>> Cc: mpls@ietf.org >>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>> >>>> >>>> >>>> Hi Venkat & all, >>>> >>>> >>>> >>>> I've read the draft and have a question and then some comments. I'm >>>> happy to be of assistance with any of what follows, and/or with working >>>> on other MIB drafts that we need to fill out the gaps identified in >>>> draft-ietf-mpls-tp-mib-management-overview. >>>> >>>> >>>> >>>> >>>> >>>> MPLS-TP Identifiers: >>>> >>>> I understand that one of the purposes of this draft is to allow >>>> configuration using MPLS-TP identifiers. Presumably, there are at >>>> least three ways this could be accomplished: >>>> >>>> 1. Define a brand new tunnel table for MPLS-TP, based on the >>>> mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>>> >>>> 2. Redefine the existing mplsTunnelTable indexing, adding GlobalID >>>> and ICC for ingress and egress nodes, and using 0 as "not used" values >>>> to allow back-compatibility. >>>> >>>> 3. Create a separate set of tables which maps the old identifiers >>>> to the new MPLS-TP identifiers. >>>> >>>> This draft takes the third strategy, but it's not immediately clear to >>>> me why this is preferable to the other two. (2) seems the least >>>> complicated because it does away extra mapping and inverse mapping >>>> tables. It's also difficult to guarantee that local identifiers (which >>>> don't have configuration or signalling significance) will not change in >>>> the case of graceful restart or configuration replay. Was option (3) >>>> chosen to avoid back-compatibility issues, or for other reasons? >>>> >>>> >>>> >>>> A comment on tunnels: >>>> >>>> I'd like to clarify how unidirectional, associated bidirectional and >>>> co-routed bidirectional paths are modelled in the MIB, and how exactly >>>> the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB >>>> fields. My preference is as follows. >>>> >>>> >>>> >>>> * Unidirectional LSPs in MPLS-TP are very similar to "normal" >>>> MPLS, but with different identifiers. Tunnels of this type do not have >>>> any entries in the mplsTunnelExtTable. >>>> >>>> >>>> >>>> * In associated bidirectional LSPs, the transport directions >>>> are set up and monitored independently, so each transport direction >>>> should be a separate row in the mplsTunnelTable. >>>> >>>> >>>> >>>> * In co-routed bidirectional LSPs, both transport directions >>>> are set up and monitored together. This means we should have only one >>>> row in the mplsTunnelTable to represent a tunnel of this type. This is >>>> not how the draft is currently structured, where the example in Section >>>> 9 creates two rows in the mplsTunnelTable. >>>> >>>> >>>> >>>> About gaps: >>>> >>>> Lastly, I think the MIB is still missing some configuration that we'll >>>> need in order to satisfy MPLS-TP requirements. These include >>>> >>>> * Bidirectional tunnels with asymmetric resource requirements >>>> >>>> * OAM configuration. Presumably this will be a reference to >>>> yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM >>>> profiles. >>>> >>>> >>>> >>>> Let me know if I can be of further assistance. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Spike >>>> >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> * To: i-d-announce at ietf.org >>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>> * From: internet-drafts at ietf.org >>>> >>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>> * Cc: mpls at ietf.org >>>> * Delivered-to: mpls at ietfa.amsl.com >>>> * List-archive: >>>> * List-help: >>>> * List-id: Multi-Protocol Label Switching WG >>>> * List-post: >>>> * List-subscribe: , >>>> >>>> * List-unsubscribe: , >>>> >>>> >>>> ________________________________ >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the Multiprotocol Label >>>> Switching Working Group of the IETF. >>>> >>>> Title : MPLS-TP Traffic Engineering (TE) Management >>>> Information Base (MIB) >>>> Author(s) : Venkatesan Mahalingam >>>> Kannan KV Sampath >>>> Huawei Technologies >>>> Thomas D. Nadeau >>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>> Pages : 39 >>>> Date : 2011-06-17 >>>> >>>> This memo defines a portion of the Management Information Base (MIB) >>>> for use with network management protocols in the Internet community. >>>> In particular, it describes managed objects of Tunnels, Identifiers, >>>> Label Switch Router and Textual conventions for Multiprotocol Label >>>> Switching (MPLS) based Transport Profile (TP). >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>> ________________________________ >>>> >>>> >>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's >>>> Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>>> >>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., >>>> Ltd's Statement about IPR related to RFC 5919 >>>> >>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., >>>> Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>>> >>>> * Next by thread: [mpls] I-D Action: >>>> draft-ietf-mpls-ldp-ip-pw-capability-00.txt >>>> >>>> * Index(es): >>>> >>>> * Date >>>> >>>> * Thread >>>> >>>> >>>> >>>> Note: Messages sent to this list are the opinions of the senders and do >>>> not imply endorsement by the IETF. >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > From tnadeau@lucidvision.com Thu Aug 11 08:56:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E09A21F8BA4 for ; Thu, 11 Aug 2011 08:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov2aD0Lg1ZWZ for ; Thu, 11 Aug 2011 08:56:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D604E21F8BA0 for ; Thu, 11 Aug 2011 08:56:20 -0700 (PDT) Received: from [10.100.68.51] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id F0C061D70940; Thu, 11 Aug 2011 11:56:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau X-Priority: 3 In-Reply-To: <01c501cc583e$462ccea0$6601a8c0@JoanPC> Date: Thu, 11 Aug 2011 11:56:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> <01c501cc583e$462ccea0$6601a8c0@JoanPC> To: "Joan Cucchiara" X-Mailer: Apple Mail (2.1244.3) Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:56:22 -0000 Cool. Thanks! On Aug 11, 2011, at 11:49 AM, Joan Cucchiara wrote: >=20 > Tom, >=20 > Thank you for adding additional info about how the mappping tables > should/could be used. >=20 > Of course, what working group wants is fine by me wrt making the > mapping tables optional or not. >=20 > I have considered your preference and think that keeping the > mapping tables with the agent may be reasonable for larger devices = which > should have the resources to support them and have an E/NMS to > take advantage of these tables. >=20 > Thanks, > -Joan >=20 >=20 > ----- Original Message ----- From: "Thomas Nadeau" = > To: "Joan Cucchiara" > Cc: > Sent: Wednesday, August 10, 2011 10:58 AM > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 >=20 >=20 > On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >=20 >>=20 >> ----- Original Message ----- From: "Thomas Nadeau" = >> To: "Joan Cucchiara" >> Cc: >> Sent: Tuesday, August 09, 2011 10:47 AM >> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >>=20 >>>=20 >>> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>>=20 >>>>=20 >>>> Spike, >>>>=20 >>>> Wanted to comment on your 3 suggestions for indexing. >>>>=20 >>>> Suggestion #1 is also my preference. This is the most = straightforward and least complex >>>> design in my opinion. Additionally, the CLI, Web, NMS, etc could = display both MPLS >>>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the = complexity of the >>>> mapping is not in the MIB (or agent). >>>=20 >>> That is the idea we were after. We want a new table that shows "TP = tunnels" >>> as a (proper) subset of those defined globally. That is, the = indexing "extends" those in >>> the MplsTunnelTable. >>>=20 >>>> Suggestion #2 is not allowed because redefining indices is not = allowed in the SMI. >>>> (We had a few emails about this during the time that the MIB was = being adopted by the WG.) >>>=20 >>> Spot on. The only way to take this approach is to deprecate RFC3811, = 12, and 13 as >>> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>>=20 >>>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the = same table. >>>> While this goal may have some benefits, the design to accomplish = the goal is more complex than #1 >>>> as you point out. I have asked the authors to ensure that there = are no backwards compatibility issues >>>> with the design so that the MPLS Tunnel Table is already populated >>>> and then MPLS-TP Tunnel indices are created such that they do not = conflict with already >>>> existing tunnel indices. In a nutshell, the problem I have with = this design is that there are 2 ways of creating indices >>>> for the same Table, one which is legacy and has been around since = 2004 and now a second way. >>>=20 >>> Don't you get both "existing at the same time in the same table" by = using the 'extends' relationship? >>>=20 >>>=20 >>>> There may be a #4 Suggestion which is to implement design #1 but = also have an additional (optional?) table >>>> which is a superset of Tunnels, this could be indexed by a type = field. >>>=20 >>> The MIB provides mapping tables *in addition to* the basic table = that extends the MplsTunnelTable. >>> This is provided as a convenience for the E/NMS to speed table = traversal/manipulation. >>>=20 >>=20 >> Tom, >>=20 >> That wasn't clear (at least to me), could this be clarified in next = rev? >=20 > Yes, of course! 8) >=20 >> Also, may be more beneficial to make these mapping tables optional -- = not every vendor will need to >> implement them, since they are for E/NMS. >=20 > That is possible, but as you know is up to the working group. It is my = personal preference as a vendor of management applications, > to avoid optional things where possible, as they are unlikely to ever = get implemented on devices and make things more difficult for > applications. >=20 > --Tom >=20 >=20 >>=20 >> Thanks, >> -Joan >>=20 >>=20 >>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>> ----- Original Message ----- From: "Eric Gray" = >>>> To: >>>> Sent: Tuesday, August 09, 2011 9:05 AM >>>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>=20 >>>>=20 >>>>> Forwarding in plain text... >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>>> Sent: Monday, August 08, 2011 5:25 AM >>>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>>> Cc: mpls@ietf.org >>>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Hi Venkat & all, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I've read the draft and have a question and then some comments. = I'm happy to be of assistance with any of what follows, and/or with = working on other MIB drafts that we need to fill out the gaps identified = in draft-ietf-mpls-tp-mib-management-overview. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> MPLS-TP Identifiers: >>>>>=20 >>>>> I understand that one of the purposes of this draft is to allow = configuration using MPLS-TP identifiers. Presumably, there are at least = three ways this could be accomplished: >>>>>=20 >>>>> 1. Define a brand new tunnel table for MPLS-TP, based on the = mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>>>>=20 >>>>> 2. Redefine the existing mplsTunnelTable indexing, adding = GlobalID and ICC for ingress and egress nodes, and using 0 as "not used" = values to allow back-compatibility. >>>>>=20 >>>>> 3. Create a separate set of tables which maps the old = identifiers to the new MPLS-TP identifiers. >>>>>=20 >>>>> This draft takes the third strategy, but it's not immediately = clear to me why this is preferable to the other two. (2) seems the least = complicated because it does away extra mapping and inverse mapping = tables. It's also difficult to guarantee that local identifiers (which = don't have configuration or signalling significance) will not change in = the case of graceful restart or configuration replay. Was option (3) = chosen to avoid back-compatibility issues, or for other reasons? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A comment on tunnels: >>>>>=20 >>>>> I'd like to clarify how unidirectional, associated bidirectional = and co-routed bidirectional paths are modelled in the MIB, and how = exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto = MIB fields. My preference is as follows. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> * Unidirectional LSPs in MPLS-TP are very similar to = "normal" MPLS, but with different identifiers. Tunnels of this type do = not have any entries in the mplsTunnelExtTable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> * In associated bidirectional LSPs, the transport = directions are set up and monitored independently, so each transport = direction should be a separate row in the mplsTunnelTable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> * In co-routed bidirectional LSPs, both transport = directions are set up and monitored together. This means we should have = only one row in the mplsTunnelTable to represent a tunnel of this type. = This is not how the draft is currently structured, where the example in = Section 9 creates two rows in the mplsTunnelTable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> About gaps: >>>>>=20 >>>>> Lastly, I think the MIB is still missing some configuration that = we'll need in order to satisfy MPLS-TP requirements. These include >>>>>=20 >>>>> * Bidirectional tunnels with asymmetric resource = requirements >>>>>=20 >>>>> * OAM configuration. Presumably this will be a reference = to yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM = profiles. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Let me know if I can be of further assistance. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Spike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>> * To: i-d-announce at ietf.org >>>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>> * From: internet-drafts at ietf.org = >>>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>>> * Cc: mpls at ietf.org >>>>> * Delivered-to: mpls at ietfa.amsl.com >>>>> * List-archive: >>>>> * List-help: >>>>> * List-id: Multi-Protocol Label Switching WG >>>>> * List-post: >>>>> * List-subscribe: , = >>>>> * List-unsubscribe: , = >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Multiprotocol Label = Switching Working Group of the IETF. >>>>>=20 >>>>> Title : MPLS-TP Traffic Engineering (TE) Management = Information Base (MIB) >>>>> Author(s) : Venkatesan Mahalingam >>>>> Kannan KV Sampath >>>>> Huawei Technologies >>>>> Thomas D. Nadeau >>>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>>> Pages : 39 >>>>> Date : 2011-06-17 >>>>>=20 >>>>> This memo defines a portion of the Management Information Base = (MIB) >>>>> for use with network management protocols in the Internet = community. >>>>> In particular, it describes managed objects of Tunnels, = Identifiers, >>>>> Label Switch Router and Textual conventions for Multiprotocol = Label >>>>> Switching (MPLS) based Transport Profile (TP). >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> = http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>> ________________________________ >>>>>=20 >>>>>=20 >>>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to RFC 5919 = >>>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>>> * Next by thread: [mpls] I-D Action: = draft-ietf-mpls-ldp-ip-pw-capability-00.txt = >>>>> * Index(es): >>>>>=20 >>>>> * Date = >>>>> * Thread = >>>>>=20 >>>>>=20 >>>>> Note: Messages sent to this list are the opinions of the senders = and do not imply endorsement by the IETF. >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >=20 >=20 From binnyjeshan@gmail.com Sat Aug 13 11:53:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B1C21F863A for ; Sat, 13 Aug 2011 11:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90R62UUMxe-j for ; Sat, 13 Aug 2011 11:53:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59A21F85B5 for ; Sat, 13 Aug 2011 11:53:46 -0700 (PDT) Received: by fxe6 with SMTP id 6so3219510fxe.31 for ; Sat, 13 Aug 2011 11:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oiwkZzH1H5CU5jcDymo7chE5TwsgAYC0gs4ukZ1GZ84=; b=yCePk72sRlf2Y8KaNQ8Odw/NapOP6cLusrH2UH3lB7/eUZ4ioDtbSZN0jSjs1TLCw0 6nrsORlXEfdy/4nxJVpjM3chMlprveudS1m6u13+MEQt8coBBTt0mNTt2vAFbz9TIiTu 6j//SvaanM3NB8+rhIB9RDiOWDG0+wi9B5JyE= MIME-Version: 1.0 Received: by 10.223.76.71 with SMTP id b7mr3097751fak.30.1313261652496; Sat, 13 Aug 2011 11:54:12 -0700 (PDT) Received: by 10.223.71.200 with HTTP; Sat, 13 Aug 2011 11:54:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Aug 2011 00:24:12 +0530 Message-ID: From: binny jeshan To: Eric Gray Content-Type: multipart/alternative; boundary=0015174786be4b50ce04aa678ecb Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" , Ross Callon Subject: Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 18:53:52 -0000 --0015174786be4b50ce04aa678ecb Content-Type: text/plain; charset=ISO-8859-1 Hi Eric and Authors, Thank you for considering this change in the new draft version 06. -Binny On 11 August 2011 16:33, Eric Gray wrote: > ** > Binny, > > We discussed this in detail. Superficially, this seemed like a great > idea, > with precedents in the CC/CV/RDI draft. > > The issues we ran into include: > 1) the Static PW ID TLV is already a sub-TLV; there are issues and a very > undesirable precedent associated with creating a sub-TLV for a > sub-TLV. > 2) the flexibility associated with inheriting the type code also poses a > risk; > we cannot know in advance what other AGI types might be invented in > the future, and whether or not it would make sense in then existing TP > implementations to support generally the new type(s) as part of the > Static PW Identifier Sub-TLV. > > What we decided to do was to change the name of the field to "Service > Identifier" - which will be an unsigned integer and which may contain a > type > 0x01 AGI, for example. Because it is an unsigned integer, it may also be > used to contain anything smaller than 64 bits. > > The flexibility to support other AGI types still exists, should it > become > necessary to do so. In that event, we could define additional Static PW > Sub-TLV type(s) to support any AGI type(s) that make sense at that time. > > Thanks for your thoughtful and thought-provoking input! We appreciate > your putting time into reviewing our draft... > > -- > Eric > ------------------------------ > *From:* binny jeshan [mailto:binnyjeshan@gmail.com] > *Sent:* Tuesday, July 12, 2011 3:46 AM > *To:* mpls@ietf.org > *Cc:* draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; Ross Callon; George > Swallow; MPLS-TP ad hoc team; Loa Andersson; Binny Jeshan > *Subject:* Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 > > Dear Authors, > > In the new draft version 05, in section 2.3.2 (Static Pseudowire Sub-TLV), > AGI is not made up in a TLV format (when comparing RFC 4446 section 3.4; RFC > 4447 Section 5.3.2). > > I had raised this question during the review, but i am not understanding > the reason behind why this is still not built in as a TLV, but 'always' a 2 > word format (a normal 7byte+1pad L2VPN ID). > > Kindly clarify > > Thanks for the time, > Binny. > > On 17 June 2011 11:34, binny jeshan wrote: > >> Hello, >> >> In this new draft version section 2.3.2., where the AGI field is newly >> added, my question is - shouldn't the AGI Type and Length also be included >> in the FEC TLV structure? >> >> Also, wouldn't it be clear if the usage of EXP bits in (PHB consideration) >> is also explicitly defined somewhere around the responder procedures? >> >> Thanks, >> Binny. >> >> >> On 17 June 2011 01:30, Loa Andersson wrote: >> >>> Working Group. >>> >>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID >>> after wg last call and published version -04 of the document. >>> >>> A document detailing how the comments have been addressed will be >>> found at: >>> http://www.pi.nu/~loa/comments-on-03.xls >>> >>> This is to start a working group call to verify that all comments >>> been adequately addressed. Please send your comments to the >>> mpls working group mailing list before June 24th. >>> >>> Loa >>> on behalf of the MPLS wg co-chairs >>> >>> -- >>> >>> >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> > --0015174786be4b50ce04aa678ecb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Eric and Authors,

Thank you for considering this chan= ge in the new draft version 06.

-Binny
<= br>
On 11 August 2011 16:33, Eric Gray <eric.gray@ericsson.com> w= rote:
Binny,
=A0
=A0=A0=A0 We discussed this in detail.=A0=20 Superficially, this seemed like a great idea,
with precedents in the CC/CV/RDI draft.
=A0
=A0=A0=A0 The issues we ran into=20 include:
1) the Static PW ID TLV is already a sub-TLV; there are=20 issues and a very
=A0=A0=A0 undesirable precedent associated with creating a=20 sub-TLV for a sub-TLV.
2) the flexibility associated with inheriting the type code=20 also poses a risk;
=A0=A0=A0 we cannot know in advance what other AGI types=20 might be invented in
=A0=A0=A0 the future, and whether or not it would make=20 sense in then existing TP
=A0=A0=A0 implementations to support generally the=20 new type(s) as part of the
=A0=A0=A0 Static PW Identifier=20 Sub-TLV.
=A0
=A0=A0=A0 What we decided to do was to change the name of=20 the field to "Service
Identifier" - which will be an unsigned integer and which= =20 may contain a type
0x01 AGI, for example.=A0 Because it is an unsigned=20 integer, it may also be
used to contain anything smaller than 64=20 bits.
=A0
=A0=A0=A0 The flexibility to support other AGI types still=20 exists, should it become
necessary to do so.=A0 In that event, we could define=20 additional Static PW
Sub-TLV type(s) to support any AGI type(s) that make sense=20 at that time.
=A0
=A0=A0=A0 Thanks for your thoughtful and thought-provoking=20 input! We appreciate
your putting time into reviewing our=20 draft...
=A0
--
Eric
From: binny jeshan=20 [mailto:binnyjes= han@gmail.com]
Sent: Tuesday, July 12, 2011 3:46=20 AM
To: mpls@ie= tf.org
Cc:=20 draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; Ross Callon; G= eorge Swallow;=20 MPLS-TP ad hoc team; Loa Andersson; Binny Jeshan
Subject: Need=20 clarification on draft-ietf-mpls-tp-on-demand-cv-05

Dear Authors,

In the new draft version 05, in section 2.3= .2=20 (Static Pseudowire Sub-TLV), AGI is not made up in a TLV format (when compa= ring=20 RFC 4446 section 3.4; RFC 4447 Section 5.3.2).

I had raised this=20 question during the review, but i am not understanding the reason behind wh= y=20 this is still not built in as a TLV, but 'always' a 2 word format (= a normal=20 7byte+1pad L2VPN ID).

Kindly clarify

Thanks for the=20 time,
Binny.

On 17 June 2011 11:34, binny jeshan = <binnyjeshan@= gmail.com>=20 wrote:
Hello,

In=20 this new draft version section 2.3.2., where the AGI field is newly added= , my=20 question is - shouldn't the AGI Type and Length also be included in t= he FEC=20 TLV structure?

Also, wouldn't it be clear if the usage of EXP = bits in=20 (PHB consideration) is also explicitly defined somewhere around the respo= nder=20 procedures?

Thanks,
Binny.


On 17 June 2011 01:30, Loa Andersson <loa@pi.nu>=20 wrote:
Working=20 Group.

the authors of draft-ietf-mpls-tp-on-demand-cv have updat= ed=20 the ID
after wg last call and published version -04 of the=20 document.

A document detailing how the comments have been addres= sed=20 will be
found at:
http://www.pi.nu/~loa/comments-on-03.xls
<= br>This is to=20 start a working group call to verify that all comments
been adequate= ly=20 addressed. Please send your comments to the
mpls working group maili= ng=20 list before June 24th.

Loa
on behalf of the MPLS wg=20 co-chairs

--


Loa Andersson = =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 email: = loa.andersson@ericsson.com
Sr Strategy and Standards=20 Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 10=20 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 +46 767 72 92=20 13
_______________________________________________
mpls mailing= =20 list
mpls@ietf.or= g
https://www.ietf.org/mailman/listinfo/mpls



--0015174786be4b50ce04aa678ecb-- From venkatflex@gmail.com Sun Aug 14 19:48:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D453D21F8A57 for ; Sun, 14 Aug 2011 19:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi0fenHv1rHR for ; Sun, 14 Aug 2011 19:48:42 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC2321F862F for ; Sun, 14 Aug 2011 19:48:42 -0700 (PDT) Received: by wwf5 with SMTP id 5so3026413wwf.13 for ; Sun, 14 Aug 2011 19:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HrfNQ5VGPMGlsgGV4nSXVCfZEbsj+fAdQEbscgJTncs=; b=v5E2uWLxN2hBYpb5ZR6F4CCgTg2eYnLjI4v62cIEBWK/SRHiffcK5Rr/C8F+CJrafd MVWPWcB9xli+bzjqqkr3qZBMiGuGGV4rSq4xzBLebX+LYkWj7qn/B3lvJGyPAHlmUs2n Ivo7/YLNWGJxhY5woIeFjGd5ZpKsgUaQFJTBk= MIME-Version: 1.0 Received: by 10.217.7.69 with SMTP id z47mr2902445wes.79.1313376563650; Sun, 14 Aug 2011 19:49:23 -0700 (PDT) Received: by 10.216.164.131 with HTTP; Sun, 14 Aug 2011 19:49:23 -0700 (PDT) Date: Sun, 14 Aug 2011 22:49:23 -0400 Message-ID: From: venkatesan mahalingam To: Spike.Curtis@metaswitch.com, draft-ietf-mpls-tp-te-mib@tools.ietf.org, mpls Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 02:48:43 -0000 Spike, Thanks for reviewing the draft. Please find below the responses inlined with the tag VM>> Thanks, Venkat. From: Spike Curtis [Spike.Curtis@metaswitch.com] Sent: Monday, August 08, 2011 2:55 PM To: draft-ietf-mpls-tp-te-mib@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Hi Venkat & all, I=92ve read the draft and have a question and then some comments. =A0I=92m happy to be of assistance with any of what follows, and/or with working on other MIB drafts that we need to fill out the gaps identified in draft-ietf-mpls-tp-mib-management-overview. MPLS-TP Identifiers: I understand that one of the purposes of this draft is to allow configuration using MPLS-TP identifiers. =A0Presumably, there are at least three ways this could be accomplished: 1. =A0 =A0 Define a brand new tunnel table for MPLS-TP, based on the mplsTunnelTable, but with the MPLS-TP identifiers as indices. 2. =A0 =A0 Redefine the existing mplsTunnelTable indexing, adding GlobalID and ICC for ingress and egress nodes, and using 0 as =93not used=94 values to allow back-compatibility. 3. =A0 =A0 Create a separate set of tables which maps the old identifiers to the new MPLS-TP identifiers. This draft takes the third strategy, but it=92s not immediately clear to me why this is preferable to the other two. (2) seems the least complicated because it does away extra mapping and inverse mapping tables. =A0It=92s also difficult to guarantee that local identifiers (which don=92t have configuration or signalling significance) will not change in the case of graceful restart or configuration replay. =A0Was option (3) chosen to avoid back-compatibility issues, or for other reasons? VM>> As replied by Tom, we reuse the existing mplsTunnelTable for bidirectional tunnel extensions also without affecting the backward compatibility. A comment on tunnels: I=92d like to clarify how unidirectional, associated bidirectional and co-routed bidirectional paths are modelled in the MIB, and how exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. =A0My preference is as follows. =B7 =A0 =A0 =A0 =A0 Unidirectional LSPs in MPLS-TP are very similar to =93n= ormal=94 MPLS, but with different identifiers. =A0Tunnels of this type do not have any entries in the mplsTunnelExtTable. VM>> Yes, this is how the tables are designed in the draft. =B7 =A0 =A0 =A0 =A0 In associated bidirectional LSPs, the transport directi= ons are set up and monitored independently, so each transport direction should be a separate row in the mplsTunnelTable. VM>> Yes, this is how the tables are designed in the draft. =B7 =A0 =A0 =A0 =A0 In co-routed bidirectional LSPs, both transport directi= ons are set up and monitored together. =A0This means we should have only one row in the mplsTunnelTable to represent a tunnel of this type. =A0This is not how the draft is currently structured, where the example in Section 9 creates two rows in the mplsTunnelTable. VM>> Thanks for pointing out this issue. We will update the draft with the required changes in the next version. About gaps: Lastly, I think the MIB is still missing some configuration that we=92ll need in order to satisfy MPLS-TP requirements. =A0These include =B7 =A0 =A0 =A0 =A0 Bidirectional tunnels with asymmetric resource requirem= ents VM>> We will address this requirement in the next version. =B7 =A0 =A0 =A0 =A0 OAM configuration. =A0Presumably this will be a referen= ce to yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM profiles. VM>> Please refer the draft http://tools.ietf.org/html/draft-vkst-mpls-tp-oam-id-mib-00 for more information. Let me know if I can be of further assistance. VM>> Thanks for your help. If time permits, please review the TP OAM identifier draft also and post the comments on MPLS WG mailing list. Cheers, Spike ________________________________ =A0* =A0 To: i-d-announce at ietf.org =A0* =A0 Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt =A0* =A0 From: internet-drafts at ietf.org =A0* =A0 Date: Fri, 17 Jun 2011 07:24:45 -0700 =A0* =A0 Cc: mpls at ietf.org =A0* =A0 Delivered-to: mpls at ietfa.amsl.com =A0* =A0 List-archive: =A0* =A0 List-help: =A0* =A0 List-id: Multi-Protocol Label Switching WG =A0* =A0 List-post: =A0* =A0 List-subscribe: , =A0* =A0 List-unsubscribe: , ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : MPLS-TP Traffic Engineering (TE)= Management Information Base (MIB) =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Venkatesan Mahalingam =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kannan KV Sampath =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Huawei Technologies =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas D. Nadeau =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-tp-te-mib-00.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 39 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-06-17 =A0 This memo defines a portion of the Management Information Base (MIB) =A0 for use with network management protocols in the Internet community. =A0 In particular, it describes managed objects of Tunnels, Identifiers, =A0 Label Switch Router and Textual conventions for Multiprotocol Label =A0 Switching (MPLS) based Transport Profile (TP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt ________________________________ =A0* =A0 Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 =A0* =A0 Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5919 =A0* =A0 Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 =A0* =A0 Next by thread: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-00.txt =A0* =A0 Index(es): =A0 =A0* =A0 Date =A0 =A0* =A0 Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF. From Spike.Curtis@metaswitch.com Mon Aug 15 01:57:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926F821F8AB0 for ; Mon, 15 Aug 2011 01:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUnAWb7LXwD4 for ; Mon, 15 Aug 2011 01:57:46 -0700 (PDT) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id A61B321F8AA9 for ; Mon, 15 Aug 2011 01:57:45 -0700 (PDT) Received: from ENFICSMBX1.datcon.co.uk (172.18.10.94) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 15 Aug 2011 10:00:48 +0100 Received: from ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715]) by ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19%20]) with mapi id 14.01.0289.001; Mon, 15 Aug 2011 09:58:30 +0100 From: Spike Curtis To: Thomas Nadeau , Joan Cucchiara Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Thread-Index: AQHMWD5FUUNhW5Pdwkeke+DOaKDjNJUXvUsAgAXknXA= Date: Mon, 15 Aug 2011 08:58:28 +0000 Message-ID: <86C289CC63A2544A932C48E05AC49582093FBB3D@ENFIRHMBX1.datcon.co.uk> References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> <01c501cc583e$462ccea0$6601a8c0@JoanPC> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 08:57:47 -0000 Hi Joan and Tom, What I meant by (1) was not to extend the mplsTunnelTable, but define a new= table. That is to say, a tunnel can appear in either the new MPLS-TP tunn= el table or the old mplsTunnelTable, not both. As Joan suggests, both tabl= es could be straightforwardly presented together at the user interface leve= l. With option 2 (modified indexing) ruled out, (1) becomes my preference as w= ell. As I mentioned, my main concern is with extra identifiers with only local s= ignificance. There are cases where rows in the table will be auto-created,= for example at LSP egress when the tunnel is signalled. The difficulty is= then to ensure they don't change if the tunnel is taken down and recreated= , or over a graceful restart. Indices to the mplsTunnelTable are reference= d in other MIBs like the pseudowire to MPLS tunnel binding and the mplsXCEx= tTable. -Spike -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Tho= mas Nadeau Sent: Thursday, August 11, 2011 4:57 PM To: Joan Cucchiara Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Cool. Thanks! On Aug 11, 2011, at 11:49 AM, Joan Cucchiara wrote: >=20 > Tom, >=20 > Thank you for adding additional info about how the mappping tables > should/could be used. >=20 > Of course, what working group wants is fine by me wrt making the > mapping tables optional or not. >=20 > I have considered your preference and think that keeping the > mapping tables with the agent may be reasonable for larger devices which > should have the resources to support them and have an E/NMS to > take advantage of these tables. >=20 > Thanks, > -Joan >=20 >=20 > ----- Original Message ----- From: "Thomas Nadeau" > To: "Joan Cucchiara" > Cc: > Sent: Wednesday, August 10, 2011 10:58 AM > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 >=20 >=20 > On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >=20 >>=20 >> ----- Original Message ----- From: "Thomas Nadeau" >> To: "Joan Cucchiara" >> Cc: >> Sent: Tuesday, August 09, 2011 10:47 AM >> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >>=20 >>>=20 >>> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>>=20 >>>>=20 >>>> Spike, >>>>=20 >>>> Wanted to comment on your 3 suggestions for indexing. >>>>=20 >>>> Suggestion #1 is also my preference. This is the most straightforwar= d and least complex >>>> design in my opinion. Additionally, the CLI, Web, NMS, etc could di= splay both MPLS >>>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the comp= lexity of the >>>> mapping is not in the MIB (or agent). >>>=20 >>> That is the idea we were after. We want a new table that shows "TP tunn= els" >>> as a (proper) subset of those defined globally. That is, the indexing "= extends" those in >>> the MplsTunnelTable. >>>=20 >>>> Suggestion #2 is not allowed because redefining indices is not allowed= in the SMI. >>>> (We had a few emails about this during the time that the MIB was being= adopted by the WG.) >>>=20 >>> Spot on. The only way to take this approach is to deprecate RFC3811, 12= , and 13 as >>> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>>=20 >>>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same t= able. >>>> While this goal may have some benefits, the design to accomplish the g= oal is more complex than #1 >>>> as you point out. I have asked the authors to ensure that there are n= o backwards compatibility issues >>>> with the design so that the MPLS Tunnel Table is already populated >>>> and then MPLS-TP Tunnel indices are created such that they do not conf= lict with already >>>> existing tunnel indices. In a nutshell, the problem I have with thi= s design is that there are 2 ways of creating indices >>>> for the same Table, one which is legacy and has been around since 2004= and now a second way. >>>=20 >>> Don't you get both "existing at the same time in the same table" by usi= ng the 'extends' relationship? >>>=20 >>>=20 >>>> There may be a #4 Suggestion which is to implement design #1 but also = have an additional (optional?) table >>>> which is a superset of Tunnels, this could be indexed by a type field. >>>=20 >>> The MIB provides mapping tables *in addition to* the basic table that e= xtends the MplsTunnelTable. >>> This is provided as a convenience for the E/NMS to speed table traversa= l/manipulation. >>>=20 >>=20 >> Tom, >>=20 >> That wasn't clear (at least to me), could this be clarified in next rev? >=20 > Yes, of course! 8) >=20 >> Also, may be more beneficial to make these mapping tables optional -- no= t every vendor will need to >> implement them, since they are for E/NMS. >=20 > That is possible, but as you know is up to the working group. It is my pe= rsonal preference as a vendor of management applications, > to avoid optional things where possible, as they are unlikely to ever get= implemented on devices and make things more difficult for > applications. >=20 > --Tom >=20 >=20 >>=20 >> Thanks, >> -Joan >>=20 >>=20 >>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>> ----- Original Message ----- From: "Eric Gray" >>>> To: >>>> Sent: Tuesday, August 09, 2011 9:05 AM >>>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>=20 >>>>=20 >>>>> Forwarding in plain text... >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>>> Sent: Monday, August 08, 2011 5:25 AM >>>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>>> Cc: mpls@ietf.org >>>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Hi Venkat & all, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I've read the draft and have a question and then some comments. I'm = happy to be of assistance with any of what follows, and/or with working on = other MIB drafts that we need to fill out the gaps identified in draft-ietf= -mpls-tp-mib-management-overview. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> MPLS-TP Identifiers: >>>>>=20 >>>>> I understand that one of the purposes of this draft is to allow confi= guration using MPLS-TP identifiers. Presumably, there are at least three w= ays this could be accomplished: >>>>>=20 >>>>> 1. Define a brand new tunnel table for MPLS-TP, based on the mpls= TunnelTable, but with the MPLS-TP identifiers as indices. >>>>>=20 >>>>> 2. Redefine the existing mplsTunnelTable indexing, adding GlobalI= D and ICC for ingress and egress nodes, and using 0 as "not used" values to= allow back-compatibility. >>>>>=20 >>>>> 3. Create a separate set of tables which maps the old identifiers= to the new MPLS-TP identifiers. >>>>>=20 >>>>> This draft takes the third strategy, but it's not immediately clear t= o me why this is preferable to the other two. (2) seems the least complicat= ed because it does away extra mapping and inverse mapping tables. It's als= o difficult to guarantee that local identifiers (which don't have configura= tion or signalling significance) will not change in the case of graceful re= start or configuration replay. Was option (3) chosen to avoid back-compati= bility issues, or for other reasons? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A comment on tunnels: >>>>>=20 >>>>> I'd like to clarify how unidirectional, associated bidirectional and = co-routed bidirectional paths are modelled in the MIB, and how exactly the = MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. My = preference is as follows. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> * Unidirectional LSPs in MPLS-TP are very similar to "normal"= MPLS, but with different identifiers. Tunnels of this type do not have an= y entries in the mplsTunnelExtTable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> * In associated bidirectional LSPs, the transport directions = are set up and monitored independently, so each transport direction should = be a separate row in the mplsTunnelTable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> * In co-routed bidirectional LSPs, both transport directions = are set up and monitored together. This means we should have only one row = in the mplsTunnelTable to represent a tunnel of this type. This is not how= the draft is currently structured, where the example in Section 9 creates = two rows in the mplsTunnelTable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> About gaps: >>>>>=20 >>>>> Lastly, I think the MIB is still missing some configuration that we'l= l need in order to satisfy MPLS-TP requirements. These include >>>>>=20 >>>>> * Bidirectional tunnels with asymmetric resource requirements >>>>>=20 >>>>> * OAM configuration. Presumably this will be a reference to = yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM profi= les. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Let me know if I can be of further assistance. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Spike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>> * To: i-d-announce at ietf.org >>>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>> * From: internet-drafts at ietf.org >>>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>>> * Cc: mpls at ietf.org >>>>> * Delivered-to: mpls at ietfa.amsl.com >>>>> * List-archive: >>>>> * List-help: >>>>> * List-id: Multi-Protocol Label Switching WG >>>>> * List-post: >>>>> * List-subscribe: , >>>>> * List-unsubscribe: , >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. This draft is a work item of the Multiprotocol Label Switching W= orking Group of the IETF. >>>>>=20 >>>>> Title : MPLS-TP Traffic Engineering (TE) Management Inf= ormation Base (MIB) >>>>> Author(s) : Venkatesan Mahalingam >>>>> Kannan KV Sampath >>>>> Huawei Technologies >>>>> Thomas D. Nadeau >>>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>>> Pages : 39 >>>>> Date : 2011-06-17 >>>>>=20 >>>>> This memo defines a portion of the Management Information Base (MIB) >>>>> for use with network management protocols in the Internet community. >>>>> In particular, it describes managed objects of Tunnels, Identifiers, >>>>> Label Switch Router and Textual conventions for Multiprotocol Label >>>>> Switching (MPLS) based Transport Profile (TP). >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>> ________________________________ >>>>>=20 >>>>>=20 >>>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's= Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., L= td's Statement about IPR related to RFC 5919 >>>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co.,= Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>>>> * Next by thread: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capabi= lity-00.txt >>>>> * Index(es): >>>>>=20 >>>>> * Date >>>>> * Thread >>>>>=20 >>>>>=20 >>>>> Note: Messages sent to this list are the opinions of the senders and = do not imply endorsement by the IETF. >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From bertietf@bwijnen.net Mon Aug 15 03:34:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BAF21F876A; Mon, 15 Aug 2011 03:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTMO524++hTm; Mon, 15 Aug 2011 03:34:17 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id EFF8A21F863E; Mon, 15 Aug 2011 03:34:16 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QsuVW-0001dl-0q; Mon, 15 Aug 2011 12:35:00 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest94.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QsuVV-0001jU-MW; Mon, 15 Aug 2011 12:34:57 +0200 Message-ID: <4E48F651.6050801@bwijnen.net> Date: Mon, 15 Aug 2011 12:34:57 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: nitinb@juniper.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4395d70b0e409cb6549208318c3b73b32 Cc: mpls@ietf.org, ops-dir@ietf.org Subject: Re: [mpls] Request for Operations Directorate Review of draft-ietf-mpls-tp-on-demand-cv-06 by 2011-08-25 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 10:34:18 -0000 I did a review of this document for the OPS Directorate. I am not fluent enough in the MPLS-TP space to determine if this document is ready for publication. I would have to dive into a lot of details in many other documents to determine that. But my main task was/is to review for operational and management aspects in this document. There are Management and Operational Considerations, but section 3.6 states: 3.6. Management Considerations for Operation with Static MPLS-TP Support for static MPLS-TP LSP, or Pseudowire, usage and on-demand CV, MAY require manageable objects to allow, for instance, configuring operating parameters such as: o duration and periodicity of on-demand connectivity tests; o identifiers associated with a statically configured LSP or PW. The specifics of this manageability requirement are out-of-scope in this document and SHOULD be addressed in appropriate management specifications. So I have no idea how.where those are described/documented. Maybe that is OK, I will leave that to the ADs. At least the doc is clear in stating that it considers it out of scope. However, I would expect that at least some guidance could be given as to what " duration and periodicity " values make sense. with some explanation as to why those values would make sense. Bert (note, I am not on the mpls WG mailing list). On 8/12/11 1:04 AM, Tina TSOU wrote: > Hello, > As a member of the Operations Directorate you are being asked to review > the following draft which is in IETF last call for it's operational > impact. > > IETF Last Call: > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ > > > > Please provide comments and review to the Ops-dir mailing list > (ops-dir@ietf.org) before 2011-08-25, and include the authors of the > draft as well. > > A Check-list of possible questions/topics to address in an OPS-DIR > review may be found in Appendix A of RFC 5706. > Only include the questions that apply to your review. > > Would you add the review requests and update the status yourself at our wiki page? > http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates > > > Thank you, > Tina > http://tinatsou.weebly.com > > From tnadeau@lucidvision.com Mon Aug 15 06:39:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91421F8B5F for ; Mon, 15 Aug 2011 06:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2RX28D4CVlG for ; Mon, 15 Aug 2011 06:39:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55321F8B55 for ; Mon, 15 Aug 2011 06:39:12 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4EAC21D7CBDE; Mon, 15 Aug 2011 09:39:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <86C289CC63A2544A932C48E05AC49582093FBB3D@ENFIRHMBX1.datcon.co.uk> Date: Mon, 15 Aug 2011 09:39:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88F3A26E-3481-4F25-80FD-3A71D34AB986@lucidvision.com> References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> <01c501cc583e$462ccea0$6601a8c0@JoanPC> <86C289CC63A2544A932C48E05AC49582093FBB3D@ENFIRHMBX1.datcon.co.uk> To: Spike Curtis X-Mailer: Apple Mail (2.1244.3) Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:39:14 -0000 On Aug 15, 2011, at 4:58 AM, Spike Curtis wrote: > Hi Joan and Tom, >=20 > What I meant by (1) was not to extend the mplsTunnelTable, but define = a new table. That is to say, a tunnel can appear in either the new = MPLS-TP tunnel table or the old mplsTunnelTable, not both. As Joan = suggests, both tables could be straightforwardly presented together at = the user interface level. Why would that approach be better than extending the existing = table? > With option 2 (modified indexing) ruled out, (1) becomes my preference = as well. >=20 > As I mentioned, my main concern is with extra identifiers with only = local significance. There are cases where rows in the table will be = auto-created, for example at LSP egress when the tunnel is signalled. = The difficulty is then to ensure they don't change if the tunnel is = taken down and recreated, or over a graceful restart. Indices to the = mplsTunnelTable are referenced in other MIBs like the pseudowire to MPLS = tunnel binding and the mplsXCExtTable. That is a bit of an implementation detail, and is also why in = general, no one relies on SNMP for provisioning. --Tom >=20 > -Spike >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Thomas Nadeau > Sent: Thursday, August 11, 2011 4:57 PM > To: Joan Cucchiara > Cc: mpls@ietf.org > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 > Cool. Thanks! >=20 > On Aug 11, 2011, at 11:49 AM, Joan Cucchiara wrote: >=20 >>=20 >> Tom, >>=20 >> Thank you for adding additional info about how the mappping tables >> should/could be used. >>=20 >> Of course, what working group wants is fine by me wrt making the >> mapping tables optional or not. >>=20 >> I have considered your preference and think that keeping the >> mapping tables with the agent may be reasonable for larger devices = which >> should have the resources to support them and have an E/NMS to >> take advantage of these tables. >>=20 >> Thanks, >> -Joan >>=20 >>=20 >> ----- Original Message ----- From: "Thomas Nadeau" = >> To: "Joan Cucchiara" >> Cc: >> Sent: Wednesday, August 10, 2011 10:58 AM >> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >>=20 >>=20 >> On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >>=20 >>>=20 >>> ----- Original Message ----- From: "Thomas Nadeau" = >>> To: "Joan Cucchiara" >>> Cc: >>> Sent: Tuesday, August 09, 2011 10:47 AM >>> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>=20 >>>=20 >>>>=20 >>>> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>>>=20 >>>>>=20 >>>>> Spike, >>>>>=20 >>>>> Wanted to comment on your 3 suggestions for indexing. >>>>>=20 >>>>> Suggestion #1 is also my preference. This is the most = straightforward and least complex >>>>> design in my opinion. Additionally, the CLI, Web, NMS, etc = could display both MPLS >>>>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the = complexity of the >>>>> mapping is not in the MIB (or agent). >>>>=20 >>>> That is the idea we were after. We want a new table that shows "TP = tunnels" >>>> as a (proper) subset of those defined globally. That is, the = indexing "extends" those in >>>> the MplsTunnelTable. >>>>=20 >>>>> Suggestion #2 is not allowed because redefining indices is not = allowed in the SMI. >>>>> (We had a few emails about this during the time that the MIB was = being adopted by the WG.) >>>>=20 >>>> Spot on. The only way to take this approach is to deprecate = RFC3811, 12, and 13 as >>>> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>>>=20 >>>>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the = same table. >>>>> While this goal may have some benefits, the design to accomplish = the goal is more complex than #1 >>>>> as you point out. I have asked the authors to ensure that there = are no backwards compatibility issues >>>>> with the design so that the MPLS Tunnel Table is already = populated >>>>> and then MPLS-TP Tunnel indices are created such that they do not = conflict with already >>>>> existing tunnel indices. In a nutshell, the problem I have with = this design is that there are 2 ways of creating indices >>>>> for the same Table, one which is legacy and has been around since = 2004 and now a second way. >>>>=20 >>>> Don't you get both "existing at the same time in the same table" by = using the 'extends' relationship? >>>>=20 >>>>=20 >>>>> There may be a #4 Suggestion which is to implement design #1 but = also have an additional (optional?) table >>>>> which is a superset of Tunnels, this could be indexed by a type = field. >>>>=20 >>>> The MIB provides mapping tables *in addition to* the basic table = that extends the MplsTunnelTable. >>>> This is provided as a convenience for the E/NMS to speed table = traversal/manipulation. >>>>=20 >>>=20 >>> Tom, >>>=20 >>> That wasn't clear (at least to me), could this be clarified in next = rev? >>=20 >> Yes, of course! 8) >>=20 >>> Also, may be more beneficial to make these mapping tables optional = -- not every vendor will need to >>> implement them, since they are for E/NMS. >>=20 >> That is possible, but as you know is up to the working group. It is = my personal preference as a vendor of management applications, >> to avoid optional things where possible, as they are unlikely to ever = get implemented on devices and make things more difficult for >> applications. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> -Joan >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- From: "Eric Gray" = >>>>> To: >>>>> Sent: Tuesday, August 09, 2011 9:05 AM >>>>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>=20 >>>>>=20 >>>>>> Forwarding in plain text... >>>>>>=20 >>>>>> ________________________________ >>>>>>=20 >>>>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>>>> Sent: Monday, August 08, 2011 5:25 AM >>>>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>>>> Cc: mpls@ietf.org >>>>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Venkat & all, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I've read the draft and have a question and then some comments. = I'm happy to be of assistance with any of what follows, and/or with = working on other MIB drafts that we need to fill out the gaps identified = in draft-ietf-mpls-tp-mib-management-overview. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> MPLS-TP Identifiers: >>>>>>=20 >>>>>> I understand that one of the purposes of this draft is to allow = configuration using MPLS-TP identifiers. Presumably, there are at least = three ways this could be accomplished: >>>>>>=20 >>>>>> 1. Define a brand new tunnel table for MPLS-TP, based on the = mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>>>>>=20 >>>>>> 2. Redefine the existing mplsTunnelTable indexing, adding = GlobalID and ICC for ingress and egress nodes, and using 0 as "not used" = values to allow back-compatibility. >>>>>>=20 >>>>>> 3. Create a separate set of tables which maps the old = identifiers to the new MPLS-TP identifiers. >>>>>>=20 >>>>>> This draft takes the third strategy, but it's not immediately = clear to me why this is preferable to the other two. (2) seems the least = complicated because it does away extra mapping and inverse mapping = tables. It's also difficult to guarantee that local identifiers (which = don't have configuration or signalling significance) will not change in = the case of graceful restart or configuration replay. Was option (3) = chosen to avoid back-compatibility issues, or for other reasons? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A comment on tunnels: >>>>>>=20 >>>>>> I'd like to clarify how unidirectional, associated bidirectional = and co-routed bidirectional paths are modelled in the MIB, and how = exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto = MIB fields. My preference is as follows. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * Unidirectional LSPs in MPLS-TP are very similar to = "normal" MPLS, but with different identifiers. Tunnels of this type do = not have any entries in the mplsTunnelExtTable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * In associated bidirectional LSPs, the transport = directions are set up and monitored independently, so each transport = direction should be a separate row in the mplsTunnelTable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * In co-routed bidirectional LSPs, both transport = directions are set up and monitored together. This means we should have = only one row in the mplsTunnelTable to represent a tunnel of this type. = This is not how the draft is currently structured, where the example in = Section 9 creates two rows in the mplsTunnelTable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> About gaps: >>>>>>=20 >>>>>> Lastly, I think the MIB is still missing some configuration that = we'll need in order to satisfy MPLS-TP requirements. These include >>>>>>=20 >>>>>> * Bidirectional tunnels with asymmetric resource = requirements >>>>>>=20 >>>>>> * OAM configuration. Presumably this will be a reference = to yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM = profiles. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Let me know if I can be of further assistance. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Spike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ________________________________ >>>>>>=20 >>>>>> * To: i-d-announce at ietf.org = >>>>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>> * From: internet-drafts at ietf.org = >>>>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>>>> * Cc: mpls at ietf.org >>>>>> * Delivered-to: mpls at ietfa.amsl.com = >>>>>> * List-archive: >>>>>> * List-help: >>>>>> * List-id: Multi-Protocol Label Switching WG >>>>>> * List-post: >>>>>> * List-subscribe: , = >>>>>> * List-unsubscribe: , = >>>>>>=20 >>>>>> ________________________________ >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the = Multiprotocol Label Switching Working Group of the IETF. >>>>>>=20 >>>>>> Title : MPLS-TP Traffic Engineering (TE) Management = Information Base (MIB) >>>>>> Author(s) : Venkatesan Mahalingam >>>>>> Kannan KV Sampath >>>>>> Huawei Technologies >>>>>> Thomas D. Nadeau >>>>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>>>> Pages : 39 >>>>>> Date : 2011-06-17 >>>>>>=20 >>>>>> This memo defines a portion of the Management Information Base = (MIB) >>>>>> for use with network management protocols in the Internet = community. >>>>>> In particular, it describes managed objects of Tunnels, = Identifiers, >>>>>> Label Switch Router and Textual conventions for Multiprotocol = Label >>>>>> Switching (MPLS) based Transport Profile (TP). >>>>>>=20 >>>>>>=20 >>>>>> A URL for this Internet-Draft is: >>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> This Internet-Draft can be retrieved at: >>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>> ________________________________ >>>>>>=20 >>>>>>=20 >>>>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to RFC 5919 = >>>>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>>>> * Next by thread: [mpls] I-D Action: = draft-ietf-mpls-ldp-ip-pw-capability-00.txt = >>>>>> * Index(es): >>>>>>=20 >>>>>> * Date = >>>>>> * Thread = >>>>>>=20 >>>>>>=20 >>>>>> Note: Messages sent to this list are the opinions of the senders = and do not imply endorsement by the IETF. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From rcallon@juniper.net Mon Aug 15 07:49:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C68721F8BEB for ; Mon, 15 Aug 2011 07:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVTGbT1RqjSq for ; Mon, 15 Aug 2011 07:49:18 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9E21F8B3E for ; Mon, 15 Aug 2011 07:49:18 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTkkyG4/pY0g52biMWpPdsCW7nimTvdtw@postini.com; Mon, 15 Aug 2011 07:50:04 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Aug 2011 07:47:13 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 15 Aug 2011 10:47:13 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Mon, 15 Aug 2011 10:47:11 -0400 Thread-Topic: IPR on draft-ietf-mpls-tp-fault Thread-Index: AcxbWjcRmkV++4iCSry9Z7fcS/EMUg== Message-ID: 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_DF7F294AF4153D498141CBEFADB17704C2E20F6158EMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] IPR on draft-ietf-mpls-tp-fault X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:49:19 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6158EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, There is an IPR disclosure on draft-ietf-mpls-tp-fault (see email which was CC'd to the MPLS list on December 15, 2010). We did not call this out expl= icitly in the working group last call, but the disclosure was available for the wo= rking group well before the WG last call. To make sure it is not missed by anyone= we have asked the ADs to call it explicitly in the upcoming IETF last call. If= anyone has an objection to going forward given the IPR disclosure, please bring th= is up during the IETF last call. thanks, Ross (for the wg chairs) --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6158EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
There is an IPR disclosure on draft-ietf-mpls-tp-fault (see email whic= h was
CC’d to the MPLS list on December 15, 2010).  We did not ca= ll this out explicitly
in the working group last call, but the disclosure was available for t= he working
group well before the WG last call. To make sure it is not missed by a= nyone we
have asked the ADs to call it explicitly in the upcoming IETF last cal= l. If anyone
has an objection to going forward given the IPR disclosure, please bri= ng this up
during the IETF last call.
 
thanks, Ross
(for the wg chairs)
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6158EMBX01WFjnprn_-- From rcallon@juniper.net Mon Aug 15 07:51:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B0D21F8C07 for ; Mon, 15 Aug 2011 07:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4SyPlcvYxbb for ; Mon, 15 Aug 2011 07:51:45 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id CA53D21F8BFE for ; Mon, 15 Aug 2011 07:51:39 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTkkyqBq/Plld1TwUUTGef5ttLEESDrP8@postini.com; Mon, 15 Aug 2011 07:52:30 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Aug 2011 07:50:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 15 Aug 2011 10:50:57 -0400 From: Ross Callon To: "adrian@olddog.co.uk" Date: Mon, 15 Aug 2011 10:50:55 -0400 Thread-Topic: Request for Publication of draft-ietf-mpls-tp-fault Thread-Index: AcxbWrxl8kBcwPFSRY6DqSgMzUX18A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "'Stewart Bryant \(stbryant\)'" Subject: [mpls] Request for Publication of draft-ietf-mpls-tp-fault X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:51:46 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The MPLS WG requests that draft-ietf-mpls-tp-fault be published as an RFC o= n the standards track. A PROTO writeup is attached. Thanks, Ross for the MPLS WG chairs --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The MPLS WG requests that draft-ietf-mpls-tp-fault be published as an = RFC on the standards track. A PROTO writeup is attached.
 
Thanks, Ross
for the MPLS WG chairs
 
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_ Content-Type: text/plain; name="Proto writeup for draft-ietf-mls-tp-fault.txt" Content-Description: Proto writeup for draft-ietf-mls-tp-fault.txt Content-Disposition: attachment; filename="Proto writeup for draft-ietf-mls-tp-fault.txt"; size=8108; creation-date="Mon, 15 Aug 2011 10:15:06 GMT"; modification-date="Mon, 15 Aug 2011 10:15:06 GMT" Content-Transfer-Encoding: base64 DQoNClRoZSBNUExTIFdHIHJlcXVlc3RzIHRoYXQ6DQoNCiAgICAgICAgICAgICAgICAgICAgTVBM UyBGYXVsdCBNYW5hZ2VtZW50IE9BTQ0KICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbXBs cy10cC1mYXVsdC0wNg0KDQppcyBwdWJsaXNoZWQgYXMgYW4gUkZDIG9uIHRoZSBzdGFuZGFyZHMg dHJhY2suDQoNCg0KPiAoMS5hKSBXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGZvciB0aGlz IGRvY3VtZW50PyBIYXMgdGhlDQo+ICAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkg cmV2aWV3ZWQgdGhpcyB2ZXJzaW9uIG9mIHRoZQ0KPiAgICAgICBkb2N1bWVudCBhbmQsIGluIHBh cnRpY3VsYXIsIGRvZXMgaGUgb3Igc2hlIGJlbGlldmUgdGhpcw0KPiAgICAgICB2ZXJzaW9uIGlz IHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8NCg0KUm9z cyBDYWxsb24gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkLg0KSGUgaGFzIHJldmlld2VkIHRoZSBk b2N1bWVudCBhbmQgYmVsaWV2ZXMgaXQgaXMgcmVhZHkgdG8gYmUNCmZvcndhcmRlZCB0byB0aGUg SUVTRyBmb3IgcHVibGljYXRpb24uDQoNCj4gKDEuYikgSGFzIHRoZSBkb2N1bWVudCBoYWQgYWRl cXVhdGUgcmV2aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycw0KPiAgICAgICBhbmQgZnJvbSBr ZXkgbm9uLVdHIG1lbWJlcnM/IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUNCj4gICAg ICAgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdz IHRoYXQNCj4gICAgICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8NCg0KVGhlIGRvY3VtZW50IGhhcyBi ZWVuIHRocm91Z2ggdGhlIHJldmlldyBwcm9jZXNzIGZvciBtcGxzLXRwIA0KZG9jdW1lbnRzLCBt ZWFuaW5nIHRoYXQgaW4gYWRkaXRpb24gdG8gdGhlIHJldmlld2VkIGluIHRoZSBtcGxzDQp3b3Jr aW5nIGdyb3VwLCBpdCBoYXMgYWxzbyBiZWVuIHJldmlld2VkIHRoZSBJVFUtVCBTRzE1LiBBbGwg DQpjb21tZW50cyBpbiB0aGUgd29ya2luZyBncm91cCBsYXN0IGhhcyBiZWVuIGFkZHJlc3NlZCBi eSB0aGUgYXV0aG9ycw0KYW5kIGEgb25lIHdlZWsgY2FsbCBoZWxkIHRvIHZlcmlmeSB0aGF0IHRo ZSBjb21tZW50cyBiZWVuIGNvcnJlY3RseSANCnVuZGVyc3Rvb2QgYW5kIGFkZHJlc3NlZC4NCg0K VGhlIHNoZXBoZXJlZCBpcyBjb252aW5jZWQgdGhhdCB0aGlzIGlzIHN1ZmZpY2llbnQgcmV2aWV3 IGZvciB0aGlzIA0KZnJhbWV3b3JrIGRvY3VtZW50Lg0KDQoNCj4gKDEuYykgRG9lcyB0aGUgRG9j dW1lbnQgU2hlcGhlcmQgaGF2ZSBjb25jZXJucyB0aGF0IHRoZSBkb2N1bWVudA0KPiAgICAgICBu ZWVkcyBtb3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBlcnNwZWN0aXZl LA0KPiAgICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9u ZSBmYW1pbGlhciB3aXRoDQo+ICAgICAgIEFBQSwgaW50ZXJuYXRpb25hbGl6YXRpb24gb3IgWE1M Pw0KDQpOby4NCg0KPiAoMS5kKSBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBz cGVjaWZpYyBjb25jZXJucyBvcg0KPiAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRo YXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3INCj4gICAgICAgYW5kL29yIHRoZSBJRVNH IHNob3VsZCBiZSBhd2FyZSBvZj8gRm9yIGV4YW1wbGUsIHBlcmhhcHMgaGUNCj4gICAgICAgb3Ig c2hlIGlzIHVuY29tZm9ydGFibGUgd2l0aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwg b3INCj4gICAgICAgaGFzIGNvbmNlcm5zIHdoZXRoZXIgdGhlcmUgcmVhbGx5IGlzIGEgbmVlZCBm b3IgaXQuIEluIGFueQ0KPiAgICAgICBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhv c2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkDQo+ICAgICAgIHRoYXQgaXQgc3RpbGwgd2lzaGVz IHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50LCBkZXRhaWwgdGhvc2UNCj4gICAgICAgY29uY2VybnMg aGVyZS4gSGFzIGFuIElQUiBkaXNjbG9zdXJlIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudA0KPiAg ICAgICBiZWVuIGZpbGVkPyBJZiBzbywgcGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhl DQo+ICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cgZGlzY3Vzc2lvbiBhbmQg Y29uY2x1c2lvbiBvbg0KPiAgICAgICB0aGlzIGlzc3VlLg0KDQpObyBzdWNoIGNvbmNlcm5zLiBU aGVyZSBpcyBvbmUgSVBSIGNsYWltIGZvciB0aGlzIGRyYWZ0LCB0aGlzIHNob3VsZCANCmJlIHBv aW50ZWQgb3V0IGluIHRoZSBJRVRGIGxhc3QgY2FsbC4NCg0KPiAoMS5lKSBIb3cgc29saWQgaXMg dGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9lcyBpdA0KPiAgICAgICBy ZXByZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0 aA0KPiAgICAgICBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBhIHdob2xl IHVuZGVyc3RhbmQgYW5kDQo+ICAgICAgIGFncmVlIHdpdGggaXQ/DQoNClRoZXJlIGlzIGEgZ29v ZCBjb25zZW5zdXMgYXJvdW5kIHRoaXMgZHJhZnQsIGl0IGhhcyBiZWVuIHRocm91Z2ggd29ya2lu Zw0KZ3JvdXAgbGFzdCBjYWxsLiBUaGUgbGFzdCBjYWxsIHdhcyBicm91Z2h0IHRvIHRoZSBub3Rp Y2Ugb2YgU0cxNSBpbiBJVFUtVA0Kd2hvIHJldmlld2VkIHRoZSBkb2N1bWVudC4gSXQgaGFzIGFs c28gcGFzc2VkIGEgd29ya2luZyBncm91cCBjYWxsIHRvIHZlcmlmeSANCnRoYXQgTEMgY29tbWVu dHMgd2VyZSBjb3JyZWN0bHkgd2l0aCBtaW5vciBjb21tZW50cy4gVGhlIGNvbW1lbnRzIGhhcyBi ZWVuDQpjYXJlZnVsbHkgZGlzY3Vzc2VkIGJldHdlZW4gdGhlIGF1dGhvcnMgYW5kIHBlb3BsZSBt YWtpbmcgdGhlIGNvbW1lbnRzIGFuZA0KaGFzIGJlZW4gcmVzb2x2ZWQuDQoNCg0KPiAoMS5mKSBI YXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0 cmVtZQ0KPiAgICAgICBkaXNjb250ZW50PyBJZiBzbywgcGxlYXNlIHN1bW1hcmlzZSB0aGUgYXJl YXMgb2YgY29uZmxpY3QgaW4NCj4gICAgICAgc2VwYXJhdGUgZW1haWwgbWVzc2FnZXMgdG8gdGhl IFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuIChJdA0KPiAgICAgICBzaG91bGQgYmUgaW4gYSBz ZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcw0KPiAgICAgICBlbnRl cmVkIGludG8gdGhlIElEIFRyYWNrZXIuKQ0KDQpObyB0aHJlYXRzIG9yIGV4dHJlbWUgZGlzY29u dGVudC4NCg0KPiAoMS5nKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgdmVy aWZpZWQgdGhhdCB0aGUNCj4gICAgICAgZG9jdW1lbnQgc2F0aXNmaWVzIGFsbCBJRCBuaXRzPyAo U2VlIHRoZSBJbnRlcm5ldC1EcmFmdHMgQ2hlY2tsaXN0DQo+ICAgICAgIGFuZCBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLykuIEJvaWxlcnBsYXRlIGNoZWNrcyBhcmUNCj4gICAg ICAgbm90IGVub3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9yb3VnaC4gSGFzIHRoZSBk b2N1bWVudA0KPiAgICAgICBtZXQgYWxsIGZvcm1hbCByZXZpZXcgY3JpdGVyaWEgaXQgbmVlZHMg dG8sIHN1Y2ggYXMgdGhlIE1JQg0KPiAgICAgICBEb2N0b3IsIG1lZGlhIHR5cGUgYW5kIFVSSSB0 eXBlIHJldmlld3M/DQoNCmNoZWNrISENCg0KPiAoMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0 IGl0cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZA0KPiAgICAgICBpbmZvcm1hdGl2ZT8g QXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0DQo+ICAgICAg IGFyZSBub3QgcmVhZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5j bGVhcg0KPiAgICAgICBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwg d2hhdCBpcyB0aGUNCj4gICAgICAgc3RyYXRlZ3kgZm9yIHRoZWlyIGNvbXBsZXRpb24/IEFyZSB0 aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNlcw0KPiAgICAgICB0aGF0IGFyZSBkb3dud2FyZCByZWZl cmVuY2VzLCBhcyBkZXNjcmliZWQgaW4gW1JGQzM5NjddPyBJZg0KPiAgICAgICBzbywgbGlzdCB0 aGVzZSBkb3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWENCj4gICAgICAgRGly ZWN0b3IgaW4gdGhlIExhc3QgQ2FsbCBwcm9jZWR1cmUgZm9yIHRoZW0gW1JGQzM5NjddLg0KDQpS ZWZlcmVuY2VzIGFyZSBjb3JyZWN0bHkgc3BsaXQuDQoNCkFsbCBkb2N1bWVudHMgdGhhdCBhcmUg bm9ybWF0aXZlbHkgcmVmZXJlbmNlZCBhcmUgaW4gSUVTRyByZXZpZXcgb3IgDQpwdWJsaXNoZWQg UkZDcy4NCg0KDQo+ICgxLmkpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhh dCB0aGUgZG9jdW1lbnQgSUFOQQ0KPiAgICAgICBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZXhpc3Rz IGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkNCj4gICAgICAgb2YgdGhlIGRvY3VtZW50 PyBJZiB0aGUgZG9jdW1lbnQgc3BlY2lmaWVzIHByb3RvY29sDQo+ICAgICAgIGV4dGVuc2lvbnMs IGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkENCj4gICAgICAg cmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVkPyBJ Zg0KPiAgICAgICB0aGUgZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyByZWdpc3RyeSwgZG9lcyBpdCBk ZWZpbmUgdGhlDQo+ICAgICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lz dHJ5IGFuZCBhbiBhbGxvY2F0aW9uDQo+ICAgICAgIHByb2NlZHVyZSBmb3IgZnV0dXJlIHJlZ2lz dHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhDQo+ICAgICAgIHJlYXNvbmFibGUgbmFtZSBmb3Ig dGhlIG5ldyByZWdpc3RyeT8gU2VlIFtSRkM1MjI2XS4gSWYgdGhlDQo+ICAgICAgIGRvY3VtZW50 IGRlc2NyaWJlcyBhbiBFeHBlcnQgUmV2aWV3IHByb2Nlc3MgaGFzIFNoZXBoZXJkDQo+ICAgICAg IGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhl IElFU0cNCj4gICAgICAgY2FuIGFwcG9pbnQgdGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIHRoZSBJ RVNHIEV2YWx1YXRpb24/DQoNClRoZXJlIGlzIGEgY2xlYXIgYW5kIGNvbmNpc2UgSUFOQSBzZWN0 aW9uIGluIHRoaXMgZG9jdW1lbnQuIFR3byBuZXcNCklBTkEgcmVnaXN0cmllcyBhcmUgZGVmaW5l ZCBhbmQgb25lIG5ldyBBc3NvY2lhdGVkIENoYW5uZWwgVHlwZSBpcw0KcmVxdWVzdGVkIGZyb20g dGhlIFBzZXVkb3dpcmUgQXNzb2NpYXRlZCBDaGFubmVsIFR5cGUgcmVnaXN0cnkuDQoNCg0KPiAo MS5qKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2Yg dGhlDQo+ICAgICAgIGRvY3VtZW50IHRoYXQgYXJlIHdyaXR0ZW4gaW4gYSBmb3JtYWwgbGFuZ3Vh Z2UsIHN1Y2ggYXMgWE1MDQo+ICAgICAgIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25z LCBldGMuLCB2YWxpZGF0ZSBjb3JyZWN0bHkgaW4NCj4gICAgICAgYW4gYXV0b21hdGVkIGNoZWNr ZXI/DQoNCk5vIHN1Y2ggZm9ybWFsIGxhbmd1YWdlLg0KDQo+ICgxLmspIFRoZSBJRVNHIGFwcHJv dmFsIGFubm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50DQo+ICAgICAgIEFubm91bmNlbWVu dCBXcml0ZS1VcC4gUGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3VtZW50DQo+ICAgICAgIEFubm91 bmNlbWVudCBXcml0ZS1VcD8gUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUNCj4g ICAgICAgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUg YXBwcm92YWwNCj4gICAgICAgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2Vj dGlvbnM6DQoNClRlY2huaWNhbCBTdW1tYXJ5DQoNCiAgIEluIHRyYWRpdGlvbmFsIHRyYW5zcG9y dCBuZXR3b3JrcywgY2lyY3VpdHMgc3VjaCBhcyBUMSBsaW5lcyBhcmUNCiAgIHR5cGljYWxseSBw cm92aXNpb25lZCBvbiBtdWx0aXBsZSBzd2l0Y2hlcy4gV2hlbiBhbiBldmVudCB0aGF0DQogICBj YXVzZXMgZGlzcnVwdGlvbiBvY2N1cnMgb24gYW55IGxpbmsgb3Igbm9kZSBhbG9uZyB0aGUgcGF0 aCBvZiANCiAgIHN1Y2ggYSB0cmFuc3BvcnQgY2lyY3VpdCwgT0FNIGluZGljYXRpb25zIGFyZSBn ZW5lcmF0ZWQgd2hpY2ggbWF5DQogICBzdXBwcmVzcyBhbGFybXMgYW5kL29yIGFjdGl2YXRlIGEg YmFja3VwIGNpcmN1aXQuIFRoZSBNUExTIGJhc2VkDQogICBUcmFuc3BvcnQgTmV0d29yayByZXF1 aXJlbWV0bnMgc3RhdGVzIHRoYXQgbWVjaGFuaXNtcyBlcXVpdmFsZW50DQogICB0byB0cmFkaXRp b25hbCB0cmFuc3BvcnQgY2lyY3VpdHMuIFRoZXJlZm9yZSBhIEZhdWx0IE1hbmFnZW1lbnQgDQog ICAoRk0pIGNhcGFiaWxpdHkgaXMgZGVmaW5lZCBmb3IgTVBMUy4gVGhpcyBjYXBhYmlsaXR5IGlz IGJlaW5nIA0KICAgZGVmaW5lZCB0byBtZWV0IHRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBpbiBS RkMgNTY1NCBbMV0sIGFuZCB0aGUNCiAgIE1QTFMtVFAgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRp b24gYW5kIE1haW50ZW5hbmNlIFJlcXVpcmVtZW50cyANCiAgIGluIFJGQyA1ODYwIFsyXS4gVGhl c2UgbWVjaGFuaXNtcyBhcmUgaW50ZW5kZWQgdG8gYmUgYXBwbGljYWJsZQ0KICAgdG8gb3RoZXIg YXNwZWN0cyBvZiBNUExTIGFzIHdlbGwuIEhvd2V2ZXIsIHRoaXMgaXMgYmV5b25kIHRoZSANCiAg IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFR3byBicm9hZCBjbGFzc2VzIG9mIHNlcnZp Y2UgZGlzcnVwdGl2ZSBjb25kaXRpb25zIGFyZSBpZGVudGlmaWVkLg0KDQogICAxLiAgRmF1bHQ6 IHRoZSBzaXR1YXRpb24gaW4gd2hpY2ggdGhlIGRlbnNpdHkgb2YgYW5vbWFsaWVzIGhhcw0KICAg ICAgIHJlYWNoZWQgYSBsZXZlbCB3aGVyZSB0aGUgYWJpbGl0eSB0byBwZXJmb3JtIGEgcmVxdWly ZWQgDQogICAgICAgZnVuY3Rpb24gaGFzIGJlZW4gaW50ZXJydXB0ZWQuDQoNCiAgIDIuICBMb2Nr OiBhbiBhZG1pbmlzdHJhdGl2ZSBzdGF0dXMgaW4gd2hpY2ggaXQgaXMgZXhwZWN0ZWQgdGhhdA0K ICAgICAgIG9ubHkgdGVzdCB0cmFmZmljLCBpZiBhbnksIGFuZCBPQU0gKGRlZGljYXRlZCB0byB0 aGUgTFNQKSBjYW4NCiAgICAgICBiZSBzZW50IG9uIGFuIExTUC4NCg0KICAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgYW4gTVBMUyBPQU0gY2hhbm5lbCBjYWxsZWQgYW4gIk1QTFMtT0FNIA0KICAg RmF1bHQgTWFuYWdlbWVudCAoRk0pIiBjaGFubmVsLiAgQSBzaW5nbGUgbWVzc2FnZSBmb3JtYXQg YW5kIGEgDQogICBzZXQgb2YgcHJvY2VkdXJlcyBhcmUgZGVmaW5lZCB0byBjb21tdW5pY2F0ZSBz ZXJ2aWNlIGRpc3J1cHRpdmUgDQogICBjb25kaXRpb25zIGZyb20gdGhlIGxvY2F0aW9uIHdoZXJl IHRoZXkgb2NjdXIgdG8gdGhlIGVuZHBvaW50cw0KICAgb2YgTFNQcyB3aGljaCBhcmUgYWZmZWN0 ZWQgYnkgdGhvc2UgY29uZGl0aW9ucy4gTXVsdGlwbGUgbWVzc2FnZSANCiAgIHR5cGVzIGFuZCBm bGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBhbmQgcXVhbGlmeSB0aGUgcGFydGljdWxhciANCiAg IGNvbmRpdGlvbi4NCg0KV29ya2luZyBHcm91cCBTdW1tYXJ5DQoNCiAgIFRoaXMgZG9jdW1lbnQg aXMgYSBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQsIGFuZCBwYXJ0IG9mIHRoZSBqb2ludA0K ICAgSUVURiAtIElUVS5UIE1QTFMtVFAgcHJvamVjdC4gSXQgaGFzIGJlZW4gcmV2aWV3ZWQgaW4g Ym90aCBvcmdhbml6YXRpb25zDQogICBhbmQgdGhlcmUgaXMgYSBzb2xpZCBzdXBwb3J0IGZvciB0 aGUgZG9jdW1lbnQuDQoNCkRvY3VtZW50IFF1YWxpdHkNCg0KICAgVGhlIGRvY3VtZW50IGhhcyBi ZWVuIGNhcmVmdWx5IHJldmlld2VkIGluIHRoZSBNUExTIHdvcmtpbmcgZ3JvdXAgYW5kIA0KICAg dGhlIElUVS1ULg0KDQo= --_004_DF7F294AF4153D498141CBEFADB17704C2E20F6175EMBX01WFjnprn_-- From internet-drafts@ietf.org Mon Aug 15 11:20:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E2211E808A; Mon, 15 Aug 2011 11:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x-MLSc0ViHo; Mon, 15 Aug 2011 11:19:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CF711E807F; Mon, 15 Aug 2011 11:19:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815181959.11808.34376.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 11:19:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 18:20:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functi= ons Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-03.txt Pages : 12 Date : 2011-08-15 This document specifies one function and describes a second function which are applicable to MPLS transport networks. The first function enables an operator to lock a transport path while the second enables an operator to set, in loopback, a given node along a transport path. This document also defines the extension to MPLS operation, administration, and maintenance (OAM) to perform the lock function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-03.txt From iesg-secretary@ietf.org Mon Aug 15 11:36:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64B421F8CD3; Mon, 15 Aug 2011 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGkdnDzdDN+k; Mon, 15 Aug 2011 11:36:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42321F8CDC; Mon, 15 Aug 2011 11:36:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815183605.17395.6693.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 11:36:05 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Using Multipoint LDP when the Backbone has no Route to the Root' to Proposed Standard (draft-ietf-mpls-mldp-recurs-fec-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 18:36:05 -0000 The IESG has approved the following document: - 'Using Multipoint LDP when the Backbone has no Route to the Root' (draft-ietf-mpls-mldp-recurs-fec-04.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-recurs-fec/ Technical Summary LDP is one of the core MPLS protocols. It was orginally designed to establish point-to-point and multipoint-to-point LSPs that reflected the topology as understood by the IGP routing protocol. LDP has since been extended for several different uses. When LDP is used as the control protocol for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") it contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and if the intermediate nodes are part of a BGP-free core, this lookup will fail. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. Working Group Summary The document has been well reviewed by the MPLS working group. There were no issues arrising. Document Quality There is one known implementation of this specification, and a number of other vendors have indicated their intention to implement. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD. From internet-drafts@ietf.org Mon Aug 15 12:02:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0E021F8CA2; Mon, 15 Aug 2011 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg99ydkN2bvk; Mon, 15 Aug 2011 12:02:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B7621F8C33; Mon, 15 Aug 2011 12:02:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815190221.25214.81998.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 12:02:21 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-fault-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:02:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Fault Management OAM Author(s) : George Swallow Annamaria Fulignoli Martin Vigoureux Sami Boutros David Ward Filename : draft-ietf-mpls-tp-fault-06.txt Pages : 16 Date : 2011-08-15 This draft specifies OAM messages to indicate service disruptive conditions for MPLS based Transport Network Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-06.txt From loa@pi.nu Mon Aug 15 12:31:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2933711E80EB; Mon, 15 Aug 2011 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi-U2rkXJCVG; Mon, 15 Aug 2011 12:31:04 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 762FD11E80D7; Mon, 15 Aug 2011 12:31:04 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 145302A8001; Mon, 15 Aug 2011 21:31:48 +0200 (CEST) Message-ID: <4E497423.8030001@pi.nu> Date: Mon, 15 Aug 2011 21:31:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , pwe3@ietf.org, CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:31:05 -0000 Working Group, this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt Please send your comments to the mpls working group mailing list. This last call ends on August 26th 2011. Loa for the mpls wg co-charirs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From davari@broadcom.com Mon Aug 15 13:38:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4CF21F8CC1; Mon, 15 Aug 2011 13:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvLQu2U1y2Hs; Mon, 15 Aug 2011 13:38:55 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97221F8CBC; Mon, 15 Aug 2011 13:38:55 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 15 Aug 2011 13:38:52 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 15 Aug 2011 13:32:58 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Mon, 15 Aug 2011 13:32:57 -0700 Thread-Topic: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt Thread-Index: AcxbggpPrt1irOFMTFqur+1feKkMTQABQBlg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7B9D@SJEXCHCCR02.corp.ad.broadcom.com> References: <4E497423.8030001@pi.nu> In-Reply-To: <4E497423.8030001@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62575C563DK11419773-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:38:56 -0000 Hi, I have a general clarification question regarding this draft. It seems that= the exact position of the Transmit, Loopback and receive MEP/MIP in the da= ta-plane processing is not well defined, which could lead to unpredictable = results. For example what is the expected behavior for Transmit, Receive an= d Loopback points: - Transmit Before or after Ingress policing? - Transmit and Loopback before or after Queuing/shaping? - Loopback Before or after forwarding (Label Switching)? - Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)? - Loopback before TTL decrement or after TTL decrement? - Loopback before or after LSP termination at LSP terminating MEP? - Loopback or not loopback ACH messages at terminating MEP? - loopback or not Loopback VCCV messages at terminating MEP? - loopback or not Loopback LSP OAM messages (such as BFD) with IP address = =3D 127/8 at terminating MEP? - loopback or not Loopback LSP-Ping messages not defined in this draft? And many similar questions. I would appreciate the authors response and cla= rification. Thanks Shahram =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, August 15, 2011 12:32 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; pwe3@ie= tf.org; CCAMP Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03= .txt Working Group, this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt Please send your comments to the mpls working group mailing list. This last call ends on August 26th 2011. Loa for the mpls wg co-charirs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Mon Aug 15 14:33:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DD321F8C87; Mon, 15 Aug 2011 14:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwz4KhnquFxS; Mon, 15 Aug 2011 14:33:11 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5FB21F8C83; Mon, 15 Aug 2011 14:33:11 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 15 Aug 2011 14:36:33 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 15 Aug 2011 14:31:18 -0700 From: "Shahram Davari" To: "Shahram Davari" , "Loa Andersson" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Mon, 15 Aug 2011 14:31:17 -0700 Thread-Topic: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt Thread-Index: AcxbggpPrt1irOFMTFqur+1feKkMTQABQBlgAAKoL3A= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7C0A@SJEXCHCCR02.corp.ad.broadcom.com> References: <4E497423.8030001@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62574EEB3KO6181140-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:33:13 -0000 Hi, A few more comments: - How is a MIP put to Loopback mode?=20 - How does the MIP get out of loopback? - How does the Ingress MEP know that the Egress MEP has accepted its reques= t for Lockout? - How does the Ingress MEP know that the MIP is or is not in loopback mode? previous versions of the draft addressed all these issues, but I am wonderi= ng how are these done without special messages and Acks. Thx Shahram -----Original Message----- From: Shahram Davari=20 Sent: Monday, August 15, 2011 1:33 PM To: 'Loa Andersson'; 'mpls@ietf.org'; 'mpls-chairs@tools.ietf.org'; 'MPLS-T= P ad hoc team'; 'pwe3@ietf.org'; 'CCAMP' Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-l= b-03.txt Hi, I have a general clarification question regarding this draft. It seems that= the exact position of the Transmit, Loopback and receive MEP/MIP in the da= ta-plane processing is not well defined, which could lead to unpredictable = results. For example what is the expected behavior for Transmit, Receive an= d Loopback points: - Transmit Before or after Ingress policing? - Transmit and Loopback before or after Queuing/shaping? - Loopback Before or after forwarding (Label Switching)? - Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)? - Loopback before TTL decrement or after TTL decrement? - Loopback before or after LSP termination at LSP terminating MEP? - Loopback or not loopback ACH messages at terminating MEP? - loopback or not Loopback VCCV messages at terminating MEP? - loopback or not Loopback LSP OAM messages (such as BFD) with IP address = =3D 127/8 at terminating MEP? - loopback or not Loopback LSP-Ping messages not defined in this draft? And many similar questions. I would appreciate the authors response and cla= rification. Thanks Shahram =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, August 15, 2011 12:32 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; pwe3@ie= tf.org; CCAMP Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03= .txt Working Group, this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt Please send your comments to the mpls working group mailing list. This last call ends on August 26th 2011. Loa for the mpls wg co-charirs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From zheng.zhi@zte.com.cn Tue Aug 16 00:14:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D7921F8A70 for ; Tue, 16 Aug 2011 00:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZEnDcNh7iNI for ; Tue, 16 Aug 2011 00:14:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7F621F893C for ; Tue, 16 Aug 2011 00:14:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 13132806486374; Tue, 16 Aug 2011 15:02:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 94545.806486374; Tue, 16 Aug 2011 15:05:20 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p7G75IYh067961 for ; Tue, 16 Aug 2011 15:05:18 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p7F8wWaO023355; Mon, 15 Aug 2011 16:58:32 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Message-Id: <201108160705.p7G75IYh067961@mse02.zte.com.cn> To: draft-ietf-mpls-entropy-label@tools.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: zheng.zhi@zte.com.cn Date: Mon, 15 Aug 2011 16:58:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-15 16:58:35, Serialize complete at 2011-08-15 16:58:35 Content-Type: multipart/alternative; boundary="=_alternative 00317CC2482578ED_=" X-MAIL: mse02.zte.com.cn p7G75IYh067961 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: mpls@ietf.org Subject: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 07:14:22 -0000 This is a multipart message in MIME format. --=_alternative 00317CC2482578ED_= Content-Type: text/plain; charset="US-ASCII" Hi authors: About the use of entropy label, consider the hierarchical LSP case below: LSP-2 _________ / \ A--...--B---...---C--...--D \________________________/ LSP-1 In the above figure, an end-to-end LSP LSP-1 is between A and D, and another LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated by the ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. So the label stack of the packets arrives at C, is like +-------------+ +-------------+ | LSP-2 label | | LSP-2 label | | LSP-1 label | | ELI-2 | | ELI-1 | OR | EL-2 | ? | EL-1 | | LSP-1 label | | ELI-2 | | ELI-1 | | EL-2 | | EL-1 | +-------------+ +-------------+ ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; Which one is the correct format? Thanks Zhi -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00317CC2482578ED_= Content-Type: text/html; charset="US-ASCII"
Hi authors:

About the use of entropy label, consider the hierarchical LSP case below:

           LSP-2
         _________
         /         \
A--...--B---...---C--...--D
\________________________/
           LSP-1


In the above figure, an end-to-end LSP LSP-1 is between A and D, and another LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated by the ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively.

So the label stack of the packets arrives at C, is like
+-------------+       +-------------+
| LSP-2 label |       | LSP-2 label |
| LSP-1 label |       |    ELI-2    |
|    ELI-1    |   OR  |    EL-2     |    ?
|    EL-1     |       | LSP-1 label |  
|    ELI-2    |       |    ELI-1    |
|    EL-2     |       |    EL-1     |
+-------------+       +-------------+

ELI-1: ELI for LSP-1; EL-1: EL for LSP-1;
ELI-2: ELI for LSP-2; EL-2: EL for LSP-2;

Which one is the correct format?

Thanks
Zhi
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00317CC2482578ED_=-- From Spike.Curtis@metaswitch.com Tue Aug 16 02:03:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C921F8B61 for ; Tue, 16 Aug 2011 02:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjDYhlNY6I6W for ; Tue, 16 Aug 2011 02:03:46 -0700 (PDT) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 07FD921F8B5B for ; Tue, 16 Aug 2011 02:03:45 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.4.12) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 16 Aug 2011 10:06:52 +0100 Received: from ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.01.0289.001; Tue, 16 Aug 2011 10:04:32 +0100 From: Spike Curtis To: Thomas Nadeau Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Thread-Index: AQHMWD5FUUNhW5Pdwkeke+DOaKDjNJUXvUsAgAXknXCAAD58gIABVfGg Date: Tue, 16 Aug 2011 09:04:32 +0000 Message-ID: <86C289CC63A2544A932C48E05AC49582093FC065@ENFIRHMBX1.datcon.co.uk> References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> <01c501cc583e$462ccea0$6601a8c0@JoanPC> <86C289CC63A2544A932C48E05AC49582093FBB3D@ENFIRHMBX1.datcon.co.uk> <88F3A26E-3481-4F25-80FD-3A71D34AB986@lucidvision.com> In-Reply-To: <88F3A26E-3481-4F25-80FD-3A71D34AB986@lucidvision.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 09:03:47 -0000 Hi Tom, I hear what you're saying. Is it a requirement that the MIB can be used fo= r provisioning? If not, then why don't we make the whole thing read-only? -Spike -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Monday, August 15, 2011 2:40 PM To: Spike Curtis Cc: Joan Cucchiara; mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt On Aug 15, 2011, at 4:58 AM, Spike Curtis wrote: > Hi Joan and Tom, >=20 > What I meant by (1) was not to extend the mplsTunnelTable, but define a n= ew table. That is to say, a tunnel can appear in either the new MPLS-TP tu= nnel table or the old mplsTunnelTable, not both. As Joan suggests, both ta= bles could be straightforwardly presented together at the user interface le= vel. Why would that approach be better than extending the existing table? > With option 2 (modified indexing) ruled out, (1) becomes my preference as= well. >=20 > As I mentioned, my main concern is with extra identifiers with only local= significance. There are cases where rows in the table will be auto-create= d, for example at LSP egress when the tunnel is signalled. The difficulty = is then to ensure they don't change if the tunnel is taken down and recreat= ed, or over a graceful restart. Indices to the mplsTunnelTable are referen= ced in other MIBs like the pseudowire to MPLS tunnel binding and the mplsXC= ExtTable. That is a bit of an implementation detail, and is also why in general, no = one relies on SNMP for provisioning. --Tom >=20 > -Spike >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of T= homas Nadeau > Sent: Thursday, August 11, 2011 4:57 PM > To: Joan Cucchiara > Cc: mpls@ietf.org > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 > Cool. Thanks! >=20 > On Aug 11, 2011, at 11:49 AM, Joan Cucchiara wrote: >=20 >>=20 >> Tom, >>=20 >> Thank you for adding additional info about how the mappping tables >> should/could be used. >>=20 >> Of course, what working group wants is fine by me wrt making the >> mapping tables optional or not. >>=20 >> I have considered your preference and think that keeping the >> mapping tables with the agent may be reasonable for larger devices which >> should have the resources to support them and have an E/NMS to >> take advantage of these tables. >>=20 >> Thanks, >> -Joan >>=20 >>=20 >> ----- Original Message ----- From: "Thomas Nadeau" >> To: "Joan Cucchiara" >> Cc: >> Sent: Wednesday, August 10, 2011 10:58 AM >> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >>=20 >>=20 >> On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >>=20 >>>=20 >>> ----- Original Message ----- From: "Thomas Nadeau" >>> To: "Joan Cucchiara" >>> Cc: >>> Sent: Tuesday, August 09, 2011 10:47 AM >>> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>=20 >>>=20 >>>>=20 >>>> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>>>=20 >>>>>=20 >>>>> Spike, >>>>>=20 >>>>> Wanted to comment on your 3 suggestions for indexing. >>>>>=20 >>>>> Suggestion #1 is also my preference. This is the most straightforwa= rd and least complex >>>>> design in my opinion. Additionally, the CLI, Web, NMS, etc could d= isplay both MPLS >>>>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the com= plexity of the >>>>> mapping is not in the MIB (or agent). >>>>=20 >>>> That is the idea we were after. We want a new table that shows "TP tun= nels" >>>> as a (proper) subset of those defined globally. That is, the indexing = "extends" those in >>>> the MplsTunnelTable. >>>>=20 >>>>> Suggestion #2 is not allowed because redefining indices is not allowe= d in the SMI. >>>>> (We had a few emails about this during the time that the MIB was bein= g adopted by the WG.) >>>>=20 >>>> Spot on. The only way to take this approach is to deprecate RFC3811, 1= 2, and 13 as >>>> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>>>=20 >>>>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same = table. >>>>> While this goal may have some benefits, the design to accomplish the = goal is more complex than #1 >>>>> as you point out. I have asked the authors to ensure that there are = no backwards compatibility issues >>>>> with the design so that the MPLS Tunnel Table is already populated >>>>> and then MPLS-TP Tunnel indices are created such that they do not con= flict with already >>>>> existing tunnel indices. In a nutshell, the problem I have with th= is design is that there are 2 ways of creating indices >>>>> for the same Table, one which is legacy and has been around since 200= 4 and now a second way. >>>>=20 >>>> Don't you get both "existing at the same time in the same table" by us= ing the 'extends' relationship? >>>>=20 >>>>=20 >>>>> There may be a #4 Suggestion which is to implement design #1 but also= have an additional (optional?) table >>>>> which is a superset of Tunnels, this could be indexed by a type field= . >>>>=20 >>>> The MIB provides mapping tables *in addition to* the basic table that = extends the MplsTunnelTable. >>>> This is provided as a convenience for the E/NMS to speed table travers= al/manipulation. >>>>=20 >>>=20 >>> Tom, >>>=20 >>> That wasn't clear (at least to me), could this be clarified in next rev= ? >>=20 >> Yes, of course! 8) >>=20 >>> Also, may be more beneficial to make these mapping tables optional -- n= ot every vendor will need to >>> implement them, since they are for E/NMS. >>=20 >> That is possible, but as you know is up to the working group. It is my p= ersonal preference as a vendor of management applications, >> to avoid optional things where possible, as they are unlikely to ever ge= t implemented on devices and make things more difficult for >> applications. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> -Joan >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- From: "Eric Gray" >>>>> To: >>>>> Sent: Tuesday, August 09, 2011 9:05 AM >>>>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>=20 >>>>>=20 >>>>>> Forwarding in plain text... >>>>>>=20 >>>>>> ________________________________ >>>>>>=20 >>>>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>>>> Sent: Monday, August 08, 2011 5:25 AM >>>>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>>>> Cc: mpls@ietf.org >>>>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Venkat & all, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I've read the draft and have a question and then some comments. I'm= happy to be of assistance with any of what follows, and/or with working on= other MIB drafts that we need to fill out the gaps identified in draft-iet= f-mpls-tp-mib-management-overview. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> MPLS-TP Identifiers: >>>>>>=20 >>>>>> I understand that one of the purposes of this draft is to allow conf= iguration using MPLS-TP identifiers. Presumably, there are at least three = ways this could be accomplished: >>>>>>=20 >>>>>> 1. Define a brand new tunnel table for MPLS-TP, based on the mpl= sTunnelTable, but with the MPLS-TP identifiers as indices. >>>>>>=20 >>>>>> 2. Redefine the existing mplsTunnelTable indexing, adding Global= ID and ICC for ingress and egress nodes, and using 0 as "not used" values t= o allow back-compatibility. >>>>>>=20 >>>>>> 3. Create a separate set of tables which maps the old identifier= s to the new MPLS-TP identifiers. >>>>>>=20 >>>>>> This draft takes the third strategy, but it's not immediately clear = to me why this is preferable to the other two. (2) seems the least complica= ted because it does away extra mapping and inverse mapping tables. It's al= so difficult to guarantee that local identifiers (which don't have configur= ation or signalling significance) will not change in the case of graceful r= estart or configuration replay. Was option (3) chosen to avoid back-compat= ibility issues, or for other reasons? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A comment on tunnels: >>>>>>=20 >>>>>> I'd like to clarify how unidirectional, associated bidirectional and= co-routed bidirectional paths are modelled in the MIB, and how exactly the= MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. My= preference is as follows. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * Unidirectional LSPs in MPLS-TP are very similar to "normal= " MPLS, but with different identifiers. Tunnels of this type do not have a= ny entries in the mplsTunnelExtTable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * In associated bidirectional LSPs, the transport directions= are set up and monitored independently, so each transport direction should= be a separate row in the mplsTunnelTable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * In co-routed bidirectional LSPs, both transport directions= are set up and monitored together. This means we should have only one row= in the mplsTunnelTable to represent a tunnel of this type. This is not ho= w the draft is currently structured, where the example in Section 9 creates= two rows in the mplsTunnelTable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> About gaps: >>>>>>=20 >>>>>> Lastly, I think the MIB is still missing some configuration that we'= ll need in order to satisfy MPLS-TP requirements. These include >>>>>>=20 >>>>>> * Bidirectional tunnels with asymmetric resource requirement= s >>>>>>=20 >>>>>> * OAM configuration. Presumably this will be a reference to= yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM prof= iles. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Let me know if I can be of further assistance. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Spike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ________________________________ >>>>>>=20 >>>>>> * To: i-d-announce at ietf.org >>>>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>> * From: internet-drafts at ietf.org >>>>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>>>> * Cc: mpls at ietf.org >>>>>> * Delivered-to: mpls at ietfa.amsl.com >>>>>> * List-archive: >>>>>> * List-help: >>>>>> * List-id: Multi-Protocol Label Switching WG >>>>>> * List-post: >>>>>> * List-subscribe: , >>>>>> * List-unsubscribe: , >>>>>>=20 >>>>>> ________________________________ >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. This draft is a work item of the Multiprotocol Label Switching = Working Group of the IETF. >>>>>>=20 >>>>>> Title : MPLS-TP Traffic Engineering (TE) Management Inf= ormation Base (MIB) >>>>>> Author(s) : Venkatesan Mahalingam >>>>>> Kannan KV Sampath >>>>>> Huawei Technologies >>>>>> Thomas D. Nadeau >>>>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>>>> Pages : 39 >>>>>> Date : 2011-06-17 >>>>>>=20 >>>>>> This memo defines a portion of the Management Information Base (MIB) >>>>>> for use with network management protocols in the Internet community. >>>>>> In particular, it describes managed objects of Tunnels, Identifiers, >>>>>> Label Switch Router and Textual conventions for Multiprotocol Label >>>>>> Switching (MPLS) based Transport Profile (TP). >>>>>>=20 >>>>>>=20 >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> This Internet-Draft can be retrieved at: >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>> ________________________________ >>>>>>=20 >>>>>>=20 >>>>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd'= s Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>>>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to RFC 5919 >>>>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies Co.= , Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 >>>>>> * Next by thread: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capab= ility-00.txt >>>>>> * Index(es): >>>>>>=20 >>>>>> * Date >>>>>> * Thread >>>>>>=20 >>>>>>=20 >>>>>> Note: Messages sent to this list are the opinions of the senders and= do not imply endorsement by the IETF. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From tnadeau@lucidvision.com Tue Aug 16 04:30:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E021F8ABB for ; Tue, 16 Aug 2011 04:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X6VeUng2PEr for ; Tue, 16 Aug 2011 04:30:20 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9AB21F8A95 for ; Tue, 16 Aug 2011 04:30:20 -0700 (PDT) Received: from [192.168.1.103] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BC4B71D7FDB2; Tue, 16 Aug 2011 07:31:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <86C289CC63A2544A932C48E05AC49582093FC065@ENFIRHMBX1.datcon.co.uk> Date: Tue, 16 Aug 2011 07:31:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> <01c501cc583e$462ccea0$6601a8c0@JoanPC> <86C289CC63A2544A932C48E05AC49582093FBB3D@ENFIRHMBX1.datcon.co.uk> <88F3A26E-3481-4F25-80FD-3A71D34AB986@lucidvision.com> <86C289CC63A2544A932C48E05AC49582093FC065@ENFIRHMBX1.datcon.co.uk> To: Spike Curtis X-Mailer: Apple Mail (2.1244.3) Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 11:30:22 -0000 On Aug 16, 2011, at 5:04 AM, Spike Curtis wrote: > Hi Tom, >=20 > I hear what you're saying. Is it a requirement that the MIB can be = used for provisioning? If not, then why don't we make the whole thing = read-only? The read-write capability is up to the WG, but my preference is = to avoid provisioning via SNMP altogether as its a pretty rare use case. --Tom >=20 > -Spike >=20 > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Monday, August 15, 2011 2:40 PM > To: Spike Curtis > Cc: Joan Cucchiara; mpls@ietf.org > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 >=20 > On Aug 15, 2011, at 4:58 AM, Spike Curtis wrote: >=20 >> Hi Joan and Tom, >>=20 >> What I meant by (1) was not to extend the mplsTunnelTable, but define = a new table. That is to say, a tunnel can appear in either the new = MPLS-TP tunnel table or the old mplsTunnelTable, not both. As Joan = suggests, both tables could be straightforwardly presented together at = the user interface level. >=20 > Why would that approach be better than extending the existing = table? >=20 >> With option 2 (modified indexing) ruled out, (1) becomes my = preference as well. >>=20 >> As I mentioned, my main concern is with extra identifiers with only = local significance. There are cases where rows in the table will be = auto-created, for example at LSP egress when the tunnel is signalled. = The difficulty is then to ensure they don't change if the tunnel is = taken down and recreated, or over a graceful restart. Indices to the = mplsTunnelTable are referenced in other MIBs like the pseudowire to MPLS = tunnel binding and the mplsXCExtTable. >=20 > That is a bit of an implementation detail, and is also why in = general, no one relies on SNMP for provisioning. >=20 > --Tom >=20 >=20 >>=20 >> -Spike >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Thomas Nadeau >> Sent: Thursday, August 11, 2011 4:57 PM >> To: Joan Cucchiara >> Cc: mpls@ietf.org >> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >> Cool. Thanks! >>=20 >> On Aug 11, 2011, at 11:49 AM, Joan Cucchiara wrote: >>=20 >>>=20 >>> Tom, >>>=20 >>> Thank you for adding additional info about how the mappping tables >>> should/could be used. >>>=20 >>> Of course, what working group wants is fine by me wrt making the >>> mapping tables optional or not. >>>=20 >>> I have considered your preference and think that keeping the >>> mapping tables with the agent may be reasonable for larger devices = which >>> should have the resources to support them and have an E/NMS to >>> take advantage of these tables. >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>> ----- Original Message ----- From: "Thomas Nadeau" = >>> To: "Joan Cucchiara" >>> Cc: >>> Sent: Wednesday, August 10, 2011 10:58 AM >>> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>=20 >>>=20 >>>=20 >>> On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >>>=20 >>>>=20 >>>> ----- Original Message ----- From: "Thomas Nadeau" = >>>> To: "Joan Cucchiara" >>>> Cc: >>>> Sent: Tuesday, August 09, 2011 10:47 AM >>>> Subject: Re: [mpls] FW: I-D Action: = draft-ietf-mpls-tp-te-mib-00.txt >>>>=20 >>>>=20 >>>>>=20 >>>>> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>>>>=20 >>>>>>=20 >>>>>> Spike, >>>>>>=20 >>>>>> Wanted to comment on your 3 suggestions for indexing. >>>>>>=20 >>>>>> Suggestion #1 is also my preference. This is the most = straightforward and least complex >>>>>> design in my opinion. Additionally, the CLI, Web, NMS, etc = could display both MPLS >>>>>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the = complexity of the >>>>>> mapping is not in the MIB (or agent). >>>>>=20 >>>>> That is the idea we were after. We want a new table that shows "TP = tunnels" >>>>> as a (proper) subset of those defined globally. That is, the = indexing "extends" those in >>>>> the MplsTunnelTable. >>>>>=20 >>>>>> Suggestion #2 is not allowed because redefining indices is not = allowed in the SMI. >>>>>> (We had a few emails about this during the time that the MIB was = being adopted by the WG.) >>>>>=20 >>>>> Spot on. The only way to take this approach is to deprecate = RFC3811, 12, and 13 as >>>>> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>>>>=20 >>>>>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the = same table. >>>>>> While this goal may have some benefits, the design to accomplish = the goal is more complex than #1 >>>>>> as you point out. I have asked the authors to ensure that there = are no backwards compatibility issues >>>>>> with the design so that the MPLS Tunnel Table is already = populated >>>>>> and then MPLS-TP Tunnel indices are created such that they do not = conflict with already >>>>>> existing tunnel indices. In a nutshell, the problem I have = with this design is that there are 2 ways of creating indices >>>>>> for the same Table, one which is legacy and has been around since = 2004 and now a second way. >>>>>=20 >>>>> Don't you get both "existing at the same time in the same table" = by using the 'extends' relationship? >>>>>=20 >>>>>=20 >>>>>> There may be a #4 Suggestion which is to implement design #1 but = also have an additional (optional?) table >>>>>> which is a superset of Tunnels, this could be indexed by a type = field. >>>>>=20 >>>>> The MIB provides mapping tables *in addition to* the basic table = that extends the MplsTunnelTable. >>>>> This is provided as a convenience for the E/NMS to speed table = traversal/manipulation. >>>>>=20 >>>>=20 >>>> Tom, >>>>=20 >>>> That wasn't clear (at least to me), could this be clarified in next = rev? >>>=20 >>> Yes, of course! 8) >>>=20 >>>> Also, may be more beneficial to make these mapping tables optional = -- not every vendor will need to >>>> implement them, since they are for E/NMS. >>>=20 >>> That is possible, but as you know is up to the working group. It is = my personal preference as a vendor of management applications, >>> to avoid optional things where possible, as they are unlikely to = ever get implemented on devices and make things more difficult for >>> applications. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> -Joan >>>>>>=20 >>>>>>=20 >>>>>> ----- Original Message ----- From: "Eric Gray" = >>>>>> To: >>>>>> Sent: Tuesday, August 09, 2011 9:05 AM >>>>>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>=20 >>>>>>=20 >>>>>>> Forwarding in plain text... >>>>>>>=20 >>>>>>> ________________________________ >>>>>>>=20 >>>>>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>>>>> Sent: Monday, August 08, 2011 5:25 AM >>>>>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Venkat & all, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I've read the draft and have a question and then some comments. = I'm happy to be of assistance with any of what follows, and/or with = working on other MIB drafts that we need to fill out the gaps identified = in draft-ietf-mpls-tp-mib-management-overview. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> MPLS-TP Identifiers: >>>>>>>=20 >>>>>>> I understand that one of the purposes of this draft is to allow = configuration using MPLS-TP identifiers. Presumably, there are at least = three ways this could be accomplished: >>>>>>>=20 >>>>>>> 1. Define a brand new tunnel table for MPLS-TP, based on the = mplsTunnelTable, but with the MPLS-TP identifiers as indices. >>>>>>>=20 >>>>>>> 2. Redefine the existing mplsTunnelTable indexing, adding = GlobalID and ICC for ingress and egress nodes, and using 0 as "not used" = values to allow back-compatibility. >>>>>>>=20 >>>>>>> 3. Create a separate set of tables which maps the old = identifiers to the new MPLS-TP identifiers. >>>>>>>=20 >>>>>>> This draft takes the third strategy, but it's not immediately = clear to me why this is preferable to the other two. (2) seems the least = complicated because it does away extra mapping and inverse mapping = tables. It's also difficult to guarantee that local identifiers (which = don't have configuration or signalling significance) will not change in = the case of graceful restart or configuration replay. Was option (3) = chosen to avoid back-compatibility issues, or for other reasons? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A comment on tunnels: >>>>>>>=20 >>>>>>> I'd like to clarify how unidirectional, associated bidirectional = and co-routed bidirectional paths are modelled in the MIB, and how = exactly the MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto = MIB fields. My preference is as follows. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> * Unidirectional LSPs in MPLS-TP are very similar to = "normal" MPLS, but with different identifiers. Tunnels of this type do = not have any entries in the mplsTunnelExtTable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> * In associated bidirectional LSPs, the transport = directions are set up and monitored independently, so each transport = direction should be a separate row in the mplsTunnelTable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> * In co-routed bidirectional LSPs, both transport = directions are set up and monitored together. This means we should have = only one row in the mplsTunnelTable to represent a tunnel of this type. = This is not how the draft is currently structured, where the example in = Section 9 creates two rows in the mplsTunnelTable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> About gaps: >>>>>>>=20 >>>>>>> Lastly, I think the MIB is still missing some configuration that = we'll need in order to satisfy MPLS-TP requirements. These include >>>>>>>=20 >>>>>>> * Bidirectional tunnels with asymmetric resource = requirements >>>>>>>=20 >>>>>>> * OAM configuration. Presumably this will be a = reference to yet-to-be-defined OAM MIBs so that tunnels can be easily = assigned OAM profiles. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Let me know if I can be of further assistance. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Spike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ________________________________ >>>>>>>=20 >>>>>>> * To: i-d-announce at ietf.org = >>>>>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>> * From: internet-drafts at ietf.org = >>>>>>> * Date: Fri, 17 Jun 2011 07:24:45 -0700 >>>>>>> * Cc: mpls at ietf.org >>>>>>> * Delivered-to: mpls at ietfa.amsl.com = >>>>>>> * List-archive: >>>>>>> * List-help: >>>>>>> * List-id: Multi-Protocol Label Switching WG >>>>>>> * List-post: >>>>>>> * List-subscribe: , = >>>>>>> * List-unsubscribe: , = >>>>>>>=20 >>>>>>> ________________________________ >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the = Multiprotocol Label Switching Working Group of the IETF. >>>>>>>=20 >>>>>>> Title : MPLS-TP Traffic Engineering (TE) Management = Information Base (MIB) >>>>>>> Author(s) : Venkatesan Mahalingam >>>>>>> Kannan KV Sampath >>>>>>> Huawei Technologies >>>>>>> Thomas D. Nadeau >>>>>>> Filename : draft-ietf-mpls-tp-te-mib-00.txt >>>>>>> Pages : 39 >>>>>>> Date : 2011-06-17 >>>>>>>=20 >>>>>>> This memo defines a portion of the Management Information Base = (MIB) >>>>>>> for use with network management protocols in the Internet = community. >>>>>>> In particular, it describes managed objects of Tunnels, = Identifiers, >>>>>>> Label Switch Router and Textual conventions for Multiprotocol = Label >>>>>>> Switching (MPLS) based Transport Profile (TP). >>>>>>>=20 >>>>>>>=20 >>>>>>> A URL for this Internet-Draft is: >>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-00.txt >>>>>>> ________________________________ >>>>>>>=20 >>>>>>>=20 >>>>>>> * Prev by Date: [mpls] IPR Disclosure: Huawei Technologies Co., = Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>>>>> * Next by Date: Re: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to RFC 5919 = >>>>>>> * Previous by thread: [mpls] IPR Disclosure: Huawei Technologies = Co., Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03 = >>>>>>> * Next by thread: [mpls] I-D Action: = draft-ietf-mpls-ldp-ip-pw-capability-00.txt = >>>>>>> * Index(es): >>>>>>>=20 >>>>>>> * Date = >>>>>>> * Thread = >>>>>>>=20 >>>>>>>=20 >>>>>>> Note: Messages sent to this list are the opinions of the senders = and do not imply endorsement by the IETF. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 From jdrake@juniper.net Tue Aug 16 05:44:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A80F21F8AD3 for ; Tue, 16 Aug 2011 05:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFwAd-aWYwPx for ; Tue, 16 Aug 2011 05:44:20 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 139D621F8AC3 for ; Tue, 16 Aug 2011 05:44:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTkpmQLKjRgCljFqZfkCd4AoNYcTWtl5L@postini.com; Tue, 16 Aug 2011 05:45:08 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 16 Aug 2011 05:41:22 -0700 From: John E Drake To: "zheng.zhi@zte.com.cn" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Date: Tue, 16 Aug 2011 05:41:19 -0700 Thread-Topic: [mpls] Entropy label in hierarchical LSP Thread-Index: Acxb5FKt4pfYy9lGRgeHZ3nXL6QYXAALPCNA Message-ID: <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net> References: <201108160705.p7G75IYh067961@mse02.zte.com.cn> In-Reply-To: <201108160705.p7G75IYh067961@mse02.zte.com.cn> 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_5E893DB832F57341992548CDBB333163A0ACB1A719EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 12:44:21 -0000 --_000_5E893DB832F57341992548CDBB333163A0ACB1A719EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The intent of the draft is that the node that creates the label stack is th= e node that places the entropy label in the stack. So, there is only one e= ntropy label present in any given MPLS packet. If this is not clear, pleas= e point me to the text that causes you confusion on this point. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of zhe= ng.zhi@zte.com.cn Sent: Monday, August 15, 2011 1:58 AM To: draft-ietf-mpls-entropy-label@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Entropy label in hierarchical LSP Hi authors: About the use of entropy label, consider the hierarchical LSP case below: LSP-2 _________ / \ A--...--B---...---C--...--D \________________________/ LSP-1 In the above figure, an end-to-end LSP LSP-1 is between A and D, and anothe= r LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated by th= e ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. So the label stack of the packets arrives at C, is like +-------------+ +-------------+ | LSP-2 label | | LSP-2 label | | LSP-1 label | | ELI-2 | | ELI-1 | OR | EL-2 | ? | EL-1 | | LSP-1 label | | ELI-2 | | ELI-1 | | EL-2 | | EL-1 | +-------------+ +-------------+ ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; Which one is the correct format? Thanks Zhi -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_5E893DB832F57341992548CDBB333163A0ACB1A719EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

The intent of the draft is that the node that crea= tes the label stack is the node that places the entropy label in the stack.=   So, there is only one entropy label present in any given MPLS packet= .  If this is not clear, please point me to the text that causes you c= onfusion on this point.

 

Thanks,

 

John

 

Sent from my iPhone

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of zheng.zhi@zte.com.cn
Sent:= Monday, August 15, 2011 1:58 AM
To: draft-ietf-mpls-entropy-= label@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] = Entropy label in hierarchical LSP

 


Hi authors:
About t= he use of entropy label, consider the hierarchical LSP case below: <= br>
&n= bsp;          LSP-2
        =  _________
         /       =   \
A--...--B---...---C--...--D
\________________________/ =
 = ;          LSP-1


In the above figure, an= end-to-end LSP LSP-1 is between A and D, and another LSP LSP-2 goes over L= SP-1 from B to C. Entropy labels are generated by the ingress LSRs, A as in= gress for LSP-1 and B for LSP-2 respectively.

So the label stack of t= he packets arrives at C, is like
+-------------+       +--= -----------+
| LSP-2 label |       | LSP-2 label | =
| LSP= -1 label |       |    ELI-2    | =
| &nb= sp;  ELI-1    |   OR  |    EL-2   &= nbsp; |    ?
|    EL-1     |     =   | LSP-1 label |  
|    ELI-2    |   =     |    ELI-1    |
|    EL-2 &nb= sp;   |       |    EL-1     |
+--= -----------+       +-------------+

ELI-1: ELI for LSP-= 1; EL-1: EL for LSP-1;
ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; <= br>
Wh= ich one is the correct format?

Thanks
Zhi

 
----------------------------------------------=
----------
ZTE Information Security Not=
ice: The information contained in this mail&n=
bsp;is solely property of the sender's organi=
zation. This mail communication is confidential.&n=
bsp;Recipients named above are obligated to m=
aintain secrecy and are not permitted to =
;disclose the contents of this communication =
to others.
This email and any =
;files transmitted with it are confidential a=
nd intended solely for the use of the&nb=
sp;individual or entity to whom they are =
;addressed. If you have received this email&n=
bsp;in error please notify the originator of&=
nbsp;the message. Any views expressed in this=
 message are those of the individual sen=
der.
This message has been scanned=
 for viruses and Spam by ZTE Anti-Spam&n=
bsp;system.
= --_000_5E893DB832F57341992548CDBB333163A0ACB1A719EMBX01HQjnprn_-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 06:25:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE53921F8AE1 for ; Tue, 16 Aug 2011 06:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szbSXavdBKKK for ; Tue, 16 Aug 2011 06:25:33 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 768C821F8ABD for ; Tue, 16 Aug 2011 06:25:26 -0700 (PDT) Received: from [85.158.139.83:37724] by server-7.bemta-5.messagelabs.com id 31/3B-21792-5FF6A4E4; Tue, 16 Aug 2011 13:26:13 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1313501173!14692832!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 1916 invoked from network); 16 Aug 2011 13:26:13 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-182.messagelabs.com with SMTP; 16 Aug 2011 13:26:13 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-ad-4e4a692ed2ba Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 5C.7D.16719.E296A4E4; Tue, 16 Aug 2011 15:57:18 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 16 Aug 2011 16:26:12 +0300 From: Alexander Vainshtein To: "ietf@ietf.org" Date: Tue, 16 Aug 2011 16:26:10 +0300 Thread-Topic: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcGBA21vETQ27uTwSWVgNiuD48+A== Message-ID: 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_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTu7sxukzkxrWteF39MExU91rTnSq5EYViR2YOKKGycve2O7cxs O2O4SSUhPbSXGIUWPmIrM0OSkkiJkgwyo7IfitUWKmEWUZv2gMpmdtKEaH59c77HPfdyDoGZ 35qsBC8qyCeyHsYUgZf0hwZsc/iV6Qn13bj9zbUK3N514bLRfjx0HV+CpQUC3w0ZYEs+SGZF UVJYBdFOJHMOJsPH72Y5P0PzTgeTyNBeD8shAYmKg2G9XiQ6mZQI+p8vWZXxIo1ETnLyosvB rFi/xma3L0iyJTIp06YkzlscscHNyzSyCSzvoQUky6wL0Wpl+3XMHeofNHqrN+UWPK3C8sHt VYVgHAGp+bD8aAHQ8ST4JFhn0rCZagSwrGFjIYhQ8WkAaw63j9UIE+WA9VdehkUWagq8U9pp 1EQYdQ+DfQWBMIFTU2FL7f2wIUo1DDwM/DEshZ3nBw06jocN1TfwQkAQJLUWdh/O08pAbeJr a21YglExsKu3wqA3R8FA02NMx9Hwbc8vo66Phi8O1QFdL8HCb8HwsSQ1ET4o7cV1fSy8W92J nwSWslGxZaMsZaMsen02rGwMmXQ8C16seocN47Y7PYbR9UowtgbE8h6vkiW4EubapBwlHnG8 gjwonpOEeqDPSd9N8LxtRjOgCMBEkhncinSzkd0t+4VmEEsYmGhyjLQy3TwhS3L63azszvTl eJDcDCCBMRYS7FA50sn69yCfNEylqg9djFnHc5I6kaKSOS8h4f8/TAxZxL1fbaZc6hTuRMiL fMM5cQTBQHKfdvxEH3Kh3B28R/lLG4hxWhuRahuSpiFlLyvIvEvnW8Fkawx5RiMojXDniCNe bUP2Dw0N9YMY9dJRpF9TRar7M+LuV4MNanDXrTQtWN2QEcqaD+xkDfORsBiKv7TkDtI95xad MOdmJ+U3rtv64V5T9omFl26N7+ibfaBDmPsz6ZRl0Lnn7Hxj8sC2a7+KSxyPtmc9tgaXTF+7 MxgbtUxaahf2lUtxqWuWfw5iVTVZV3+0V1ob9r4+X8E9O7h5V14R9fKY8im0LK/1Qt6ru0m7 +OxFRyYxuOxmE2diPpn9DbtAghf8AwAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:25:34 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal= -in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-= of-stack position. As stated in the Introduction, this draft removes the restriction imposed by= RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The cor= responding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST al= ways be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requi= rement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reser= ves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (= LSE) at the bottom of stack in order to facilitate the load balancing of the= flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseud= owires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowir= es is the case when an edge-to-edge service emulation crosses multiple IP/MP= LS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe= 3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) wo= uld potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-= TP domain, e.g., for relying a PW status message that it has received over a= Targeted LDP session from the IP/MPLS domain to a static PW status message= to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE= 3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG d= ocument, with arguments for both the flow label and GAL taking the bottom-o= f-the-stack position. But, to the best of my understanding, consensus on thi= s issue has not been reached. Hopefully this comment will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,=

 

I would l= ike to raise the following issue with regard to draft-ie= tf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw w= ith regard to bottom-of-stack position.

<= o:p> 

As stated in the Introduction, this= draft removes the restriction imposed by RFC 5586 on usage of Generic Assoc= iated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC= 5586 states:

In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concat= enated Segments of LSPs, and with Sections, and MUST NOT be used with PWs.&n= bsp; It MUST always be at the bottom of the label stack    (i= .e., S bit set to 1).

 <= /o:p>

draft-ietf-pwe3-gal-in-pw proposed to replace= the original text in RFC 5586 with the following

 

In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Con= catenated Segments of LSPs, and with Sections, and MAY be used with PWs. It= MUST always be at the bottom of the label stack (i.e., S bit set to 1).

 <= /p>

I.e.,  while remov= ing this restriction of 5586, it does not modify its requirement for the GAL= being always at the bottom of the label stack.

 

At the same draft-ietf-pwe3-fat-pw (currentl= y also in the IESG review) reserves the bottom of the PW stack for the PW fl= ow labels, e.g., in Section 1.1:

 

This document describes a method of adding an additional l= abel stack entry (LSE) at the bottom of stack in order to facilitate the loa= d balancing of the flows within a PW over the available ECMPs.  =

 =

One could argue= that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and tha= t MPLS-TP does not use ECMP. IMHO and FWIW,

such an argument, were it presented, would= be highly problematic, because:

 

1.       RFC 5960 (which defines the MPLS-TP data plane) did= not define any differences between the PW data plane in IP/MPLS and MPLS-TP= .

2. &n= bsp;     = One of the most popular scenarios for using multi-segment pseudowires is the= case when an edge-to-edge service emulation crosses multiple IP/MPLS and MP= LS-TP domains. In these scenarios, the flow label of draft-ietf-pwe3-fat-pw= (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pote= ntially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domai= n, e.g., for relying a PW status message that it has received over a Targete= d LDP session from the IP/MPLS domain to a static PW status message to cross= the MPLS-TP domain) for the bottom-of-stack position.

 

The issue I am raising Is not new. It= has been actively discussed on the PWE3 mailing list with regard to adoptio= n of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments  for bot= h the flow label and GAL taking the bottom-of-the-stack position. But, to th= e best of my understanding, consensus on this issue has not been reached.

 

Hopefully this comment will be useful.

 

Regards,=

     Sasha

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_-- From lizho.jin@gmail.com Tue Aug 16 08:03:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B721F8BA9 for ; Tue, 16 Aug 2011 08:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLbEPGdWG7bn for ; Tue, 16 Aug 2011 08:03:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81A0F21F8B98 for ; Tue, 16 Aug 2011 08:03:48 -0700 (PDT) Received: by ywm21 with SMTP id 21so4139440ywm.31 for ; Tue, 16 Aug 2011 08:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=I82b5G9MRm/iMtJs8l/k+eYppxhV8bIgWsqfIttnSRo=; b=Nf9x3BeLdDLRdRgMEcjxxN2kwU2WM2oixQWe2A6eiJXC9J1f/uyhnM9otQbVo8ozYz quxAzuWjDmpK3/ItP4sPZtI7vtwVOP4PVgIAj3NA8kUrFgpeSvOoIv9Fkod1kN1F3RSh NKUj3Ey8LRldras3JAC2ndCjojwxvWoIS6OGA= MIME-Version: 1.0 Received: by 10.42.180.200 with SMTP id bv8mr5606849icb.21.1313507076600; Tue, 16 Aug 2011 08:04:36 -0700 (PDT) Received: by 10.42.167.72 with HTTP; Tue, 16 Aug 2011 08:04:36 -0700 (PDT) Date: Tue, 16 Aug 2011 23:04:36 +0800 Message-ID: From: Lizhong Jin To: jdrake@juniper.net Content-Type: multipart/alternative; boundary=90e6ba6e8f9cb5f24b04aaa0b29d Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 15:03:49 -0000 --90e6ba6e8f9cb5f24b04aaa0b29d Content-Type: text/plain; charset=ISO-8859-1 Hi John, With regarding the scenario and figure in Zhi's email, LSP1 will be nested by LSP2, and both LSP1 and LSP2 support entropy label. Then do you mean node B will not add entropy label for the labeled traffic of LSP1, right? I think the draft is not clear for an ingress node to encapsulate a labeled packet. The received labeled packet maybe already contain entropy label. Thanks Lizhong > ------------------------------ > > Date: Tue, 16 Aug 2011 05:41:19 -0700 > From: John E Drake > To: "zheng.zhi@zte.com.cn" , > "draft-ietf-mpls-entropy-label@tools.ietf.org" > > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Entropy label in hierarchical LSP > Message-ID: > <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > The intent of the draft is that the node that creates the label stack is > the node that places the entropy label in the stack. So, there is only one > entropy label present in any given MPLS packet. If this is not clear, > please point me to the text that causes you confusion on this point. > > Thanks, > > John > > Sent from my iPhone > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > zheng.zhi@zte.com.cn > Sent: Monday, August 15, 2011 1:58 AM > To: draft-ietf-mpls-entropy-label@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Entropy label in hierarchical LSP > > > Hi authors: > > About the use of entropy label, consider the hierarchical LSP case below: > > LSP-2 > _________ > / \ > A--...--B---...---C--...--D > \________________________/ > LSP-1 > > > In the above figure, an end-to-end LSP LSP-1 is between A and D, and > another LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated > by the ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. > > So the label stack of the packets arrives at C, is like > +-------------+ +-------------+ > | LSP-2 label | | LSP-2 label | > | LSP-1 label | | ELI-2 | > | ELI-1 | OR | EL-2 | ? > | EL-1 | | LSP-1 label | > | ELI-2 | | ELI-1 | > | EL-2 | | EL-1 | > +-------------+ +-------------+ > > ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; > ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; > > Which one is the correct format? > > Thanks > Zhi > > > --90e6ba6e8f9cb5f24b04aaa0b29d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi John,
With regarding the scenario and figure in Zhi's email, LSP1 will b= e nested by LSP2, and both LSP1 and LSP2 support entropy label. Then do you= mean node B will not add entropy label for the=A0labeled=A0traffic of LSP1= , right? I think the draft is not clear for an ingress=A0node to=A0encapsul= ate a=A0labeled packet. The received labeled packet maybe already contain e= ntropy label.
=A0
Thanks
Lizhong
=A0
=A0
------------------------------
Date: Tue, 16 Aug 2011 05:41:19 -0700
From: John E Drake <jdrake@juniper.net>
To: "zheng.zhi@zte.com.cn&= quot; <zheng.zhi@zte.com.cn&= gt;,
=A0 =A0 =A0 =A0"draft-ietf-mpls-entropy-label@tools.ietf.org" =A0 =A0 =A0 =A0<draft-ietf-mpls-entropy-label@tools.ietf.org>
Cc: "<= a href=3D"mailto:mpls@ietf.org">mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Entropy label in hierarchical LSP
Message-ID:
=A0= =A0 =A0 =A0<5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.= jnpr.net>
Content-Type: text/plain; charset=3D"us-ascii"

Hi,

= The intent of the draft is that the node that creates the label stack is th= e node that places the entropy label in the stack. =A0So, there is only one= entropy label present in any given MPLS packet. =A0If this is not clear, p= lease point me to the text that causes you confusion on this point.

Thanks,

John

Sent from my iPhone

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of zheng.zhi@zte.com.cn
Sent: Monday, August 15, 2011 1:58 AM
To: draft-ietf-mpls-entropy-label@tools.ietf.= org
Cc: mpls@ietf.org
Subjec= t: [mpls] Entropy label in hierarchical LSP


Hi authors:

About the use of entropy label, consider the hie= rarchical LSP case below:

=A0 =A0 =A0 =A0 =A0 LSP-2
=A0 =A0 =A0 = =A0 _________
=A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 \
A--...--B---...---C= --...--D
\________________________/
=A0 =A0 =A0 =A0 =A0 LSP-1


In the above figure, an end-to-end LSP= LSP-1 is between A and D, and another LSP LSP-2 goes over LSP-1 from B to = C. Entropy labels are generated by the ingress LSRs, A as ingress for LSP-1= and B for LSP-2 respectively.

So the label stack of the packets arrives at C, is like
+-----------= --+ =A0 =A0 =A0 +-------------+
| LSP-2 label | =A0 =A0 =A0 | LSP-2 labe= l |
| LSP-1 label | =A0 =A0 =A0 | =A0 =A0ELI-2 =A0 =A0|
| =A0 =A0ELI-= 1 =A0 =A0| =A0 OR =A0| =A0 =A0EL-2 =A0 =A0 | =A0 =A0?
| =A0 =A0EL-1 =A0 =A0 | =A0 =A0 =A0 | LSP-1 label |
| =A0 =A0ELI-2 =A0 = =A0| =A0 =A0 =A0 | =A0 =A0ELI-1 =A0 =A0|
| =A0 =A0EL-2 =A0 =A0 | =A0 =A0= =A0 | =A0 =A0EL-1 =A0 =A0 |
+-------------+ =A0 =A0 =A0 +-------------+=

ELI-1: ELI for LSP-1; EL-1: EL for LSP-1;
ELI-2: ELI for LSP-2; = EL-2: EL for LSP-2;

Which one is the correct format?

Thanks
Zhi


--90e6ba6e8f9cb5f24b04aaa0b29d-- From jdrake@juniper.net Tue Aug 16 08:25:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAFE11E8088 for ; Tue, 16 Aug 2011 08:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zkUGx4ZTDZV for ; Tue, 16 Aug 2011 08:25:14 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A577021F8BF3 for ; Tue, 16 Aug 2011 08:25:13 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTkqMAys7e2YYXncj6mLZFxWKdDSRBzJW@postini.com; Tue, 16 Aug 2011 08:26:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 16 Aug 2011 08:24:36 -0700 From: John E Drake To: Lizhong Jin Date: Tue, 16 Aug 2011 08:24:34 -0700 Thread-Topic: [mpls] Entropy label in hierarchical LSP Thread-Index: AcxcJdHRLz8JkLwSQdmlrWLe5lg0gAAAOJPA Message-ID: <5E893DB832F57341992548CDBB333163A0ACB1A837@EMBX01-HQ.jnpr.net> References: In-Reply-To: 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_5E893DB832F57341992548CDBB333163A0ACB1A837EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 15:25:19 -0000 --_000_5E893DB832F57341992548CDBB333163A0ACB1A837EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong, That's correct, only the ingress LER places an entropy label in the label s= tack. I think part of the confusion arises because the authors, for some unknown = reason (stupidity perhaps), use the term 'LSR' rather than 'LER' throughout= . This is covered by the statement in Section 1.1: "The term ingress (or egress) LSR is used interchangeably with ingress (or= egress) LER." But people may have missed this. Thanks, John Sent from my iPhone From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Tuesday, August 16, 2011 8:05 AM To: John E Drake Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; mpl= s@ietf.org Subject: Re: [mpls] Entropy label in hierarchical LSP Hi John, With regarding the scenario and figure in Zhi's email, LSP1 will be nested = by LSP2, and both LSP1 and LSP2 support entropy label. Then do you mean nod= e B will not add entropy label for the labeled traffic of LSP1, right? I th= ink the draft is not clear for an ingress node to encapsulate a labeled pac= ket. The received labeled packet maybe already contain entropy label. Thanks Lizhong ------------------------------ Date: Tue, 16 Aug 2011 05:41:19 -0700 From: John E Drake > To: "zheng.zhi@zte.com.cn" >, "draft-ietf-mpls-entropy-label@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Entropy label in hierarchical LSP Message-ID: <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=3D"us-ascii" Hi, The intent of the draft is that the node that creates the label stack is th= e node that places the entropy label in the stack. So, there is only one e= ntropy label present in any given MPLS packet. If this is not clear, pleas= e point me to the text that causes you confusion on this point. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of zheng.zhi@zte.com.= cn Sent: Monday, August 15, 2011 1:58 AM To: draft-ietf-mpls-entropy-label@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Entropy label in hierarchical LSP Hi authors: About the use of entropy label, consider the hierarchical LSP case below: LSP-2 _________ / \ A--...--B---...---C--...--D \________________________/ LSP-1 In the above figure, an end-to-end LSP LSP-1 is between A and D, and anothe= r LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated by th= e ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. So the label stack of the packets arrives at C, is like +-------------+ +-------------+ | LSP-2 label | | LSP-2 label | | LSP-1 label | | ELI-2 | | ELI-1 | OR | EL-2 | ? | EL-1 | | LSP-1 label | | ELI-2 | | ELI-1 | | EL-2 | | EL-1 | +-------------+ +-------------+ ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; Which one is the correct format? Thanks Zhi --_000_5E893DB832F57341992548CDBB333163A0ACB1A837EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lizhong,<= o:p>

 

That’s correct, only the ingress LER pl= aces an entropy label in the label stack.

 

I t= hink part of the confusion arises because the authors, for some unknown rea= son (stupidity perhaps), use the term ‘LSR’ rather than ‘= LER’ throughout.  This is covered by the statement in Section 1.= 1:

 

“The term ingress (or egress) LSR is= used interchangeably with ingress  (or egress) LER.”=

 

But people may have missed this.

<= p class=3DMsoNormal> 

Thanks,

 = ;

John

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Sent from my iPhone

=  

From: L= izhong Jin [mailto:lizho.jin@gmail.com]
Sent: Tuesday, August 16= , 2011 8:05 AM
To: John E Drake
Cc: zheng.zhi@zte.com.c= n; draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org
Subjec= t: Re: [mpls] Entropy label in hierarchical LSP

 

Hi John,

With regardi= ng the scenario and figure in Zhi's email, LSP1 will be nested by LSP2, and= both LSP1 and LSP2 support entropy label. Then do you mean node B will not= add entropy label for the labeled traffic of LSP1, right? I thin= k the draft is not clear for an ingress node to encapsulate a&nbs= p;labeled packet. The received labeled packet maybe already contain entropy= label.

 

=

Thanks

Lizhong

 =

 

------------------------------

Date: Tue, 16 = Aug 2011 05:41:19 -0700
From: John E Drake <jdrake@juniper.net>
To: "zheng.zhi@zte.com.cn" <zheng.zhi@zte.com.cn>,
      &nb= sp;"dr= aft-ietf-mpls-entropy-label@tools.ietf.org"
     = ;  <draft-ietf-mpls-entropy-label@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Entropy label in h= ierarchical LSP
Message-ID:
       <5E89= 3DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net>
Conten= t-Type: text/plain; charset=3D"us-ascii"

Hi,

The in= tent of the draft is that the node that creates the label stack is the node= that places the entropy label in the stack.  So, there is only one en= tropy label present in any given MPLS packet.  If this is not clear, p= lease point me to the text that causes you confusion on this point.

= Thanks,

John

Sent from my iPhone

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of zheng.zhi@zte.com.cn
Sent: Monday, = August 15, 2011 1:58 AM
To: draft-ietf-mpls-entropy-label@tools.ietf.org
Cc:= mpls@ietf.org
Subject: [mpls] Entr= opy label in hierarchical LSP


Hi authors:

About the use o= f entropy label, consider the hierarchical LSP case below:

  &n= bsp;       LSP-2
        _________        /         \
A--...--B--= -...---C--...--D
\________________________/
      &nbs= p;   LSP-1


In the above figure, an end-to-end LSP LSP-1 is = between A and D, and another LSP LSP-2 goes over LSP-1 from B to C. Entropy= labels are generated by the ingress LSRs, A as ingress for LSP-1 and B for= LSP-2 respectively.

So the label stack of the packets arrives at C,= is like
+-------------+       +-------------+
| LSP-2= label |       | LSP-2 label |
| LSP-1 label |   &nb= sp;   |    ELI-2    |
|    ELI-1 &nbs= p;  |   OR  |    EL-2     |    = ;?
|    EL-1     |       | LSP-1 labe= l |
|    ELI-2    |       |   &n= bsp;ELI-1    |
|    EL-2     |   &nbs= p;   |    EL-1     |
+-------------+   &nb= sp;   +-------------+

ELI-1: ELI for LSP-1; EL-1: EL for LSP-1;=
ELI-2: ELI for LSP-2; EL-2: EL for LSP-2;

Which one is the corre= ct format?

Thanks
Zhi

= --_000_5E893DB832F57341992548CDBB333163A0ACB1A837EMBX01HQjnprn_-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 10:01:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55321F8B52; Tue, 16 Aug 2011 10:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.954, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRcUwzioRWUm; Tue, 16 Aug 2011 10:01:57 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 4F3AB21F8B47; Tue, 16 Aug 2011 10:01:56 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1313514149!40800009!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 5681 invoked from network); 16 Aug 2011 17:02:29 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-21.messagelabs.com with SMTP; 16 Aug 2011 17:02:29 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-8f-4e4a9becf855 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id CB.CF.16719.CEB9A4E4; Tue, 16 Aug 2011 19:33:48 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 16 Aug 2011 20:02:41 +0300 From: Alexander Vainshtein To: "ietf@ietf.org" Date: Tue, 16 Aug 2011 20:02:20 +0300 Thread-Topic: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcGBA21vETQ27uTwSWVgNiuD48+AAHMfDU Message-ID: References: In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTmzszarDkxu2Vet4hprEBjZbcXG7lhRWRSZlv0IwobZ6+7U7sz 284YWlDaA3tq71IDzSzyEabZgx5U/jCUoCexaAWRRZlEiVH9KLuzUyZE99d3z/ed7xzuPYcm raUjbLQkaygsCwE+JpY60ts/YO+rzMxynO1Jcb1trqJcXWfrTK7S/lYqncyorf1OZIPVRSBN kGVFEzTEeZEquvnssLRJEAt5TvK6eSfPhQKCiIJI1ty8EAoh2cvPjeX+OWlYJskckkXFK8k+ N794xTK7yzVztt3Jz52S5Jw+J3alX1I5ZA8KUoALIlUVfIjDkXWtpL/yeT0R+ril4NX27aYi UObfC8w0ZGfAoztLYgw8Fj582YRxLG1lbwDYcOSJybgcB7DjW19UFcO6YUvDiygewybBO+WR qIhkrxKwpOopqRMUOxneHziHMU2PZufBxvYlhn4+jNR8IQw8DXY/uhX1YdjlsPrlPZOOrRg/ Li6mdGxmPfDH4EBUA3B3Xzsbo7kkmwC7eqoIo2sW1t58QBo4Hr5//dNk6OPh85ImYOgV2HRl 9+9aFthR3kMZ+kR493yEOgjGVgyzrRiWUjEsxYinwsixozEGngrPnf5AGtgOT/5so4bHq8GI epAoBUJabtDnmGZX8rVUJEoaCqBUUQm2AGOA3l0D3feT2wBLAz6OWbw7M8tqEjaphcE2kEgT fDyztRqHRuUq3kK/oPpzwvkBpLYBSJP8GAbkYY7xCoWbUVj5Qy3EH3CItI0UFTyqspYz3eH4 /4VPYPaJfUutrA+P5waEQij8x2c8TfOQaT6NS1jCyIcK8qSA9pcmaLPeRhxu47yuYdSQEFQl n8F3Ajv9obuqHVgpWZGRLYEha7CI1UX+fHnIR1+jbYODg70gAT/AaOaNbhWHl2zIqRcXIXCR rusZehG8RkOUrQj4Lhes96jgouNtR3r1maTGjAWcp8H8+fXKFk/6pwPitVxeWGMp8WizdjRv rFuYfWFinWdAs+3fStSVFrCJez+mH+6NfHqTtSTzxPViR/yllEVXuPa1AJo7V427fSavf5ez ZtypsmdxlgkCnZbDTMzpnHRMfJhcZnFXtu7JffeqladUv+BMIcOq8As0QBzmIQQAAA== Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 17:01:58 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, After having sent out my comments I've noticed that the specific example to= illustrate the need to combine GAL and "flow label" was inaccurate. A more relevant example would look like following (I do not include a diagra= m, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no= ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled u= sing a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-= PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS dom= ain, hence he enables insertion and discard of "flow labels" at the two S-PE= s. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not= happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 3. The operator also intends to operate some end-to-end OAM for this MS-PW= using "GAL-in-PW". This results in a conflict since both GAL and "flow labe= l" are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controv= ersy. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander V= ainshtein [Alexander.Vainshtein@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren= Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal= -in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-= of-stack position. As stated in the Introduction, this draft removes the restriction imposed by= RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The cor= responding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST al= ways be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requi= rement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reser= ves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (= LSE) at the bottom of stack in order to facilitate the load balancing of the= flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseud= owires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowir= es is the case when an edge-to-edge service emulation crosses multiple IP/MP= LS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe= 3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) wo= uld potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-= TP domain, e.g., for relying a PW status message that it has received over a= Targeted LDP session from the IP/MPLS domain to a static PW status message= to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE= 3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG d= ocument, with arguments for both the flow label and GAL taking the bottom-o= f-the-stack position. But, to the best of my understanding, consensus on thi= s issue has not been reached. Hopefully this comment will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Hi all,
After having sent out my comments I've n= oticed that the specific example to illustrate the need to combine GAL and &= quot;flow label" was inaccurate.
 
A more relevant example would look like<= a> following (I do not include a diagram, but it can be easily provided= if necessary)
  1. A MS-PW:
    • Starts at an S-PE that resides at the edg= e of an MPLS-TP domain (no ECMP)
    • Crosses this domain and enters an IP= /MPLS domain with ECMP enabled using a T-PE that resides at the age of these= two domains
    • Leaves this domain and enters a 2nd= MPLS-TP domain (using the 2nd T-PE)
    • Terminates on another S-PE at t= he edge of the 2nd MPLS-TP domain
  2. The operator intends to improve traf= fic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs. Note that:
    • This does not violate the MPLS-TP restric= tion on ECMP: ECMP does not happen in he MPLS-TP domains
    • T-PEs do not even have to be aware o= f flow labels
  3. The operator also intends to operate= some end-to-end OAM for this MS-PW using "GAL-in-PW". This result= s in a conflict since both GAL and "flow label" are defined (in th= e corresponding drafts) as bottom of stack.

 

IMHO this describes a realistic scenario where the two drafts are in contro= versy.
 
Regards,
     Sas= ha
From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein [Alexand= er.Vainshtein@ecitele.com]
Sent: Tuesday, August 16, 2011 4:26 PM
To: ietf@ietf.org
Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe= 3; Oren Gal; John Shirron; Rotem Cohen
Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Hi all,

 

I would like to raise the following issue with regard= to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.

 

As stated in the Introduction, this draft removes the= restriction imposed by RFC 5586 on usage of Generic Associated Channel Labe= l (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:

In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MUST NOT be used with PWs.  It MUST always be at the bottom of the label stack &nb= sp;  (i.e., S bit set to 1).

 

draft-ietf-pwe3-gal-in-pw proposed to replace the ori= ginal text in RFC 5586 with the following

 

In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit s= et to 1).

 

I.e.,  while remov= ing this restriction of 5586, it does not modify its requirement for the GAL= being always at the bottom of the label stack.

 

At the same draft-ietf-= pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the P= W stack for the PW flow labels, e.g., in Section 1.1:

 

This document descri= bes a method of adding an additional label stack entry (LSE) at the bottom o= f stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. 

 

One could argue that dr= aft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-T= P does not use ECMP. IMHO and FWIW,

such an argument, were= it presented, would be highly problematic, because:

 

1.   &n= bsp;   RFC 5960 (which defines the MPLS-TP d= ata plane) did not define any differences between the PW data plane in IP/MP= LS and MPLS-TP.

2.   &n= bsp;   One of the most popular scenarios for= using multi-segment pseudowires is the case when an edge-to-edge service em= ulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, th= e flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pote= ntially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domai= n, e.g., for relying a PW status message that it has received over a Targete= d LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the b= ottom-of-stack position.

 

The issue I am raising= Is not new. It has been actively discussed on the PWE3 mailing list with re= gard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with argument= s  for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understandi= ng, consensus on this issue has not been reached.

 

Hopefully this comment will be useful.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_-- From jdrake@juniper.net Tue Aug 16 11:29:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1722F21F8C11 for ; Tue, 16 Aug 2011 11:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Oy-5JFZRlf for ; Tue, 16 Aug 2011 11:29:03 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2740921F8C10 for ; Tue, 16 Aug 2011 11:29:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTkq3GipVQsj1yh+sLNTHIcCXlR6hSgMf@postini.com; Tue, 16 Aug 2011 11:29:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 16 Aug 2011 10:21:02 -0700 From: John E Drake To: Lizhong Jin Date: Tue, 16 Aug 2011 10:20:59 -0700 Thread-Topic: [mpls] Entropy label in hierarchical LSP Thread-Index: AcxcJdHRLz8JkLwSQdmlrWLe5lg0gAAAOJPAAARZ4/A= Message-ID: <5E893DB832F57341992548CDBB333163A0ACB1AA4C@EMBX01-HQ.jnpr.net> References: 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_5E893DB832F57341992548CDBB333163A0ACB1AA4CEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 18:29:06 -0000 --_000_5E893DB832F57341992548CDBB333163A0ACB1AA4CEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My email, below, contained an example of self-deprecating humor which at le= ast one person did not get. So, in the interest of increased clarity, I wo= uld like to replace the phrase: "the authors, for some unknown reason (stu= pidity perhaps)" with the phrase: "the authors of the Entropy Label I-D (o= f which I am one), for some unknown reason (stupidity perhaps)" Thanks, John Sent from my iPhone From: John E Drake Sent: Tuesday, August 16, 2011 8:25 AM To: 'Lizhong Jin' Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; mpl= s@ietf.org Subject: RE: [mpls] Entropy label in hierarchical LSP Lizhong, That's correct, only the ingress LER places an entropy label in the label s= tack. I think part of the confusion arises because the authors, for some unknown = reason (stupidity perhaps), use the term 'LSR' rather than 'LER' throughout= . This is covered by the statement in Section 1.1: "The term ingress (or egress) LSR is used interchangeably with ingress (or= egress) LER." But people may have missed this. Thanks, John Sent from my iPhone From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Tuesday, August 16, 2011 8:05 AM To: John E Drake Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; mpl= s@ietf.org Subject: Re: [mpls] Entropy label in hierarchical LSP Hi John, With regarding the scenario and figure in Zhi's email, LSP1 will be nested = by LSP2, and both LSP1 and LSP2 support entropy label. Then do you mean nod= e B will not add entropy label for the labeled traffic of LSP1, right? I th= ink the draft is not clear for an ingress node to encapsulate a labeled pac= ket. The received labeled packet maybe already contain entropy label. Thanks Lizhong ------------------------------ Date: Tue, 16 Aug 2011 05:41:19 -0700 From: John E Drake > To: "zheng.zhi@zte.com.cn" >, "draft-ietf-mpls-entropy-label@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Entropy label in hierarchical LSP Message-ID: <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=3D"us-ascii" Hi, The intent of the draft is that the node that creates the label stack is th= e node that places the entropy label in the stack. So, there is only one e= ntropy label present in any given MPLS packet. If this is not clear, pleas= e point me to the text that causes you confusion on this point. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of zheng.zhi@zte.com.= cn Sent: Monday, August 15, 2011 1:58 AM To: draft-ietf-mpls-entropy-label@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Entropy label in hierarchical LSP Hi authors: About the use of entropy label, consider the hierarchical LSP case below: LSP-2 _________ / \ A--...--B---...---C--...--D \________________________/ LSP-1 In the above figure, an end-to-end LSP LSP-1 is between A and D, and anothe= r LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated by th= e ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. So the label stack of the packets arrives at C, is like +-------------+ +-------------+ | LSP-2 label | | LSP-2 label | | LSP-1 label | | ELI-2 | | ELI-1 | OR | EL-2 | ? | EL-1 | | LSP-1 label | | ELI-2 | | ELI-1 | | EL-2 | | EL-1 | +-------------+ +-------------+ ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; Which one is the correct format? Thanks Zhi --_000_5E893DB832F57341992548CDBB333163A0ACB1AA4CEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

My email, below, contained an example of self-depr= ecating humor which at least one person did not get.  So, in the inter= est of increased clarity, I would like to replace the phrase:  “= the authors, for some unknown reason (stupidity perhaps)̶= 1; with the phrase:  “the authors of the Entropy Label I-D (of w= hich I am one), for some unknown reason (stupidity perhaps)”

 

Thanks,

 

John

 

Sent from my iPhone

 

<= div>

From: John E Drake
Sent: Tuesday= , August 16, 2011 8:25 AM
To: 'Lizhong Jin'
Cc: zheng.z= hi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org<= br>Subject: RE: [mpls] Entropy label in hierarchical LSP<= /span>

 

Lizhong,

=  

That’s correc= t, only the ingress LER places an entropy label in the label stack.

 

I think part of the confusion arises because the aut= hors, for some unknown reason (stupidity perhaps), use the term ‘LSR&= #8217; rather than ‘LER’ throughout.  This is covered by t= he statement in Section 1.1:

 

“The term = ingress (or egress) LSR is used interchangeably with ingress  (or egre= ss) LER.”

 = ;

But people may have missed th= is.

 

Thanks,

 

Joh= n

 =

Sent from my iPhone

 

=

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Se= nt: Tuesday, August 16, 2011 8:05 AM
To: John E Drake
C= c: zheng.zhi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; = mpls@ietf.org
Subject: Re: [mpls] Entropy label in hierarchical L= SP

 <= /p>

Hi John,

With regarding the scenario and figure in Zhi's email, LSP1 w= ill be nested by LSP2, and both LSP1 and LSP2 support entropy label. Then d= o you mean node B will not add entropy label for the labeled traf= fic of LSP1, right? I think the draft is not clear for an ingress node= to encapsulate a labeled packet. The received labeled packet may= be already contain entropy label.

 

Thanks=

Lizhong

 

 <= o:p>

------------------------------

Date: Tue, 16 Aug 2011 05:= 41:19 -0700
From: John E Drake <jdrake@juniper.net>
To: "zheng.zhi@zte.com.cn" <zheng.zhi@zte.com.cn>,
       "draft-ietf-mpl= s-entropy-label@tools.ietf.org"
       <= draft-ietf-= mpls-entropy-label@tools.ietf.org>
Cc: "mpls@ietf.org" <m= pls@ietf.org>
Subject: Re: [mpls] Entropy label in hierarchical L= SP
Message-ID:
       <5E893DB832F573419= 92548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net>
Content-Type: text/= plain; charset=3D"us-ascii"

Hi,

The intent of the d= raft is that the node that creates the label stack is the node that places = the entropy label in the stack.  So, there is only one entropy label p= resent in any given MPLS packet.  If this is not clear, please point m= e to the text that causes you confusion on this point.

Thanks,
John

Sent from my iPhone

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of zheng.zhi@zte.com.cn
Sent: Monday, August 15, 2011= 1:58 AM
To: draft-ietf-mpls-entropy-label@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] Entropy label in hi= erarchical LSP


Hi authors:

About the use of entropy label= , consider the hierarchical LSP case below:

      &nb= sp;   LSP-2
        _________
    =     /         \
A--...--B---...---C--...--= D
\________________________/
          LSP-1=


In the above figure, an end-to-end LSP LSP-1 is between A and D= , and another LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are gen= erated by the ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respecti= vely.

So the label stack of the packets arrives at C, is like
+--= -----------+       +-------------+
| LSP-2 label |  =     | LSP-2 label |
| LSP-1 label |       | &n= bsp;  ELI-2    |
|    ELI-1    | &nbs= p; OR  |    EL-2     |    ?
|   =  EL-1     |       | LSP-1 label |
|  =  ELI-2    |       |    ELI-1  = ;  |
|    EL-2     |       | &nb= sp;  EL-1     |
+-------------+       +---= ----------+

ELI-1: ELI for LSP-1; EL-1: EL for LSP-1;
ELI-2: ELI = for LSP-2; EL-2: EL for LSP-2;

Which one is the correct format?
<= br>Thanks
Zhi

= = --_000_5E893DB832F57341992548CDBB333163A0ACB1AA4CEMBX01HQjnprn_-- From pabloisnot@gmail.com Tue Aug 16 14:16:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BACA11E80A1; Tue, 16 Aug 2011 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEtAR9AImzN6; Tue, 16 Aug 2011 14:16:58 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E16E221F8B5A; Tue, 16 Aug 2011 14:16:57 -0700 (PDT) Received: by qwc23 with SMTP id 23so265773qwc.31 for ; Tue, 16 Aug 2011 14:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ITT/6udhCCGAqO5aSgr4ZoRMsNlOdvUOXhtaOVWhGhA=; b=urcvgw4wORqEeb/c7eWNPWHzcNLuQhWQWBroRoGEmsnpShxhq32d/t4+Qs+rk1iawe e9xvZImcIer4sUrhGXiC1liDuYvgwpsX2mXZfRyH9Ls6PL6jDFB2E4YAnK52SIzbR3dt XrpwZBYj7/I8+ASf09EcsphQzY2itNO1DiEgY= MIME-Version: 1.0 Received: by 10.224.202.196 with SMTP id ff4mr208023qab.391.1313529466826; Tue, 16 Aug 2011 14:17:46 -0700 (PDT) Received: by 10.224.45.146 with HTTP; Tue, 16 Aug 2011 14:17:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 17:17:46 -0400 Message-ID: From: Pablo Frank To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=20cf300fb42d45b07d04aaa5e901 Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:16:59 -0000 --20cf300fb42d45b07d04aaa5e901 Content-Type: text/plain; charset=ISO-8859-1 I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Hi all, > After having sent out my comments I've noticed that the specific example to > illustrate the need to combine GAL and "flow label" was inaccurate. > > A more relevant example would look like following (I do not include a > diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > - Starts at an S-PE that resides at the edge of an MPLS-TP domain > (no ECMP) > - Crosses this domain and enters an IP/MPLS domain with ECMP enabled > using a T-PE that resides at the age of these two domains > - Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd > T-PE) > - Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > 2. The operator intends to improve traffic distribution in the IP/MPLS > domain, hence he enables insertion and discard of "flow labels" at the > two S-PEs. Note that: > - This does not violate the MPLS-TP restriction on ECMP: ECMP does > not happen in he MPLS-TP domains > - T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for this > MS-PW using "GAL-in-PW". This results in a conflict since both GAL and "flow > label" are defined (in the corresponding drafts) as bottom of stack. > > > IMHO this describes a realistic scenario where the two drafts are in > controversy. > > Regards, > Sasha > ------------------------------ > *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; > Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi all, > > > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw: > controversy vs. draft-ietf-pwe3-fat-pwwith regard to bottom-of-stack position. > > > > As stated in the Introduction, this draft removes the restriction imposed > by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The > corresponding text Section 4.2 of RFC 5586 states: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with > PWs. It MUST always be at the bottom of the label stack (i.e., S bit set > to 1). > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 > with the following > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. > It MUST always be at the bottom of the label stack (i.e., S bit set to 1). > > > > I.e., while removing this restriction of 5586, it does not modify its > requirement for the GAL being always at the bottom of the label stack. > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) > reserves the bottom of the PW stack for the PW flow labels, e.g., in Section > 1.1: > > > > This document describes a method of adding an additional label stack entry > (LSE) at the bottom of stack in order to facilitate the load balancing of > the flows within a PW over the available ECMPs. > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP > pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, > > such an argument, were it presented, would be highly problematic, because: > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not define > any differences between the PW data plane in IP/MPLS and MPLS-TP. > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation crosses > multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of > draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an > IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at > the edge of an MPLS-TP domain, e.g., for relying a PW status message that it > has received over a Targeted LDP session from the IP/MPLS domain to a static > PW status message to cross the MPLS-TP domain) for the bottom-of-stack > position. > > > > The issue I am raising Is not new. It has been actively discussed on the > PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a > WG document, with arguments for both the flow label and GAL taking the > bottom-of-the-stack position. But, to the best of my understanding, > consensus on this issue has not been reached. > > > > Hopefully this comment will be useful. > > > > Regards, > > Sasha > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --20cf300fb42d45b07d04aaa5e901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS do= main in the middle segment, you're no longer in an MPLS-TP environment = and so the GAL is not required to be BOS. =A0During that middle segment, th= e PW flow label would be placed below the GAL and above the GACh. =A0It get= s removed when it hits the S-PE that switches you back into the MPLS-TP env= ironment. =A0In other words, whether you're in an MPLS-TP environment i= s determined segment by segment in a MS-PW.

Pablo

On Tue, Aug 16, 2011= at 1:02 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
Hi all,
After having sent out my comments I'= ;ve noticed that the specific example to illustrate the need to combine GAL= and "flow label" was inaccurate.
=A0
A more relevant example would look like= following (I do not include a diagram, but it can be easily provide= d if necessary)
  1. A MS-PW:
    • Starts at an S-PE that resides at the ed= ge of an MPLS-TP domain (no ECMP)
    • Crosses this domain and enters an I= P/MPLS domain with ECMP enabled using a T-PE that resides at the age of the= se two domains
    • Leaves this domain and enters a 2nd= MPLS-TP domain (using the 2nd T-PE)
    • Terminates on another S-PE at=A0the= edge of the 2nd MPLS-TP domain
  2. The operator intends to improve tra= ffic distribution in the IP/MPLS domain, hence he enables=A0insertion and discard of "flow labels" at the two S-PEs. Note that:
    • This does not violate the MPLS-TP restri= ction on ECMP: ECMP does not happen in he MPLS-TP domains
    • T-PEs do not even have to be aware = of flow labels
  3. The operator also intends to operat= e some end-to-end OAM for this MS-PW using "GAL-in-PW". This resu= lts in a conflict since both GAL and "flow label" are defined (in= the=A0corresponding drafts) as bottom of stack.

=A0

=A0
Regards,
=A0=A0=A0=A0 Sasha
From: mpls-bounces@ietf.org [= mpls-bounces@iet= f.org] On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, August 16, 2011 4:26 PM
To: ietf@ietf.org=
Cc: mpls@ietf.org= ; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Rotem Cohen
Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw<= br>

Hi all,

=A0

I would like to raise the following issue with regar= d to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.

=A0

As stated in the Introduction, this draft removes th= e restriction imposed by RFC 5586 on usage of Generic Associated Channel La= bel (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:

In MPLS-TP, the = GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of = LSPs, and with Sections, and MUST NOT be used with PWs.=A0 It MUST always be at the bottom of the label stack =A0= =A0=A0(i.e., S bit set to 1).

=A0

draft-ietf-pwe3-gal-in-pw proposed to replace the or= iginal text in RFC 5586 with the following

=A0

In MPLS-TP, the = GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of = LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit = set to 1).

=A0

I.e., =A0while removing= this restriction of 5586, it does not modify its requirement for the GAL b= eing always at the bottom of the label stack.

=A0

At the same draft-ietf-= pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the = PW stack for the PW flow labels, e.g., in Section 1.1:

=A0

This document de= scribes a method of adding an additional label stack entry (LSE) at the bot= tom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs.=A0

=A0

One could argue that dr= aft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-= TP does not use ECMP. IMHO and FWIW,

such an argument, were = it presented, would be highly problematic, because:

=A0

1.=A0=A0=A0=A0=A0=A0 RFC 5960 (which defines the MPLS-TP = data plane) did not define any differences between the PW data plane in IP/= MPLS and MPLS-TP.

2.=A0=A0=A0=A0=A0=A0 One of the most popular scenarios fo= r using multi-segment pseudowires is the case when an edge-to-edge service = emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios,= the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pot= entially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP dom= ain, e.g., for relying a PW status message that it has received over a Targ= eted LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the = bottom-of-stack position.

=A0

The issue I am raising = Is not new. It has been actively discussed on the PWE3 mailing list with re= gard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with argumen= ts =A0for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understand= ing, consensus on this issue has not been reached.

=A0

Hopefully this comment will be useful.

=A0

Regards,

=A0=A0=A0=A0 Sasha

=A0

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--20cf300fb42d45b07d04aaa5e901-- From davari@broadcom.com Tue Aug 16 14:24:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1805B11E80AB; Tue, 16 Aug 2011 14:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncQkFkN9WeZE; Tue, 16 Aug 2011 14:24:07 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id E56CA11E8085; Tue, 16 Aug 2011 14:24:06 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 16 Aug 2011 14:29:56 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 16 Aug 2011 14:24:41 -0700 From: "Shahram Davari" To: "Pablo Frank" , "Alexander Vainshtein" Date: Tue, 16 Aug 2011 14:24:39 -0700 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcWgC3iJ/eCK3bTEKpvSbExjfcvQAAKyWQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5@SJEXCHCCR02.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62543EDE3KO6562533-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_ Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:24:11 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Pablo, This is not acceptable. Are you suggesting an LSR to pop a label that is no= t to of the stack? I can assure you 99.99% of HW out there can't do this. Thx SD From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pab= lo Frank Sent: Tuesday, August 16, 2011 2:18 PM To: Alexander Vainshtein Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael We= xler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain= in the middle segment, you're no longer in an MPLS-TP environment and so t= he GAL is not required to be BOS. During that middle segment, the PW flow = label would be placed below the GAL and above the GACh. It gets removed wh= en it hits the S-PE that switches you back into the MPLS-TP environment. I= n other words, whether you're in an MPLS-TP environment is determined segme= nt by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > wrote: Hi all, After having sent out my comments I've noticed that the specific example to= illustrate the need to combine GAL and "flow label" was inaccurate. A more relevant example would look like following (I do not include a diagr= am, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no= ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled = using a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T= -PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 1. The operator intends to improve traffic distribution in the IP/MPLS do= main, hence he enables insertion and discard of "flow labels" at the two S-= PEs. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does no= t happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 1. The operator also intends to operate some end-to-end OAM for this MS-P= W using "GAL-in-PW". This results in a conflict since both GAL and "flow la= bel" are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in contro= versy. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@iet= f.org] On Behalf Of Alexander Vainshtein [Ale= xander.Vainshtein@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mis= hael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-ga= l-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bot= tom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed b= y RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The c= orresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatena= ted Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It= MUST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatena= ted Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST = always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requ= irement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) rese= rves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.= 1: This document describes a method of adding an additional label stack entry = (LSE) at the bottom of stack in order to facilitate the load balancing of t= he flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseu= dowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowi= res is the case when an edge-to-edge service emulation crosses multiple IP/= MPLS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-= pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain= ) would potentially compete with GAL (inserted by a T-PE at the edge of an = MPLS-TP domain, e.g., for relying a PW status message that it has received = over a Targeted LDP session from the IP/MPLS domain to a static PW status m= essage to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PW= E3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG= document, with arguments for both the flow label and GAL taking the botto= m-of-the-stack position. But, to the best of my understanding, consensus on= this issue has not been reached. Hopefully this comment will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Pablo,

 

=

This is not acceptable. Are you suggesting an L= SR to pop a label that is not to of the stack? I can assure you 99.99% of H= W out there can’t do this.

=  

Thx

SD

 

Fr= om: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of= Pablo Frank
Sent: Tuesday, August 16, 2011 2:18 PM
To:= Alexander Vainshtein
Cc: mpls@ietf.org; ietf@ietf.org; Vladi= mir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rot= em Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on dra= ft-ietf-pwe3-gal-in-pw

 

I think it's okay because as the PW c= rosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no lon= ger in an MPLS-TP environment and so the GAL is not required to be BOS. &nb= sp;During that middle segment, the PW flow label would be placed below the = GAL and above the GACh.  It gets removed when it hits the S-PE that sw= itches you back into the MPLS-TP environment.  In other words, whether= you're in an MPLS-TP environment is determined segment by segment in a MS-= PW.

 

Pablo

On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshte= in <Alexander.Vainsh= tein@ecitele.com> wrote:

Hi all,

=

After having sent out my c= omments I've noticed that the specific example to illustrate the need to co= mbine GAL and "flow label" was inaccurate.

<= /div>

 

A m= ore relevant example would look like following (I do not include a diagram,= but it can be easily provided if necessary)

  • A MS-PW:
      • Starts at an S-PE that resides at the edge of = an MPLS-TP domain (no ECMP)
      • Crosses this domain and enters an IP/MPLS domain with ECMP ena= bled using a T-PE that resides at the age of these two domains <= /li>
      • Leaves this domain and ente= rs a 2nd MPLS-TP domain (using the 2nd T-PE)
      • Terminates on another S-PE at the edge o= f the 2nd MPLS-TP domain
      The operator intends to improve t= raffic distribution in the IP/MPLS domain, hence he enables insertion = and discard of "flow labels" at the two S-PEs. Note that:
      • This does not violate the MPLS-TP restriction on EC= MP: ECMP does not happen in he MPLS-TP domains
      • T-PEs do not even have to be aware of flow = labels
    1. The operator also intends to operate some end-to-en= d OAM for this MS-PW using "GAL-in-PW". This results in a conflic= t since both GAL and "flow label" are defined (in the corres= ponding drafts) as bottom of stack.

     

    IMHO this describes a realistic scenario where the two d= rafts are in controversy.

     

    Regards,

    =

      &nb= sp;  Sasha

    From: mpls-bounces@ietf.org [mpls-bounces@ietf.org]= On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
    = Sent: Tuesday, August 16, 2011 4:26 PM
    To: ietf@ietf.org
    Cc: mpls@ietf.org; Vladimir Kleine= r; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem CohenSubject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-p= w

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Hi all,

     

    I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pw: controversy = vs. draft-ietf-pwe3-fat-pw with regard to b= ottom-of-stack position.

     

    As sta= ted in the Introduction, this draft removes the restriction imposed by RFC = 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresp= onding text Section 4.2 of RFC 5586 states:

    In MPLS-TP, the GAL MUST be used with packet= s on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and= MUST NOT be used with PWs.  It MUST always be at the bottom of the la= bel stack    (i.e., S bit set to 1).

     <= o:p>

    draft-ietf-pwe3-gal= -in-pw proposed to replace the original text in RFC 5586 with the following=

     <= /span>

    In MPLS-TP, the GAL MUST b= e used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and = with Sections, and MAY be used with PWs. It MUST always be at the bottom of= the label stack (i.e., S bit set to 1).=

     

    I.e.,  while removing this restriction of 5586, it does not mo= dify its requirement for the GAL being always at the bottom of the label st= ack.

     

    At the same draft-ietf-pwe3-fat-pw (currently also in the IESG= review) reserves the bottom of the PW stack for the PW flow labels, e.g., = in Section 1.1:

     

    This document describes a method of adding an additional label sta= ck entry (LSE) at the bottom of stack in order to facilitate the load balan= cing of the flows within a PW over the available ECMPs. 

     

    One could argue that draft-ietf-pwe3-gal-in-p= w only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. = IMHO and FWIW,

    such an argument, were it presented, would be highly probl= ematic, because:

     

    1.       RFC 5960 (which defines the MPLS-TP data plane) did not define any dif= ferences between the PW data plane in IP/MPLS and MPLS-TP.

    2.=      &= nbsp; One of the most popular scenarios = for using multi-segment pseudowires is the case when an edge-to-edge servic= e emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenario= s, the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE = at the edge of an IP/MPLS domain) would potentially compete with GAL (inser= ted by a T-PE at the edge of an MPLS-TP domain, e.g., for relying a PW stat= us message that it has received over a Targeted LDP session from the IP/MPL= S domain to a static PW status message to cross the MPLS-TP domain) for the= bottom-of-stack position.

    =  

    The issue I am raising Is not new. It ha= s been actively discussed on the PWE3 mailing list with regard to adoption = of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments  for both= the flow label and GAL taking the bottom-of-the-stack position. But, to th= e best of my understanding, consensus on this issue has not been reached.

    &= nbsp;

    Hopefully thi= s comment will be useful.

     

    Reg= ards,

      &= nbsp;  Sasha

    &= nbsp;

    This e-mail= message is intended for the recipient only and contains information which = is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have re= ceived this transmission in error, please inform us by e-mail, phone or fax= , and then delete the original and all copies thereof.

    This e-mail message is intended for the recipient only and= contains information which is CONFIDENTIAL and which may be proprietary to= ECI Telecom. If you have received this transmission in error, please infor= m us by e-mail, phone or fax, and then delete the original and all copies t= hereof.


    _______________________________________________
    pwe3 mailing l= ist
    pwe3@ietf.org
    https://www.ietf= .org/mailman/listinfo/pwe3

     

    = --_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_-- From pabloisnot@gmail.com Tue Aug 16 15:20:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55CE21F8AF7; Tue, 16 Aug 2011 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQytu4G42jX5; Tue, 16 Aug 2011 15:19:59 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A721F8AF3; Tue, 16 Aug 2011 15:19:59 -0700 (PDT) Received: by qyk35 with SMTP id 35so289966qyk.10 for ; Tue, 16 Aug 2011 15:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GG1lOBxwpsd7UFLZSspPo1lXsfxrI/lHsHEH1A7ID0U=; b=SNlKeYhCerYsH14CVDZZoG+RAKtIkihV3vXj90shhKUWSZ3frc5d/wdpqogYs8O5Da D5I7deS1kHxfFx6tPt881OmXxyxD5QvyX6pxGj1SRVHjmBkBlifQaab5D90/uE7938aV 8gnILAjAzNWshqjGR94n92zdDjamCNJNf6s+s= MIME-Version: 1.0 Received: by 10.224.200.202 with SMTP id ex10mr279993qab.241.1313533248220; Tue, 16 Aug 2011 15:20:48 -0700 (PDT) Received: by 10.224.45.146 with HTTP; Tue, 16 Aug 2011 15:20:48 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 16 Aug 2011 18:20:48 -0400 Message-ID: From: Pablo Frank To: Shahram Davari Content-Type: multipart/alternative; boundary=20cf300faf91a92e0904aaa6ca8c Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:20:01 -0000 --20cf300faf91a92e0904aaa6ca8c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My mistake. Flow-labels are used end-to-end in a multi-segment pseudowire. I suppose the flow label can easily be ignored when it crosses the MPLS-TP segments but that does create the conflict that Sasha is pointing out. Pablo On Tue, Aug 16, 2011 at 5:24 PM, Shahram Davari wrote= : > Pablo,**** > > ** ** > > This is not acceptable. Are you suggesting an LSR to pop a label that is > not to of the stack? I can assure you 99.99% of HW out there can=92t do t= his. > **** > > ** ** > > Thx**** > > SD**** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Pablo Frank > *Sent:* Tuesday, August 16, 2011 2:18 PM > *To:* Alexander Vainshtein > *Cc:* mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishae= l > Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* Re: [mpls] [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw**** > > ** ** > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS doma= in > in the middle segment, you're no longer in an MPLS-TP environment and so = the > GAL is not required to be BOS. During that middle segment, the PW flow > label would be placed below the GAL and above the GACh. It gets removed > when it hits the S-PE that switches you back into the MPLS-TP environment= . > In other words, whether you're in an MPLS-TP environment is determined > segment by segment in a MS-PW.**** > > ** ** > > Pablo**** > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote:**** > > Hi all,**** > > After having sent out my comments I've noticed that the specific example = to > illustrate the need to combine GAL and "flow label" was inaccurate.**** > > **** > > A more relevant example would look like following (I do not include a > diagram, but it can be easily provided if necessary)**** > > 1. A MS-PW: **** > > > - Starts at an S-PE that resides at the edge of an MPLS-TP domain (no > ECMP) **** > - Crosses this domain and enters an IP/MPLS domain with ECMP enable= d > using a T-PE that resides at the age of these two domains **** > - Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd > T-PE) **** > - Terminates on another S-PE at the edge of the 2nd MPLS-TP domain*= * > ** > > > 1. The operator intends to improve traffic distribution in the IP/MPLS > domain, hence he enables insertion and discard of "flow labels" at the= two > S-PEs. Note that: **** > > > - This does not violate the MPLS-TP restriction on ECMP: ECMP does not > happen in he MPLS-TP domains **** > - T-PEs do not even have to be aware of flow labels**** > > > 1. The operator also intends to operate some end-to-end OAM for this > MS-PW using "GAL-in-PW". This results in a conflict since both GAL and= "flow > label" are defined (in the corresponding drafts) as bottom of stack.**= * > * > > **** > > IMHO this describes a realistic scenario where the two drafts are in > controversy.**** > > **** > > Regards,**** > > Sasha**** > ------------------------------ > > *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; > Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw**** > > Hi all,**** > > **** > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw: > controversy vs. draft-ietf-pwe3-fat-pwwith regard to bottom-of-stack posit= ion. > **** > > **** > > As stated in the Introduction, this draft removes the restriction imposed > by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. Th= e > corresponding text Section 4.2 of RFC 5586 states:**** > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be used wi= th > PWs. It MUST always be at the bottom of the label stack (i.e., S bit = set > to 1).**** > > **** > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 55= 86 > with the following**** > > **** > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used with PW= s. > It MUST always be at the bottom of the label stack (i.e., S bit set to 1)= . > **** > > **** > > I.e., while removing this restriction of 5586, it does not modify its > requirement for the GAL being always at the bottom of the label stack. **= * > * > > **** > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) > reserves the bottom of the PW stack for the PW flow labels, e.g., in Sect= ion > 1.1:**** > > **** > > This document describes a method of adding an additional label stack entr= y > (LSE) at the bottom of stack in order to facilitate the load balancing of > the flows within a PW over the available ECMPs. **** > > **** > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP > pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, **** > > such an argument, were it presented, would be highly problematic, because= : > **** > > **** > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not define > any differences between the PW data plane in IP/MPLS and MPLS-TP. **** > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation crosses > multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label = of > draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an > IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at > the edge of an MPLS-TP domain, e.g., for relying a PW status message that= it > has received over a Targeted LDP session from the IP/MPLS domain to a sta= tic > PW status message to cross the MPLS-TP domain) for the bottom-of-stack > position. **** > > **** > > The issue I am raising Is not new. It has been actively discussed on the > PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as = a > WG document, with arguments for both the flow label and GAL taking the > bottom-of-the-stack position. But, to the best of my understanding, > consensus on this issue has not been reached.**** > > **** > > Hopefully this comment will be useful.**** > > **** > > Regards,**** > > Sasha**** > > **** > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. **** > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. **** > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3**** > > ** ** > --20cf300faf91a92e0904aaa6ca8c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    My mistake. =A0Flow-labels are used end-to-end in a multi-segment pseu= dowire. =A0I suppose the flow label can easily be ignored when it crosses t= he MPLS-TP segments but that does create the conflict that Sasha is pointin= g out.

    Pablo

    On = Tue, Aug 16, 2011 at 5:24 PM, Shahram Davari <davari@broadcom.com> wrote:

    Pablo,

    =A0

    This = is not acceptable. Are you suggesting an LSR to pop a label that is not to = of the stack? I can assure you 99.99% of HW out there can=92t do this.

    =A0

    Thx

    SD

    =A0

    From: mpls-bounces@ietf.org [mailto:mpls-= bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Tuesday, August 16, 2011 2:18 PM
    To: Alexander Vains= htein
    Cc: mpls= @ietf.org; ietf@ietf= .org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; Jo= hn Shirron; Rotem Cohen
    Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3= -gal-in-pw

    =A0<= u>

    I think it's okay because as the PW cr= osses the ECMP-enabled IP/MPLS domain in the middle segment, you're no = longer in an MPLS-TP environment and so the GAL is not required to be BOS. = =A0During that middle segment, the PW flow label would be placed below the = GAL and above the GACh. =A0It gets removed when it hits the S-PE that switc= hes you back into the MPLS-TP environment. =A0In other words, whether you&#= 39;re in an MPLS-TP environment is determined segment by segment in a MS-PW= .

    =A0

    Pablo

    On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein <Alexand= er.Vainshtein@ecitele.com> wrote:

    Hi all,

    After having sent out my comments I've noticed that the speci= fic example to illustrate the need to combine GAL and "flow label"= ; was inaccurate.

    =A0=

    A more relevant example would look like following (I do not include a dia= gram, but it can be easily provided if necessary)

    1. A MS-PW:
      • Starts at an S-PE th= at resides at the edge of an MPLS-TP domain (no ECMP)
      • Crosses this domain and enter= s an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age = of these two domains
      • Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) =
      • Terminates on= another S-PE at=A0the edge of the 2nd MPLS-TP domain
    1. The operator intends to improve traffic distribution in the IP/MPLS doma= in, hence he enables=A0insertion and discard of "flow labels" at = the two S-PEs. Note that:
      • This does not violate the MPLS-TP restriction on ECM= P: ECMP does not happen in he MPLS-TP domains
      • T-PEs do not even have to be aware of flow labels
      1. The operator also intends to operate some end-to-end OAM for this MS-PW us= ing "GAL-in-PW". This results in a conflict since both GAL and &q= uot;flow label" are defined (in the=A0corresponding drafts) as bottom = of stack.

      =A0

      IMHO this describes a realisti= c scenario where the two drafts are in controversy.

      =A0

      Rega= rds,

      =A0=A0=A0=A0 Sasha

      From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexa= nder Vainshtein [Alexander.Vainshtein@ecitele.com]
      Sent: Tuesday, August 16, 2011 4:26 PM
      To: ietf@ietf.org
      Cc: mpls@ietf.org; Vladimir Kle= iner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohe= n
      Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw<= /span>

      =

      Hi all,

      =A0=

      I would like to rais= e the following issue with regard to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.=

      =A0=

      As stated in the Int= roduction, this draft removes the restriction imposed by RFC 5586 on usage = of Generic Associated Channel Label (GAL) in PWs. The corresponding text Se= ction 4.2 of RFC 5586 states:

      = In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatena= ted Segments of LSPs, and with Sections, and MUST NOT be used with PWs.=A0 = It MUST always be at the bottom of the label stack =A0=A0=A0(i.e., S bit se= t to 1).

      =A0=

      draft-ietf-pwe3-gal-= in-pw proposed to replace the original text in RFC 5586 with the following<= u>

      =A0=

      In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Conca= tenated Segments of LSPs, and with Sections, and MAY be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1).

      =A0

      I.e., =A0while removing this restrict= ion of 5586, it does not modify its requirement for the GAL being always at= the bottom of the label stack.

      =A0

      At the same draft-ietf-pwe3-fat-pw (c= urrently also in the IESG review) reserves the bottom of the PW stack for t= he PW flow labels, e.g., in Section 1.1:

      =A0

      This document describes a method of adding= an additional label stack entry (LSE) at the bottom of stack in order to f= acilitate the load balancing of the flows within a PW over the available EC= MPs.=A0

      =A0

      One could argue that draft-ietf-pwe3-= gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not us= e ECMP. IMHO and FWIW,

      such an argument, were it presented, would be highly problematic, beca= use:

      =A0

      1.=A0=A0=A0=A0=A0=A0 RF= C 5960 (which defines the MPLS-TP data plane) did not define any difference= s between the PW data plane in IP/MPLS and MPLS-TP.

      2.=A0=A0=A0=A0=A0=A0 One of the most popular scenarios for using multi-segment = pseudowires is the case when an edge-to-edge service emulation crosses mult= iple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of dra= ft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPL= S domain) would potentially compete with GAL (inserted by a T-PE at the edg= e of an MPLS-TP domain, e.g., for relying a PW status message that it has r= eceived over a Targeted LDP session from the IP/MPLS domain to a static PW = status message to cross the MPLS-TP domain) for the bottom-of-stack positio= n.

      =A0

      The issue I am raising Is not new. It= has been actively discussed on the PWE3 mailing list with regard to adopti= on of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments =A0for both= the flow label and GAL taking the bottom-of-the-stack position. But, to th= e best of my understanding, consensus on this issue has not been reached.

      =A0

      Hopefully this comment will be useful.

      =A0

      Regards,

      =A0=A0=A0=A0 Sasha=

      =A0

      This e-mail message is intended for the recipient only an= d contains information which is CONFIDENTIAL and which may be proprietary t= o ECI Telecom. If you have received this transmission in error, please info= rm us by e-mail, phone or fax, and then delete the original and all copies = thereof.

    This e-mail message is intended for the recipient only and c= ontains information which is CONFIDENTIAL and which may be proprietary to E= CI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies the= reof.


    ___________= ____________________________________
    pwe3 mailing list
    pwe3@ietf.org
    https://www.ietf.or= g/mailman/listinfo/pwe3

    =A0


    --20cf300faf91a92e0904aaa6ca8c-- From hideki.endo.es@hitachi.com Tue Aug 16 18:06:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DAE21F8A35 for ; Tue, 16 Aug 2011 18:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.767 X-Spam-Level: X-Spam-Status: No, score=0.767 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M099HI8unBDX for ; Tue, 16 Aug 2011 18:06:46 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 994ED21F89BE for ; Tue, 16 Aug 2011 18:06:45 -0700 (PDT) Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id EAC2337C82; Wed, 17 Aug 2011 10:07:34 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id p7H17Ykr006836; Wed, 17 Aug 2011 10:07:34 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p7H17X6g019850; Wed, 17 Aug 2011 10:07:34 +0900 X-AuditID: b753bd60-9f483ba000000655-0d-4e4b14550509 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id C08B7774280; Wed, 17 Aug 2011 10:07:33 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p7H17Xl28278848; Wed, 17 Aug 2011 10:07:33 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Wed, 17 Aug 2011 10:07:21 +0900 References: <4E1C5B89.8070904@ripe.net> <038c01cc50f6$f23861e0$d6a925a0$@olddog.co.uk> <02d301cc5529$ed7a0a00$c86e1e00$@olddog.co.uk> Priority: normal Importance: normal X400-Content-Identifier: X4E4B143200000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110817100658NC7] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 01:06:48 -0000 Hi Adrian, Thank you for your comments. Yaacov, Could you give us some comments, especially you and I discussed in Quebec? BR, Hideki >Hi Hideki, > >We didn't see Yaacov's email so we can't comment. But I think I agree with >Eric... >If it isn't documented in a current draft or an RFC, it doesn't exist. >So I think there is no definition of LP using ACH TLVs, and no version zero of >the protocol. > >Cheers, >Adrian > >> -----Original Message----- >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >> Sent: 06 August 2011 01:56 >> To: eosborne@cisco.com >> Cc: adrian@olddog.co.uk; mpls@ietf.org; yaacov.weingarten@nsn.com >> Subject: Re[2]: [mpls] Comments on draft-ietf-mpls-tp-linear-protection >> >> Hi Eric, >> >> Thank you for clarifications. >> >> I understand what you say. >> However, it's different from what Yaacov said. >> I'm confusing.. >> >> If your explanation is right status of this draft, >> why did you changed the version number of PSC? >> If the only one channel type for PSC is assigned, >> you don't need to change the version number, do you? >> >> BR, >> Hideki >> >> >> >Hi Hideki- >> > >> > I'm afraid you've been misinformed. Version 0 is not in use. We had >> >talked about ACH TLVs as some point, but do not use them. Per rfc5586, >> >"If the G-ACh message MAY be preceded by one or more ACH TLVs, then this >> >MUST be explicitly specified in the definition of an ACH Channel Type" >> >and we do not make that explicit specification in the draft. >> > >> > Version 1 is the only version which we have defined, and it uses >> >optional TLVs below the PSC header. >> > >> > >> > >> >eric >> > >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> >Of >> >> hideki.endo.es@hitachi.com >> >> Sent: Friday, August 05, 2011 12:48 AM >> >> To: adrian@olddog.co.uk >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection >> >> >> >> Hi Adrian, >> >> >> >> I'm very sorry for my late response. >> >> >> >> You are right. >> >> A protocol version number normally doesn't matter in final RFC, >> >because >> >> previous version number is put away and the latest version is >> >available. >> >> >> >> However, I heard from Yaacov that >> >> not only version number '1' but also '0' was availble in this draft. >> >> The version '0' is to use ACH TLVs. >> >> The version '1' is to use Optional TLVs which will be defined for the >> >> future. >> >> >> >> Unfortunately, I think this solution has big fault as a protocol. >> >> Because the version number is following ACH TLVs, it is impossible to >> >> determine whether there are ACH TLVs or Optional TLVs in a packet. >> >> >> >> I'd like to advertise the fact in WG. >> >> >> >> BR, >> >> Hideki >> >> >> >> >> >> >Hi Hideki, >> >> > >> >> >I have no particular reason to support any protocol version number in >> >> >the document, but you said... >> >> > >> >> >> You should infom the reason why you have changed the protocol >> >version >> >> >> from 0 to 1 in the draft-08. >> >> >> This is very important to implement PSC protocol. >> >> > >> >> >...and this made me curious, >> >> > >> >> >Why is the value of the protocol version field in the final RFC so >> >> important? >> >> > >> >> >Cheers, >> >> >Adrian >> >> > >> >> > >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > > > From lizhong.jin@zte.com.cn Tue Aug 16 20:45:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594E811E808B; Tue, 16 Aug 2011 20:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.692 X-Spam-Level: X-Spam-Status: No, score=-101.692 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hd5hxQW5Dh2; Tue, 16 Aug 2011 20:45:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8E11E8083; Tue, 16 Aug 2011 20:45:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Wed, 17 Aug 2011 11:34:31 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 94545.6445880624; Wed, 17 Aug 2011 11:46:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p7H3kT8A029775; Wed, 17 Aug 2011 11:46:29 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Alexander.Vainshtein@ecitele.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 17 Aug 2011 11:46:09 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 11:46:21, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 11:46:21, Serialize complete at 2011-08-17 11:46:21, S/MIME Sign failed at 2011-08-17 11:46:21: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-17 11:46:30, Serialize complete at 2011-08-17 11:46:30 Content-Type: multipart/alternative; boundary="=_alternative 0014B925482578EF_=" X-MAIL: mse01.zte.com.cn p7H3kT8A029775 Cc: mpls@ietf.org, Vladimir.Kleiner@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, pwe3@ietf.org, Oren.Gal@ecitele.com, John.Shirron@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 03:45:53 -0000 This is a multipart message in MIME format. --=_alternative 0014B925482578EF_= Content-Type: text/plain; charset="US-ASCII" Hi Sasha, Do you mean different PW segments of one MS-PW could support different flow label capability? If in that case, flow LSE is not transparent to the label swap operation on S-PE, Flow Label Sub-TLV signalling is also not transitive, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change the draft-fat-pw. Regards Lizhong > ------------------------------ > > Message: 5 > Date: Tue, 16 Aug 2011 20:02:20 +0300 > From: Alexander Vainshtein > To: "ietf@ietf.org" > Cc: "mpls@ietf.org" , Vladimir Kleiner > , Idan Kaspit , > Mishael Wexler , pwe3 , > Oren Gal , John Shirron > , Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was inaccurate. > > A more relevant example would look like following (I do not include > a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of "flow > labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: ECMP > does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since both > GAL and "flow label" are defined (in the corresponding drafts) as > bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are in > controversy. > > Regards, > Sasha > _____________________________ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0014B925482578EF_= Content-Type: text/html; charset="US-ASCII"
    Hi Sasha,
    Do you mean different PW segments of one MS-PW could support different flow label capability? If in that case, flow LSE is not transparent to the label swap operation on S-PE, Flow Label Sub-TLV signalling is also not transitive, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change the draft-fat-pw.

    Regards
    Lizhong


    > ------------------------------
    >
    > Message: 5
    > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > To: "ietf@ietf.org" <ietf@ietf.org>
    > Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Kleiner
    >    <Vladimir.Kleiner@ecitele.com>,   Idan Kaspit <Idan.Kaspit@ecitele.com>,
    >    Mishael Wexler <Mishael.Wexler@ecitele.com>,   pwe3 <pwe3@ietf.org>,
    >    Oren Gal <Oren.Gal@ecitele.com>,   John Shirron
    >    <John.Shirron@ecitele.com>,   Rotem Cohen <Rotem.Cohen@ecitele.com>
    > Subject: Re: [PWE3] IETF Last Call comment on
    >    draft-ietf-pwe3-gal-in-pw
    > Message-ID:
    >    <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
    > Content-Type: text/plain; charset="iso-8859-1"
    >
    > Hi all,
    > After having sent out my comments I've noticed that the specific
    > example to illustrate the need to combine GAL and "flow label" was inaccurate.
    >
    > A more relevant example would look like following (I do not include
    > a diagram, but it can be easily provided if necessary)
    >
    >  1.  A MS-PW:
    >     *   Starts at an S-PE that resides at the edge of an MPLS-TP
    > domain (no ECMP)
    >     *   Crosses this domain and enters an IP/MPLS domain with ECMP
    > enabled using a T-PE that resides at the age of these two domains
    >     *   Leaves this domain and enters a 2nd MPLS-TP domain (using
    > the 2nd T-PE)
    >     *   Terminates on another S-PE at the edge of the 2nd MPLS-TP domain
    >  2.  The operator intends to improve traffic distribution in the
    > IP/MPLS domain, hence he enables insertion and discard of "flow
    > labels" at the two S-PEs. Note that:
    >     *   This does not violate the MPLS-TP restriction on ECMP: ECMP
    > does not happen in he MPLS-TP domains
    >     *   T-PEs do not even have to be aware of flow labels
    >  3.  The operator also intends to operate some end-to-end OAM for
    > this MS-PW using "GAL-in-PW". This results in a conflict since both
    > GAL and "flow label" are defined (in the corresponding drafts) as
    > bottom of stack.
    >
    >
    >
    > IMHO this describes a realistic scenario where the two drafts are in
    > controversy.
    >
    > Regards,
    >      Sasha
    > _____________________________
    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 0014B925482578EF_=-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 20:48:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54C711E80BF; Tue, 16 Aug 2011 20:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=1.523, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KY8gU7eWTAM; Tue, 16 Aug 2011 20:48:39 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 66E2411E8083; Tue, 16 Aug 2011 20:48:38 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1313552966!21858990!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 20992 invoked from network); 17 Aug 2011 03:49:26 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-15.tower-174.messagelabs.com with SMTP; 17 Aug 2011 03:49:26 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-d7-4e4b337fde9f Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id FB.61.16719.F733B4E4; Wed, 17 Aug 2011 06:20:31 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 17 Aug 2011 06:49:25 +0300 From: Alexander Vainshtein To: Pablo Frank Date: Wed, 17 Aug 2011 06:46:37 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcWehnDCf52OvWSKeoT404R1SjwAANmj+G Message-ID: References: , In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURT1daZliowZi5UHUVPHKEEti0BSozUkihQXxPVDTXRsn+1IO1M7 A6F+SGNcMVEQBKnGiqIRNVANJrIYlbgEJIEvQxD8kbiUGiNRCNFQZxgFEuP7Ou+ec++5ubmX wHSXohIIlhORh2OctCYarwgNfzf60jfmpXZW4KYP9wO4qe9mvdpUPfRKYzo33IRn4ZZm/0CU pa5uTJWv2u0DqxmO40VGRAYbEqxmOt/DFjFWL21gbWY6jTa4nYwVuRAnmmnG7UacjV4Tbfjn rZZkLGdAnJW3sZzdTOdu32I0mTJXGtPoNUsWpaWvit7hYAUDMroY1mlwIUFg7MggRfY3YY6b T46r3Q1VoNj3sB73gV9HS4GWgFQGrC5/qVHwXNjzrlHC0YSOagWw8nVQrXyqAAz/aJtQaSgz fHB3YALPoZbAhvIaIIswqlcFg7XXgUzg1GI40Pp9QhRL5cDzt24DJcECa250RJUCQsIr4GDY LYdJaissv3Lmj9k7AK92tGEyoZWIkcffJnKB1N5o5z2VjDEqDvYNBlRK2xSsa+vGFKyHn9+P qxW9HvafagSyF0bx8H6tVvGaDTtqBnFFHg+f3e7Fy8Bc/7Sq/qkM/7QMRZIMey9WahS8DN6q HcIUbISXxtvx6fFrIOoOiGedbvGAy566wsgXisnIyorIiZKtvOsBUFbp0yPwtiupHVAEoGPI 3NMb8nRqpkjwutpBPKGi9WTzyo15ulkHeJvXwQiOfZ5CJxLaASQweg65DkgcaWO8R5CH/0tl S/MvxxJmWnlpaTlxX3pq6v8/dBx51hrerKPs0noWIORGnr915hEEDcntsv1sD7Kj4oOsU5yi VYRWbiNGaqNE1pCCm3EJrF3hO4GRGHobeAl0OMdzKCGO7JFFlCxyFHKTdeSDKolEIiEQJw0g lmyRVTHSuU1WCkkmKsmkr8Uim0hnNEkl+ID+U3BBc0n2DUvB86fHHPWWlPM7lx462pg/utZW sDDY3d+VGRu6t2n8RPAw982/PpQ4o64v6/q2yxG6KfvN11yRtGt/pvQHln/c+2KhmPjwcm5G UbfrZPhJ8Muu/OSk9MBIMbdnbeFI1cCY9nNxlr7rTWS4J+V0mTc4lBSfc+Xr/As0LjiYtKWY R2B+AyEke08rBAAA Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 03:48:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (becaus= e only T=3DPE can be "flow-aware"). S-PE simply performs swap on PW label. Regards, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Wednesday, August 17, 2011 12:17 AM To: Alexander Vainshtein Cc: ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wex= ler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain= in the middle segment, you're no longer in an MPLS-TP environment and so th= e GAL is not required to be BOS. During that middle segment, the PW flow la= bel would be placed below the GAL and above the GACh. It gets removed when= it hits the S-PE that switches you back into the MPLS-TP environment. In o= ther words, whether you're in an MPLS-TP environment is determined segment b= y segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > wrote: Hi all, After having sent out my comments I've noticed that the specific example to= illustrate the need to combine GAL and "flow label" was inaccurate. A more relevant example would look like following (I do not include a diagra= m, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no= ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled u= sing a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-= PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS dom= ain, hence he enables insertion and discard of "flow labels" at the two S-PE= s. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not= happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 3. The operator also intends to operate some end-to-end OAM for this MS-PW= using "GAL-in-PW". This results in a conflict since both GAL and "flow labe= l" are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controv= ersy. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf= .org] On Behalf Of Alexander Vainshtein [Alexa= nder.Vainshtein@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal= -in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-= of-stack position. As stated in the Introduction, this draft removes the restriction imposed by= RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The cor= responding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST al= ways be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requi= rement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reser= ves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (= LSE) at the bottom of stack in order to facilitate the load balancing of the= flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseud= owires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowir= es is the case when an edge-to-edge service emulation crosses multiple IP/MP= LS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe= 3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) wo= uld potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-= TP domain, e.g., for relying a PW status message that it has received over a= Targeted LDP session from the IP/MPLS domain to a static PW status message= to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE= 3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG d= ocument, with arguments for both the flow label and GAL taking the bottom-o= f-the-stack position. But, to the best of my understanding, consensus on thi= s issue has not been reached. Hopefully this comment will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
    Pablo,
    Sorry, but I think you're wrong. Only T-= PE can insert the flow label (because only T=3DPE can be "flow-aware&qu= ot;). S-PE simply performs swap on PW label.<= /div>
     
    Regards,
         Sasha
     
    From: Pablo Frank= [pabloisnot@gmail.com]
    Sent: Wednesday, August 17, 2011 12:17 AM
    To: Alexander Vainshtein
    Cc: ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
    Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw

    I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS do= main in the middle segment, you're no longer in an MPLS-TP environment and s= o the GAL is not required to be BOS.  During that middle segment, the P= W flow label would be placed below the GAL and above the GACh.  It gets removed when it hits the S-PE tha= t switches you back into the MPLS-TP environment.  In other words, whet= her you're in an MPLS-TP environment is determined segment by segment in a M= S-PW.

    Pablo

    On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainsh= tein <Alexander.Vainshtein= @ecitele.com> wrote:
    Hi all,
    After having sent out my comments I've n= oticed that the specific example to illustrate the need to combine GAL and &= quot;flow label" was inaccurate.
     
    A more relevant example would look like<= a> following (I do not include a diagram, but it can be easily provided= if necessary)
    1. A MS-PW:
      • Starts at an S-PE that resides at the edg= e of an MPLS-TP domain (no ECMP)
      • Crosses this domain and enters an IP= /MPLS domain with ECMP enabled using a T-PE that resides at the age of these= two domains
      • Leaves this domain and enters a 2nd= MPLS-TP domain (using the 2nd T-PE)
      • Terminates on another S-PE at t= he edge of the 2nd MPLS-TP domain
    2. The operator intends to improve traf= fic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs. Note that:
      • This does not violate the MPLS-TP restric= tion on ECMP: ECMP does not happen in he MPLS-TP domains
      • T-PEs do not even have to be aware o= f flow labels
    3. The operator also intends to operate= some end-to-end OAM for this MS-PW using "GAL-in-PW". This result= s in a conflict since both GAL and "flow label" are defined (in th= e corresponding drafts) as bottom of stack.

     

    IMHO this describes a realistic scenario where the two drafts are in contro= versy.
     
    Regards,
         Sas= ha
    From: mpls-bounces@ietf.org [mpls-bou= nces@ietf.org] On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
    Sent: Tuesday, August 16, 2011 4:26 PM
    To: ietf@ietf.org
    Cc: mpls@ietf.org; Vladimir Klei= ner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen<= br> Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

    Hi all,

     

    I would like to raise the following issue with regard= to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.

     

    As stated in the Introduction, this draft removes the= restriction imposed by RFC 5586 on usage of Generic Associated Channel Labe= l (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:

    In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MUST NOT be used with PWs.  It MUST always be at the bottom of the label stack &nb= sp;  (i.e., S bit set to 1).

     

    draft-ietf-pwe3-gal-in-pw proposed to replace the ori= ginal text in RFC 5586 with the following

     

    In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit s= et to 1).

     

    I.e.,  while remov= ing this restriction of 5586, it does not modify its requirement for the GAL= being always at the bottom of the label stack.

     

    At the same draft-ietf-= pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the P= W stack for the PW flow labels, e.g., in Section 1.1:

     

    This document descri= bes a method of adding an additional label stack entry (LSE) at the bottom o= f stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. 

     

    One could argue that dr= aft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-T= P does not use ECMP. IMHO and FWIW,

    such an argument, were= it presented, would be highly problematic, because:

     

    1.       RFC 5960 (which defines the MPLS-TP d= ata plane) did not define any differences between the PW data plane in IP/MP= LS and MPLS-TP.

    2.       One of the most popular scenarios for= using multi-segment pseudowires is the case when an edge-to-edge service em= ulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, th= e flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pote= ntially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domai= n, e.g., for relying a PW status message that it has received over a Targete= d LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the b= ottom-of-stack position.

     

    The issue I am raising= Is not new. It has been actively discussed on the PWE3 mailing list with re= gard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with argument= s  for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understandi= ng, consensus on this issue has not been reached.

     

    Hopefully this comment will be useful.

     

    Regards,

         Sasha

     

    This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

    This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


    _______________________________________________
    pwe3 mailing list
    pwe3@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/pwe3


    This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

    --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 20:52:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF95721F8783 for ; Tue, 16 Aug 2011 20:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m688BFt+B7N for ; Tue, 16 Aug 2011 20:52:56 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 20AB821F877F for ; Tue, 16 Aug 2011 20:52:55 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1313553219!45574116!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 26339 invoked from network); 17 Aug 2011 03:53:40 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-13.tower-21.messagelabs.com with SMTP; 17 Aug 2011 03:53:40 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-dc-4e4b3481c660 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 7E.61.16719.1843B4E4; Wed, 17 Aug 2011 06:24:49 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 17 Aug 2011 06:53:43 +0300 From: Alexander Vainshtein To: "lizhong.jin@zte.com.cn" Date: Wed, 17 Aug 2011 06:50:10 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxckD2sGjdkpUGsQiWYH2uTvRKVgAAAJLdo Message-ID: References: , In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphl+LIzCtJLcpLzFFi42KZ/OrTF91GE28/g/VNRhZHu/4xWtxaupLV ou/TFhYHZo8lS34yeazZ94MlgCmqgdEmMS8vvySxJFUhJbU42VYpoCizLDG5UkkhM8VWyVBJ oSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZqSkb GltzhWRkFiuk6uYmZuYo5KYWFyempyoARRK2MGe87mhmKdgcUTF9SnADY593FyMnh4SAicTe 87MZIWwxiQv31rOB2EICOxklervTuhi5gOwpjBJzX7xlB0mwCdhKbFp9F6iIg0NEwFTizrZM kBpmgUNMEj8uv2ABqWERUJVo3LkCzBYWcJfoX7YCbIGIgIfEzMUn2SFsI4ltK/awgszhFQiU eHqLG2JvvcT6lnVgJZwCwRKXFm8AsxmBbvt+ag0TiM0sIC5x68l8JoibBSSW7DnPDGGLSrx8 /I8Vol5U4k77ekaI+nyJuR1PwM7hFRCUODkTwpYQkJQ4uOIGywRGsVlIxs5C0jILSQtEXE/i xtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKJmZU1CSlJtuYKSbX1qil5qcWZKak6qXnJ+7 iRGShF7sYLx9RvMQowAHoxIPr2eHl58Qa2JZcWXuIUZJDiYlUd6dlt5+QnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4XRiBcrwpiZVVqUX5MClXYARMZJbiTs4HJta8knhjAwPcHCVx3u7kN75C AunAtJmdmlqQWgQzR4aDQ0mCd7sV0ArBotT01Iq0zJwShDQTByfIGTxAZ9SDnMhbXJCYW5yZ DpE/xagoBTQapFkAJJFRmgfXC8o89f///3/FKA70tDDECh5g1oLrfgU0mAlo8K1dHiCDgfkG LiXVwHi2oaLaYH3GBosyXcErJ+33G3PbezjKsbycEqh+Q7xYY/aMPf96WJ6/+8TFJfnQJKDP 5uQ8dZEQk42nP3aeiT4tvkrzZ3qFXUDsK/XAu7WfWvrzbV9l7/k3UdM6YNrf5X8ND5+P8D3X mv9pRe6cG1POSTYtsu2c2cmhP4PNKDopIllTctGqu0osxRmJhlrMRcWJAEKnGxYXBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 03:52:57 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi Lizhong, No. I mean that the flow label can be inserted by T-PE (and only by T-PE) e= ven if some of the domains that are crossed by an MS-PW do not perform ECMP.= In the case of an MPLS-TP domain, ECMP would be simply disabled. But in an= IP/MPLS domain ECP can be enabled, and the hash would include flow labels. Hopefully this clarifies my position. Regards, Sasha ________________________________ From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn] Sent: Wednesday, August 17, 2011 6:46 AM To: Alexander Vainshtein Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wex= ler; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi Sasha, Do you mean different PW segments of one MS-PW could support different flow= label capability? If in that case, flow LSE is not transparent to the label= swap operation on S-PE, Flow Label Sub-TLV signalling is also not transitiv= e, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to= do this, we have to change the draft-fat-pw. Regards Lizhong > ------------------------------ > > Message: 5 > Date: Tue, 16 Aug 2011 20:02:20 +0300 > From: Alexander Vainshtein > To: "ietf@ietf.org" > Cc: "mpls@ietf.org" , Vladimir Kleiner > , Idan Kaspit = , > Mishael Wexler , pwe3 , > Oren Gal , John Shirron > , Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw > Message-ID: > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was inaccur= ate. > > A more relevant example would look like following (I do not include > a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of "flow > labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: ECMP > does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since both > GAL and "flow label" are defined (in the corresponding drafts) as > bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are in > controversy. > > Regards, > Sasha > _____________________________ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is s= olely property of the sender's organization. This mail communication is conf= idential. Recipients named above are obligated to maintain secrecy and are n= ot permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended s= olely for the use of the individual or entity to whom they are addressed. If= you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
    Hi Lizhong,
    No.  I mean that the flow label can= be inserted by T-PE (and only by T-PE) even if some of the domains that are= crossed by an MS-PW do not perform ECMP. In the case of an MPLS-TP domain,= ECMP would be simply disabled. But in an IP/MPLS domain ECP can be enabled, and the hash would include flow label= s.
     
    Hopefully this clarifies my position.
      
    Regards,
         Sasha
     
    From: lizhong.jin@= zte.com.cn [lizhong.jin@zte.com.cn]
    Sent: Wednesday, August 17, 2011 6:46 AM
    To: Alexander Vainshtein
    Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; Oren Gal; John Shirron; Rotem Cohen
    Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw


    Hi Sasha,
    Do you mean different PW segments of one MS-PW could su= pport different flow label capability? If in that case, flow LSE is not tran= sparent to the label swap operation on S-PE, Flow Label Sub-TLV signalling i= s also not transitive, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to do this, w= e have to change the draft-fat-pw.

    Regards
    Lizhong


    > ------------------------------
    >
    > Message: 5
    > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > To: "ietf@ietf.org" <ietf@ietf.org>
    > Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Kl= einer
    >    <Vladimir.Kleiner@ecitele.com>,   Idan Kaspit &= lt;Idan.Kaspit@ecitele.com>,
    >    Mishael Wexler <Mishael.Wexler@ecitele.com>,  = pwe3 <pwe3@ietf.org>,
    >    Oren Gal <Oren.Gal@ecitele.com>,   John Shirron=
    >    <John.Shirron@ecitele.com>,   Rotem Cohen <R= otem.Cohen@ecitele.com>
    > Subject: Re: [PWE3] IETF Last Call comment on
    >    draft-ietf-pwe3-gal-in-pw
    > Message-ID:
    >    <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL0= 2.ecitele.com>
    > Content-Type: text/plain; charset=3D"iso-8859-1"
    >
    > Hi all,
    > After having sent out my comments I've noticed that the specific
    > example to illustrate the need to combine GAL and "flow label"= ; was inaccurate.
    >
    > A more relevant example would look like following (I do not include > a diagram, but it can be easily provided if necessary)
    >
    >  1.  A MS-PW:
    >     *   Starts at an S-PE that resides at the edge of an= MPLS-TP
    > domain (no ECMP)
    >     *   Crosses this domain and enters an IP/MPLS domain= with ECMP
    > enabled using a T-PE that resides at the age of these two domains
    >     *   Leaves this domain and enters a 2nd MPLS-TP doma= in (using
    > the 2nd T-PE)
    >     *   Terminates on another S-PE at the edge of the 2n= d MPLS-TP domain
    >  2.  The operator intends to improve traffic distribution in= the
    > IP/MPLS domain, hence he enables insertion and discard of "flow > labels" at the two S-PEs. Note that:
    >     *   This does not violate the MPLS-TP restriction on= ECMP: ECMP
    > does not happen in he MPLS-TP domains
    >     *   T-PEs do not even have to be aware of flow label= s
    >  3.  The operator also intends to operate some end-to-end OAM= for
    > this MS-PW using "GAL-in-PW". This results in a conflict sinc= e both
    > GAL and "flow label" are defined (in the corresponding drafts= ) as
    > bottom of stack.
    >
    >
    >
    > IMHO this describes a realistic scenario where the two drafts are in > controversy.
    >
    > Regards,
    >      Sasha
    > _____________________________
    --------------------------------------------------------
ZTE Information Security Notice: The information&nb=
sp;contained in this mail is solely property&n=
bsp;of the sender's organization. This mail co=
mmunication is confidential. Recipients named above=
 are obligated to maintain secrecy and ar=
e not permitted to disclose the contents =
of this communication to others.
This email and any files transmitted with =
;it are confidential and intended solely for&n=
bsp;the use of the individual or entity t=
o whom they are addressed. If you have&nb=
sp;received this email in error please notify&=
nbsp;the originator of the message. Any views&=
nbsp;expressed in this message are those of&nb=
sp;the individual sender.
This message has been scanned for viruses =
;and Spam by ZTE Anti-Spam system.

    This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

    --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_-- From lizhong.jin@zte.com.cn Tue Aug 16 21:13:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80BF11E80BF; Tue, 16 Aug 2011 21:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.713 X-Spam-Level: X-Spam-Status: No, score=-101.713 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU68aFQbRPRS; Tue, 16 Aug 2011 21:13:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E751411E8084; Tue, 16 Aug 2011 21:13:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Wed, 17 Aug 2011 12:01:50 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 52059.6445880624; Wed, 17 Aug 2011 12:13:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p7H4E2iu053148; Wed, 17 Aug 2011 12:14:02 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 17 Aug 2011 12:13:42 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 12:13:53, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 12:13:53, Serialize complete at 2011-08-17 12:13:53, S/MIME Sign failed at 2011-08-17 12:13:53: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-17 12:14:03, Serialize complete at 2011-08-17 12:14:03 Content-Type: multipart/alternative; boundary="=_alternative 00173EBF482578EF_=" X-MAIL: mse01.zte.com.cn p7H4E2iu053148 Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 04:13:22 -0000 This is a multipart message in MIME format. --=_alternative 00173EBF482578EF_= Content-Type: text/plain; charset="US-ASCII" Hi Sasha, But in your example, you said: "The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs". It seems that you want S-PE to insert and remove flow label. Regards Lizhong Alexander Vainshtein wrote on 2011-08-17 11:50:10: > Hi Lizhong, > No. I mean that the flow label can be inserted by T-PE (and only by > T-PE) even if some of the domains that are crossed by an MS-PW do > not perform ECMP. In the case of an MPLS-TP domain, ECMP would be > simply disabled. But in an IP/MPLS domain ECP can be enabled, and > the hash would include flow labels. > > Hopefully this clarifies my position. > > Regards, > Sasha > > From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn] > Sent: Wednesday, August 17, 2011 6:46 AM > To: Alexander Vainshtein > Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi Sasha, > Do you mean different PW segments of one MS-PW could support > different flow label capability? If in that case, flow LSE is not > transparent to the label swap operation on S-PE, Flow Label Sub-TLV > signalling is also not transitive, which is conflict with section 6 > of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change > the draft-fat-pw. > > Regards > Lizhong > > > > ------------------------------ > > > > Message: 5 > > Date: Tue, 16 Aug 2011 20:02:20 +0300 > > From: Alexander Vainshtein > > To: "ietf@ietf.org" > > Cc: "mpls@ietf.org" , Vladimir Kleiner > > , Idan Kaspit , > > Mishael Wexler , pwe3 , > > Oren Gal , John Shirron > > , Rotem Cohen > > Subject: Re: [PWE3] IETF Last Call comment on > > draft-ietf-pwe3-gal-in-pw > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > Hi all, > > After having sent out my comments I've noticed that the specific > > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > > > A more relevant example would look like following (I do not include > > a diagram, but it can be easily provided if necessary) > > > > 1. A MS-PW: > > * Starts at an S-PE that resides at the edge of an MPLS-TP > > domain (no ECMP) > > * Crosses this domain and enters an IP/MPLS domain with ECMP > > enabled using a T-PE that resides at the age of these two domains > > * Leaves this domain and enters a 2nd MPLS-TP domain (using > > the 2nd T-PE) > > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > > 2. The operator intends to improve traffic distribution in the > > IP/MPLS domain, hence he enables insertion and discard of "flow > > labels" at the two S-PEs. Note that: > > * This does not violate the MPLS-TP restriction on ECMP: ECMP > > does not happen in he MPLS-TP domains > > * T-PEs do not even have to be aware of flow labels > > 3. The operator also intends to operate some end-to-end OAM for > > this MS-PW using "GAL-in-PW". This results in a conflict since both > > GAL and "flow label" are defined (in the corresponding drafts) as > > bottom of stack. > > > > > > > > IMHO this describes a realistic scenario where the two drafts are in > > controversy. > > > > Regards, > > Sasha > > _____________________________ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00173EBF482578EF_= Content-Type: text/html; charset="US-ASCII"
    Hi Sasha,
    But in your example, you said: "The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs". It seems that you want S-PE to insert and remove flow label.

    Regards
    Lizhong
     

    Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote on 2011-08-17 11:50:10:

    > Hi Lizhong,
    > No.  I mean that the flow label can be inserted by T-PE (and only by
    > T-PE) even if some of the domains that are crossed by an MS-PW do
    > not perform ECMP. In the case of an MPLS-TP domain, ECMP would be
    > simply disabled. But in an IP/MPLS domain ECP can be enabled, and
    > the hash would include flow labels.
    >  
    > Hopefully this clarifies my position.
    >    
    > Regards,
    >      Sasha
    >  
    > From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn]
    > Sent: Wednesday, August 17, 2011 6:46 AM
    > To: Alexander Vainshtein
    > Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit;
    > Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen
    > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
    >
    > Hi Sasha,
    > Do you mean different PW segments of one MS-PW could support
    > different flow label capability? If in that case, flow LSE is not
    > transparent to the label swap operation on S-PE, Flow Label Sub-TLV
    > signalling is also not transitive, which is conflict with section 6
    > of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change
    > the draft-fat-pw.
    >
    > Regards
    > Lizhong
    >
    >
    > > ------------------------------
    > >
    > > Message: 5
    > > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > > To: "ietf@ietf.org" <ietf@ietf.org>
    > > Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Kleiner
    > >    <Vladimir.Kleiner@ecitele.com>,   Idan Kaspit <Idan.Kaspit@ecitele.com>,
    > >    Mishael Wexler <Mishael.Wexler@ecitele.com>,   pwe3 <pwe3@ietf.org>,
    > >    Oren Gal <Oren.Gal@ecitele.com>,   John Shirron
    > >    <John.Shirron@ecitele.com>,   Rotem Cohen <Rotem.Cohen@ecitele.com>
    > > Subject: Re: [PWE3] IETF Last Call comment on
    > >    draft-ietf-pwe3-gal-in-pw
    > > Message-ID:
    > >    <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
    > > Content-Type: text/plain; charset="iso-8859-1"
    > >
    > > Hi all,
    > > After having sent out my comments I've noticed that the specific
    > > example to illustrate the need to combine GAL and "flow label" was
    > inaccurate.
    > >
    > > A more relevant example would look like following (I do not include
    > > a diagram, but it can be easily provided if necessary)
    > >
    > >  1.  A MS-PW:
    > >     *   Starts at an S-PE that resides at the edge of an MPLS-TP
    > > domain (no ECMP)
    > >     *   Crosses this domain and enters an IP/MPLS domain with ECMP
    > > enabled using a T-PE that resides at the age of these two domains
    > >     *   Leaves this domain and enters a 2nd MPLS-TP domain (using
    > > the 2nd T-PE)
    > >     *   Terminates on another S-PE at the edge of the 2nd MPLS-TP domain
    > >  2.  The operator intends to improve traffic distribution in the
    > > IP/MPLS domain, hence he enables insertion and discard of "flow
    > > labels" at the two S-PEs. Note that:
    > >     *   This does not violate the MPLS-TP restriction on ECMP: ECMP
    > > does not happen in he MPLS-TP domains
    > >     *   T-PEs do not even have to be aware of flow labels
    > >  3.  The operator also intends to operate some end-to-end OAM for
    > > this MS-PW using "GAL-in-PW". This results in a conflict since both
    > > GAL and "flow label" are defined (in the corresponding drafts) as
    > > bottom of stack.
    > >
    > >
    > >
    > > IMHO this describes a realistic scenario where the two drafts are in
    > > controversy.
    > >
    > > Regards,
    > >      Sasha
    > > _____________________________     

    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 00173EBF482578EF_=-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 23:31:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89B11E8073; Tue, 16 Aug 2011 23:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=1.536, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxEP4+oCs9vy; Tue, 16 Aug 2011 23:30:59 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A302D21F88B6; Tue, 16 Aug 2011 23:30:56 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1313562657!36239923!51 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 13824 invoked from network); 17 Aug 2011 06:31:27 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-3.tower-27.messagelabs.com with SMTP; 17 Aug 2011 06:31:27 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-cd-4e4b598a2a1c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 7D.A3.16719.A895B4E4; Wed, 17 Aug 2011 09:02:50 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 17 Aug 2011 09:31:43 +0300 From: Alexander Vainshtein To: "lizhong.jin@zte.com.cn" Date: Wed, 17 Aug 2011 09:31:42 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxclBiztob2ezI4RW2U2WrjeJlVwQAEchqw Message-ID: References: In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTXUgUURTmzqy748/UdVP3Kj2s0x+lG2pFG7aS/VqSGfaSL9s4e9ud2p3d ZkbTKDMS0tXKEqw2+pHMLCPBNCJNS5FShIpezH5ekiiLSoksi2xmJ02I7tN3z/ed75zLPYci jWWGOIoXZCwKrJvRh+mqh0e/WPzbM7OSvpYut/b4fwHr4OWrIdZjoy26VWRGXd13IuN6xzdd NpFbAlayguCVWRmbHVjibEy2yBewXBFj5h02Jpkx+9wshz1YkG0M6/NhwcGkhZn/OSsVGS+Y scB5HbzgtDEbc7ZYrNZlKyzJTNr8OclLUsO2uXjJjC0elnebPViSWCc2K5EdLaRrvLeJ9HXX gsInR8/qS8D7SuAHoRSCS1HVzx+khmPQ41dNej8Io4ywDaDyT5U6lTDCGoCqR6wq1kMbam58 qYgoKgouQy9u8aqehF0EujFy06BqdHAeGqh6EjSdBTeg4/UNwWJRMAOdudRr0HAK+nypgVR9 aLgV1d6fr9UNAOQ/XRKsGwpz0J3SoSAGSnNjfdcJFZPQhAaHLhBa0xDVtT/684Bo9O71rxBN H41eHGkCmt6LHjx9F9TQMBL1ntE8EYxF9xsGdFUgJjDNNjAtJTAtRYsnootto3oNJ6D62vfk JO6/95qYHr8IDNdALO/2yXkeZ1KKxZsvL8YcL2M3Xsx5Pc1AG6O3t8Hz/oVdAFKAiaA3lm3K MoawBVKRpwvEUgQTTa+2Z2YZZ+R5HUUuVnLZxXw3lroAokgmil4LFI52sEX7sOidpNYpP3CC jAvnvMrACrJ9SVLS/y+Mia7gPmw2Qqcyn7sx9mFx0mc2RTGILlXLR4rYiQt38m75L01QoWob EUoba1QNLflYj8Q7Nb4PxMeZ6FMqAVXClS9M5aoLdHBiYmIYmJRHz6IPqKoIZb2msocVY0Ix HryToRoruzNFxZUAe2ruTBGCE3XrozMH0scb4xdWHi9ImFtsenPSOdY/5MxpNXQsfd6z31GV a79ij6luF8Pt5RvOdVdHzLTNSHlW4yBq7K3jC9K54rudD8ZG0j9PJKRmpu06OZS489bDjlEx T9+4/mM4ffj0+ZZA6KFHkcKxikDnp71ifCG952pf/FZGJ7nY5EWkKLG/AUMN7+QbBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 06:31:02 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Lizhong, Oops! This was a typo, T-PE intended there. Lots of thanks for catching it. Only T-PEs can insert flow labels, and it is insertion by T-PEs which makes= the scenario problematic, because it combines: 1. ECMP in the "middle" IP/MPLS domain based on hashing of the label s= tack and hence requiring flow labels "end-to-end" 2. End-to-end fate-sharing OAM which, if VCCV Type 1 is not available,= would presumably require GAL to guarantee that OAM packets do not leak to r= emote CE. Regards, Sasha From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, August 17, 2011 7:14 AM To: Alexander Vainshtein Cc: Idan Kaspit; John Shirron; Mishael Wexler; mpls@ietf.org; Oren Gal; pwe3= @ietf.org; Rotem Cohen; Vladimir Kleiner Subject: RE: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi Sasha, But in your example, you said: "The operator intends to improve traffic dist= ribution in the IP/MPLS domain, hence he enables insertion and discard of "f= low labels" at the two S-PEs". It seems that you want S-PE to insert and rem= ove flow label. Regards Lizhong Alexander Vainshtein wrote on 2011-08-17= 11:50:10: > Hi Lizhong, > No. I mean that the flow label can be inserted by T-PE (and only by > T-PE) even if some of the domains that are crossed by an MS-PW do > not perform ECMP. In the case of an MPLS-TP domain, ECMP would be > simply disabled. But in an IP/MPLS domain ECP can be enabled, and > the hash would include flow labels. > > Hopefully this clarifies my position. > > Regards, > Sasha > > From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn] > Sent: Wednesday, August 17, 2011 6:46 AM > To: Alexander Vainshtein > Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi Sasha, > Do you mean different PW segments of one MS-PW could support > different flow label capability? If in that case, flow LSE is not > transparent to the label swap operation on S-PE, Flow Label Sub-TLV > signalling is also not transitive, which is conflict with section 6 > of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change > the draft-fat-pw. > > Regards > Lizhong > > > > ------------------------------ > > > > Message: 5 > > Date: Tue, 16 Aug 2011 20:02:20 +0300 > > From: Alexander Vainshtein > > To: "ietf@ietf.org" > > Cc: "mpls@ietf.org" , Vladimir Kleiner > > , Idan Kaspit , > > Mishael Wexler , pwe3 , > > Oren Gal , John Shirron > > , Rotem Cohen > > Subject: Re: [PWE3] IETF Last Call comment on > > draft-ietf-pwe3-gal-in-pw > > Message-ID: > > > > Content-Type: text/plain; charset=3D"iso-8859-1" > > > > Hi all, > > After having sent out my comments I've noticed that the specific > > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > > > A more relevant example would look like following (I do not include > > a diagram, but it can be easily provided if necessary) > > > > 1. A MS-PW: > > * Starts at an S-PE that resides at the edge of an MPLS-TP > > domain (no ECMP) > > * Crosses this domain and enters an IP/MPLS domain with ECMP > > enabled using a T-PE that resides at the age of these two domains > > * Leaves this domain and enters a 2nd MPLS-TP domain (using > > the 2nd T-PE) > > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > > 2. The operator intends to improve traffic distribution in the > > IP/MPLS domain, hence he enables insertion and discard of "flow > > labels" at the two S-PEs. Note that: > > * This does not violate the MPLS-TP restriction on ECMP: ECMP > > does not happen in he MPLS-TP domains > > * T-PEs do not even have to be aware of flow labels > > 3. The operator also intends to operate some end-to-end OAM for > > this MS-PW using "GAL-in-PW". This results in a conflict since both > > GAL and "flow label" are defined (in the corresponding drafts) as > > bottom of stack. > > > > > > > > IMHO this describes a realistic scenario where the two drafts are in > > controversy. > > > > Regards, > > Sasha > > _____________________________ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is s= olely property of the sender's organization. This mail communication is conf= idential. Recipients named above are obligated to maintain secrecy and are n= ot permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended s= olely for the use of the individual or entity to whom they are addressed. If= you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

    Lizhong,

     

    Oops! This was a typo, T-PE intended there. Lots of= thanks for catching it.

     

    Only T-PEs can insert f= low labels, and it is insertion by T-PEs which makes the scenario problemati= c, because it combines:

     

    1.  &nbs= p;    <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>ECMP in the “middle” IP/MPLS domain based on hashing of the= label stack and hence requiring flow labels “end-to-end” <= /o:p>

    2.    =    End= -to-end fate-sharing OAM which, if VCCV Type 1 is not available, would presu= mably require GAL to guarantee that OAM packets do not leak to remote CE.

     

    Regards,

    =      Sasha

     

    From:= lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
    Sent: W= ednesday, August 17, 2011 7:14 AM
    To: Alexander Vainshtein
    C= c: Idan Kaspit; John Shirron; Mishael Wexler; mpls@ietf.org; Oren Gal; p= we3@ietf.org; Rotem Cohen; Vladimir Kleiner
    Subject: RE: [PWE3] IE= TF Last Call comment on draft-ietf-pwe3-gal-in-pw

     


    Hi Sasha,
    But in your example, you said: "The operator intends to improve traffic= distribution in the IP/MPLS domain, hence he enables insertion and discard= of "flow labels" at the two S-PEs". It seems that you want S= -PE to insert and remove flow label.

    Regards
    Lizhong
     

    A= lexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote on 2011-0= 8-17 11:50:10:

    > Hi Lizhong,
    > No.  I mean that the flow label can be inserted by= T-PE (and only by
    > T-PE) even if some of the domains that are crossed= by an MS-PW do
    > not perform ECMP. In the case of an MPLS-T= P domain, ECMP would be
    > simply disabled. But in an IP/MPLS= domain ECP can be enabled, and
    > the hash would include flo= w labels.
    >  
    > Hopefully this clar= ifies my position.
    >=    
    > Reg= ards,
    >    = ;  Sasha
    > &nbs= p;
    > From: lizhong.j= in@zte.com.cn [lizhong.jin@zte.com.cn]
    > Sent: Wednesday, August 17, 20= 11 6:46 AM
    > To: Alexander Vainshtein
    > Cc: pw= e3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit;
    >= Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen
    > Subjec= t: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

    >
    > Hi Sasha, =
    > Do you mean different PW segments of one MS-PW could support
    > different flow label capability? If in that case, flow LSE i= s not
    > transparent to the label swap operation on S-PE, Flo= w Label Sub-TLV
    > signalling is also not transitive, which i= s conflict with section 6
    > of draft-ietf-pwe3-fat-pw. If we= want to do this, we have to change
    > the draft-fat-pw.
    >
    > Regards
    > Lizhong
    <= tt>>
    >
    > > ---------------------------= ---
    > >
    > > Message: 5
    >= > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > > From: Alex= ander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > &= gt; To: "ietf@ietf.org" <ietf@ietf.org>
    > >= ; Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Klein= er
    > >    <Vladimir.Kleiner@ecitele.com>,=   Idan Kaspit <Idan.Kaspit@ecitele.com>,
    > > &= nbsp;  Mishael Wexler <Mishael.Wexler@ecitele.com>,   pwe3 &= lt;pwe3@ietf.org>,
    > >    Oren Gal <Oren.G= al@ecitele.com>,   John Shirron
    > >    &= lt;John.Shirron@ecitele.com>,   Rotem Cohen <Rotem.Cohen@ecitele.= com>
    > > Subject: Re: [PWE3] IETF Last Call comment on<= /tt>
    > >    draft-ietf-pwe3-gal-in-pw
    >= ; > Message-ID:
    > >    <A3C5DF08D38B604983= 9A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
    > >= Content-Type: text/plain; charset=3D"iso-8859-1"
    >= >
    > > Hi all,
    > > After having sent= out my comments I've noticed that the specific
    > > examp= le to illustrate the need to combine GAL and "flow label" was=
    > inaccurate.
    > >
    > > A more= relevant example would look like following (I do not include
    &= gt; > a diagram, but it can be easily provided if necessary)
    = > >
    > >  1.  A MS-PW:
    > &g= t;     *   Starts at an S-PE that resides at the edge of an M= PLS-TP
    > > domain (no ECMP)
    > >  =   *   Crosses this domain and enters an IP/MPLS domain with ECMP=
    > > enabled using a T-PE that resides at the age of thes= e two domains
    > >     *   Leaves this domai= n and enters a 2nd MPLS-TP domain (using
    > > the 2nd T-PE= )
    > >     *   Terminates on another S-PE at= the edge of the 2nd MPLS-TP domain
    > >  2.  The= operator intends to improve traffic distribution in the
    > &= gt; IP/MPLS domain, hence he enables insertion and discard of "flow
    > > labels" at the two S-PEs. Note that:
    &g= t; >     *   This does not violate the MPLS-TP restriction= on ECMP: ECMP
    > > does not happen in he MPLS-TP domains<= /tt>
    > >     *   T-PEs do not even have to be aw= are of flow labels
    > >  3.  The operator also in= tends to operate some end-to-end OAM for
    > > this MS-PW u= sing "GAL-in-PW". This results in a conflict since both
    <= tt>> > GAL and "flow label" are defined (in the correspondin= g drafts) as
    > > bottom of stack.
    > > <= /tt>
    > >
    > >
    > > IMHO thi= s describes a realistic scenario where the two drafts are in
    >= ; > controversy.
    > >
    > > Regards,
    > >      Sasha
    > > ________= _____________________     

     
    --------------------------------------------------------
    ZTE Information Security Notice: The inform=
ation contained in this mail is solely pr=
operty of the sender's organization. This mail=
 communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy and=
 are not permitted to disclose the conten=
ts of this communication to others.
    This email and any files transmitted wit=
h it are confidential and intended solely =
;for the use of the individual or entity&=
nbsp;to whom they are addressed. If you h=
ave received this email in error please n=
otify the originator of the message. Any =
views expressed in this message are those =
;of the individual sender.
    This mes=
sage has been scanned for viruses and Spa=
m by ZTE Anti-Spam system.
    <= p> This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

    --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_-- From lizho.jin@gmail.com Wed Aug 17 07:47:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4721F8B73 for ; Wed, 17 Aug 2011 07:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAQt3XyftC6O for ; Wed, 17 Aug 2011 07:47:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47921F8B71 for ; Wed, 17 Aug 2011 07:47:58 -0700 (PDT) Received: by ywm21 with SMTP id 21so839329ywm.31 for ; Wed, 17 Aug 2011 07:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f2POCdFDuNyhAaQJYVjwZM8ROxQEgXFEk4Zf2s3af1s=; b=UASM52pa+7UOKimr9vmsZiicMSCVffS550PCGXi4KomJn77ZJkGN7cB5WnR2Zpo2a6 SNgnwhPXPlb8kFHjyTBdN3KzxtVSEvAPqf4NkmYrNJ0eCjhFOxIYXsRHSwCftpeJVD2K iNfw0nLxRrnHTDoX8hbdX8cP0UVV3p3MUwv6s= MIME-Version: 1.0 Received: by 10.42.77.7 with SMTP id g7mr1076144ick.88.1313592528992; Wed, 17 Aug 2011 07:48:48 -0700 (PDT) Received: by 10.42.167.72 with HTTP; Wed, 17 Aug 2011 07:48:48 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0ACB1A837@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0ACB1A837@EMBX01-HQ.jnpr.net> Date: Wed, 17 Aug 2011 22:48:48 +0800 Message-ID: From: Lizhong Jin To: John E Drake Content-Type: multipart/alternative; boundary=20cf3005da2611fb5d04aab498d9 Cc: mpls@ietf.org, draft-ietf-mpls-entropy-label@tools.ietf.org Subject: Re: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 14:47:59 -0000 --20cf3005da2611fb5d04aab498d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, For the hierarchical LSP case, it is possible for the ingress LER to add entropy label for the incoming labeled packet. The ingress LER will not know whether the incoming labeled packet already contains entropy label. Then the packet sent out by ingress LER may contain two entropy labels, one is from the original packet, the other is added by itself. Did I miss something? >From the draft-entropy-label, it seems it makes an assumption that the incoming packet is not an MPLS packet. Thanks Lizhong 2011/8/16 John E Drake > Lizhong,**** > > ** ** > > That=92s correct, only the ingress LER places an entropy label in the lab= el > stack.**** > > ** ** > > I think part of the confusion arises because the authors, for some unknow= n > reason (stupidity perhaps), use the term =91LSR=92 rather than =91LER=92 > throughout. This is covered by the statement in Section 1.1:**** > > ** ** > > =93The term ingress (or egress) LSR is used interchangeably with ingress = (or > egress) LER.=94**** > > ** ** > > But people may have missed this.**** > > ** ** > > Thanks,**** > > ** ** > > John**** > > ** ** > > Sent from my iPhone**** > > ** ** > > *From:* Lizhong Jin [mailto:lizho.jin@gmail.com] > *Sent:* Tuesday, August 16, 2011 8:05 AM > *To:* John E Drake > *Cc:* zheng.zhi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; > mpls@ietf.org > > *Subject:* Re: [mpls] Entropy label in hierarchical LSP**** > > ** ** > > Hi John,**** > > With regarding the scenario and figure in Zhi's email, LSP1 will be neste= d > by LSP2, and both LSP1 and LSP2 support entropy label. Then do you mean n= ode > B will not add entropy label for the labeled traffic of LSP1, right? I th= ink > the draft is not clear for an ingress node to encapsulate a labeled packe= t. > The received labeled packet maybe already contain entropy label.**** > > **** > > Thanks**** > > Lizhong**** > > **** > > **** > > ------------------------------ > > Date: Tue, 16 Aug 2011 05:41:19 -0700 > From: John E Drake > To: "zheng.zhi@zte.com.cn" , > "draft-ietf-mpls-entropy-label@tools.ietf.org" > > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Entropy label in hierarchical LSP > Message-ID: > <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi, > > The intent of the draft is that the node that creates the label stack is > the node that places the entropy label in the stack. So, there is only o= ne > entropy label present in any given MPLS packet. If this is not clear, > please point me to the text that causes you confusion on this point. > > Thanks, > > John > > Sent from my iPhone > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > zheng.zhi@zte.com.cn > Sent: Monday, August 15, 2011 1:58 AM > To: draft-ietf-mpls-entropy-label@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Entropy label in hierarchical LSP > > > Hi authors: > > About the use of entropy label, consider the hierarchical LSP case below: > > LSP-2 > _________ > / \ > A--...--B---...---C--...--D > \________________________/ > LSP-1 > > > In the above figure, an end-to-end LSP LSP-1 is between A and D, and > another LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generat= ed > by the ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. > > So the label stack of the packets arrives at C, is like > +-------------+ +-------------+ > | LSP-2 label | | LSP-2 label | > | LSP-1 label | | ELI-2 | > | ELI-1 | OR | EL-2 | ? > | EL-1 | | LSP-1 label | > | ELI-2 | | ELI-1 | > | EL-2 | | EL-1 | > +-------------+ +-------------+ > > ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; > ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; > > Which one is the correct format? > > Thanks > Zhi > > **** > > --20cf3005da2611fb5d04aab498d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi John,
    For the hierarchical LSP case, it is possible for the ingress LER to a= dd entropy label for the incoming labeled packet. The ingress LER will not = know=A0whether the incoming labeled packet already contains entropy label. = Then the packet sent out by ingress LER may contain two entropy labels, one= is from the original packet, the other is added by itself. Did I miss some= thing?
    From the draft-entropy-label, it seems it makes an assumption that=A0t= he incoming packet is not an MPLS packet.
    =A0
    Thanks
    Lizhong


    =A0
    2011/8/16 John E Drake <jdrake@juniper.net>

    Lizh= ong,

    <= /u>=A0

    That= =92s correct, only the ingress LER places an entropy label in the label sta= ck.

    <= /u>=A0

    I th= ink part of the confusion arises because the authors, for some unknown reas= on (stupidity perhaps), use the term =91LSR=92 rather than =91LER=92 throug= hout.=A0 This is covered by the statement in Section 1.1:

    <= /u>=A0

    =93T= he term ingress (or egress) LSR is used interchangeably with ingress =A0(or= egress) LER.=94

    <= /u>=A0

    But = people may have missed this.

    <= /u>=A0

    Than= ks,

    <= /u>=A0

    John=

    <= /u>=A0

    Sent= from my iPhone

    <= /u>=A0

    From:<= span style=3D"FONT-SIZE: 10pt"> Lizhong Jin [mailto:lizho.jin@gmail.com]
    Sent:= Tuesday, August 16, 2011 8:05 AM
    To: John E Drake
    Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls-entro= py-label@tools.ietf.org; mpls@ietf.org=20


    Subject: Re: [mpls] Entropy label in hierarchi= cal LSP

    =A0

    Hi John,

    With regarding the scenario and figure in Zhi's = email, LSP1 will be nested by LSP2, and both LSP1 and LSP2 support entropy = label. Then do you mean node B will not add entropy label for the=A0labeled= =A0traffic of LSP1, right? I think the draft is not clear for an ingress=A0= node to=A0encapsulate a=A0labeled packet. The received labeled packet maybe= already contain entropy label.

    =A0

    Thanks

    Lizhong

    =A0

    =A0

    ----------------------= --------

    Date: Tue, 16 Aug 2011 05:41:19 -0700
    From: John E Drake= <jdrake@juniper= .net>
    To: "zheng.z= hi@zte.com.cn" <zheng.zhi@zte.com.cn>,
    =A0 =A0 =A0 =A0"= draft-ietf-mpls-entropy-label@tools.ietf.org"
    =A0 =A0 =A0 =A0<draft-ietf-mpls-entropy-label@tools.ietf.org&= gt;
    Cc: "mpls@ie= tf.org" <mpl= s@ietf.org>
    Subject: Re: [mpls] Entropy label in hierarchical LSP
    Message-ID:
    =A0= =A0 =A0 =A0<5E893DB832F57341992548CDBB333163A0A= CB1A719@EMBX01-HQ.jnpr.net>
    Content-Type: text/plain; charset=3D"us-ascii"

    Hi,

    = The intent of the draft is that the node that creates the label stack is th= e node that places the entropy label in the stack. =A0So, there is only one= entropy label present in any given MPLS packet. =A0If this is not clear, p= lease point me to the text that causes you confusion on this point.

    Thanks,

    John

    Sent from my iPhone

    From: mpls-bounces@ietf.org [= mailto:mpls-boun= ces@ietf.org] On Behalf Of zheng.zhi@zte.com.cn
    Sent: Monday, August 15, 2011 1:58 AM
    To: draft-ietf-mpls-entropy= -label@tools.ietf.org
    Cc: mpls@ietf.org
    Subject: [mpls] Entropy label in hierarchical LSP


    Hi authors:
    About the use of entropy label, consider the hierarchical LSP case bel= ow:

    =A0 =A0 =A0 =A0 =A0 LSP-2
    =A0 =A0 =A0 =A0 _________
    =A0 = =A0 =A0 =A0 / =A0 =A0 =A0 =A0 \
    A--...--B---...---C--...--D
    \________________________/
    =A0 =A0 =A0 = =A0 =A0 LSP-1


    In the above figure, an end-to-end LSP LSP-1 is be= tween A and D, and another LSP LSP-2 goes over LSP-1 from B to C. Entropy l= abels are generated by the ingress LSRs, A as ingress for LSP-1 and B for L= SP-2 respectively.

    So the label stack of the packets arrives at C, is like
    +-----------= --+ =A0 =A0 =A0 +-------------+
    | LSP-2 label | =A0 =A0 =A0 | LSP-2 labe= l |
    | LSP-1 label | =A0 =A0 =A0 | =A0 =A0ELI-2 =A0 =A0|
    | =A0 =A0ELI-= 1 =A0 =A0| =A0 OR =A0| =A0 =A0EL-2 =A0 =A0 | =A0 =A0?
    | =A0 =A0EL-1 =A0 =A0 | =A0 =A0 =A0 | LSP-1 label |
    | =A0 =A0ELI-2 =A0 = =A0| =A0 =A0 =A0 | =A0 =A0ELI-1 =A0 =A0|
    | =A0 =A0EL-2 =A0 =A0 | =A0 =A0= =A0 | =A0 =A0EL-1 =A0 =A0 |
    +-------------+ =A0 =A0 =A0 +-------------+=

    ELI-1: ELI for LSP-1; EL-1: EL for LSP-1;
    ELI-2: ELI for LSP-2; = EL-2: EL for LSP-2;

    Which one is the correct format?

    Thanks
    Zhi

    =


    --20cf3005da2611fb5d04aab498d9-- From jdrake@juniper.net Wed Aug 17 08:46:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27E521F8B1C for ; Wed, 17 Aug 2011 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb-8l46qIeI0 for ; Wed, 17 Aug 2011 08:46:56 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC3A21F8B2B for ; Wed, 17 Aug 2011 08:46:56 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTkvintwoBa/HPpxjDdV/NIaJ3lW/WTCq@postini.com; Wed, 17 Aug 2011 08:47:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 17 Aug 2011 08:44:33 -0700 From: John E Drake To: Lizhong Jin Date: Wed, 17 Aug 2011 08:44:30 -0700 Thread-Topic: [mpls] Entropy label in hierarchical LSP Thread-Index: Acxc7NdP5zKjRyAOQ5iC9rRl6POcOwABkJmg Message-ID: <5E893DB832F57341992548CDBB333163A0ACC2F91A@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0ACB1A837@EMBX01-HQ.jnpr.net> In-Reply-To: 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_5E893DB832F57341992548CDBB333163A0ACC2F91AEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-entropy-label@tools.ietf.org" Subject: Re: [mpls] Entropy label in hierarchical LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:46:59 -0000 --_000_5E893DB832F57341992548CDBB333163A0ACC2F91AEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong, We are using the term ingress Label Edge Router (LER) to mean the node whic= h creates and adds the MPLS label stack to a given packet. There will be = only one such node for a given packet and hence only one entropy label for = a given packet. If a given packet already contains an MPLS label stack, no= other node in the network will add an entropy label to that stack. As I asked you before, is there specific text in the Entropy Label I-D whi= ch gives a contrary impression? Thanks, John Sent from my iPhone From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Wednesday, August 17, 2011 7:49 AM To: John E Drake Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls-entropy-label@tools.ietf.org; mpl= s@ietf.org Subject: Re: [mpls] Entropy label in hierarchical LSP Hi John, For the hierarchical LSP case, it is possible for the ingress LER to add en= tropy label for the incoming labeled packet. The ingress LER will not know = whether the incoming labeled packet already contains entropy label. Then th= e packet sent out by ingress LER may contain two entropy labels, one is fro= m the original packet, the other is added by itself. Did I miss something? >From the draft-entropy-label, it seems it makes an assumption that the inco= ming packet is not an MPLS packet. Thanks Lizhong 2011/8/16 John E Drake > Lizhong, That's correct, only the ingress LER places an entropy label in the label s= tack. I think part of the confusion arises because the authors, for some unknown = reason (stupidity perhaps), use the term 'LSR' rather than 'LER' throughout= . This is covered by the statement in Section 1.1: "The term ingress (or egress) LSR is used interchangeably with ingress (or= egress) LER." But people may have missed this. Thanks, John Sent from my iPhone From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Tuesday, August 16, 2011 8:05 AM To: John E Drake Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls-entr= opy-label@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] Entropy label in hierarchical LSP Hi John, With regarding the scenario and figure in Zhi's email, LSP1 will be nested = by LSP2, and both LSP1 and LSP2 support entropy label. Then do you mean nod= e B will not add entropy label for the labeled traffic of LSP1, right? I th= ink the draft is not clear for an ingress node to encapsulate a labeled pac= ket. The received labeled packet maybe already contain entropy label. Thanks Lizhong ------------------------------ Date: Tue, 16 Aug 2011 05:41:19 -0700 From: John E Drake > To: "zheng.zhi@zte.com.cn" >, "draft-ietf-mpls-entropy-label@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Entropy label in hierarchical LSP Message-ID: <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=3D"us-ascii" Hi, The intent of the draft is that the node that creates the label stack is th= e node that places the entropy label in the stack. So, there is only one e= ntropy label present in any given MPLS packet. If this is not clear, pleas= e point me to the text that causes you confusion on this point. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of zheng.zhi@zte.com.= cn Sent: Monday, August 15, 2011 1:58 AM To: draft-ietf-mpls-entropy-label@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Entropy label in hierarchical LSP Hi authors: About the use of entropy label, consider the hierarchical LSP case below: LSP-2 _________ / \ A--...--B---...---C--...--D \________________________/ LSP-1 In the above figure, an end-to-end LSP LSP-1 is between A and D, and anothe= r LSP LSP-2 goes over LSP-1 from B to C. Entropy labels are generated by th= e ingress LSRs, A as ingress for LSP-1 and B for LSP-2 respectively. So the label stack of the packets arrives at C, is like +-------------+ +-------------+ | LSP-2 label | | LSP-2 label | | LSP-1 label | | ELI-2 | | ELI-1 | OR | EL-2 | ? | EL-1 | | LSP-1 label | | ELI-2 | | ELI-1 | | EL-2 | | EL-1 | +-------------+ +-------------+ ELI-1: ELI for LSP-1; EL-1: EL for LSP-1; ELI-2: ELI for LSP-2; EL-2: EL for LSP-2; Which one is the correct format? Thanks Zhi --_000_5E893DB832F57341992548CDBB333163A0ACC2F91AEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = = --Apple-Mail=_4C0C7CAB-803D-47D2-AFA3-DD10EEB08E14-- From gregimirsky@gmail.com Wed Aug 17 13:15:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62E81F0C51; Wed, 17 Aug 2011 13:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Vsc0A+AAdz; Wed, 17 Aug 2011 13:15:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71FBF1F0C4A; Wed, 17 Aug 2011 13:15:39 -0700 (PDT) Received: by vxi29 with SMTP id 29so1423405vxi.31 for ; Wed, 17 Aug 2011 13:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RSK9+KJqPchPHrvzgvA7+tzZbZU+SDD8z9VZkJw217I=; b=V+nybEzwlv8Ym2i7jDaQ114evYpvLspyORZr9+jHmRTSlQnzqhYFuHIU7B3AWQQ7Nc AimLZbmHhgKl37LS7bwtoDjP/Kez1l4WfzilMTKel3v7Tis3EMGpgAAN+kMEQZe+Jpy1 KIbIMJoIVPXOLA9F17khTacnnYGVR+vch+0N4= MIME-Version: 1.0 Received: by 10.52.70.100 with SMTP id l4mr1417125vdu.23.1313612191057; Wed, 17 Aug 2011 13:16:31 -0700 (PDT) Received: by 10.52.167.229 with HTTP; Wed, 17 Aug 2011 13:16:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Aug 2011 13:16:30 -0700 Message-ID: From: Greg Mirsky To: George Swallow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org, ccamp@ietf.org, draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext@tools.ietf.org Subject: Re: [mpls] [CCAMP] Fault OAM configuration X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:15:40 -0000 Dear George, you've asked: (As a preface to the following three paragraphs, it is not clear if draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. There are no procedures in the draft for sending and receiving these messages let alone delivering them to midpoints). I'm not an author and can only assume that defined in RFC 4379 traceroute procedure will be used to signal to MIP, i.e. controlling MSE's TTL. Regards, Greg On Wed, Aug 17, 2011 at 11:59 AM, George Swallow wrote: > The current drafts on Fault OAM configurations, > > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and > draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06 > > allow for an extreme amount of control which I believe will not be > implemented in many cases and where implemented will not be used. > > I think a much simple configuration model would be quite sufficient. > > The current drafts allow: > > MPLS OAM FMS sub-TLV > > =A0=A0=A0The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TL= V of > =A0=A0=A0the "OAM Configuration sub-TLV". > > =A0=A0=A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A01 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A02 =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A03 > =A0=A0=A0=A0=A0=A0=A0=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1 > =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+ > =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type (5) =A0(IANA) = =A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0Length =3D 12 =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0| > =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+ > =A0=A0=A0=A0=A0=A0=A0|A|D|L|C| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Reserv= ed =A0=A0(set all to 0s) =A0=A0=A0=A0=A0=A0=A0|E| PHB | > =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+ > =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0Refresh Timer =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| > =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+ > > =A0=A0=A0Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to > =A0=A0=A0define). > > =A0=A0=A0Length: indicates the TLV total length in octets. > > =A0=A0=A0Signal Flags: are used to enable the following signals: > > =A0=A0=A0=A0=A0=A0- A: Alarm Indication Signal (AIS) as described in [MPL= S-FMS] > > =A0=A0=A0=A0=A0=A0- D: Link Down Indication (LDI) as described in [MPLS-F= MS] > > =A0=A0=A0=A0=A0=A0- L: Locked Report (LKR) as described in [MPLS-FMS] > > =A0=A0=A0=A0=A0=A0- C: Client Signal Failure (CSF) as described in [MPLS-= CSF] > > =A0=A0=A0=A0=A0=A0- Remaining bits: Reserved for future specification and= set to 0. > > =A0=A0=A0Configuration Flags: > > =A0=A0=A0=A0=A0=A0- E: used to enable/disable explicitly clearing faults > > =A0=A0=A0=A0=A0=A0- PHB: identifies the per-hop behavior of packets with = fault > =A0=A0=A0=A0=A0=A0management information > > =A0=A0=A0Refresh Timer: indicates the refresh timer (in microseconds) of = fault > =A0=A0=A0indication messages. =A0If the edge LSR receiving the Path messa= ge can > =A0=A0=A0not support such value, it can reply back with a higher interval= . > > (As a preface to the following three paragraphs, it is not clear if > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. =A0=A0= There > are no procedures in the draft for sending and receiving these messages l= et > alone delivering them to midpoints). > > One of the keys to scaling is to keep midpoints simple. =A0I do not want = to be > running separate timers for every LSP that may need fault OAM. =A0I belie= ve > that operators will be quite happy to configure a single timer per node (= or > at most, per interface), and send all fault messages according to that > timer. =A0The same is true explicit clearing. =A0PHB, > > Midpoints will also set the LDI flag when applicable, so this bit does no= t > apply at midpoints. =A0The draft needs to say that the bit only applies t= o > whether a receiver should react to the LDI flag. > > I also cannot imagine an operator wanting to be informed of Alarms but no= t > Locks or vice versa. =A0So these two bits should be eliminated or it shou= ld be > made clear that they have no semantics at a midpoint. > > Alternatively, these configuration flags could be used on and end to end > basis to say that the receiver SHOULD treat AIS or LKR as a hard failure > (LOC). =A0(This applies to the LSP-PING draft even if it is only an end t= o end > draft.) > > Bottom line. > > The refresh timer should be removed. > The E flag should be removed. > PHB should either be removed or said to apply only to CSF. > The semantics of the D flag should be clarified to be only end-to-end. > The A and L flags should be either eliminated or given and end-to-end > semantic of LOC. > For RSVP at a midpoint, the presence of the FMS tlv should signal that Fa= ult > OAM messages are desired. > Procedures for sending and receiving LSP Ping messages with OAM config ne= ed > to be added and (non-)applicability at midpoints needs to be made clear. > > ...George > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From swallow@cisco.com Wed Aug 17 15:19:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0173521F8C55; Wed, 17 Aug 2011 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.943 X-Spam-Level: X-Spam-Status: No, score=-101.943 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAVMnccQpB3b; Wed, 17 Aug 2011 15:19:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D284C21F8C51; Wed, 17 Aug 2011 15:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=6265; q=dns/txt; s=iport; t=1313619601; x=1314829201; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=U1BT+WMUM6RrY2E1DzOIxbJR2hY5jv6pWyIuOym+uH4=; b=iUXK963l2S37LMmsmukjYAUlfUuzkw+bJCX/RMn8Qh6wBOCl4ibj/xjW XHPeimPF3lybFMdYPXpTq/cxeBmXqWhbGPSByOCv+q0Gtc3r4Na84v8GC QR/tE9v7zUI9EQ+br3+990/I3n2U4G8TsdrQOm6uxNiLjWQvHDLDqgRwF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEE9TE6tJXHB/2dsb2JhbAA6CKgEbneBQAEBAQECAQEBAQ8BKQEqBwsFDQEIGE8GMAEBBA4FIodOBJd6AZ8IgyqDHgSHMYtihRWEYYcb X-IronPort-AV: E=Sophos;i="4.68,241,1312156800"; d="scan'208";a="14120178" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 17 Aug 2011 22:20:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7HMK0U2026642; Wed, 17 Aug 2011 22:20:00 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 17:20:00 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Aug 2011 22:20:00 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 17 Aug 2011 18:19:58 -0400 From: George Swallow To: Greg Mirsky Message-ID: Thread-Topic: [CCAMP] Fault OAM configuration Thread-Index: AcxdK8xUWaQMoYzaTEeGQyt2fJFF+g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Aug 2011 22:20:00.0583 (UTC) FILETIME=[CDDF1D70:01CC5D2B] Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org, ccamp@ietf.org, draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext@tools.ietf.org Subject: Re: [mpls] [CCAMP] Fault OAM configuration X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 22:19:10 -0000 Greg - I'm an author of 4379. This draft needs to spell out what to do one way or the other. If the plan is to go hop by hop, then you have to trace to the end first to get the max TTL and then send the OAM config. Otherwise you cannot tell if you are at the end if you get a return code of (suggested value) 16. And I don't know what you do with that return code, since it is not clear how the unsupported OAM function is identified. ...George On 8/17/11 4:16 PM, "Greg Mirsky" wrote: > Dear George, > you've asked: > (As a preface to the following three paragraphs, it is not clear if > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. > There are no procedures in the draft for sending and receiving these > messages let alone delivering them to midpoints). > I'm not an author and can only assume that defined in RFC 4379 > traceroute procedure will be used to signal to MIP, i.e. controlling > MSE's TTL. >=20 > Regards, > Greg >=20 > On Wed, Aug 17, 2011 at 11:59 AM, George Swallow wrot= e: >> The current drafts on Fault OAM configurations, >>=20 >> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and >> draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06 >>=20 >> allow for an extreme amount of control which I believe will not be >> implemented in many cases and where implemented will not be used. >>=20 >> I think a much simple configuration model would be quite sufficient. >>=20 >> The current drafts allow: >>=20 >> MPLS OAM FMS sub-TLV >>=20 >> =A0=A0=A0The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TLV of >> =A0=A0=A0the "OAM Configuration sub-TLV". >>=20 >> =A0=A0=A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A01 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A02 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A03 >> =A0=A0=A0=A0=A0=A0=A0=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type (5) =A0(IANA) =A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0Length =3D 12 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| >> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> =A0=A0=A0=A0=A0=A0=A0|A|D|L|C| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Reserved =A0=A0(set all to 0s) =A0=A0=A0=A0=A0=A0=A0|E| PHB | >> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Refresh Timer =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| >> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> =A0=A0=A0Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to >> =A0=A0=A0define). >>=20 >> =A0=A0=A0Length: indicates the TLV total length in octets. >>=20 >> =A0=A0=A0Signal Flags: are used to enable the following signals: >>=20 >> =A0=A0=A0=A0=A0=A0- A: Alarm Indication Signal (AIS) as described in [MPLS-FMS] >>=20 >> =A0=A0=A0=A0=A0=A0- D: Link Down Indication (LDI) as described in [MPLS-FMS] >>=20 >> =A0=A0=A0=A0=A0=A0- L: Locked Report (LKR) as described in [MPLS-FMS] >>=20 >> =A0=A0=A0=A0=A0=A0- C: Client Signal Failure (CSF) as described in [MPLS-CSF] >>=20 >> =A0=A0=A0=A0=A0=A0- Remaining bits: Reserved for future specification and set to 0. >>=20 >> =A0=A0=A0Configuration Flags: >>=20 >> =A0=A0=A0=A0=A0=A0- E: used to enable/disable explicitly clearing faults >>=20 >> =A0=A0=A0=A0=A0=A0- PHB: identifies the per-hop behavior of packets with fault >> =A0=A0=A0=A0=A0=A0management information >>=20 >> =A0=A0=A0Refresh Timer: indicates the refresh timer (in microseconds) of fault >> =A0=A0=A0indication messages. =A0If the edge LSR receiving the Path message can >> =A0=A0=A0not support such value, it can reply back with a higher interval. >>=20 >> (As a preface to the following three paragraphs, it is not clear if >> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. =A0=A0The= re >> are no procedures in the draft for sending and receiving these messages = let >> alone delivering them to midpoints). >>=20 >> One of the keys to scaling is to keep midpoints simple. =A0I do not want t= o be >> running separate timers for every LSP that may need fault OAM. =A0I believ= e >> that operators will be quite happy to configure a single timer per node = (or >> at most, per interface), and send all fault messages according to that >> timer. =A0The same is true explicit clearing. =A0PHB, >>=20 >> Midpoints will also set the LDI flag when applicable, so this bit does n= ot >> apply at midpoints. =A0The draft needs to say that the bit only applies to >> whether a receiver should react to the LDI flag. >>=20 >> I also cannot imagine an operator wanting to be informed of Alarms but n= ot >> Locks or vice versa. =A0So these two bits should be eliminated or it shoul= d be >> made clear that they have no semantics at a midpoint. >>=20 >> Alternatively, these configuration flags could be used on and end to end >> basis to say that the receiver SHOULD treat AIS or LKR as a hard failure >> (LOC). =A0(This applies to the LSP-PING draft even if it is only an end to= end >> draft.) >>=20 >> Bottom line. >>=20 >> The refresh timer should be removed. >> The E flag should be removed. >> PHB should either be removed or said to apply only to CSF. >> The semantics of the D flag should be clarified to be only end-to-end. >> The A and L flags should be either eliminated or given and end-to-end >> semantic of LOC. >> For RSVP at a midpoint, the presence of the FMS tlv should signal that F= ault >> OAM messages are desired. >> Procedures for sending and receiving LSP Ping messages with OAM config n= eed >> to be added and (non-)applicability at midpoints needs to be made clear. >>=20 >> ...George >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 From gregimirsky@gmail.com Wed Aug 17 18:40:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98D121F8B26; Wed, 17 Aug 2011 18:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJNRPLis3LYe; Wed, 17 Aug 2011 18:40:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01521F8B24; Wed, 17 Aug 2011 18:40:57 -0700 (PDT) Received: by vws12 with SMTP id 12so1404391vws.31 for ; Wed, 17 Aug 2011 18:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3CLMfzwt8vZA5gUr7YJcZxVcZSrdz90re4KdDfwfNxA=; b=vk1b+J+da6OnXJiWCJt9439+ivjMJ8QfGPEsfMPXuCbDC/f68jne7a0F90K6ZDDD6y vG+U+55G0QZ2MPrkKKANZUjzQMU3JEIFpx9OXDQyGFGf3iUbkmy2snwvwwvVLut8Oje4 nwr2HdFdmddVhSPfiscNeAfgMx4ehoSj9vhtc= MIME-Version: 1.0 Received: by 10.52.98.98 with SMTP id eh2mr129418vdb.291.1313631709987; Wed, 17 Aug 2011 18:41:49 -0700 (PDT) Received: by 10.52.167.229 with HTTP; Wed, 17 Aug 2011 18:41:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Aug 2011 18:41:49 -0700 Message-ID: From: Greg Mirsky To: George Swallow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org, ccamp@ietf.org, draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext@tools.ietf.org Subject: Re: [mpls] [CCAMP] Fault OAM configuration X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 01:40:58 -0000 Dear George, I'm not sure that there's only one way to slice the proverbial bread in this case to put it in as standard. I think that one can implement by following your suggestion (probe connection first, then distribute OAM configuration). Or OAM configuration TLV can be combined with DSMAP TLV in order to detect the end of a connection. Regards, Greg On Wed, Aug 17, 2011 at 3:19 PM, George Swallow wrote: > Greg - > > I'm an author of 4379. =A0This draft needs to spell out what to do one wa= y or > the other. =A0If the plan is to go hop by hop, then you have to trace to = the > end first to get the max TTL and then send the OAM config. =A0Otherwise y= ou > cannot tell if you are at the end if you get a return code of (suggested > value) 16. > > And I don't know what you do with that return code, since it is not clear > how the unsupported OAM function is identified. > > ...George > > > On 8/17/11 4:16 PM, "Greg Mirsky" wrote: > >> Dear George, >> you've asked: >> (As a preface to the following three paragraphs, it is not clear if >> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. >> There are no procedures in the draft for sending and receiving these >> messages let alone delivering them to midpoints). >> I'm not an author and can only assume that defined in RFC 4379 >> traceroute procedure will be used to signal to MIP, i.e. controlling >> MSE's TTL. >> >> Regards, >> Greg >> >> On Wed, Aug 17, 2011 at 11:59 AM, George Swallow wro= te: >>> The current drafts on Fault OAM configurations, >>> >>> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and >>> draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06 >>> >>> allow for an extreme amount of control which I believe will not be >>> implemented in many cases and where implemented will not be used. >>> >>> I think a much simple configuration model would be quite sufficient. >>> >>> The current drafts allow: >>> >>> MPLS OAM FMS sub-TLV >>> >>> =A0=A0=A0The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-= TLV of >>> =A0=A0=A0the "OAM Configuration sub-TLV". >>> >>> =A0=A0=A0=A0=A0=A0=A0=A00 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A01 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A02 =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A03 >>> =A0=A0=A0=A0=A0=A0=A0=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1 >>> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ >>> =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type (5) =A0(IANA)= =A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0Length =3D 12 =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0| >>> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ >>> =A0=A0=A0=A0=A0=A0=A0|A|D|L|C| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Rese= rved =A0=A0(set all to 0s) =A0=A0=A0=A0=A0=A0=A0|E| PHB | >>> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ >>> =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0Refresh Timer =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0=A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ >>> >>> =A0=A0=A0Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA t= o >>> =A0=A0=A0define). >>> >>> =A0=A0=A0Length: indicates the TLV total length in octets. >>> >>> =A0=A0=A0Signal Flags: are used to enable the following signals: >>> >>> =A0=A0=A0=A0=A0=A0- A: Alarm Indication Signal (AIS) as described in [M= PLS-FMS] >>> >>> =A0=A0=A0=A0=A0=A0- D: Link Down Indication (LDI) as described in [MPLS= -FMS] >>> >>> =A0=A0=A0=A0=A0=A0- L: Locked Report (LKR) as described in [MPLS-FMS] >>> >>> =A0=A0=A0=A0=A0=A0- C: Client Signal Failure (CSF) as described in [MPL= S-CSF] >>> >>> =A0=A0=A0=A0=A0=A0- Remaining bits: Reserved for future specification a= nd set to 0. >>> >>> =A0=A0=A0Configuration Flags: >>> >>> =A0=A0=A0=A0=A0=A0- E: used to enable/disable explicitly clearing fault= s >>> >>> =A0=A0=A0=A0=A0=A0- PHB: identifies the per-hop behavior of packets wit= h fault >>> =A0=A0=A0=A0=A0=A0management information >>> >>> =A0=A0=A0Refresh Timer: indicates the refresh timer (in microseconds) o= f fault >>> =A0=A0=A0indication messages. =A0If the edge LSR receiving the Path mes= sage can >>> =A0=A0=A0not support such value, it can reply back with a higher interv= al. >>> >>> (As a preface to the following three paragraphs, it is not clear if >>> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. =A0= =A0There >>> are no procedures in the draft for sending and receiving these messages= let >>> alone delivering them to midpoints). >>> >>> One of the keys to scaling is to keep midpoints simple. =A0I do not wan= t to be >>> running separate timers for every LSP that may need fault OAM. =A0I bel= ieve >>> that operators will be quite happy to configure a single timer per node= (or >>> at most, per interface), and send all fault messages according to that >>> timer. =A0The same is true explicit clearing. =A0PHB, >>> >>> Midpoints will also set the LDI flag when applicable, so this bit does = not >>> apply at midpoints. =A0The draft needs to say that the bit only applies= to >>> whether a receiver should react to the LDI flag. >>> >>> I also cannot imagine an operator wanting to be informed of Alarms but = not >>> Locks or vice versa. =A0So these two bits should be eliminated or it sh= ould be >>> made clear that they have no semantics at a midpoint. >>> >>> Alternatively, these configuration flags could be used on and end to en= d >>> basis to say that the receiver SHOULD treat AIS or LKR as a hard failur= e >>> (LOC). =A0(This applies to the LSP-PING draft even if it is only an end= to end >>> draft.) >>> >>> Bottom line. >>> >>> The refresh timer should be removed. >>> The E flag should be removed. >>> PHB should either be removed or said to apply only to CSF. >>> The semantics of the D flag should be clarified to be only end-to-end. >>> The A and L flags should be either eliminated or given and end-to-end >>> semantic of LOC. >>> For RSVP at a midpoint, the presence of the FMS tlv should signal that = Fault >>> OAM messages are desired. >>> Procedures for sending and receiving LSP Ping messages with OAM config = need >>> to be added and (non-)applicability at midpoints needs to be made clear= . >>> >>> ...George >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> > > From gregimirsky@gmail.com Wed Aug 17 19:40:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D3221F85A1; Wed, 17 Aug 2011 19:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQdc5eX0ELIm; Wed, 17 Aug 2011 19:40:10 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBF2521F8581; Wed, 17 Aug 2011 19:40:09 -0700 (PDT) Received: by vxi29 with SMTP id 29so1685572vxi.31 for ; Wed, 17 Aug 2011 19:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NQFPDZpyO+gnIX1agm181eoqzhsM8PhV9f5UEOFwmQw=; b=tF8L7EeFyA+iTkqSvEmMsWZW9B5ByGmHRrT8nDOpLQJHw7oueBOYvcNVRrgZoNrNPx jThk7grhDsWg/dPnQ36N25UxPSn94/CZ5D9eY4AO/e/DFii/j/gs++qjRRCZ1jeDinrN 1tRqjq7iQxanExgkv1IwKTK7nFNxZ6LiNCB7o= MIME-Version: 1.0 Received: by 10.52.66.15 with SMTP id b15mr150128vdt.425.1313635260234; Wed, 17 Aug 2011 19:41:00 -0700 (PDT) Received: by 10.52.167.229 with HTTP; Wed, 17 Aug 2011 19:41:00 -0700 (PDT) In-Reply-To: <4E4C0F3F.8010700@cisco.com> References: <4E4C0F3F.8010700@cisco.com> Date: Wed, 17 Aug 2011 19:41:00 -0700 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 02:40:11 -0000 Dear Luca, I'm thinking of other ways of wording, interpreting your formula. Can it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? Regards, Greg On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrote: > The solution is quite simple: > > "Flow Labels MUST not be used in an MPLS-TP environment." > > Luca > > > > > > On 08/16/11 21:46, Alexander Vainshtein wrote: >> Pablo, >> Sorry, but I think you're wrong. Only T-PE can insert the flow label >> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on >> PW label. >> >> Regards, >> =A0 =A0 =A0Sasha >> >> ------------------------------------------------------------------------ >> *From:* Pablo Frank [pabloisnot@gmail.com] >> *Sent:* Wednesday, August 17, 2011 12:17 AM >> *To:* Alexander Vainshtein >> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-p= w >> >> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >> domain in the middle segment, you're no longer in an MPLS-TP >> environment and so the GAL is not required to be BOS. =A0During that >> middle segment, the PW flow label would be placed below the GAL and >> above the GACh. =A0It gets removed when it hits the S-PE that switches >> you back into the MPLS-TP environment. =A0In other words, whether you're >> in an MPLS-TP environment is determined segment by segment in a MS-PW. >> >> Pablo >> >> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >> > > wrote: >> >> =A0 =A0 Hi all, >> =A0 =A0 After having sent out my comments I've noticed that the specific >> =A0 =A0 example to illustrate the need to combine GAL and "flow label" w= as >> =A0 =A0 inaccurate. >> >> =A0 =A0 A more relevant example would look like following (I do not >> =A0 =A0 include a diagram, but it can be easily provided if necessary) >> >> =A0 =A0 =A01. A MS-PW: >> =A0 =A0 =A0 =A0 =A0 * Starts at an S-PE that resides at the edge of an M= PLS-TP >> =A0 =A0 =A0 =A0 =A0 =A0 domain (no ECMP) >> =A0 =A0 =A0 =A0 =A0 * Crosses this domain and enters an IP/MPLS domain w= ith ECMP >> =A0 =A0 =A0 =A0 =A0 =A0 enabled using a T-PE that resides at the age of = these two >> =A0 =A0 =A0 =A0 =A0 =A0 domains >> =A0 =A0 =A0 =A0 =A0 * Leaves this domain and enters a 2nd MPLS-TP domain= (using >> =A0 =A0 =A0 =A0 =A0 =A0 the 2nd T-PE) >> =A0 =A0 =A0 =A0 =A0 * Terminates on another S-PE at the edge of the 2nd = MPLS-TP >> =A0 =A0 =A0 =A0 =A0 =A0 domain >> =A0 =A0 =A02. The operator intends to improve traffic distribution in th= e >> =A0 =A0 =A0 =A0 IP/MPLS domain, hence he enables insertion and discard o= f >> =A0 =A0 =A0 =A0 "flow labels" at the two S-PEs. Note that: >> =A0 =A0 =A0 =A0 =A0 * This does not violate the MPLS-TP restriction on E= CMP: >> =A0 =A0 =A0 =A0 =A0 =A0 ECMP does not happen in he MPLS-TP domains >> =A0 =A0 =A0 =A0 =A0 * T-PEs do not even have to be aware of flow labels >> =A0 =A0 =A03. The operator also intends to operate some end-to-end OAM f= or >> =A0 =A0 =A0 =A0 this MS-PW using "GAL-in-PW". This results in a conflict= since >> =A0 =A0 =A0 =A0 both GAL and "flow label" are defined (in the correspond= ing >> =A0 =A0 =A0 =A0 drafts) as bottom of stack. >> >> >> >> =A0 =A0 IMHO this describes a realistic scenario where the two drafts ar= e >> =A0 =A0 in controversy. >> >> =A0 =A0 Regards, >> =A0 =A0 =A0 =A0 =A0Sasha >> =A0 =A0 ----------------------------------------------------------------= -------- >> =A0 =A0 *From:* mpls-bounces@ietf.org >> =A0 =A0 [mpls-bounces@ietf.org ] On Behalf >> =A0 =A0 Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >> =A0 =A0 ] >> =A0 =A0 *Sent:* Tuesday, August 16, 2011 4:26 PM >> =A0 =A0 *To:* ietf@ietf.org >> =A0 =A0 *Cc:* mpls@ietf.org ; Vladimir Kleiner; Id= an >> =A0 =A0 Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohe= n >> =A0 =A0 *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-= in-pw >> >> =A0 =A0 Hi all, >> >> >> >> =A0 =A0 I would like to raise the following issue with regard to >> =A0 =A0 draft-ietf-pwe3-gal-in-pw >> =A0 =A0 : >> =A0 =A0 controversy vs. draft-ietf-pwe3-fat-pw >> =A0 =A0 >> =A0 =A0 with regard to bottom-of-stack position. >> >> >> >> =A0 =A0 As stated in the Introduction, this draft removes the restrictio= n >> =A0 =A0 imposed by RFC 5586 on usage of Generic Associated Channel Label >> =A0 =A0 (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 sta= tes: >> >> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs= , >> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MUST NOT b= e >> =A0 =A0 used with PWs. =A0It MUST always be at the bottom of the label s= tack >> =A0 =A0 =A0 =A0(i.e., S bit set to 1). >> >> >> >> =A0 =A0 draft-ietf-pwe3-gal-in-pw proposed to replace the original text = in >> =A0 =A0 RFC 5586 with the following >> >> >> >> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs= , >> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MAY be use= d >> =A0 =A0 with PWs. It MUST always be at the bottom of the label stack >> =A0 =A0 (i.e., S bit set to 1). >> >> >> >> =A0 =A0 I.e., =A0while removing this restriction of 5586, it does not mo= dify >> =A0 =A0 its requirement for the GAL being always at the bottom of the >> =A0 =A0 label stack. >> >> >> >> =A0 =A0 At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >> =A0 =A0 review) reserves the bottom of the PW stack for the PW flow >> =A0 =A0 labels, e.g., in Section 1.1: >> >> >> >> =A0 =A0 This document describes a method of adding an additional label >> =A0 =A0 stack entry (LSE) at the bottom of stack in order to facilitate >> =A0 =A0 the load balancing of the flows within a PW over the available >> =A0 =A0 ECMPs. >> >> >> >> =A0 =A0 One could argue that draft-ietf-pwe3-gal-in-pw only applies to >> =A0 =A0 MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO an= d >> =A0 =A0 FWIW, >> >> =A0 =A0 such an argument, were it presented, would be highly problematic= , >> =A0 =A0 because: >> >> >> >> =A0 =A0 1. =A0 =A0 =A0 RFC 5960 (which defines the MPLS-TP data plane) d= id not >> =A0 =A0 define any differences between the PW data plane in IP/MPLS and >> =A0 =A0 MPLS-TP. >> >> =A0 =A0 2. =A0 =A0 =A0 One of the most popular scenarios for using multi= -segment >> =A0 =A0 pseudowires is the case when an edge-to-edge service emulation >> =A0 =A0 crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios= , >> =A0 =A0 the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-awa= re >> =A0 =A0 T-PE at the edge of an IP/MPLS domain) would potentially compete >> =A0 =A0 with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >> =A0 =A0 e.g., for relying a PW status message that it has received over = a >> =A0 =A0 Targeted LDP session from the IP/MPLS domain to a static PW stat= us >> =A0 =A0 message to cross the MPLS-TP domain) for the bottom-of-stack >> =A0 =A0 position. >> >> >> >> =A0 =A0 The issue I am raising Is not new. It has been actively discusse= d >> =A0 =A0 on the PWE3 mailing list with regard to adoption of >> =A0 =A0 draft-nadeau-pwe3-vccv-2 as a WG document, with arguments =A0for >> =A0 =A0 both the flow label and GAL taking the bottom-of-the-stack >> =A0 =A0 position. But, to the best of my understanding, consensus on thi= s >> =A0 =A0 issue has not been reached. >> >> >> >> =A0 =A0 Hopefully this comment will be useful. >> >> >> >> =A0 =A0 Regards, >> >> =A0 =A0 =A0 =A0 =A0Sasha >> >> >> >> =A0 =A0 This e-mail message is intended for the recipient only and >> =A0 =A0 contains information which is CONFIDENTIAL and which may be >> =A0 =A0 proprietary to ECI Telecom. If you have received this transmissi= on >> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >> =A0 =A0 delete the original and all copies thereof. >> >> =A0 =A0 This e-mail message is intended for the recipient only and >> =A0 =A0 contains information which is CONFIDENTIAL and which may be >> =A0 =A0 proprietary to ECI Telecom. If you have received this transmissi= on >> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >> =A0 =A0 delete the original and all copies thereof. >> >> >> =A0 =A0 _______________________________________________ >> =A0 =A0 pwe3 mailing list >> =A0 =A0 pwe3@ietf.org >> =A0 =A0 https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From internet-drafts@ietf.org Wed Aug 17 20:38:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485C711E8098; Wed, 17 Aug 2011 20:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBQwbhhffU7K; Wed, 17 Aug 2011 20:38:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F0B11E8080; Wed, 17 Aug 2011 20:38:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110818033805.14258.22098.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2011 20:38:05 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 03:38:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Non Penultimate Hop Popping Behavior and out-of-band map= ping for RSVP-TE Label Switched Paths Author(s) : Zafar Ali George Swallow Rahul Aggarwal Filename : draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt Pages : 11 Date : 2011-08-17 There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to- point (P2P) and point-to-multipoint (P2MP) LSPs. = A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-no-php-oob-mapp= ing-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-no-php-oob-mappi= ng-09.txt From Alexander.Vainshtein@ecitele.com Wed Aug 17 21:51:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C46A5E8002 for ; Wed, 17 Aug 2011 21:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=1.156, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJXv8CMk-FBL for ; Wed, 17 Aug 2011 21:51:40 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id C83315E8004 for ; Wed, 17 Aug 2011 21:51:39 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1313643122!34996405!3 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 6523 invoked from network); 18 Aug 2011 04:52:13 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-6.tower-21.messagelabs.com with SMTP; 18 Aug 2011 04:52:13 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-ae-4e4c93c6d087 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 05.71.16719.6C39C4E4; Thu, 18 Aug 2011 07:23:35 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 18 Aug 2011 07:52:27 +0300 From: Alexander Vainshtein To: Luca Martini Date: Thu, 18 Aug 2011 07:52:19 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdD9cSGREkAFVzQWqJ2mkm3HQMwQATb/YR Message-ID: References: , , <4E4C0F3F.8010700@cisco.com> In-Reply-To: <4E4C0F3F.8010700@cisco.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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTf2wMWRy/NzO7O12dy7NV+7pB5saPpGrZKjLCivQfK9oqFeQSrbH7bnfY nVk7U7EIzUkIEkqpdJH6US31K3qSotxRqWodLjmSqtY/mlaXiNSPUrRmzOn1cu+vz3ufz+f7 ee/l+6VJW7/ZQYuSiiOSEOTMVqok3vPWeackK8dVfS2V77xYTvFdbV8sfOvJ0yb+4ItGM7+7 5xI11+TZ/+miyXMl1m7xVFR8JHLJn4vAbEGSZFVQMevDitfN5UbEdYI3yrGiz82lc2w4KHhx CEuqmxPCYSz5uDlW9n9rtiYTJRZLXtknSn43Nz9voZPnp890pnNzJoxNz5hlXRIQFRY7Q4IY ZENYUQQ/ZrWTlZfIQM+dYkv4+LL1R473morA48ydIIFGcBr6o/OeycAj0V9PL5h3Aittg3UA 1TZ8tBibUoAa2+NAV5mhG9WcaTfreAQcj87f+gR0EQn7CdS59W9CJyiNKK16adFxEpyH9lSe AobBg8pONFkMPBWVHDpH6piBi9C76gOUjm3wNoFeN2TrOAGmoru3Gr9pgHa93uaz3+qT0I5a O8oJ49oQVVx7QBo4GXU/6zcZ+mTUtv0CMPST0NG6HrOB01DlsRf/5A5HTWUdlOFNQTdPtVDF wB4bEhEbYo8NsceG2I8CqhqkiMGwuirkd011yoXqZOwVVRzEk71yqAYY3fP8MnjyZ2o9gDTg EpmWrgU5NpOwTomG6kEKTXDJTG9ZVo7tx1WyLxoQlEBBpDCIlXqAaJIbwWxjNY7xCdENOCJ/ p3jtp/eSjmFeWetTSS3IcLn+s+HszC7vy2wb9GuttwbjMI58t46iaQ4x1/XE4RHsx+t/EYPq vzRBJ+jJiVryDV3DKGEhpIh+g28GTnpHx93bwEZJsoQddgbGNBHURYFCabCOPjZbBgYG4sCu vTmJ6dNLJWpDNVgproUQWkjrVY8eoo3IIOUoAqdrPxfk5f20MWNf4Per3bubnvQvG7O8qvic u/T66vtvZvje/rDixqGmV/aRBx5louxMf/6DrDF1v1XGub4Vexf35eZvTmLH5U8c3bLlsZWo +bV1XHPt8ykQPnRE1276kGbnq13lKxvb9ueljeoeu2epq2JRsmOKueFwF6HIhVU13e/zOUoJ COkTyYgifAVO/Ut1EQQAAA== Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 04:51:41 -0000 Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3-fat-pw-06.= Instead, it contans the following text in Section 8.5 " Applicability to MP= LS-TP": The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity re= quirements specified in the SLA can be satisfied. (In the -07 version this text is repeated but followed by an incomplete stat= ement " In a" immediately followed by the heading of Section 8.6. Since this= addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP= environments is conditional on meeting specific SLA requirements for the se= rvice. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf-pwe3-fat-= pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain= would be perfectly safe if ECMP (i.e., hashing of the label stack and takin= g one of multiple NHLFEs for the given incoming label in the ILM) were not u= sed in this domain, e.g., by associating exactly one ILM entry with each inc= oming label in the ILM. And since MPLS-TP is supposed to carry not just PW c= lients but also IP ones, I would expect that this would be the case in any M= PLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the exp= ense of making another, conditional one (on usage of flow labels in MPLS-TP= environments) absolute is not the most appropriate method for resolving tec= hnical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a pa= cket then G-ACh header MUST be present immediately after the bottom of the l= abel stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discuss= ion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to univers= al usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha ____________________________________ From: Luca Martini [lmartini@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM To: Alexander Vainshtein Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit= ; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw The solution is quite simple: "Flow Labels MUST not be used in an MPLS-TP environment." Luca On 08/16/11 21:46, Alexander Vainshtein wrote: > Pablo, > Sorry, but I think you're wrong. Only T-PE can insert the flow label > (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on > PW label. > > Regards, > Sasha > > ------------------------------------------------------------------------ > *From:* Pablo Frank [pabloisnot@gmail.com] > *Sent:* Wednesday, August 17, 2011 12:17 AM > *To:* Alexander Vainshtein > *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS > domain in the middle segment, you're no longer in an MPLS-TP > environment and so the GAL is not required to be BOS. During that > middle segment, the PW flow label would be placed below the GAL and > above the GACh. It gets removed when it hits the S-PE that switches > you back into the MPLS-TP environment. In other words, whether you're > in an MPLS-TP environment is determined segment by segment in a MS-PW. > > Pablo > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > > wrote: > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > A more relevant example would look like following (I do not > include a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two > domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP > domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of > "flow labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: > ECMP does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since > both GAL and "flow label" are defined (in the corresponding > drafts) as bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are > in controversy. > > Regards, > Sasha > ----------------------------------------------------------------------= -- > *From:* mpls-bounces@ietf.org > [mpls-bounces@ietf.org ] On Behalf > Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > ] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi all, > > > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw > : > controversy vs. draft-ietf-pwe3-fat-pw > > with regard to bottom-of-stack position. > > > > As stated in the Introduction, this draft removes the restriction > imposed by RFC 5586 on usage of Generic Associated Channel Label > (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be > used with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in > RFC 5586 with the following > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used > with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > I.e., while removing this restriction of 5586, it does not modify > its requirement for the GAL being always at the bottom of the > label stack. > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > review) reserves the bottom of the PW stack for the PW flow > labels, e.g., in Section 1.1: > > > > This document describes a method of adding an additional label > stack entry (LSE) at the bottom of stack in order to facilitate > the load balancing of the flows within a PW over the available > ECMPs. > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to > MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and > FWIW, > > such an argument, were it presented, would be highly problematic, > because: > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not > define any differences between the PW data plane in IP/MPLS and > MPLS-TP. > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation > crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, > the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware > T-PE at the edge of an IP/MPLS domain) would potentially compete > with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > e.g., for relying a PW status message that it has received over a > Targeted LDP session from the IP/MPLS domain to a static PW status > message to cross the MPLS-TP domain) for the bottom-of-stack > position. > > > > The issue I am raising Is not new. It has been actively discussed > on the PWE3 mailing list with regard to adoption of > draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > both the flow label and GAL taking the bottom-of-the-stack > position. But, to the best of my understanding, consensus on this > issue has not been reached. > > > > Hopefully this comment will be useful. > > > > Regards, > > Sasha > > > > This e-mail message is intended for the recipient only and > contains information which is CONFIDENTIAL and which may be > proprietary to ECI Telecom. If you have received this transmission > in error, please inform us by e-mail, phone or fax, and then > delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and > contains information which is CONFIDENTIAL and which may be > proprietary to ECI Telecom. If you have received this transmission > in error, please inform us by e-mail, phone or fax, and then > delete the original and all copies thereof. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and > all copies thereof. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Wed Aug 17 22:10:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D3A11E808A for ; Wed, 17 Aug 2011 22:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyWgIcPdg9RG for ; Wed, 17 Aug 2011 22:10:48 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id D016C21F85B8 for ; Wed, 17 Aug 2011 22:10:47 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1313644298!28317763!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 27222 invoked from network); 18 Aug 2011 05:11:38 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-7.tower-174.messagelabs.com with SMTP; 18 Aug 2011 05:11:38 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-93-4e4c9844a0e9 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 4C.B1.16719.4489C4E4; Thu, 18 Aug 2011 07:42:44 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 18 Aug 2011 08:11:37 +0300 From: Alexander Vainshtein To: Greg Mirsky Date: Thu, 18 Aug 2011 08:11:36 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdUEbUL4P0Pmq6TLKJzbICnDH3tAAE7vYH Message-ID: References: <4E4C0F3F.8010700@cisco.com>, In-Reply-To: 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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTW0zTUBj2rN0oSLUMcQfipanxbs1A0KkMkfgAXtgU44M+aNmOW+PWLWtB ZkwkGjXiBRU1Mm9oJvEWUeMFQaOSqBE0Eh8UETXRqYC3hBhhCM6WKmLs09f/+77/O+fk/wlM 36lLInhBQj6BczG6GLysveMbO+/gwlxjpCXe9P3AO63pQ0tvlKn55GmtaVfHZTwTz97346I2 +3rgZVR2MBjWWLHlxSCdEwSPxEmItiPRZmasPr6Qs/kZmrebmWSG9ro4G3IjQTIznNeLBDuT EUP/96XLMl6gkWDz2HnBYWZy8iysyZQ2k01mMsaNSZ42O2apkxdpxLo53kW7kShyDkTLlVWX MWfnrUxviaWo5XgEFIO76SUgmoBUKtz16SOu4uGw8VWVrgTEEHqqFsBwzxGdQuipAwB23UYK 1lFmeOnsy776MGo83Hb1fpRiwKhmDXxb06otAQSBU2Nhfe86RRNPWWFj5Satql8MNze8ASpO geHX5X19SLl+ofoZUIN3YLB7Z0ijENEyUdZ9L0rBQD5dZ/25vjpGGWBz6JhGPTUFgzceYypO gG1vf2pVfQJs2VoFVP0UWFHboVPxZFh5/COmBsfBB+Wh37dPhHdONeG7gSEwICIwwB4YYA8M sFcA/AxI5F1eKd/tMKawngJpKrLxEnKhqTaP+xJQx6a1Grx4OLEOUARgYsmmDwty9VquUPS7 60AioWESyM7yhbn6Ifkeu9/Jic6VvgIXEusAJDBmGLmFljnSzvnXIZ/nD2WSX3oPljTY5pEH VJBWTjMa//lhDOR226dFesohD94ahLzI98c6giAYSEpH5a5xPuRARat5l/SX1hDRSnKsnOxV NKTo5dwi71D5esAS20IN94AeFzwCSjKQOYqIUkTOAqG/j7IvGyKRSDswyHeOJ9MUVay8Tf2d 2uUQjRzSXJOthMgL0k8lFYPCUY0T2/ZXzCHqV52xZt3K0+1YciP+fnjvvtFj77ITUFxTxbMT S3U901OeWhqsTVk7r8ztyqwJbrgwK78uL/weG2Q5/KgazbcEx38lfLW97Iy1PVW53RsRwadO KTVOWp8jLbj2vPx8hv9J1tAvn1/NZENPRiZSN0szDomZy6wrcioZXHRyyZMwn8j9AsvwxAkK BAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 05:10:49 -0000 Dear Greg, I am afraid that your wording would be effectively equivalent to "MPLS-TP SH= OULD NOT be used outside of "walled garden" scenarios. Today the core networks are IP/MPLS and use ECMP at different levels while M= PLS-TP deployments are seem by many as mainly happening in the access/aggreg= ation/metro. If you do not allow an MS-PW to start in the MPLS-TP domain (ac= cess/metro), to cross an IP/MPLS core and then to terminate, say, in another= MPLS-TP domain (access/core), applicability of MPLS-TP would be IMHO greatl= y reduced. Please note also that there is also a draft proposing using of ECMP for both= MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). Regards, Sasha ________________________________________ From: Greg Mirsky [gregimirsky@gmail.com] Sent: Thursday, August 18, 2011 5:41 AM To: Luca Martini Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw Dear Luca, I'm thinking of other ways of wording, interpreting your formula. Can it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? Regards, Greg On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrote: > The solution is quite simple: > > "Flow Labels MUST not be used in an MPLS-TP environment." > > Luca > > > > > > On 08/16/11 21:46, Alexander Vainshtein wrote: >> Pablo, >> Sorry, but I think you're wrong. Only T-PE can insert the flow label >> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on >> PW label. >> >> Regards, >> Sasha >> >> ------------------------------------------------------------------------ >> *From:* Pablo Frank [pabloisnot@gmail.com] >> *Sent:* Wednesday, August 17, 2011 12:17 AM >> *To:* Alexander Vainshtein >> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw >> >> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >> domain in the middle segment, you're no longer in an MPLS-TP >> environment and so the GAL is not required to be BOS. During that >> middle segment, the PW flow label would be placed below the GAL and >> above the GACh. It gets removed when it hits the S-PE that switches >> you back into the MPLS-TP environment. In other words, whether you're >> in an MPLS-TP environment is determined segment by segment in a MS-PW. >> >> Pablo >> >> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >> > > wrote: >> >> Hi all, >> After having sent out my comments I've noticed that the specific >> example to illustrate the need to combine GAL and "flow label" was >> inaccurate. >> >> A more relevant example would look like following (I do not >> include a diagram, but it can be easily provided if necessary) >> >> 1. A MS-PW: >> * Starts at an S-PE that resides at the edge of an MPLS-TP >> domain (no ECMP) >> * Crosses this domain and enters an IP/MPLS domain with ECMP >> enabled using a T-PE that resides at the age of these two >> domains >> * Leaves this domain and enters a 2nd MPLS-TP domain (using >> the 2nd T-PE) >> * Terminates on another S-PE at the edge of the 2nd MPLS-TP >> domain >> 2. The operator intends to improve traffic distribution in the >> IP/MPLS domain, hence he enables insertion and discard of >> "flow labels" at the two S-PEs. Note that: >> * This does not violate the MPLS-TP restriction on ECMP: >> ECMP does not happen in he MPLS-TP domains >> * T-PEs do not even have to be aware of flow labels >> 3. The operator also intends to operate some end-to-end OAM for >> this MS-PW using "GAL-in-PW". This results in a conflict since >> both GAL and "flow label" are defined (in the corresponding >> drafts) as bottom of stack. >> >> >> >> IMHO this describes a realistic scenario where the two drafts are >> in controversy. >> >> Regards, >> Sasha >> ---------------------------------------------------------------------= --- >> *From:* mpls-bounces@ietf.org >> [mpls-bounces@ietf.org ] On Behalf >> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >> ] >> *Sent:* Tuesday, August 16, 2011 4:26 PM >> *To:* ietf@ietf.org >> *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan >> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw >> >> Hi all, >> >> >> >> I would like to raise the following issue with regard to >> draft-ietf-pwe3-gal-in-pw >> : >> controversy vs. draft-ietf-pwe3-fat-pw >> >> with regard to bottom-of-stack position. >> >> >> >> As stated in the Introduction, this draft removes the restriction >> imposed by RFC 5586 on usage of Generic Associated Channel Label >> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: >> >> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, >> Concatenated Segments of LSPs, and with Sections, and MUST NOT be >> used with PWs. It MUST always be at the bottom of the label stack >> (i.e., S bit set to 1). >> >> >> >> draft-ietf-pwe3-gal-in-pw proposed to replace the original text in >> RFC 5586 with the following >> >> >> >> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, >> Concatenated Segments of LSPs, and with Sections, and MAY be used >> with PWs. It MUST always be at the bottom of the label stack >> (i.e., S bit set to 1). >> >> >> >> I.e., while removing this restriction of 5586, it does not modify >> its requirement for the GAL being always at the bottom of the >> label stack. >> >> >> >> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >> review) reserves the bottom of the PW stack for the PW flow >> labels, e.g., in Section 1.1: >> >> >> >> This document describes a method of adding an additional label >> stack entry (LSE) at the bottom of stack in order to facilitate >> the load balancing of the flows within a PW over the available >> ECMPs. >> >> >> >> One could argue that draft-ietf-pwe3-gal-in-pw only applies to >> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and >> FWIW, >> >> such an argument, were it presented, would be highly problematic, >> because: >> >> >> >> 1. RFC 5960 (which defines the MPLS-TP data plane) did not >> define any differences between the PW data plane in IP/MPLS and >> MPLS-TP. >> >> 2. One of the most popular scenarios for using multi-segment >> pseudowires is the case when an edge-to-edge service emulation >> crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, >> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware >> T-PE at the edge of an IP/MPLS domain) would potentially compete >> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >> e.g., for relying a PW status message that it has received over a >> Targeted LDP session from the IP/MPLS domain to a static PW status >> message to cross the MPLS-TP domain) for the bottom-of-stack >> position. >> >> >> >> The issue I am raising Is not new. It has been actively discussed >> on the PWE3 mailing list with regard to adoption of >> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for >> both the flow label and GAL taking the bottom-of-the-stack >> position. But, to the best of my understanding, consensus on this >> issue has not been reached. >> >> >> >> Hopefully this comment will be useful. >> >> >> >> Regards, >> >> Sasha >> >> >> >> This e-mail message is intended for the recipient only and >> contains information which is CONFIDENTIAL and which may be >> proprietary to ECI Telecom. If you have received this transmission >> in error, please inform us by e-mail, phone or fax, and then >> delete the original and all copies thereof. >> >> This e-mail message is intended for the recipient only and >> contains information which is CONFIDENTIAL and which may be >> proprietary to ECI Telecom. If you have received this transmission >> in error, please inform us by e-mail, phone or fax, and then >> delete the original and all copies thereof. >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From gregimirsky@gmail.com Wed Aug 17 22:42:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC02B21F8593; Wed, 17 Aug 2011 22:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRagjo78v+KF; Wed, 17 Aug 2011 22:42:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7FE21F8581; Wed, 17 Aug 2011 22:42:37 -0700 (PDT) Received: by vxi29 with SMTP id 29so1785114vxi.31 for ; Wed, 17 Aug 2011 22:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zotSvij3FkNZ4ec4HAr+kxQS0j/S/EBdCSb27AaDilQ=; b=xXPQLAoO2U38e9ULwzyGGE5VLhR8RpiyMhDA+oA6KCPAuqvHgq0YP6ft/M3T6QsWVV ruC4nzIVX79D5qv4Vwo9NxGmothuddMsGvhD/MnxrxKhvQdxQJ0tUTmI8b/50DOff8iI wkYyudAyXQm2Ebas8Zv0+YJvlgFzmn70dnjtA= MIME-Version: 1.0 Received: by 10.52.27.3 with SMTP id p3mr311379vdg.224.1313646209899; Wed, 17 Aug 2011 22:43:29 -0700 (PDT) Received: by 10.52.167.229 with HTTP; Wed, 17 Aug 2011 22:43:29 -0700 (PDT) In-Reply-To: References: <4E4C0F3F.8010700@cisco.com> Date: Wed, 17 Aug 2011 22:43:29 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 05:42:38 -0000 Dear Sasha, thank you for your comment as it helps me to understand what are possible ramifications of proposed solution. I should have noted in the first place that I'm not proposing but merely try to interpret, re-word Luca's proposal. And I could have put it as a question "Is an MPLS-TP MS-PW crossing ECMP domain is conforming MPLS-TP construct?" or "What are requirements for control over ECMP domain to conform with MPLS-TP?" Regards, Greg On Wed, Aug 17, 2011 at 10:11 PM, Alexander Vainshtein wrote: > Dear Greg, > I am afraid that your wording would be effectively equivalent to "MPLS-TP= SHOULD NOT be used outside of "walled garden" scenarios. > > Today the core networks are IP/MPLS and use ECMP at different levels whil= e MPLS-TP deployments are seem by many as mainly happening in the access/ag= gregation/metro. If you do not allow an MS-PW to start in the MPLS-TP domai= n (access/metro), to cross an IP/MPLS core and then to terminate, say, in a= nother MPLS-TP domain (access/core), applicability of MPLS-TP would be IMHO= greatly reduced. > > Please note also that there is also a draft proposing using of ECMP for b= oth MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). > > Regards, > =A0 =A0 Sasha > ________________________________________ > From: Greg Mirsky [gregimirsky@gmail.com] > Sent: Thursday, August 18, 2011 5:41 AM > To: Luca Martini > Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; M= ishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-= in-pw > > Dear Luca, > I'm thinking of other ways of wording, interpreting your formula. Can > it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? > > Regards, > Greg > > On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrote= : >> The solution is quite simple: >> >> "Flow Labels MUST not be used in an MPLS-TP environment." >> >> Luca >> >> >> >> >> >> On 08/16/11 21:46, Alexander Vainshtein wrote: >>> Pablo, >>> Sorry, but I think you're wrong. Only T-PE can insert the flow label >>> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on >>> PW label. >>> >>> Regards, >>> =A0 =A0 =A0Sasha >>> >>> -----------------------------------------------------------------------= - >>> *From:* Pablo Frank [pabloisnot@gmail.com] >>> *Sent:* Wednesday, August 17, 2011 12:17 AM >>> *To:* Alexander Vainshtein >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw >>> >>> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >>> domain in the middle segment, you're no longer in an MPLS-TP >>> environment and so the GAL is not required to be BOS. =A0During that >>> middle segment, the PW flow label would be placed below the GAL and >>> above the GACh. =A0It gets removed when it hits the S-PE that switches >>> you back into the MPLS-TP environment. =A0In other words, whether you'r= e >>> in an MPLS-TP environment is determined segment by segment in a MS-PW. >>> >>> Pablo >>> >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >>> >> > wrote: >>> >>> =A0 =A0 Hi all, >>> =A0 =A0 After having sent out my comments I've noticed that the specifi= c >>> =A0 =A0 example to illustrate the need to combine GAL and "flow label" = was >>> =A0 =A0 inaccurate. >>> >>> =A0 =A0 A more relevant example would look like following (I do not >>> =A0 =A0 include a diagram, but it can be easily provided if necessary) >>> >>> =A0 =A0 =A01. A MS-PW: >>> =A0 =A0 =A0 =A0 =A0 * Starts at an S-PE that resides at the edge of an = MPLS-TP >>> =A0 =A0 =A0 =A0 =A0 =A0 domain (no ECMP) >>> =A0 =A0 =A0 =A0 =A0 * Crosses this domain and enters an IP/MPLS domain = with ECMP >>> =A0 =A0 =A0 =A0 =A0 =A0 enabled using a T-PE that resides at the age of= these two >>> =A0 =A0 =A0 =A0 =A0 =A0 domains >>> =A0 =A0 =A0 =A0 =A0 * Leaves this domain and enters a 2nd MPLS-TP domai= n (using >>> =A0 =A0 =A0 =A0 =A0 =A0 the 2nd T-PE) >>> =A0 =A0 =A0 =A0 =A0 * Terminates on another S-PE at the edge of the 2nd= MPLS-TP >>> =A0 =A0 =A0 =A0 =A0 =A0 domain >>> =A0 =A0 =A02. The operator intends to improve traffic distribution in t= he >>> =A0 =A0 =A0 =A0 IP/MPLS domain, hence he enables insertion and discard = of >>> =A0 =A0 =A0 =A0 "flow labels" at the two S-PEs. Note that: >>> =A0 =A0 =A0 =A0 =A0 * This does not violate the MPLS-TP restriction on = ECMP: >>> =A0 =A0 =A0 =A0 =A0 =A0 ECMP does not happen in he MPLS-TP domains >>> =A0 =A0 =A0 =A0 =A0 * T-PEs do not even have to be aware of flow labels >>> =A0 =A0 =A03. The operator also intends to operate some end-to-end OAM = for >>> =A0 =A0 =A0 =A0 this MS-PW using "GAL-in-PW". This results in a conflic= t since >>> =A0 =A0 =A0 =A0 both GAL and "flow label" are defined (in the correspon= ding >>> =A0 =A0 =A0 =A0 drafts) as bottom of stack. >>> >>> >>> >>> =A0 =A0 IMHO this describes a realistic scenario where the two drafts a= re >>> =A0 =A0 in controversy. >>> >>> =A0 =A0 Regards, >>> =A0 =A0 =A0 =A0 =A0Sasha >>> =A0 =A0 ---------------------------------------------------------------= --------- >>> =A0 =A0 *From:* mpls-bounces@ietf.org >>> =A0 =A0 [mpls-bounces@ietf.org ] On Behal= f >>> =A0 =A0 Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >>> =A0 =A0 ] >>> =A0 =A0 *Sent:* Tuesday, August 16, 2011 4:26 PM >>> =A0 =A0 *To:* ietf@ietf.org >>> =A0 =A0 *Cc:* mpls@ietf.org ; Vladimir Kleiner; I= dan >>> =A0 =A0 Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Coh= en >>> =A0 =A0 *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal= -in-pw >>> >>> =A0 =A0 Hi all, >>> >>> >>> >>> =A0 =A0 I would like to raise the following issue with regard to >>> =A0 =A0 draft-ietf-pwe3-gal-in-pw >>> =A0 =A0 : >>> =A0 =A0 controversy vs. draft-ietf-pwe3-fat-pw >>> =A0 =A0 >>> =A0 =A0 with regard to bottom-of-stack position. >>> >>> >>> >>> =A0 =A0 As stated in the Introduction, this draft removes the restricti= on >>> =A0 =A0 imposed by RFC 5586 on usage of Generic Associated Channel Labe= l >>> =A0 =A0 (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 st= ates: >>> >>> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSP= s, >>> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MUST NOT = be >>> =A0 =A0 used with PWs. =A0It MUST always be at the bottom of the label = stack >>> =A0 =A0 =A0 =A0(i.e., S bit set to 1). >>> >>> >>> >>> =A0 =A0 draft-ietf-pwe3-gal-in-pw proposed to replace the original text= in >>> =A0 =A0 RFC 5586 with the following >>> >>> >>> >>> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSP= s, >>> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MAY be us= ed >>> =A0 =A0 with PWs. It MUST always be at the bottom of the label stack >>> =A0 =A0 (i.e., S bit set to 1). >>> >>> >>> >>> =A0 =A0 I.e., =A0while removing this restriction of 5586, it does not m= odify >>> =A0 =A0 its requirement for the GAL being always at the bottom of the >>> =A0 =A0 label stack. >>> >>> >>> >>> =A0 =A0 At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >>> =A0 =A0 review) reserves the bottom of the PW stack for the PW flow >>> =A0 =A0 labels, e.g., in Section 1.1: >>> >>> >>> >>> =A0 =A0 This document describes a method of adding an additional label >>> =A0 =A0 stack entry (LSE) at the bottom of stack in order to facilitate >>> =A0 =A0 the load balancing of the flows within a PW over the available >>> =A0 =A0 ECMPs. >>> >>> >>> >>> =A0 =A0 One could argue that draft-ietf-pwe3-gal-in-pw only applies to >>> =A0 =A0 MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO a= nd >>> =A0 =A0 FWIW, >>> >>> =A0 =A0 such an argument, were it presented, would be highly problemati= c, >>> =A0 =A0 because: >>> >>> >>> >>> =A0 =A0 1. =A0 =A0 =A0 RFC 5960 (which defines the MPLS-TP data plane) = did not >>> =A0 =A0 define any differences between the PW data plane in IP/MPLS and >>> =A0 =A0 MPLS-TP. >>> >>> =A0 =A0 2. =A0 =A0 =A0 One of the most popular scenarios for using mult= i-segment >>> =A0 =A0 pseudowires is the case when an edge-to-edge service emulation >>> =A0 =A0 crosses multiple IP/MPLS and MPLS-TP domains. In these scenario= s, >>> =A0 =A0 the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aw= are >>> =A0 =A0 T-PE at the edge of an IP/MPLS domain) would potentially compet= e >>> =A0 =A0 with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >>> =A0 =A0 e.g., for relying a PW status message that it has received over= a >>> =A0 =A0 Targeted LDP session from the IP/MPLS domain to a static PW sta= tus >>> =A0 =A0 message to cross the MPLS-TP domain) for the bottom-of-stack >>> =A0 =A0 position. >>> >>> >>> >>> =A0 =A0 The issue I am raising Is not new. It has been actively discuss= ed >>> =A0 =A0 on the PWE3 mailing list with regard to adoption of >>> =A0 =A0 draft-nadeau-pwe3-vccv-2 as a WG document, with arguments =A0fo= r >>> =A0 =A0 both the flow label and GAL taking the bottom-of-the-stack >>> =A0 =A0 position. But, to the best of my understanding, consensus on th= is >>> =A0 =A0 issue has not been reached. >>> >>> >>> >>> =A0 =A0 Hopefully this comment will be useful. >>> >>> >>> >>> =A0 =A0 Regards, >>> >>> =A0 =A0 =A0 =A0 =A0Sasha >>> >>> >>> >>> =A0 =A0 This e-mail message is intended for the recipient only and >>> =A0 =A0 contains information which is CONFIDENTIAL and which may be >>> =A0 =A0 proprietary to ECI Telecom. If you have received this transmiss= ion >>> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >>> =A0 =A0 delete the original and all copies thereof. >>> >>> =A0 =A0 This e-mail message is intended for the recipient only and >>> =A0 =A0 contains information which is CONFIDENTIAL and which may be >>> =A0 =A0 proprietary to ECI Telecom. If you have received this transmiss= ion >>> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >>> =A0 =A0 delete the original and all copies thereof. >>> >>> >>> =A0 =A0 _______________________________________________ >>> =A0 =A0 pwe3 mailing list >>> =A0 =A0 pwe3@ietf.org >>> =A0 =A0 https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and >>> all copies thereof. >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > From Rolf.Winter@neclab.eu Wed Aug 17 23:57:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04C921F8570; Wed, 17 Aug 2011 23:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCQ0nNkN2anr; Wed, 17 Aug 2011 23:57:37 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C44D621F8565; Wed, 17 Aug 2011 23:57:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 34DDF2800032C; Thu, 18 Aug 2011 08:58:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGQ0oifzVq5K; Thu, 18 Aug 2011 08:58:29 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 17791280001AA; Thu, 18 Aug 2011 08:58:14 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.194]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 18 Aug 2011 08:58:14 +0200 From: Rolf Winter To: "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard Thread-Index: AQHMWC0Ywr0I1Kz6gkW/M9/KtmFRppUiNvaQ Date: Thu, 18 Aug 2011 06:58:13 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D05F07B@Polydeuces.office.hd> References: <20110811134542.25435.61281.idtracker@ietfa.amsl.com> In-Reply-To: <20110811134542.25435.61281.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 06:57:38 -0000 Hi, I have made this comment before, I just want to make sure it is not lost. T= his draft is proposing a way to specify the length of sub-TLVs that is inco= nsistent with RFC 4379. I believe it would be better to align this with 437= 9 as the draft is updating it and I see no technical reason why this should= be done differently from 4379.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > The IESG > Sent: Donnerstag, 11. August 2011 15:46 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: > (MPLS On-demand Connectivity Verification and Route Tracing) to > Proposed Standard >=20 >=20 > The IESG has received a request from the Multiprotocol Label Switching > WG > (mpls) to consider the following document: > - 'MPLS On-demand Connectivity Verification and Route Tracing' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 > Label Switched Path Ping (LSP-Ping) is an existing and widely > deployed Operations, Administration and Maintenance (OAM) mechanism > for Multi-Protocol Label Switching (MPLS) Label Switched Paths > (LSPs). This document describes extensions to LSP-Ping so that LSP- > Ping can be used for On-demand Connectivity Verification of MPLS > Transport Profile (MPLS-TP) LSPs and Pseudowires. This document > also > clarifies procedures to be used for processing the related OAM > packets. Further, it describes procedures for using LSP-Ping to > perform Connectivity Verification and Route Tracing functions in > MPLS-TP networks. Finally this document updates RFC 4379 by adding > a > new address type and requesting an IANA registry. >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Thu Aug 18 01:03:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA821F86C3; Thu, 18 Aug 2011 01:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[AWL=-2.266, BAYES_00=-2.599, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T91dRL8HiCz; Thu, 18 Aug 2011 01:03:56 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7675B21F85DA; Thu, 18 Aug 2011 01:03:55 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 18 Aug 2011 09:04:47 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 18 Aug 2011 09:04:47 +0100 From: To: , Date: Thu, 18 Aug 2011 09:04:42 +0100 Thread-Topic: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdaccDd6p6WxJWQPeR1xCjDJBG1AAELHkw Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405EDDFCB8@EMV62-UKRD.domain1.systemhost.net> References: <4E4C0F3F.8010700@cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, Vladimir.Kleiner@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, pwe3@ietf.org, Oren.Gal@ecitele.com, John.Shirron@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:03:57 -0000 Greg, This may help you answer your own question: A layer network at level N is composed of layer N nodes and layer N links. = The layer N links are provided by layer N-1 E2E paths....recurse to the du= ct. This has the following ramifications: 1 The disjoint connectivity of any layer network M cannot be greater = than that of the duct graph....in practice this means a disjoint connectivi= ty of >3 is practically difficult with BOS guided EM wave networks based on= metallic or optical media. Aside=3D> Going 3-dim can improve this, eg use= a radio BOS section layer. 2 The performance enjoyed by a layer N network is (to a good 1st ~) t= he sum of the impairments introduced by the layer N nodes and those inherit= ed by the layer N links from their server E2E layer N-1 path...recurse to t= he duct. Now given the critical service a transport network provides to its clients = is transparency (of the carriage of client symbols) then this requires cont= rol over all inherited impairments down the stack of nested layer networks = to the duct. It immediately follows that one must have resource determinis= m of *each and every* layer network to the duct if one wishes to control re= source impairments caused by traffic load (in nodes). This is a given without any action when dealing with layer networks based o= n the space resource partition, or a co-cs time resource partition since th= is is based on regular and fixed-duration time-slices. One can get close t= o approximating this behaviour in the co-ps mode, which is usually based on= irregular time-slices of variable-duration, providing one respects the 2 r= equirements of: - using proper single source connection constructs and - not overbooking resource One clearly cannot provide the required behaviour over a cl-ps server layer= or a some approximation of the co-ps mode that does not meet the above req= uirements, eg MPLS LDP is like this as its constructs are not single source= ....ECMP just complicates/exacerbates matters. I now think the answer to your question Greg is obvious. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: 18 August 2011 06:43 > To: Alexander Vainshtein > Cc: mpls@ietf.org; Vladimir Kleiner; Luca Martini; Idan Kaspit; Mishael > Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > > Dear Sasha, > thank you for your comment as it helps me to understand what are > possible ramifications of proposed solution. > I should have noted in the first place that I'm not proposing but > merely try to interpret, re-word Luca's proposal. > And I could have put it as a question "Is an MPLS-TP MS-PW crossing > ECMP domain is conforming MPLS-TP construct?" or "What are > requirements for control over ECMP domain to conform with MPLS-TP?" > > Regards, > Greg > > On Wed, Aug 17, 2011 at 10:11 PM, Alexander Vainshtein > wrote: > > Dear Greg, > > I am afraid that your wording would be effectively equivalent to > "MPLS-TP SHOULD NOT be used outside of "walled garden" scenarios. > > > > Today the core networks are IP/MPLS and use ECMP at different levels > while MPLS-TP deployments are seem by many as mainly happening in the > access/aggregation/metro. If you do not allow an MS-PW to start in the > MPLS-TP domain (access/metro), to cross an IP/MPLS core and then to > terminate, say, in another MPLS-TP domain (access/core), applicability > of MPLS-TP would be IMHO greatly reduced. > > > > Please note also that there is also a draft proposing using of ECMP > for both MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). > > > > Regards, > > Sasha > > ________________________________________ > > From: Greg Mirsky [gregimirsky@gmail.com] > > Sent: Thursday, August 18, 2011 5:41 AM > > To: Luca Martini > > Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > > > > Dear Luca, > > I'm thinking of other ways of wording, interpreting your formula. Can > > it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? > > > > Regards, > > Greg > > > > On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini > wrote: > >> The solution is quite simple: > >> > >> "Flow Labels MUST not be used in an MPLS-TP environment." > >> > >> Luca > >> > >> > >> > >> > >> > >> On 08/16/11 21:46, Alexander Vainshtein wrote: > >>> Pablo, > >>> Sorry, but I think you're wrong. Only T-PE can insert the flow > label > >>> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap > on > >>> PW label. > >>> > >>> Regards, > >>> Sasha > >>> > >>> ------------------------------------------------------------------- > ----- > >>> *From:* Pablo Frank [pabloisnot@gmail.com] > >>> *Sent:* Wednesday, August 17, 2011 12:17 AM > >>> *To:* Alexander Vainshtein > >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > >>> > >>> I think it's okay because as the PW crosses the ECMP-enabled > IP/MPLS > >>> domain in the middle segment, you're no longer in an MPLS-TP > >>> environment and so the GAL is not required to be BOS. During that > >>> middle segment, the PW flow label would be placed below the GAL and > >>> above the GACh. It gets removed when it hits the S-PE that > switches > >>> you back into the MPLS-TP environment. In other words, whether > you're > >>> in an MPLS-TP environment is determined segment by segment in a MS- > PW. > >>> > >>> Pablo > >>> > >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > >>> >>> > wrote: > >>> > >>> Hi all, > >>> After having sent out my comments I've noticed that the > specific > >>> example to illustrate the need to combine GAL and "flow label" > was > >>> inaccurate. > >>> > >>> A more relevant example would look like following (I do not > >>> include a diagram, but it can be easily provided if necessary) > >>> > >>> 1. A MS-PW: > >>> * Starts at an S-PE that resides at the edge of an MPLS- > TP > >>> domain (no ECMP) > >>> * Crosses this domain and enters an IP/MPLS domain with > ECMP > >>> enabled using a T-PE that resides at the age of these > two > >>> domains > >>> * Leaves this domain and enters a 2nd MPLS-TP domain > (using > >>> the 2nd T-PE) > >>> * Terminates on another S-PE at the edge of the 2nd MPLS- > TP > >>> domain > >>> 2. The operator intends to improve traffic distribution in the > >>> IP/MPLS domain, hence he enables insertion and discard of > >>> "flow labels" at the two S-PEs. Note that: > >>> * This does not violate the MPLS-TP restriction on ECMP: > >>> ECMP does not happen in he MPLS-TP domains > >>> * T-PEs do not even have to be aware of flow labels > >>> 3. The operator also intends to operate some end-to-end OAM > for > >>> this MS-PW using "GAL-in-PW". This results in a conflict > since > >>> both GAL and "flow label" are defined (in the corresponding > >>> drafts) as bottom of stack. > >>> > >>> > >>> > >>> IMHO this describes a realistic scenario where the two drafts > are > >>> in controversy. > >>> > >>> Regards, > >>> Sasha > >>> --------------------------------------------------------------- > --------- > >>> *From:* mpls-bounces@ietf.org > >>> [mpls-bounces@ietf.org ] On > Behalf > >>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > >>> ] > >>> *Sent:* Tuesday, August 16, 2011 4:26 PM > >>> *To:* ietf@ietf.org > >>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; > Idan > >>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem > Cohen > >>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > >>> > >>> Hi all, > >>> > >>> > >>> > >>> I would like to raise the following issue with regard to > >>> draft-ietf-pwe3-gal-in-pw > >>> in-pw/?include_text=3D1>: > >>> controversy vs. draft-ietf-pwe3-fat-pw > >>> pw/?include_text=3D1> > >>> with regard to bottom-of-stack position. > >>> > >>> > >>> > >>> As stated in the Introduction, this draft removes the > restriction > >>> imposed by RFC 5586 on usage of Generic Associated Channel > Label > >>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 > states: > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MUST NOT > be > >>> used with PWs. It MUST always be at the bottom of the label > stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> draft-ietf-pwe3-gal-in-pw proposed to replace the original text > in > >>> RFC 5586 with the following > >>> > >>> > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MAY be > used > >>> with PWs. It MUST always be at the bottom of the label stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> I.e., while removing this restriction of 5586, it does not > modify > >>> its requirement for the GAL being always at the bottom of the > >>> label stack. > >>> > >>> > >>> > >>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > >>> review) reserves the bottom of the PW stack for the PW flow > >>> labels, e.g., in Section 1.1: > >>> > >>> > >>> > >>> This document describes a method of adding an additional label > >>> stack entry (LSE) at the bottom of stack in order to facilitate > >>> the load balancing of the flows within a PW over the available > >>> ECMPs. > >>> > >>> > >>> > >>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to > >>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO > and > >>> FWIW, > >>> > >>> such an argument, were it presented, would be highly > problematic, > >>> because: > >>> > >>> > >>> > >>> 1. RFC 5960 (which defines the MPLS-TP data plane) did > not > >>> define any differences between the PW data plane in IP/MPLS and > >>> MPLS-TP. > >>> > >>> 2. One of the most popular scenarios for using multi- > segment > >>> pseudowires is the case when an edge-to-edge service emulation > >>> crosses multiple IP/MPLS and MPLS-TP domains. In these > scenarios, > >>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- > aware > >>> T-PE at the edge of an IP/MPLS domain) would potentially > compete > >>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > >>> e.g., for relying a PW status message that it has received over > a > >>> Targeted LDP session from the IP/MPLS domain to a static PW > status > >>> message to cross the MPLS-TP domain) for the bottom-of-stack > >>> position. > >>> > >>> > >>> > >>> The issue I am raising Is not new. It has been actively > discussed > >>> on the PWE3 mailing list with regard to adoption of > >>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > >>> both the flow label and GAL taking the bottom-of-the-stack > >>> position. But, to the best of my understanding, consensus on > this > >>> issue has not been reached. > >>> > >>> > >>> > >>> Hopefully this comment will be useful. > >>> > >>> > >>> > >>> Regards, > >>> > >>> Sasha > >>> > >>> > >>> > >>> This e-mail message is intended for the recipient only and > >>> contains information which is CONFIDENTIAL and which may be > >>> proprietary to ECI Telecom. If you have received this > transmission > >>> in error, please inform us by e-mail, phone or fax, and then > >>> delete the original and all copies thereof. > >>> > >>> This e-mail message is intended for the recipient only and > >>> contains information which is CONFIDENTIAL and which may be > >>> proprietary to ECI Telecom. If you have received this > transmission > >>> in error, please inform us by e-mail, phone or fax, and then > >>> delete the original and all copies thereof. > >>> > >>> > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pwe3 > >>> > >>> > >>> This e-mail message is intended for the recipient only and contains > >>> information which is CONFIDENTIAL and which may be proprietary to > ECI > >>> Telecom. If you have received this transmission in error, please > >>> inform us by e-mail, phone or fax, and then delete the original and > >>> all copies thereof. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From maarten.vissers@huawei.com Thu Aug 18 02:35:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A81921F8B04 for ; Thu, 18 Aug 2011 02:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[AWL=1.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MrhkH8LzAAd for ; Thu, 18 Aug 2011 02:35:06 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66121F8AEC for ; Thu, 18 Aug 2011 02:35:06 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ4001LTANXD5@lhrga02-in.huawei.com> for mpls@ietf.org; Thu, 18 Aug 2011 10:35:58 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LQ4005IPANKZM@lhrga02-in.huawei.com> for mpls@ietf.org; Thu, 18 Aug 2011 10:35:57 +0100 (BST) Received: from LHREML401-HUB.china.huawei.com (10.201.5.30) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 18 Aug 2011 10:35:38 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML401-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 18 Aug 2011 10:35:46 +0100 Date: Thu, 18 Aug 2011 09:35:45 +0000 From: Maarten vissers In-reply-to: <20110815190221.25214.81998.idtracker@ietfa.amsl.com> X-Originating-IP: [10.202.113.13] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] I-D Action: draft-ietf-mpls-tp-fault-06.txt Thread-index: AQHMW34XSt1G8yK0aky11ncmllJuspUiKG0g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110815190221.25214.81998.idtracker@ietfa.amsl.com> Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-fault-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 09:35:07 -0000 My comment on the use of the terms Fault and Defect in version -05: --------------- 1. Defect: the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted. <..> Within the Defect class, a further category, Fault is identified. A fault is the inability of a function to perform a required action. A fault is a persistent defect. ----------------- has resulted in a swapping of the terms Fault and Defect in version -06: ----------------- 1. Fault: the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted. <..> Within the Fault class, a further category, Defect is identified. A defect is the inability of a function to perform a required action. A defect is a persistent fault. ----------------- It was not my intention to simply see these two terms being swapped. I suggested to introduce a third term (which is not present today in G.806), so that we would get the following three terms: - Fault - Defect - Fatal Defect Most likely my original comment has been lacking some examples to illustrate what a Fault is in terms of G.806. A Fault represents a problem in the network. Some examples of Faults are: 1) a broken fiber, 2) a removed matrix connection, 3) a wrong matrix connection, 4) a failed optical transmitter which does not generate light, 5) an optical transmitter which operates at e.g. 10% of its required optical power, 6) a dirty optical connector which causes too much optical attenuation. To detect the presence of a Fault, transport equipment is equipped with 'Defect detectors'. You find those Defect detector processes illustrated in Figures 6-1 an 6-2 of G.806 http://www.itu.int/rec/T-REC-G.806/en and in the atomic function figures in G.798, G.8021, G.8121. Faults number 1 and 4 result in of loss of optical power and detection of a LOS defect. Fault number 2 results in either loss of optical power (OCh layer) and detection of LOS defect, or the loss of frames/packets or presence of frames with a default value and detection of LOC/UNEQ/OCI defect (depending on the technology). Fault number 3 results in delivering frames/packets to the wrong destination and detection of TIM/MMG defect (depending on the technology). Faults number 5,6 result in reduction of optical power, mistakes in the recovery of the '0' and '1' bit values and detection of DEG defect. Figures 6-1 and 6-2/G.806 also illustrate that the output of those Defect detector processes control the Consequent Actions (AIS, RDI, TSF, TSD, SSF generation). At the moment the L-flag is unknown in the G.806 fault management process and will have to be added. To add the L-Flag consequent action (e.g. as 'aLDI') it will be necessary to introduce an additional state 'aLDI' in the process for each client connection. This additional state 'aLDI' controls the setting of the L-flag in the AIS message. If 'aLDI' is set, the L-flag is set to '1' in each generated AIS message. If 'aLDI' is cleared, the L-flag is set to '0' in each generated AIS message. 'aLDI' is cleared ('0') if: - the connection (LSP, PW) is either a working or protection connection and neither working or protection connection is in a Signal Fail condition and external commands are not preventing the protection switch to perform a switch - the connection (LSP, PW) is unprotected in this node and is possibly protected in an upstream node and there has not been a signal fail condition for some time T1; default value for T1 is 100 ms 'aLDI' is set ('1') if: - the unprotected connection (LSP, PW) is in a signal fail condition for some time T2; default value for T2 is 100 ms (i.e. either no upstream protection present, or upstream protection failed) - the working [protection] connection (LSP, PW) is in a signal fail condition for some time T3 and the protection switch process did not select the traffic from the protection [working] connection (i.e. protection failed); default value for T3 is 100 ms - the protection switch process is forced into selecting traffic from working or protection connection (i.e. unable to protect a future fault) - the protection switch process is selecting traffic from working [protection] due to the presence of a signal fail condition on protection [working] (i.e. unable to protect a second fault) I will present enhanced text in a separate email to limit the size of this email. Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 15 August 2011 21:02 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-fault-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiprotocol Label > Switching Working Group of the IETF. > > Title : MPLS Fault Management OAM > Author(s) : George Swallow > Annamaria Fulignoli > Martin Vigoureux > Sami Boutros > David Ward > Filename : draft-ietf-mpls-tp-fault-06.txt > Pages : 16 > Date : 2011-08-15 > > This draft specifies OAM messages to indicate service disruptive > conditions for MPLS based Transport Network Label Switched Paths > (LSPs). The notification mechanism employs a generic method for a > service disruptive condition to be communicated to a Maintenance End > Point (MEP). An MPLS Operation, Administration, and Maintenance > (OAM) channel is defined along with messages to communicate various > types of service disruptive conditions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-06.txt > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Spike.Curtis@metaswitch.com Thu Aug 18 04:07:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C4C21F8760 for ; Thu, 18 Aug 2011 04:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Un7E34nDeDB for ; Thu, 18 Aug 2011 04:07:22 -0700 (PDT) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id E152D21F86B3 for ; Thu, 18 Aug 2011 04:07:21 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.4.12) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 18 Aug 2011 12:10:35 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.01.0289.001; Thu, 18 Aug 2011 12:08:14 +0100 From: Spike Curtis To: Thomas Nadeau Thread-Topic: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt Thread-Index: AQHMWD5FUUNhW5Pdwkeke+DOaKDjNJUXvUsAgAXknXCAAD58gIABVfGggAAYY4CAAy7mEA== Date: Thu, 18 Aug 2011 11:08:14 +0000 Message-ID: <86C289CC63A2544A932C48E05AC495820940541E@ENFICSMBX1.datcon.co.uk> References: <30d001cc56a2$3e764210$6601a8c0@JoanPC> <008701cc5769$75314e90$6601a8c0@JoanPC> <01c501cc583e$462ccea0$6601a8c0@JoanPC> <86C289CC63A2544A932C48E05AC49582093FBB3D@ENFIRHMBX1.datcon.co.uk> <88F3A26E-3481-4F25-80FD-3A71D34AB986@lucidvision.com> <86C289CC63A2544A932C48E05AC49582093FC065@ENFIRHMBX1.datcon.co.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 11:07:23 -0000 Hi Tom,=20 I'm also happy to drop provisioning as a use case for the MIB. The issues = with local identifiers I mentioned aren't relevant if we don't support prov= isioning. I do think we should be explicit about this. If there aren't ob= jections from the WG, then we should change the MIB to be read-only. -Spike -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Tuesday, August 16, 2011 12:31 PM To: Spike Curtis Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt On Aug 16, 2011, at 5:04 AM, Spike Curtis wrote: > Hi Tom, >=20 > I hear what you're saying. Is it a requirement that the MIB can be used = for provisioning? If not, then why don't we make the whole thing read-only= ? The read-write capability is up to the WG, but my preference is to avoid p= rovisioning via SNMP altogether as its a pretty rare use case. --Tom >=20 > -Spike >=20 > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Monday, August 15, 2011 2:40 PM > To: Spike Curtis > Cc: Joan Cucchiara; mpls@ietf.org > Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >=20 >=20 > On Aug 15, 2011, at 4:58 AM, Spike Curtis wrote: >=20 >> Hi Joan and Tom, >>=20 >> What I meant by (1) was not to extend the mplsTunnelTable, but define a = new table. That is to say, a tunnel can appear in either the new MPLS-TP t= unnel table or the old mplsTunnelTable, not both. As Joan suggests, both t= ables could be straightforwardly presented together at the user interface l= evel. >=20 > Why would that approach be better than extending the existing table? >=20 >> With option 2 (modified indexing) ruled out, (1) becomes my preference a= s well. >>=20 >> As I mentioned, my main concern is with extra identifiers with only loca= l significance. There are cases where rows in the table will be auto-creat= ed, for example at LSP egress when the tunnel is signalled. The difficulty= is then to ensure they don't change if the tunnel is taken down and recrea= ted, or over a graceful restart. Indices to the mplsTunnelTable are refere= nced in other MIBs like the pseudowire to MPLS tunnel binding and the mplsX= CExtTable. >=20 > That is a bit of an implementation detail, and is also why in general, n= o one relies on SNMP for provisioning. >=20 > --Tom >=20 >=20 >>=20 >> -Spike >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Thomas Nadeau >> Sent: Thursday, August 11, 2011 4:57 PM >> To: Joan Cucchiara >> Cc: mpls@ietf.org >> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>=20 >> Cool. Thanks! >>=20 >> On Aug 11, 2011, at 11:49 AM, Joan Cucchiara wrote: >>=20 >>>=20 >>> Tom, >>>=20 >>> Thank you for adding additional info about how the mappping tables >>> should/could be used. >>>=20 >>> Of course, what working group wants is fine by me wrt making the >>> mapping tables optional or not. >>>=20 >>> I have considered your preference and think that keeping the >>> mapping tables with the agent may be reasonable for larger devices whic= h >>> should have the resources to support them and have an E/NMS to >>> take advantage of these tables. >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>> ----- Original Message ----- From: "Thomas Nadeau" >>> To: "Joan Cucchiara" >>> Cc: >>> Sent: Wednesday, August 10, 2011 10:58 AM >>> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>=20 >>>=20 >>>=20 >>> On Aug 10, 2011, at 10:26 AM, Joan Cucchiara wrote: >>>=20 >>>>=20 >>>> ----- Original Message ----- From: "Thomas Nadeau" >>>> To: "Joan Cucchiara" >>>> Cc: >>>> Sent: Tuesday, August 09, 2011 10:47 AM >>>> Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>=20 >>>>=20 >>>>>=20 >>>>> On Aug 9, 2011, at 10:40 AM, Joan Cucchiara wrote: >>>>>=20 >>>>>>=20 >>>>>> Spike, >>>>>>=20 >>>>>> Wanted to comment on your 3 suggestions for indexing. >>>>>>=20 >>>>>> Suggestion #1 is also my preference. This is the most straightforw= ard and least complex >>>>>> design in my opinion. Additionally, the CLI, Web, NMS, etc could = display both MPLS >>>>>> Tunnels and MPLS-TP Tunnels in the same table if wanted. So the co= mplexity of the >>>>>> mapping is not in the MIB (or agent). >>>>>=20 >>>>> That is the idea we were after. We want a new table that shows "TP tu= nnels" >>>>> as a (proper) subset of those defined globally. That is, the indexing= "extends" those in >>>>> the MplsTunnelTable. >>>>>=20 >>>>>> Suggestion #2 is not allowed because redefining indices is not allow= ed in the SMI. >>>>>> (We had a few emails about this during the time that the MIB was bei= ng adopted by the WG.) >>>>>=20 >>>>> Spot on. The only way to take this approach is to deprecate RFC3811, = 12, and 13 as >>>>> well as the GMPLS and PWE3 MIB RFCs that are also based on these. >>>>>=20 >>>>>> Suggestion #3: allows MPLS and MPLS-TP tunnels to exist in the same= table. >>>>>> While this goal may have some benefits, the design to accomplish the= goal is more complex than #1 >>>>>> as you point out. I have asked the authors to ensure that there are= no backwards compatibility issues >>>>>> with the design so that the MPLS Tunnel Table is already populated >>>>>> and then MPLS-TP Tunnel indices are created such that they do not co= nflict with already >>>>>> existing tunnel indices. In a nutshell, the problem I have with t= his design is that there are 2 ways of creating indices >>>>>> for the same Table, one which is legacy and has been around since 20= 04 and now a second way. >>>>>=20 >>>>> Don't you get both "existing at the same time in the same table" by u= sing the 'extends' relationship? >>>>>=20 >>>>>=20 >>>>>> There may be a #4 Suggestion which is to implement design #1 but als= o have an additional (optional?) table >>>>>> which is a superset of Tunnels, this could be indexed by a type fiel= d. >>>>>=20 >>>>> The MIB provides mapping tables *in addition to* the basic table that= extends the MplsTunnelTable. >>>>> This is provided as a convenience for the E/NMS to speed table traver= sal/manipulation. >>>>>=20 >>>>=20 >>>> Tom, >>>>=20 >>>> That wasn't clear (at least to me), could this be clarified in next re= v? >>>=20 >>> Yes, of course! 8) >>>=20 >>>> Also, may be more beneficial to make these mapping tables optional -- = not every vendor will need to >>>> implement them, since they are for E/NMS. >>>=20 >>> That is possible, but as you know is up to the working group. It is my = personal preference as a vendor of management applications, >>> to avoid optional things where possible, as they are unlikely to ever g= et implemented on devices and make things more difficult for >>> applications. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> -Joan >>>>>>=20 >>>>>>=20 >>>>>> ----- Original Message ----- From: "Eric Gray" >>>>>> To: >>>>>> Sent: Tuesday, August 09, 2011 9:05 AM >>>>>> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>=20 >>>>>>=20 >>>>>>> Forwarding in plain text... >>>>>>>=20 >>>>>>> ________________________________ >>>>>>>=20 >>>>>>> From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] >>>>>>> Sent: Monday, August 08, 2011 5:25 AM >>>>>>> To: draft-ietf-mpls-tp-te-mib@tools.ietf.org >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: RE: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Venkat & all, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I've read the draft and have a question and then some comments. I'= m happy to be of assistance with any of what follows, and/or with working o= n other MIB drafts that we need to fill out the gaps identified in draft-ie= tf-mpls-tp-mib-management-overview. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> MPLS-TP Identifiers: >>>>>>>=20 >>>>>>> I understand that one of the purposes of this draft is to allow con= figuration using MPLS-TP identifiers. Presumably, there are at least three= ways this could be accomplished: >>>>>>>=20 >>>>>>> 1. Define a brand new tunnel table for MPLS-TP, based on the mp= lsTunnelTable, but with the MPLS-TP identifiers as indices. >>>>>>>=20 >>>>>>> 2. Redefine the existing mplsTunnelTable indexing, adding Globa= lID and ICC for ingress and egress nodes, and using 0 as "not used" values = to allow back-compatibility. >>>>>>>=20 >>>>>>> 3. Create a separate set of tables which maps the old identifie= rs to the new MPLS-TP identifiers. >>>>>>>=20 >>>>>>> This draft takes the third strategy, but it's not immediately clear= to me why this is preferable to the other two. (2) seems the least complic= ated because it does away extra mapping and inverse mapping tables. It's a= lso difficult to guarantee that local identifiers (which don't have configu= ration or signalling significance) will not change in the case of graceful = restart or configuration replay. Was option (3) chosen to avoid back-compa= tibility issues, or for other reasons? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A comment on tunnels: >>>>>>>=20 >>>>>>> I'd like to clarify how unidirectional, associated bidirectional an= d co-routed bidirectional paths are modelled in the MIB, and how exactly th= e MPLS-TP identifiers for the Tunnel_IDs and LSP_IDs map onto MIB fields. M= y preference is as follows. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> * Unidirectional LSPs in MPLS-TP are very similar to "norma= l" MPLS, but with different identifiers. Tunnels of this type do not have = any entries in the mplsTunnelExtTable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> * In associated bidirectional LSPs, the transport direction= s are set up and monitored independently, so each transport direction shoul= d be a separate row in the mplsTunnelTable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> * In co-routed bidirectional LSPs, both transport direction= s are set up and monitored together. This means we should have only one ro= w in the mplsTunnelTable to represent a tunnel of this type. This is not h= ow the draft is currently structured, where the example in Section 9 create= s two rows in the mplsTunnelTable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> About gaps: >>>>>>>=20 >>>>>>> Lastly, I think the MIB is still missing some configuration that we= 'll need in order to satisfy MPLS-TP requirements. These include >>>>>>>=20 >>>>>>> * Bidirectional tunnels with asymmetric resource requiremen= ts >>>>>>>=20 >>>>>>> * OAM configuration. Presumably this will be a reference t= o yet-to-be-defined OAM MIBs so that tunnels can be easily assigned OAM pro= files. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Let me know if I can be of further assistance. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Spike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ________________________________ >>>>>>>=20 >>>>>>> * To: i-d-announce at ietf.org >>>>>>> * Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-00.txt >>>>>>> * From: internet-drafts at ietf.org

    Lizhong,<= o:p>

     

    We are using the term ingress Label Edge Rout= er (LER) to mean the node which creates and adds the MPLS label stack to a = given packet.   There will be only one such node for a given pack= et and hence only one entropy label for a given packet.  If a given pa= cket already contains an MPLS label stack, no other node in the network wil= l add an entropy label to that stack. 

     

    As I asked you before,  is there specific text in the Entropy Label I= -D which gives a contrary impression?

     

    Thanks,=

     <= /p>

    John

     

    Sent from= my iPhone

     

    From: Lizhong Jin [mai= lto:lizho.jin@gmail.com]
    Sent: Wednesday, August 17, 2011 7:49 A= M
    To: John E Drake
    Cc: zheng.zhi@zte.com.cn; draft-ietf= -mpls-entropy-label@tools.ietf.org; mpls@ietf.org
    Subject: Re: [m= pls] Entropy label in hierarchical LSP

     

    Hi John,

    For the hierarchical LSP case,= it is possible for the ingress LER to add entropy label for the incoming l= abeled packet. The ingress LER will not know whether the incoming labe= led packet already contains entropy label. Then the packet sent out by ingr= ess LER may contain two entropy labels, one is from the original packet, th= e other is added by itself. Did I miss something?

    =

    From the draft-entropy-label, it seems it makes an ass= umption that the incoming packet is not an MPLS packet.

    =

     

    Thanks

    Lizhong=



     

    2011/8/16 John E Drake <jdrake@juniper.net>

    Lizhong,<= /p>

     =

    That’= s correct, only the ingress LER places an entropy label in the label stack.=

     

    I think part of the confusion arises because the authors, for some = unknown reason (stupidity perhaps), use the term ‘LSR’ rather t= han ‘LER’ throughout.  This is covered by the statement in= Section 1.1:

     

    “The term ingress (or egress) LSR is used interc= hangeably with ingress  (or egress) LER.”

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

    But people may = have missed this.

     

    Thanks,

     

    <= span style=3D'font-size:11.0pt;color:#1F497D'>John

     =

    Sent from my iPho= ne

     

    From:= Lizhong Jin [mailto:lizho.jin@gmail.com]
    Sent: Tuesday, August 16, 2011 8:05 = AM
    To: John E Drake
    Cc: zheng.zhi@zte.com.cn; draft-ietf-mpls= -entropy-label@tools.ietf.org; mpls@ietf.org


    Subject: Re: [mpls] Ent= ropy label in hierarchical LSP

     

    Hi John,=

    With regarding the scenario and figure in Zhi's email= , LSP1 will be nested by LSP2, and both LSP1 and LSP2 support entropy label= . Then do you mean node B will not add entropy label for the labeled&n= bsp;traffic of LSP1, right? I think the draft is not clear for an ingress&n= bsp;node to encapsulate a labeled packet. The received labeled pa= cket maybe already contain entropy label.

    &= nbsp;

    Thanks

    Lizhong

     

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

    -------------------------= -----

    Date: Tue, 16 Aug 2011 05:41:19 -0700
    From: John E Drake &l= t;jdrake@juniper.ne= t>
    To: "zheng.zhi@zte.com.cn" <zheng.zhi@zte.com.cn>,
        &nbs= p;  "draft-ietf-mpls-entropy-label@tools.ietf.org"= ;
           <draft-ietf-mpls-entropy-label@to= ols.ietf.org>
    Cc: "mpls@ietf.org" <mpls@ietf.org>
    Subject: Re: [mpls] Entropy label = in hierarchical LSP
    Message-ID:
           <5E893DB832F57341992548CDBB333163A0ACB1A719@EMBX01-HQ.jnpr= .net>
    Content-Type: text/plain; charset=3D"us-ascii"
    Hi,

    The intent of the draft is that the node that creates the l= abel stack is the node that places the entropy label in the stack.  So= , there is only one entropy label present in any given MPLS packet.  I= f this is not clear, please point me to the text that causes you confusion = on this point.

    Thanks,

    John

    Sent from my iPhone
    From: mpls-boun= ces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of zheng.zhi@zte.com.cn
    Sent: Monday, A= ugust 15, 2011 1:58 AM
    To: draft-ietf-mpls-entropy-label@tools.ie= tf.org
    Cc: mpls@i= etf.org
    Subject: [mpls] Entropy label in hierarchical LSP

    Hi authors:

    About the use of entropy label, consider the hierarchic= al LSP case below:

              LSP-2
     = ;       _________
            /   &n= bsp;     \
    A--...--B---...---C--...--D
    \___________________= _____/
              LSP-1


    In the above = figure, an end-to-end LSP LSP-1 is between A and D, and another LSP LSP-2 g= oes over LSP-1 from B to C. Entropy labels are generated by the ingress LSR= s, A as ingress for LSP-1 and B for LSP-2 respectively.

    So the label= stack of the packets arrives at C, is like
    +-------------+    = ;   +-------------+
    | LSP-2 label |       | LSP-2 la= bel |
    | LSP-1 label |       |    ELI-2   &= nbsp;|
    |    ELI-1    |   OR  |   &nbs= p;EL-2     |    ?
    |    EL-1     = |       | LSP-1 label |
    |    ELI-2    = ;|       |    ELI-1    |
    |   &nb= sp;EL-2     |       |    EL-1   &nb= sp; |
    +-------------+       +-------------+

    ELI-1:= ELI for LSP-1; EL-1: EL for LSP-1;
    ELI-2: ELI for LSP-2; EL-2: EL for L= SP-2;

    Which one is the correct format?

    Thanks
    Zhi

     

    = --_000_5E893DB832F57341992548CDBB333163A0ACC2F91AEMBX01HQjnprn_-- From lmartini@cisco.com Wed Aug 17 11:57:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF9821F8A56; Wed, 17 Aug 2011 11:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el+or8lu+69g; Wed, 17 Aug 2011 11:57:43 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0027D21F87FA; Wed, 17 Aug 2011 11:57:42 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p7HIw78g021987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2011 12:58:11 -0600 (MDT) Message-ID: <4E4C0F3F.8010700@cisco.com> Date: Wed, 17 Aug 2011 12:58:07 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Vainshtein References: , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 18:57:44 -0000 The solution is quite simple: "Flow Labels MUST not be used in an MPLS-TP environment." Luca On 08/16/11 21:46, Alexander Vainshtein wrote: > Pablo, > Sorry, but I think you're wrong. Only T-PE can insert the flow label > (because only T=PE can be "flow-aware"). S-PE simply performs swap on > PW label. > > Regards, > Sasha > > ------------------------------------------------------------------------ > *From:* Pablo Frank [pabloisnot@gmail.com] > *Sent:* Wednesday, August 17, 2011 12:17 AM > *To:* Alexander Vainshtein > *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS > domain in the middle segment, you're no longer in an MPLS-TP > environment and so the GAL is not required to be BOS. During that > middle segment, the PW flow label would be placed below the GAL and > above the GACh. It gets removed when it hits the S-PE that switches > you back into the MPLS-TP environment. In other words, whether you're > in an MPLS-TP environment is determined segment by segment in a MS-PW. > > Pablo > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > > wrote: > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > A more relevant example would look like following (I do not > include a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two > domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP > domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of > "flow labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: > ECMP does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since > both GAL and "flow label" are defined (in the corresponding > drafts) as bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are > in controversy. > > Regards, > Sasha > ------------------------------------------------------------------------ > *From:* mpls-bounces@ietf.org > [mpls-bounces@ietf.org ] On Behalf > Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > ] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi all, > > > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw > : > controversy vs. draft-ietf-pwe3-fat-pw > > with regard to bottom-of-stack position. > > > > As stated in the Introduction, this draft removes the restriction > imposed by RFC 5586 on usage of Generic Associated Channel Label > (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be > used with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in > RFC 5586 with the following > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used > with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > I.e., while removing this restriction of 5586, it does not modify > its requirement for the GAL being always at the bottom of the > label stack. > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > review) reserves the bottom of the PW stack for the PW flow > labels, e.g., in Section 1.1: > > > > This document describes a method of adding an additional label > stack entry (LSE) at the bottom of stack in order to facilitate > the load balancing of the flows within a PW over the available > ECMPs. > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to > MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and > FWIW, > > such an argument, were it presented, would be highly problematic, > because: > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not > define any differences between the PW data plane in IP/MPLS and > MPLS-TP. > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation > crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, > the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware > T-PE at the edge of an IP/MPLS domain) would potentially compete > with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > e.g., for relying a PW status message that it has received over a > Targeted LDP session from the IP/MPLS domain to a static PW status > message to cross the MPLS-TP domain) for the bottom-of-stack > position. > > > > The issue I am raising Is not new. It has been actively discussed > on the PWE3 mailing list with regard to adoption of > draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > both the flow label and GAL taking the bottom-of-the-stack > position. But, to the best of my understanding, consensus on this > issue has not been reached. > > > > Hopefully this comment will be useful. > > > > Regards, > > Sasha > > > > This e-mail message is intended for the recipient only and > contains information which is CONFIDENTIAL and which may be > proprietary to ECI Telecom. If you have received this transmission > in error, please inform us by e-mail, phone or fax, and then > delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and > contains information which is CONFIDENTIAL and which may be > proprietary to ECI Telecom. If you have received this transmission > in error, please inform us by e-mail, phone or fax, and then > delete the original and all copies thereof. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and > all copies thereof. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From swallow@cisco.com Wed Aug 17 11:59:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6573711E809D; Wed, 17 Aug 2011 11:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYmm6bdKjNR5; Wed, 17 Aug 2011 11:59:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2563B11E8089; Wed, 17 Aug 2011 11:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=11349; q=dns/txt; s=iport; t=1313607594; x=1314817194; h=date:subject:from:to:cc:message-id:mime-version; bh=OvQN6oDaJIFL3GiOQPx/PxLcacpLjG6mTdax6c9OMEc=; b=OAV+NknQMOrWq5m359QUZlKVQCWxtLkB8tLzsQuX82dU15ikjPEizMw3 7zn2TU44mjY0ZtU/qqgiEYd/5oZgpe+Z86Frzj16SbcHNe+mcarWAxxaV 08fsUgQKQm8QxVwYH/2fyB7OC0KlCTF/wq+GH6b3hVF+Z/nsh4thvaxzo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABYPTE6tJXG9/2dsb2JhbAA6CIJNpTVvd4FCAQEDEgEqKhISAYEmAQQBDSefOQGfD4Mqgx4EkxOFFYt8 X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="scan'208,217";a="14060796" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 17 Aug 2011 18:59:53 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7HIxrrL017801; Wed, 17 Aug 2011 18:59:53 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 13:59:53 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Aug 2011 18:59:52 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 17 Aug 2011 14:59:51 -0400 From: George Swallow To: , Message-ID: Thread-Topic: Fault OAM configuration Thread-Index: AcxdD9eaINXt+AUojkW4dihJ3mndUw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3396437991_4863971" X-OriginalArrivalTime: 17 Aug 2011 18:59:53.0301 (UTC) FILETIME=[D8F94850:01CC5D0F] Cc: mpls@ietf.org, ccamp@ietf.org Subject: [mpls] Fault OAM configuration X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 18:59:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3396437991_4863971 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The current drafts on Fault OAM configurations, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06 allow for an extreme amount of control which I believe will not be implemented in many cases and where implemented will not be used. I think a much simple configuration model would be quite sufficient. The current drafts allow: MPLS OAM FMS sub-TLV The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TLV of the "OAM Configuration sub-TLV". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (5) (IANA) | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|D|L|C| Reserved (set all to 0s) |E| PHB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to define). Length: indicates the TLV total length in octets. Signal Flags: are used to enable the following signals: - A: Alarm Indication Signal (AIS) as described in [MPLS-FMS] - D: Link Down Indication (LDI) as described in [MPLS-FMS] - L: Locked Report (LKR) as described in [MPLS-FMS] - C: Client Signal Failure (CSF) as described in [MPLS-CSF] - Remaining bits: Reserved for future specification and set to 0. Configuration Flags: - E: used to enable/disable explicitly clearing faults - PHB: identifies the per-hop behavior of packets with fault management information Refresh Timer: indicates the refresh timer (in microseconds) of fault indication messages. If the edge LSR receiving the Path message can not support such value, it can reply back with a higher interval. (As a preface to the following three paragraphs, it is not clear if draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. There are no procedures in the draft for sending and receiving these messages let alone delivering them to midpoints). One of the keys to scaling is to keep midpoints simple. I do not want to be running separate timers for every LSP that may need fault OAM. I believe that operators will be quite happy to configure a single timer per node (or at most, per interface), and send all fault messages according to that timer. The same is true explicit clearing. PHB, Midpoints will also set the LDI flag when applicable, so this bit does not apply at midpoints. The draft needs to say that the bit only applies to whether a receiver should react to the LDI flag. I also cannot imagine an operator wanting to be informed of Alarms but not Locks or vice versa. So these two bits should be eliminated or it should be made clear that they have no semantics at a midpoint. Alternatively, these configuration flags could be used on and end to end basis to say that the receiver SHOULD treat AIS or LKR as a hard failure (LOC). (This applies to the LSP-PING draft even if it is only an end to end draft.) Bottom line. 1. The refresh timer should be removed. 2. The E flag should be removed. 3. PHB should either be removed or said to apply only to CSF. 4. The semantics of the D flag should be clarified to be only end-to-end. 5. The A and L flags should be either eliminated or given and end-to-end semantic of LOC. 6. For RSVP at a midpoint, the presence of the FMS tlv should signal that Fault OAM messages are desired. 7. Procedures for sending and receiving LSP Ping messages with OAM config need to be added and (non-)applicability at midpoints needs to be made clear. ...George --B_3396437991_4863971 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Fault OAM configuration The cur= rent drafts on Fault OAM configurations,

    draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and
    draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06

    allow for an extreme amount of control which I believe will not be implemen= ted in many cases and where implemented will not be used.

    I think a much simple configuration model would be quite sufficient.

    The current drafts allow:

    MPLS OAM FMS sub-TLV

       The "MPLS OAM FMS sub-TLV" depicted below is ca= rried as a sub-TLV of
       the "OAM Configuration sub-TLV".

            0     &= nbsp;            = ; 1            &= nbsp;      2      &nb= sp;            3=
            0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |      &= nbsp;    Type (5)  (IANA)    |  = ;      Length =3D 12     &nb= sp;      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |A|D|L|C|     = ;        Reserved   (set a= ll to 0s)        |E| PHB |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |      &= nbsp;            = ;   Refresh Timer        &= nbsp;            = ;       |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type: indicates a new type, the "MPLS OAM FMS sub-TL= V" (IANA to
       define).

       Length: indicates the TLV total length in octets.

       Signal Flags: are used to enable the following signals:
          - A: Alarm Indication Signal (AIS) as d= escribed in [MPLS-FMS]

          - D: Link Down Indication (LDI) as desc= ribed in [MPLS-FMS]

          - L: Locked Report (LKR) as described i= n [MPLS-FMS]

          - C: Client Signal Failure (CSF) as des= cribed in [MPLS-CSF]

          - Remaining bits: Reserved for future s= pecification and set to 0.

       Configuration Flags:

          - E: used to enable/disable explicitly = clearing faults

          - PHB: identifies the per-hop behavior = of packets with fault
          management information

       Refresh Timer: indicates the refresh timer (in microsecon= ds) of fault
       indication messages.  If the edge LSR receiving the = Path message can
       not support such value, it can reply back with a higher i= nterval.

    (As a preface to the following three paragraphs, it is not clear if draft-i= etf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints.   Ther= e are no procedures in the draft for sending and receiving these messages le= t alone delivering them to midpoints).

    One of the keys to scaling is to keep midpoints simple.  I do not want= to be running separate timers for every LSP that may need fault OAM.  = I believe that operators will be quite happy to configure a single timer per= node (or at most, per interface), and send all fault messages according to = that timer.  The same is true explicit clearing.  PHB,

    Midpoints will also set the LDI flag when applicable, so this bit does not = apply at midpoints.  The draft needs to say that the bit only applies t= o whether a receiver should react to the LDI flag.

    I also cannot imagine an operator wanting to be informed of Alarms but not = Locks or vice versa.  So these two bits should be eliminated or it shou= ld be made clear that they have no semantics at a midpoint.

    Alternatively, these configuration flags could be used on and end to end ba= sis to say that the receiver SHOULD treat AIS or LKR as a hard failure (LOC)= .  (This applies to the LSP-PING draft even if it is only an end to end= draft.)

    Bottom line.

    1. The refresh timer should be removed.
    2. The E flag should be removed.
    3. PHB should either be removed or said to apply only to CSF.
    4. The semantics of the D flag should be clarified to be only end-to= -end.
    5. The A and L flags should be either eliminated or given and end-to= -end semantic of LOC.
    6. For RSVP at a midpoint, the presence of the FMS tlv should signal= that Fault OAM messages are desired.
    7. Procedures for sending and receiving LSP Ping messages with OAM c= onfig need to be added and (non-)applicability at midpoints needs to be made= clear.

    ...George





     --B_3396437991_4863971-- From tnadeau@lucidvision.com Wed Aug 17 12:48:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724451F0C3F; Wed, 17 Aug 2011 12:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZT9g7mRpnrF; Wed, 17 Aug 2011 12:48:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D778A21F8BD5; Wed, 17 Aug 2011 12:48:39 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DC0411D86AB0; Wed, 17 Aug 2011 15:49:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_4C0C7CAB-803D-47D2-AFA3-DD10EEB08E14" From: Thomas Nadeau In-Reply-To: Date: Wed, 17 Aug 2011 15:49:30 -0400 Message-Id: <6804C93A-697E-48F2-BDE4-E794D3B93663@lucidvision.com> References: To: George Swallow X-Mailer: Apple Mail (2.1244.3) Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org, ccamp@ietf.org, draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext@tools.ietf.org Subject: Re: [mpls] [CCAMP] Fault OAM configuration X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 19:48:41 -0000 --Apple-Mail=_4C0C7CAB-803D-47D2-AFA3-DD10EEB08E14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree with your changes which narrow the scope of these "oam = configuration" drafts, but I'd like to open up a wider discussion as to = whether or not we should be doing this at all. If you recall I raised this issue during the PWE3 meeting in Quebec when = a related draft was presented. I raised this issue because I am very = concerned about the recent proliferation of drafts allowing = configuration via LSP ping (for MPLS-TP, GMPLS and otherwise). I totally = understand the motivation for why this is desired - configuration of = MIPs and MEPs is a royal pain. However, from an operational perspective, = configuration of network element parameters is a real pain at best if = allowed via multiple points too, which this draft effectively sets up. = In particular, for the OSS, NMS and operator there are issues like = synchronization of configuration changes, capacity planning, etc=85 that = this sort of mechanism seems to invite in. Imagine a simple scenario = where by two distant LSRs have operators sit down and enter LSP ping = commands to configure, first a MIP point at an intermediate LSR where = one creates the point and say one destroys it. What do we do now? This raises the other concern is with regard to security of such = mechanisms. I understand that most devices require some form of = authentication to gain access to the writable configuration; however, = that notwithstanding, I thought the basic premise behind MPLS-TP was to = obviate the use of the control plane for reasons pertaining to = unauthorized tampering at unsecured nodes. This seems to violate that = original tenant if allowed to be done based on the local authentication = of an LSR, which might not necessarily match that of another LSR. = Consider the case of a cable MSO with different operational domains, = where one operator isn't authorized to make configuration changes in the = other domain. In this case, they could accidentally make changes that = would confuse (at best) the running configuration of an LSR in the other = domain. =20 I think in the least, these documents should have some sort of = filtering mechanism precluding a device from accepting configuration = changes if so configured. Authentication of such requests is probably a = good idea too. This gets into your point about being specific around = the actual operation of the packet processing of these messages defined = in these drafts. =09 Since this is just my opinion, what I=92d suggest is that we have a = bit of an architectural discussion as to whether or not this is a good = idea in general. That might be a good way to guide the WGs as to where = to set the limits (if any) on this mode of configuration. --Tom > The current drafts on Fault OAM configurations, >=20 > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and > draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06=20 >=20 > allow for an extreme amount of control which I believe will not be = implemented in many cases and where implemented will not be used. >=20 > I think a much simple configuration model would be quite sufficient. >=20 > The current drafts allow: >=20 > MPLS OAM FMS sub-TLV >=20 > The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TLV = of > the "OAM Configuration sub-TLV". >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (5) (IANA) | Length =3D 12 = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|D|L|C| Reserved (set all to 0s) |E| PHB = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Refresh Timer = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to > define). >=20 > Length: indicates the TLV total length in octets. >=20 > Signal Flags: are used to enable the following signals: >=20 > - A: Alarm Indication Signal (AIS) as described in [MPLS-FMS] >=20 > - D: Link Down Indication (LDI) as described in [MPLS-FMS] >=20 > - L: Locked Report (LKR) as described in [MPLS-FMS] >=20 > - C: Client Signal Failure (CSF) as described in [MPLS-CSF] >=20 > - Remaining bits: Reserved for future specification and set to = 0. >=20 > Configuration Flags: >=20 > - E: used to enable/disable explicitly clearing faults >=20 > - PHB: identifies the per-hop behavior of packets with fault > management information >=20 > Refresh Timer: indicates the refresh timer (in microseconds) of = fault > indication messages. If the edge LSR receiving the Path message = can > not support such value, it can reply back with a higher interval. >=20 > (As a preface to the following three paragraphs, it is not clear if = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. = There are no procedures in the draft for sending and receiving these = messages let alone delivering them to midpoints). >=20 > One of the keys to scaling is to keep midpoints simple. I do not want = to be running separate timers for every LSP that may need fault OAM. I = believe that operators will be quite happy to configure a single timer = per node (or at most, per interface), and send all fault messages = according to that timer. The same is true explicit clearing. PHB,=20 >=20 > Midpoints will also set the LDI flag when applicable, so this bit does = not apply at midpoints. The draft needs to say that the bit only = applies to whether a receiver should react to the LDI flag. >=20 > I also cannot imagine an operator wanting to be informed of Alarms but = not Locks or vice versa. So these two bits should be eliminated or it = should be made clear that they have no semantics at a midpoint. >=20 > Alternatively, these configuration flags could be used on and end to = end basis to say that the receiver SHOULD treat AIS or LKR as a hard = failure (LOC). (This applies to the LSP-PING draft even if it is only = an end to end draft.) >=20 > Bottom line. >=20 > The refresh timer should be removed. > The E flag should be removed. > PHB should either be removed or said to apply only to CSF. > The semantics of the D flag should be clarified to be only end-to-end. > The A and L flags should be either eliminated or given and end-to-end = semantic of LOC. > For RSVP at a midpoint, the presence of the FMS tlv should signal that = Fault OAM messages are desired. > Procedures for sending and receiving LSP Ping messages with OAM config = need to be added and (non-)applicability at midpoints needs to be made = clear. >=20 > ...George >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp --Apple-Mail=_4C0C7CAB-803D-47D2-AFA3-DD10EEB08E14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I agree with your changes which = narrow the scope of these "oam configuration" drafts, but I'd like to = open up a wider discussion as to whether or not we should be doing this = at all.
    If you recall I = raised this issue during the PWE3 meeting in Quebec when a related draft = was presented. I raised this issue because I am very concerned = about the recent proliferation of drafts allowing configuration via LSP = ping (for MPLS-TP, GMPLS and otherwise). I totally understand the = motivation for why this is desired - configuration of MIPs and MEPs is a = royal pain. However, from an operational perspective, configuration of = network element parameters is a real pain at best if allowed via = multiple points too, which this draft effectively sets up.  In = particular, for the OSS, NMS and operator there are issues like = synchronization of configuration changes, capacity planning, etc=85 that = this sort of mechanism seems to invite in.  Imagine a simple = scenario where by two distant LSRs have operators sit down and enter LSP = ping commands to configure, first a MIP point at an intermediate LSR = where one creates the point and say one destroys it. What do we do = now?

        This raises = the other concern is with regard to security of such mechanisms. I = understand that most devices require some form of authentication to gain = access to the writable configuration; however, that notwithstanding, I = thought the basic premise behind MPLS-TP was to obviate the use of the = control plane for reasons pertaining to unauthorized tampering at = unsecured nodes. This seems to violate that original tenant if allowed = to be done based on the local authentication of an LSR, which might not = necessarily match that of another LSR. Consider the case of a cable MSO = with different operational domains, where one operator isn't authorized = to make configuration changes in the other domain. In this case, they = could accidentally make changes that would confuse (at best) the running = configuration of an LSR in the other domain.  

    I think in the least, these = documents should have some sort of filtering mechanism precluding a = device from accepting configuration changes if so configured. = Authentication of such requests is probably a good idea too.  This = gets into your point about being specific around the actual operation of = the packet processing of these messages defined in these = drafts.
    =
        Since this is just my opinion, what I=92d = suggest is that we have a bit of an architectural discussion as to = whether or not this is a good idea in general.   That might be = a good way to guide the WGs as to where to set the limits (if any) on = this mode of configuration.



    Fault OAM configuration
    The current drafts on Fault OAM = configurations,

    draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and
    draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06

    allow for an extreme amount of control which I believe will not be = implemented in many cases and where implemented will not be used.

    I think a much simple configuration model would be quite sufficient.

    The current drafts allow:

    MPLS OAM FMS sub-TLV

       The "MPLS OAM FMS sub-TLV" depicted below is carried = as a sub-TLV of
       the "OAM Configuration sub-TLV".

            0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
            0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    =        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | =           Type (5) =  (IANA)    | =        Length =3D 12 =            |
    =        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |A|D|L|C| =             Re= served   (set all to 0s) =        |E| PHB |
    =        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | =             &n= bsp;        Refresh Timer =             &n= bsp;           &nbs= p;  |
    =        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type: indicates a new type, the "MPLS OAM FMS sub-TLV" = (IANA to
       define).

       Length: indicates the TLV total length in octets.

       Signal Flags: are used to enable the following = signals:

          - A: Alarm Indication Signal (AIS) = as described in [MPLS-FMS]

          - D: Link Down Indication (LDI) as = described in [MPLS-FMS]

          - L: Locked Report (LKR) as = described in [MPLS-FMS]

          - C: Client Signal Failure (CSF) as = described in [MPLS-CSF]

          - Remaining bits: Reserved for = future specification and set to 0.

       Configuration Flags:

          - E: used to enable/disable = explicitly clearing faults

          - PHB: identifies the per-hop = behavior of packets with fault
          management information

       Refresh Timer: indicates the refresh timer (in = microseconds) of fault
       indication messages.  If the edge LSR receiving = the Path message can
       not support such value, it can reply back with a = higher interval.

    (As a preface to the following three paragraphs, it is not clear if = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints. =   There are no procedures in the draft for sending and = receiving these messages let alone delivering them to midpoints).

    One of the keys to scaling is to keep midpoints simple.  I do not = want to be running separate timers for every LSP that may need fault = OAM.  I believe that operators will be quite happy to configure a = single timer per node (or at most, per interface), and send all fault = messages according to that timer.  The same is true explicit = clearing.  PHB,

    Midpoints will also set the LDI flag when applicable, so this bit does = not apply at midpoints.  The draft needs to say that the bit only = applies to whether a receiver should react to the LDI flag.

    I also cannot imagine an operator wanting to be informed of Alarms but = not Locks or vice versa.  So these two bits should be eliminated or = it should be made clear that they have no semantics at a midpoint.

    Alternatively, these configuration flags could be used on and end to end = basis to say that the receiver SHOULD treat AIS or LKR as a hard failure = (LOC).  (This applies to the LSP-PING draft even if it is only an = end to end draft.)

    Bottom line.

    1. The refresh timer should be removed.
    2. The E flag should be removed.
    3. PHB should either be removed or said to apply = only to CSF.
    4. The semantics of the D flag should be clarified = to be only end-to-end.
    5. The A and L flags should be either eliminated = or given and end-to-end semantic of LOC.
    6. For RSVP at a midpoint, the presence of the FMS = tlv should signal that Fault OAM messages are desired.
    7. Procedures for sending and receiving LSP Ping = messages with OAM config need to be added and (non-)applicability at = midpoints needs to be made clear.

    ...George
    _______________________________________________
    CCAMP mailing = list
    CCAMP@ietf.org
    https://www.ietf.org/= mailman/listinfo/ccamp