From loa@pi.nu Wed Jun 1 02:18: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 EBFCFE069E for ; Wed, 1 Jun 2011 02:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.619 X-Spam-Level: X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 JqRFrwJHe3JW for ; Wed, 1 Jun 2011 02:18:42 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 66AFFE0694 for ; Wed, 1 Jun 2011 02:18:42 -0700 (PDT) Received: from [10.154.12.25] (unknown [192.165.126.77]) (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 28EF62A8001; Wed, 1 Jun 2011 11:18:40 +0200 (CEST) Message-ID: <4DE603EE.7050107@pi.nu> Date: Wed, 01 Jun 2011 11:18:38 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org, Ross Callon , George Swallow References: <4DCBE7BE.5010708@pi.nu> In-Reply-To: <4DCBE7BE.5010708@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 01 Jun 2011 09:18:43 -0000 Working Group, this poll has ended and we have enough support to make it a working group document. Can the authors please publish a new version of the document as: draft-ietf-mpls-seamless-mcast-00.txt without any other changes than dates and file name. /Loa On 2011-05-12 15:59, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-raggarwa-mpls-seamless-mcast-03.txt > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends on May 27th. > > /Loa > -- 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 internet-drafts@ietf.org Wed Jun 1 08:08: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 D7A6FE08AE; Wed, 1 Jun 2011 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Gdc6jLq57+Ns; Wed, 1 Jun 2011 08:08:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A99E07BE; Wed, 1 Jun 2011 08:08: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.55 Message-ID: <20110601150859.26113.78011.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 08:08:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-loss-delay-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: Wed, 01 Jun 2011 15:09: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 : Packet Loss and Delay Measurement for MPLS Networks Author(s) : Dan Frost Stewart Bryant Filename : draft-ietf-mpls-loss-delay-03.txt Pages : 50 Date : 2011-06-01 Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-loss-delay-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-loss-delay-03.txt From iesg-secretary@ietf.org Wed Jun 1 08:43:25 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 88C47E08E7; Wed, 1 Jun 2011 08:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 B5mRWMcaMHk9; Wed, 1 Jun 2011 08:43:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2492DE0837; Wed, 1 Jun 2011 08:43:25 -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.55 Message-ID: <20110601154325.3305.99411.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 08:43:25 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Packet Loss and Delay Measurement for MPLS Networks) 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: Wed, 01 Jun 2011 15:43:25 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Packet Loss and Delay Measurement for MPLS Networks' 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-06-15. 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 Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Jun 1 08:44: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 34E1DE0905; Wed, 1 Jun 2011 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 Gl+bgbkpObQG; Wed, 1 Jun 2011 08:44:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47207E090A; Wed, 1 Jun 2011 08:44:39 -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.55 Message-ID: <20110601154439.31232.60363.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 08:44:39 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks) to Informational RFC 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: Wed, 01 Jun 2011 15:44:45 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks' as an Informational RFC 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-06-15. 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 Procedures and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC XXXX. 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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] [RFC Editor, please replace XXXX with the RFC number assigned to draft-ietf-mpls-loss-delay.] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ No IPR declarations have been submitted directly on this I-D. From marla.azinger@ftr.com Wed Jun 1 08:38:35 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 A8059E08E8; Wed, 1 Jun 2011 08:38:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlvJEVQ2g4Ej; Wed, 1 Jun 2011 08:38:33 -0700 (PDT) Received: from frontiercorp.com (mail04.frontiercorp.com [66.133.172.21]) by ietfa.amsl.com (Postfix) with ESMTP id 80E60E08E3; Wed, 1 Jun 2011 08:38:32 -0700 (PDT) Received: from ([10.162.69.10]) by mail04.frontiercorp.com with ESMTP with TLS id 4LZG4M1.270939180; Wed, 01 Jun 2011 11:38:29 -0400 Received: from ROCH-EXCH1.corp.pvt ([10.160.69.50]) by nyrofcswnexht01.corp.pvt ([10.162.69.10]) with mapi; Wed, 1 Jun 2011 11:38:28 -0400 From: "Azinger, Marla" To: Gerald Ash , "rtgwg@ietf.org" Date: Wed, 1 Jun 2011 11:38:26 -0400 Thread-Topic: Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks Thread-Index: AcwbxUsq48DaIgoHQ2i4idN8vz8NtwErJ1WQ Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1049E24E45BC@ROCH-EXCH1.corp.pvt> References: <285128.82087.qm@web125919.mail.ne1.yahoo.com> In-Reply-To: <285128.82087.qm@web125919.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2E2FECEBAE57CC4BAACDE67638305F1049E24E45BCROCHEXCH1corp_" MIME-Version: 1.0 X-esp: ESP<17>= SHA:<0> SHA_FLAGS:<0> UHA:<18> ISC:<0> BAYES:<-1> SenderID:<0> DKIM:<0> TS:<0> SIG:<> DSC:<0> TRU_urllinks: <0> TRU_spam1: <0> TRU_playsites: <0> TRU_ru_spamsubj: <0> TRU_freehosting: <0> TRU_phish_spam: <0> TRU_scam_spam: <0> TRU_stock_spam: <0> TRU_embedded_image_spam: <0> TRU_money_spam: <0> URL Real-Time Signatures: <0> TRU_legal_spam: <0> TRU_watch_spam: <0> TRU_misc_spam: <0> TRU_profanity_spam: <0> TRU_html_image_spam: <0> TRU_adult_spam: <0> TRU_spam2: <0> TRU_medical_spam: <0> TRU_lotto_spam: <0> TRU_marketing_spam: <0> X-Mailman-Approved-At: Wed, 01 Jun 2011 11:07:19 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks 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, 01 Jun 2011 15:38:35 -0000 --_000_2E2FECEBAE57CC4BAACDE67638305F1049E24E45BCROCHEXCH1corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jerry- Did you get a response from anyone on this yet? Cheers Marla ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of G= erald Ash Sent: Thursday, May 26, 2011 9:51 AM To: rtgwg@ietf.org Cc: mpls@ietf.org Subject: Generic Connection Admission Control (GCAC) Algorithm Specificatio= n for IP/MPLS Networks Hi, Adrian has suggested that the RTGWG and the MPLS WG review the draft "Gener= ic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS = Networks", available at http://www.ietf.org/id/draft-ash-gcac-algorithm-sp= ec-00.txt (abstract below). The underlying goal of the work is to specify an optional GCAC algorithm fo= r IP/MPLS networks, to be adopted and implemented by vendors and service pr= oviders, that interoperates between vendor equipment and across multiple se= rvice provider domains. This would be analogous to the PNNI GCAC that was = widely adopted and helped promote interoperability of ATM networks. In add= ition, the approach: o is based on CSPF, widely implemented by vendors o does NOT include aspects of CAC that might be considered vendor proprieta= ry implementations, such as detailed path selection mechanisms o relies on available standard mechanisms for MPLS based networks, such as = RSVP, DSTE, PCE... Comments appreciated. Thanks, Jerry From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt X-RSN: 1/0/935/34473/37870 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generic Connection Admission Control (GCAC) Algorithm Specification= for IP/MPLS Networks Author(s) : G. Ash, D. McDysan Filename : draft-ash-gcac-algorithm-spec-00.txt Pages : 23 Date : 2011-1-11 This document presents a generic connection admission control (GCAC) reference model and algorithm for IP/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for example, to reject voice over Internet Protocol (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE, NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective QoS for specified QoS constraints. The source is able to compute a source route with high likelihood that MPLS GCAC via elements along the selected path will in fact admit the request. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ***** Click below to download the attachment(s) in this message: Attachment: draft_ash_gcac_algorithm_spec_00= .txt (1K) ________________________________ This communication is confidential. Frontier only sends and receives email = on the basis of the terms set out at http://www.frontier.com/email_disclaim= er. --_000_2E2FECEBAE57CC4BAACDE67638305F1049E24E45BCROCHEXCH1corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jerry-
 
Did you get a response from anyone on this yet?
 
Cheers
Marla

From: rtgwg-bounces@ietf.org [mailt= o:rtgwg-bounces@ietf.org] On Behalf Of Gerald Ash
Sent: Thursday, May 26, 2011 9:51 AM
To: rtgwg@ietf.org
Cc: mpls@ietf.org
Subject: Generic Connection Admission Control (GCAC) Algorithm Speci= fication for IP/MPLS Networks

Hi,
 
Adrian has suggested that the RTGWG and the MPLS WG review the dr= aft "Generic Connection Admission Control (GCAC) Algorithm Specification for IP/M= PLS Networks", available at  http://www.ietf.org/id/d= raft-ash-gcac-algorithm-spec-00.txt (abstract below).<= br>
The underlying goal of the work is to specify an optional GCAC algorit= hm for IP/MPLS networks, to be adopted and implemented by vendors and = service providers, that interoperates between vendor equipment and across m= ultiple service provider domains.  This would be analogous to the PNNI GCAC that was widely adopted and helpe= d promote interoperability of ATM networks.  In addition, the app= roach:
o is based on CSPF, widely implemented by vendors
o does NOT include aspects of CAC that might be considered v= endor proprietary implementations, such as detailed path selection mechanis= ms
o relies on available standard mechanisms for MPLS based networks= , such as RSVP, DSTE, PCE...
 
Comments appreciated.
 
Thanks,
Jerry
 
From: Internet-Drafts@ietf.org 
To: i-d-announce@ietf.org 
Reply-to: Internet-Drafts@ietf.org 
Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt 
X-RSN: 1/0/935/34473/37870 
 
A New Internet-Draft is available from the on-line Internet-Drafts   directories.
 
Title : Generic Connection Admission Control (GCAC) Algorithm Specification= for IP/MPLS Networks 
Author(s) : G. Ash, D. McDysan 
Filename : draft-ash-gcac-algorithm-spec-00.txt 
Pages : 23 
Date : 2011-1-11 
 
This document presents a generic connection admission control (GCAC) <= br> reference model an= d algorithm for IP/MPLS-based networks. Service 
provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for = ;
example, to reject voice over Internet Protocol (VoIP) calls when 
additional calls would adversely affect calls already in progress.   
Without MPLS GCAC, connections on congested links will suffer 
degraded quality. The MPLS GCAC algorithm can be optionally 
implemented in vendor equipment and deployed by service providers.  MPLS GCAC interoperates between vendor equipment and across multiple <= br> service provider domains. The MPLS GCAC algorithm uses available 
standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE, =
NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include  aspects of CAC that might be considered vendor proprietary 
implementations, such as detailed path selection mechanisms. MPLS 
GCAC functions are implemented in a distributed manner to deliver the =
objective QoS for specified QoS constraints. The source is able to  compute a source route with high likelihood that MPLS GCAC via 
elements along the selected path will in fact admit the request. 
MPLS GCAC is applicable to any service or flow that must meet an 
objective QoS (delay, jitter, packet loss rate) for a specified 
quantity of traffic. 
 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ash-gcac-algo= rithm-spec-00.txt

Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version of the 
Internet-Draft. 
_______________________________________________ 
I-D-Announce mailing list 
I-D-Announce@ietf.org 
https://www.ietf.or= g/mailman/listinfo/i-d-announce 
Internet-Draft directories: http://www.ietf.org/shad= ow.html 
or = ftp://ftp.ietf.org/ietf/= 1shadow-sites.txt 
 
***** 
Click below to download the attachment(s) in this message: 
<A HREF=3D"http://www.i= etf.org/ibin/c5i?mid=3D6&gid=3D0&rid=3D8&k1=3D935&file=3Di-= d-announce.37870.1.txt">Attachment: draft_ash_gcac_algorithm_spec_00.txt</A> (1K) 

This communication is conf= idential. Frontier only sends and receives email on the basis of the terms = set out at http://www.frontier.com/email_disclaimer.
 --_000_2E2FECEBAE57CC4BAACDE67638305F1049E24E45BCROCHEXCH1corp_-- From eric.gray@ericsson.com Wed Jun 1 11:14: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 C412BE0839 for ; Wed, 1 Jun 2011 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 Sqo4CpLM6ctf for ; Wed, 1 Jun 2011 11:14:27 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B030CE084D for ; Wed, 1 Jun 2011 11:13:29 -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 p51IDS61029029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Jun 2011 13:13:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 1 Jun 2011 14:13:27 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 1 Jun 2011 14:13:25 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AQHMFwT7QXSM6/mFcE6u13UrRuHfH5SXc3wAgAIxuFCADzvdgA== 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: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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, 01 Jun 2011 18:14:29 -0000 Forwarding in plain text...=20 ________________________________ From: Mach Chen [mailto:mach.chen@huawei.com]=20 Sent: Sunday, May 22, 2011 11:35 PM To: Malcolm.BETTS@zte.com.cn; adrian@olddog.co.uk Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Hi Malcolm, =20 See my response inline... =20 Ermino, We have already been round this loop on this list once. Want to do it again?=20 [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for OA= M interworking shows "layering" not gatewaying, and certainly not mixing. Tha= t is, one end of the e2e path must be capable of operating both systems, but the = other does not need to.=20 [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to.=20 [MB] It requires that one of the operators must administer both types of id= entifiers.=20 [Mach] If mixed identifiers used, seems that all relevant domains (other th= an only one domain) of the path must administer both types of identifiers, = and the operators(only prefer to ICC based Opr_ID) have to support and conf= igure both ICC and Global_ID style identifier. On the contrary, for a speci= fic LSP or PW, if only one type of identifiers is used, the operators (only= prefer to ICC based Opr_ID) can really only need to support and administer= only one type of identifiers (ICC) if they get the agreement of using ICC = type of identifier with other operators. This causes two problems a) A (potentially) new operational process must b= e invoked to assign the second identifier type and; b) Given that a node wi= ll terminate/originate traffic from/to the local network and a third party = network that node will have (different) identifiers, this will cause signif= icant issues when attempting to perform normal operational processes e.g. a= larm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers.=20 [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string) presented= matches the expected string. [Mach] Here is an example that the transit nodes may require to "inspect" t= he identifiers: MPLS-TP control plane. Because Opr_ID is part of the identi= fier of an LSP, PW and Section, the control plane has to communicate the Op= r_IDs of the LSP, PW or Section among the relevant nodes when signal the LS= P, PW or Section. Best regards, Mach =20 BTW, we just submitted two drafts that define extensions to RSVP-TE and PW = protocol for communicating Opr_ID when setup an LSP or PW. http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. >=20 > You can download the latest version of Y.1731 (the pdr version is for fre= e) at > the following URL: >=20 > http://www.itu.int/rec/T-REC-Y.1731/en >=20 > It is a pity that with the current version of the identifier draft, MPLS-= TP is > not capable to support such a network scenario. >=20 > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network support= s > >> multi carrier data plane interconnection with end to end OAM. In today= 's > >> transport network this interconnection is supported by SDH and OTN. Th= e > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solut= ion > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal serv= er > >> > layer in the transport core). If peer layer interworking ever becom= es > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, f= or > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Su= ch > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme= in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (an= d > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of t= he > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we ha= ve > >> only > >> >> really considered intra-layer misconnectivity, ie between differen= t > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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 th= is > >> >> information > >> >> is prohibited. If you've received this email in error, please let = me > >> know > >> >> immediately > >> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs= and > >> >>> ICCs. We are fine with specifications that require both ends of a= n > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global and= ICC > >> >>>> identifiers. > >> >>>> > >> >>>> The identifiers for Tunnel, LSP, PW, and MEG include fields to > >> >>> identify each > >> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or = MEG > >> >>> to use > >> >>>> either the Global-ID for both ends or or the ICC for both ends. > >> >>> Mixed use > >> >>>> is not permitted. > >> >>>> > >> >>>> The ITU liaison requests that we allow mixed use. > >> >>>> > >> >>>> The authors of the draft are very reluctant to do this. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have A= S > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test case= s. > >> >>>> The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des > >> >>> of ICC > >> >>>> and Global-ID identification is required, they can be added late= r. > >> >>>> For signaled connections, there is no plan to allow routing base= d on > >> >>> either > >> >>>> the Global-ID or ICC. That would be a radical change to how IP > >> >>> works. > >> >>>> However for IP routing to work (in order to forward the signalin= g > >> >>>> messages), the providers involved will need to run BGP and have = AS > >> >>> numbers. > >> >>>> > >> >>>> We are looking for input/consensus from the WG. > >> >>>> > >> >>>> George, Eric, & Matthew > >> >>>> _______________________________________________ > >> >>>> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Wed Jun 1 11:14: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 F207BE081B for ; Wed, 1 Jun 2011 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, 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 su+95ajiMFlx for ; Wed, 1 Jun 2011 11:14:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id E59F1E086B for ; Wed, 1 Jun 2011 11:14:14 -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 p51IE3P9015366 for ; Wed, 1 Jun 2011 13:14:14 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 1 Jun 2011 14:14:08 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 1 Jun 2011 14:14:06 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYfOILbjiXqiSrQlWlTexiSPgBaAAPAGxQAfOwdyA= 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: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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, 01 Jun 2011 18:14:30 -0000 Forwarding in plain text... ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Sunday, May 22, 2011 3:56 PM To: Malcolm.BETTS@zte.com.cn Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Thanks Malcolm, That would work. Though we would need to know a priori what IDs all other = parties were using who could enter in to client/server relationships. Further, since client/server relationships are THE critical service for a t= ransport network (non-TOS peering is not a good idea IMO for many reasons) = this means we can have inter-layer misconnectivity and thus it is simply no= t tenable to say 'we will only consider IDs from this family' anyway. Obvi= ously a single CV 'SA' structure that all parties use would be best, but if= X SA formats are used then each party really needs to be able to handle in= coming misconnected traffic from any of the X SA formats. 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 From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: 22 May 2011 13:36 To: Harrison,N,Neil,DKQ7 R Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Neil, I should have been more explicit. We have two forms of Global identifiers,= ICC based and IP based, both offer a "real" source ID. I put "real" in qu= otes since whilst it is a unique identifier it is not a routable address (i= n the Ethernet SA sense). I assume that when we get around to doing the encoding we will have a simpl= e flag to identify which type is being used to both, avoid accidental colli= sions and allow interpretation. My assertion is that their is no need, in = the data plane, to understand the semantics of the identifier to determine = if it is the correct value. The actual received value can be passed up to an OSS, off line, for further= analysis, at which level, using the type flag it should be possible to pre= sent the actual location, or at least the network that the OAM PDU was rece= ived from. This will allow the source to be identified so that the actual = route can be traced to located the point of the miss-connection. Regards, Malcolm 22/05/2011 03:19 AM To , cc , Subject RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm wrote: "[MB] Why? only the entity inserting the identifier needs to understand the= semantics, all other nodes only need to check if the (bit string) presente= d matches the expected string." IMO this is not a great idea. Indeed, just inserting any old string of sym= bols is not a great idea anyway....this was always the major weakness of BF= D as originally defined. One wants a proper SA semantic so that operations= folks cannot only detect misconnectivity they can immediately *diagnose* f= rom where it came. Note also that when we have a nested transparent (one hopes) client/server = relationship (which is a pretty fundamental capability for a useful co-ps m= ode transport network) then: - not only must we be able to detect and diagnose a source of misconn= ectivity from within this layer network (ie intra-layer misconnectivity), - we must also be able to detect and diagnose a source of misconnecti= vity from other layer networks due to a misconnectivity defect in some lowe= r server layer network (ie inter-layer misconnectivity) and not mistake thi= s for intra-layer misconnectivity. So IMO any identifiers that are used should be pukka SAs.....to use some ot= her structure is not a great idea IMO....and they must not only be unique a= cross all same technology co-ps mode layer networks that can form client/se= rver relationships they must also be known to all such layer networks, ie w= hich party owns a given SA structure, so that rapid operations diagnosis ca= n be made. I don't think sufficient attention has be paid to the diagnosis point. regards, Neil BT Design 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 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: 22 May 2011 01:04 To: adrian@olddog.co.uk Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Adrian, Please see in line below. Regards, Malcolm "Adrian Farrel" Sent by: mpls-bounces@ietf.org 20/05/2011 11:45 AM Please respond to adrian@olddog.co.uk To cc mpls@ietf.org Subject Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for OA= M interworking shows "layering" not gatewaying, and certainly not mixing. Tha= t is, one end of the e2e path must be capable of operating both systems, but the = other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of id= entifiers. This causes two problems a) A (potentially) new operational pro= cess must be invoked to assign the second identifier type and; b) Given tha= t a node will terminate/originate traffic from/to the local network and a t= hird party network that node will have (different) identifiers, this will c= ause significant issues when attempting to perform normal operational proce= sses e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string) presented= matches the expected string. None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for fre= e) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-= TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network support= s > >> multi carrier data plane interconnection with end to end OAM. In today= 's > >> transport network this interconnection is supported by SDH and OTN. Th= e > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solut= ion > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal serv= er > >> > layer in the transport core). If peer layer interworking ever becom= es > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, f= or > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Su= ch > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme= in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (an= d > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of t= he > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we ha= ve > >> only > >> >> really considered intra-layer misconnectivity, ie between differen= t > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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 th= is > >> >> information > >> >> is prohibited. If you've received this email in error, please let = me > >> know > >> >> immediately > >> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs= and > >> >>> ICCs. We are fine with specifications that require both ends of a= n > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global and= ICC > >> >>>> identifiers. > >> >>>> > >> >>>> The identifiers for Tunnel, LSP, PW, and MEG include fields to > >> >>> identify each > >> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or = MEG > >> >>> to use > >> >>>> either the Global-ID for both ends or or the ICC for both ends. > >> >>> Mixed use > >> >>>> is not permitted. > >> >>>> > >> >>>> The ITU liaison requests that we allow mixed use. > >> >>>> > >> >>>> The authors of the draft are very reluctant to do this. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have A= S > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test case= s. > >> >>>> The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des > >> >>> of ICC > >> >>>> and Global-ID identification is required, they can be added late= r. > >> >>>> For signaled connections, there is no plan to allow routing base= d on > >> >>> either > >> >>>> the Global-ID or ICC. That would be a radical change to how IP > >> >>> works. > >> >>>> However for IP routing to work (in order to forward the signalin= g > >> >>>> messages), the providers involved will need to run BGP and have = AS > >> >>> numbers. > >> >>>> > >> >>>> We are looking for input/consensus from the WG. > >> >>>> > >> >>>> George, Eric, & Matthew > >> >>>> _______________________________________________ > >> >>>> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >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 > > > > > _______________________________________________ > 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 eric.gray@ericsson.com Wed Jun 1 11:14: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 81BBFE0904 for ; Wed, 1 Jun 2011 11:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 QzqUJk9+S0a9 for ; Wed, 1 Jun 2011 11:14:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id CAB76E085B for ; Wed, 1 Jun 2011 11:14:51 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p51IEo7q015532 for ; Wed, 1 Jun 2011 13:14:51 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 1 Jun 2011 14:14:44 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 1 Jun 2011 14:14:43 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYfOxiaNjDlEnVTImxzTnximrqWgICs//Q 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: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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, 01 Jun 2011 18:14:57 -0000 Forwarding in plain text... ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Sunday, May 22, 2011 8:36 AM To: neil.2.harrison@bt.com Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Neil, I should have been more explicit. We have two forms of Global identifiers,= ICC based and IP based, both offer a "real" source ID. I put "real" in qu= otes since whilst it is a unique identifier it is not a routable address (i= n the Ethernet SA sense). I assume that when we get around to doing the encoding we will have a simpl= e flag to identify which type is being used to both, avoid accidental colli= sions and allow interpretation. My assertion is that their is no need, in = the data plane, to understand the semantics of the identifier to determine = if it is the correct value. The actual received value can be passed up to an OSS, off line, for further= analysis, at which level, using the type flag it should be possible to pre= sent the actual location, or at least the network that the OAM PDU was rece= ived from. This will allow the source to be identified so that the actual = route can be traced to located the point of the miss-connection. Regards, Malcolm 22/05/2011 03:19 AM To , cc , Subject RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm wrote: "[MB] Why? only the entity inserting the identifier needs to understand the= semantics, all other nodes only need to check if the (bit string) presente= d matches the expected string." IMO this is not a great idea. Indeed, just inserting any old string of sym= bols is not a great idea anyway....this was always the major weakness of BF= D as originally defined. One wants a proper SA semantic so that operations= folks cannot only detect misconnectivity they can immediately *diagnose* f= rom where it came. Note also that when we have a nested transparent (one hopes) client/server = relationship (which is a pretty fundamental capability for a useful co-ps m= ode transport network) then: - not only must we be able to detect and diagnose a source of misconn= ectivity from within this layer network (ie intra-layer misconnectivity), - we must also be able to detect and diagnose a source of misconnecti= vity from other layer networks due to a misconnectivity defect in some lowe= r server layer network (ie inter-layer misconnectivity) and not mistake thi= s for intra-layer misconnectivity. So IMO any identifiers that are used should be pukka SAs.....to use some ot= her structure is not a great idea IMO....and they must not only be unique a= cross all same technology co-ps mode layer networks that can form client/se= rver relationships they must also be known to all such layer networks, ie w= hich party owns a given SA structure, so that rapid operations diagnosis ca= n be made. I don't think sufficient attention has be paid to the diagnosis point. regards, Neil BT Design 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 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: 22 May 2011 01:04 To: adrian@olddog.co.uk Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Adrian, Please see in line below. Regards, Malcolm "Adrian Farrel" Sent by: mpls-bounces@ietf.org 20/05/2011 11:45 AM Please respond to adrian@olddog.co.uk To cc mpls@ietf.org Subject Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for OA= M interworking shows "layering" not gatewaying, and certainly not mixing. Tha= t is, one end of the e2e path must be capable of operating both systems, but the = other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of id= entifiers. This causes two problems a) A (potentially) new operational pro= cess must be invoked to assign the second identifier type and; b) Given tha= t a node will terminate/originate traffic from/to the local network and a t= hird party network that node will have (different) identifiers, this will c= ause significant issues when attempting to perform normal operational proce= sses e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string) presented= matches the expected string. None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for fre= e) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-= TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network support= s > >> multi carrier data plane interconnection with end to end OAM. In today= 's > >> transport network this interconnection is supported by SDH and OTN. Th= e > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solut= ion > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal serv= er > >> > layer in the transport core). If peer layer interworking ever becom= es > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, f= or > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Su= ch > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme= in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (an= d > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of t= he > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we ha= ve > >> only > >> >> really considered intra-layer misconnectivity, ie between differen= t > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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 th= is > >> >> information > >> >> is prohibited. If you've received this email in error, please let = me > >> know > >> >> immediately > >> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs= and > >> >>> ICCs. We are fine with specifications that require both ends of a= n > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global and= ICC > >> >>>> identifiers. > >> >>>> > >> >>>> The identifiers for Tunnel, LSP, PW, and MEG include fields to > >> >>> identify each > >> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or = MEG > >> >>> to use > >> >>>> either the Global-ID for both ends or or the ICC for both ends. > >> >>> Mixed use > >> >>>> is not permitted. > >> >>>> > >> >>>> The ITU liaison requests that we allow mixed use. > >> >>>> > >> >>>> The authors of the draft are very reluctant to do this. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have A= S > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test case= s. > >> >>>> The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des > >> >>> of ICC > >> >>>> and Global-ID identification is required, they can be added late= r. > >> >>>> For signaled connections, there is no plan to allow routing base= d on > >> >>> either > >> >>>> the Global-ID or ICC. That would be a radical change to how IP > >> >>> works. > >> >>>> However for IP routing to work (in order to forward the signalin= g > >> >>>> messages), the providers involved will need to run BGP and have = AS > >> >>> numbers. > >> >>>> > >> >>>> We are looking for input/consensus from the WG. > >> >>>> > >> >>>> George, Eric, & Matthew > >> >>>> _______________________________________________ > >> >>>> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >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 > > > > > _______________________________________________ > 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 eric.gray@ericsson.com Wed Jun 1 11:15: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 C3392E08B9 for ; Wed, 1 Jun 2011 11:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 LwZh-2H-iF6N for ; Wed, 1 Jun 2011 11:15:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACBBE08AC for ; Wed, 1 Jun 2011 11:15:28 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p51IFQsV015625 for ; Wed, 1 Jun 2011 13:15:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 1 Jun 2011 14:15:21 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 1 Jun 2011 14:15:19 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYGDddKGaM8MlcRTqYFr1cmZVTpAANh35wAg5fAHA= 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: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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, 01 Jun 2011 18:15:29 -0000 Forwarding in plain text... ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Sunday, May 22, 2011 3:20 AM To: Malcolm.BETTS@zte.com.cn; adrian@olddog.co.uk Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Malcolm wrote: "[MB] Why? only the entity inserting the identifier needs to understand the= semantics, all other nodes only need to check if the (bit string) presente= d matches the expected string." IMO this is not a great idea. Indeed, just inserting any old string of sym= bols is not a great idea anyway....this was always the major weakness of BF= D as originally defined. One wants a proper SA semantic so that operations= folks cannot only detect misconnectivity they can immediately *diagnose* f= rom where it came. Note also that when we have a nested transparent (one hopes) client/server = relationship (which is a pretty fundamental capability for a useful co-ps m= ode transport network) then: - not only must we be able to detect and diagnose a source of misconn= ectivity from within this layer network (ie intra-layer misconnectivity), - we must also be able to detect and diagnose a source of misconnecti= vity from other layer networks due to a misconnectivity defect in some lowe= r server layer network (ie inter-layer misconnectivity) and not mistake thi= s for intra-layer misconnectivity. So IMO any identifiers that are used should be pukka SAs.....to use some ot= her structure is not a great idea IMO....and they must not only be unique a= cross all same technology co-ps mode layer networks that can form client/se= rver relationships they must also be known to all such layer networks, ie w= hich party owns a given SA structure, so that rapid operations diagnosis ca= n be made. I don't think sufficient attention has be paid to the diagnosis point. regards, Neil BT Design 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 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: 22 May 2011 01:04 To: adrian@olddog.co.uk Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Adrian, Please see in line below. Regards, Malcolm "Adrian Farrel" Sent by: mpls-bounces@ietf.org 20/05/2011 11:45 AM Please respond to adrian@olddog.co.uk To cc mpls@ietf.org Subject Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for OA= M interworking shows "layering" not gatewaying, and certainly not mixing. Tha= t is, one end of the e2e path must be capable of operating both systems, but the = other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of id= entifiers. This causes two problems a) A (potentially) new operational pro= cess must be invoked to assign the second identifier type and; b) Given tha= t a node will terminate/originate traffic from/to the local network and a t= hird party network that node will have (different) identifiers, this will c= ause significant issues when attempting to perform normal operational proce= sses e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string) presented= matches the expected string. None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for fre= e) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-= TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network support= s > >> multi carrier data plane interconnection with end to end OAM. In today= 's > >> transport network this interconnection is supported by SDH and OTN. Th= e > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solut= ion > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal serv= er > >> > layer in the transport core). If peer layer interworking ever becom= es > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, f= or > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Su= ch > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme= in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (an= d > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of t= he > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we ha= ve > >> only > >> >> really considered intra-layer misconnectivity, ie between differen= t > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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 th= is > >> >> information > >> >> is prohibited. If you've received this email in error, please let = me > >> know > >> >> immediately > >> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs= and > >> >>> ICCs. We are fine with specifications that require both ends of a= n > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global and= ICC > >> >>>> identifiers. > >> >>>> > >> >>>> The identifiers for Tunnel, LSP, PW, and MEG include fields to > >> >>> identify each > >> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or = MEG > >> >>> to use > >> >>>> either the Global-ID for both ends or or the ICC for both ends. > >> >>> Mixed use > >> >>>> is not permitted. > >> >>>> > >> >>>> The ITU liaison requests that we allow mixed use. > >> >>>> > >> >>>> The authors of the draft are very reluctant to do this. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have A= S > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test case= s. > >> >>>> The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des > >> >>> of ICC > >> >>>> and Global-ID identification is required, they can be added late= r. > >> >>>> For signaled connections, there is no plan to allow routing base= d on > >> >>> either > >> >>>> the Global-ID or ICC. That would be a radical change to how IP > >> >>> works. > >> >>>> However for IP routing to work (in order to forward the signalin= g > >> >>>> messages), the providers involved will need to run BGP and have = AS > >> >>> numbers. > >> >>>> > >> >>>> We are looking for input/consensus from the WG. > >> >>>> > >> >>>> George, Eric, & Matthew > >> >>>> _______________________________________________ > >> >>>> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >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 > > > > > _______________________________________________ > 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 eric.gray@ericsson.com Wed Jun 1 11:16: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 44A0FE090E for ; Wed, 1 Jun 2011 11:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 F4rQISIurqmL for ; Wed, 1 Jun 2011 11:16:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC73130015 for ; Wed, 1 Jun 2011 11:16:00 -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 p51IFtKI015716 for ; Wed, 1 Jun 2011 13:15:59 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 1 Jun 2011 14:15:50 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 1 Jun 2011 14:15:49 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AQHMFwT7QXSM6/mFcE6u13UrRuHfH5SXc3wAgALCenCADqrT0A== 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: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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, 01 Jun 2011 18:16:03 -0000 Forwarding in plain text...=20 ________________________________ From: Mach Chen [mailto:mach.chen@huawei.com]=20 Sent: Monday, May 23, 2011 6:15 AM To: mpls@ietf.org Cc: adrian@olddog.co.uk Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Hi,=20 =20 Please see my response inline... =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Sunday, May 22, 2011 8:04 AM To: adrian@olddog.co.uk Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? =20 Adrian,=20 Please see in line below.=20 Regards,=20 Malcolm=20 "Adrian Farrel" =20 Sent by: mpls-bounces@ietf.org=20 20/05/2011 11:45 AM=20 Please respond to adrian@olddog.co.uk =09 To =20 =09 cc mpls@ietf.org=20 =09 Subject Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? =09 =20 =09 Ermino, We have already been round this loop on this list once. Want to do it again?=20 [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for OA= M interworking shows "layering" not gatewaying, and certainly not mixing. Tha= t is, one end of the e2e path must be capable of operating both systems, but the = other does not need to.=20 [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to.=20 [MB] It requires that one of the operators must administer both types of id= entifiers.=20 [Mach] If mixed identifiers used, seems that all relevant domains (other th= an only one domain) of the path must administer both types of identifiers, = and the operators(only prefer to ICC based Opr_ID) have to support and conf= igure both ICC and Global_ID style identifier. On the contrary, for a speci= fic LSP or PW, if only one type of identifiers is used, the operators (only= prefer to ICC based Opr_ID) can really only need to support and administer= only one type of identifiers (ICC) if they get the agreement of using ICC = type of identifier with other operators. This causes two problems a) A (potentially) new operational process must b= e invoked to assign the second identifier type and; b) Given that a node wi= ll terminate/originate traffic from/to the local network and a third party = network that node will have (different) identifiers, this will cause signif= icant issues when attempting to perform normal operational processes e.g. a= larm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers.=20 [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string) presented= matches the expected string. [Mach] Here is an example that the transit nodes may require to "inspect" t= he identifiers: MPLS-TP control plane. Because Opr_ID is part of the identi= fier of an LSP, PW and Section, the control plane has to communicate the Op= r_IDs of the LSP, PW or Section among the relevant nodes when signal the LS= P, PW or Section. Best regards, Mach =20 BTW, we just submitted two drafts that define extensions to RSVP-TE and PW = protocol for communicating Opr_ID when setup an LSP or PW. http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. >=20 > You can download the latest version of Y.1731 (the pdr version is for fre= e) at > the following URL: >=20 > http://www.itu.int/rec/T-REC-Y.1731/en >=20 > It is a pity that with the current version of the identifier draft, MPLS-= TP is > not capable to support such a network scenario. >=20 > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network support= s > >> multi carrier data plane interconnection with end to end OAM. In today= 's > >> transport network this interconnection is supported by SDH and OTN. Th= e > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solut= ion > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal serv= er > >> > layer in the transport core). If peer layer interworking ever becom= es > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, f= or > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Su= ch > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme= in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (an= d > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of t= he > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we ha= ve > >> only > >> >> really considered intra-layer misconnectivity, ie between differen= t > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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 th= is > >> >> information > >> >> is prohibited. If you've received this email in error, please let = me > >> know > >> >> immediately > >> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs= and > >> >>> ICCs. We are fine with specifications that require both ends of a= n > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global and= ICC > >> >>>> identifiers. > >> >>>> > >> >>>> The identifiers for Tunnel, LSP, PW, and MEG include fields to > >> >>> identify each > >> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or = MEG > >> >>> to use > >> >>>> either the Global-ID for both ends or or the ICC for both ends. > >> >>> Mixed use > >> >>>> is not permitted. > >> >>>> > >> >>>> The ITU liaison requests that we allow mixed use. > >> >>>> > >> >>>> The authors of the draft are very reluctant to do this. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have A= S > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test case= s. > >> >>>> The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des > >> >>> of ICC > >> >>>> and Global-ID identification is required, they can be added late= r. > >> >>>> For signaled connections, there is no plan to allow routing base= d on > >> >>> either > >> >>>> the Global-ID or ICC. That would be a radical change to how IP > >> >>> works. > >> >>>> However for IP routing to work (in order to forward the signalin= g > >> >>>> messages), the providers involved will need to run BGP and have = AS > >> >>> numbers. > >> >>>> > >> >>>> We are looking for input/consensus from the WG. > >> >>>> > >> >>>> George, Eric, & Matthew > >> >>>> _______________________________________________ > >> >>>> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Wed Jun 1 11:16: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 5A8E9130024 for ; Wed, 1 Jun 2011 11:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 l9W9Zibf7yOu for ; Wed, 1 Jun 2011 11:16:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 76785130018 for ; Wed, 1 Jun 2011 11:16:05 -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 p51IFqXP015715 for ; Wed, 1 Jun 2011 13:16:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 1 Jun 2011 14:15:54 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 1 Jun 2011 14:15:52 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AQHMGatrImDxJu5RDUehAq6m8HGoSpSbb0cwgA1r71A= 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: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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, 01 Jun 2011 18:16:10 -0000 Forwarding in plain text... ________________________________ From: Maarten vissers [mailto:maarten.vissers@huawei.com] Sent: Tuesday, May 24, 2011 1:39 AM To: mpls@ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? As Malcolm indicates, an ID mismatch process has to determine if there is a= match/mismatch between the expected ID and the received ID. Such match/mi= smatch detection process compares the received bit pattern with the expecte= d bit pattern. There is no need for the mismatch process to understand the = structure of the bit patterns. The received and accepted ID bit pattern is reported to NMS/GMPLS on reques= t of NMS/GMPLS. NMS can present the received ID on a GUI. At this point it = is helpful if the ID bit pattern is presented as an ICC, Domain Name based = sting, MAC address + 2-octet integer or Character string structured ID (ca= se of Ethernet/VPLS), or an ICC or Global-ID structured ID (case of MPLS-TP= ). In order to present the structured ID correctly on a GUI, the ID should = include a format field, format length field and an ID field. Refer to MAID = field in clause 21.6.5/802.1ag as an example. Regards, Maarten From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: 24 May 2011 02:42 To: Mach Chen Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Hi Mach, Please see in line below - marked by [MB2] Regards, Malcolm Mach Chen 22/05/2011 11:34 PM To "Malcolm.BETTS@zte.com.cn" , "adrian@oldd= og.co.uk" cc "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Malcolm, See my response inline... Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for OA= M interworking shows "layering" not gatewaying, and certainly not mixing. Tha= t is, one end of the e2e path must be capable of operating both systems, but the = other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of id= entifiers. [Mach] If mixed identifiers used, seems that all relevant domains (other th= an only one domain) of the path must administer both types of identifiers, [MB2] Why? As I have explained several times on this thread a node that re= ceives an OAM message only needs to check that it is from the expected enti= ty, no need to understand or administer the format. and the operators(only prefer to ICC based Opr_ID) have to support and con= figure both ICC and Global_ID style identifier. On the contrary, for a spec= ific LSP or PW, if only one type of identifiers is used, the operators (onl= y prefer to ICC based Opr_ID) can really only need to support and administe= r only one type of identifiers (ICC) if they get the agreement of using ICC= type of identifier with other operators. This causes two problems a) A (potentially) new operational process must b= e invoked to assign the second identifier type and; b) Given that a node wi= ll terminate/originate traffic from/to the local network and a third party = network that node will have (different) identifiers, this will cause signif= icant issues when attempting to perform normal operational processes e.g. a= larm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string) presented= matches the expected string. [Mach] Here is an example that the transit nodes may require to "inspect" t= he identifiers: MPLS-TP control plane. Because Opr_ID is part of the identi= fier of an LSP, PW and Section, the control plane has to communicate the Op= r_IDs of the LSP, PW or Section among the relevant nodes when signal the LS= P, PW or Section. [MB2] As defined in the architecture the data plane and control plane must= be independent, including the identifiers that they use. Best regards, Mach BTW, we just submitted two drafts that define extensions to RSVP-TE and PW = protocol for communicating Opr_ID when setup an LSP or PW. http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for fre= e) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-= TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network support= s > >> multi carrier data plane interconnection with end to end OAM. In today= 's > >> transport network this interconnection is supported by SDH and OTN. Th= e > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solut= ion > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal serv= er > >> > layer in the transport core). If peer layer interworking ever becom= es > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, f= or > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Su= ch > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme= in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (an= d > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of t= he > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we ha= ve > >> only > >> >> really considered intra-layer misconnectivity, ie between differen= t > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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 th= is > >> >> information > >> >> is prohibited. If you've received this email in error, please let = me > >> know > >> >> immediately > >> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs= and > >> >>> ICCs. We are fine with specifications that require both ends of a= n > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global and= ICC > >> >>>> identifiers. > >> >>>> > >> >>>> The identifiers for Tunnel, LSP, PW, and MEG include fields to > >> >>> identify each > >> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or = MEG > >> >>> to use > >> >>>> either the Global-ID for both ends or or the ICC for both ends. > >> >>> Mixed use > >> >>>> is not permitted. > >> >>>> > >> >>>> The ITU liaison requests that we allow mixed use. > >> >>>> > >> >>>> The authors of the draft are very reluctant to do this. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have A= S > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test case= s. > >> >>>> The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des > >> >>> of ICC > >> >>>> and Global-ID identification is required, they can be added late= r. > >> >>>> For signaled connections, there is no plan to allow routing base= d on > >> >>> either > >> >>>> the Global-ID or ICC. That would be a radical change to how IP > >> >>> works. > >> >>>> However for IP routing to work (in order to forward the signalin= g > >> >>>> messages), the providers involved will need to run BGP and have = AS > >> >>> numbers. > >> >>>> > >> >>>> We are looking for input/consensus from the WG. > >> >>>> > >> >>>> George, Eric, & Matthew > >> >>>> _______________________________________________ > >> >>>> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >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 > > > > > _______________________________________________ > 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 yaacov.weingarten@nsn.com Wed Jun 1 12:20: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 4DBF0E0958 for ; Wed, 1 Jun 2011 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 zNtAER0j8Spl for ; Wed, 1 Jun 2011 12:20:13 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A1456E0711 for ; Wed, 1 Jun 2011 12:20:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p51JK9W3017567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Jun 2011 21:20:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p51JK9NZ009725 for ; Wed, 1 Jun 2011 21:20:09 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 21:20:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC2090.EBA7F664" Date: Wed, 1 Jun 2011 21:20:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution of WG LC comments on Linear Protection draft Thread-index: AcwgbeitUiSNzegzTVeqsk+4sidCUQ== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 01 Jun 2011 19:20:09.0132 (UTC) FILETIME=[EBDB9EC0:01CC2090] Subject: [mpls] Resolution of WG LC comments on Linear Protection 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, 01 Jun 2011 19:20:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2090.EBA7F664 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, (Note: resent as plain text to not go beyond size limitations) A WG LC was conducted on the Linear Protection draft prior to the Prague = meetings. The authors received comments from - Jie Dong (Huawei), Xuehui Dai (ZTE), Marc Lasserre (Alcatel-Lucent), the = ITU (LS), and some offline comments. We have been laboring to make the necessary corrections to the Linear = Protection draft and will publish an updated version with corrections = relating to these LC comments and the addition of the proper IANA and = Security Consideration sections. Attached is an Excel sheet that documents the comments that were = received and the author's reply to each comment, after further = discussion with some of the commentors. Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#:=A0 +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_001_01CC2090.EBA7F664 Content-Type: application/octet-stream; name="LastCallCommentsResolved.xlsx" Content-Transfer-Encoding: base64 Content-Description: LastCallCommentsResolved.xlsx Content-Disposition: attachment; filename="LastCallCommentsResolved.xlsx" UEsDBBQABgAIAAAAIQDIo800dgEAAAQFAAATAN0BW0NvbnRlbnRfVHlwZXNdLnhtbCCi2QEooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKxUyW7CMBC9V+o/RL5WxNBDVVUEDl2OLRL0A0w8IRaObXkGCn/fSVJQqWgk FC6Jsszb5iXj6a6yyRYiGu8yMUqHIgGXe23cKhOfi7fBo0iQlNPKegeZ2AOK6eT2ZrzYB8CEpx1m oiQKT1JiXkKlMPUBHD8pfKwU8WVcyaDytVqBvB8OH2TuHYGjAdUYYjJ+gUJtLCWvO77dKlkaJ5Ln 9r2aKhMqBGtyRSxUbp3+QzLwRWFy0D7fVAydYoigNJYAVNk0RMOMcQ5EbAyFnIw/2HQ0GpKZivSu KmaQOyuJHUB7HKXsoZeIBuyuRvmfEGlvAXtTnfptQQ/MZ+KNYPEyaz8LTHmy2QGWJmAHQ3d23Zl8 +bheer++dip1G9JKGXfQfa4EXKFZ9AElF663AKgbrUEPAkNCJAPHzM5xcwFr701tUTan/i08rcYR vysD1oGliqDnxF/O6ur1/I3dpeO4i9xHuHwZh87W02c2IJt/2OQbAAD//wMAUEsDBBQABgAIAAAA IQC1VTAj9QAAAEwCAAALAM4BX3JlbHMvLnJlbHMgosoBKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMks9OwzAMxu9IvEPk++puSAihpbtM SLshVB7AJO4ftY2jJED39oQDgkpj29H2588/W97u5mlUHxxiL07DuihBsTNie9dqeK2fVg+gYiJn aRTHGo4cYVfd3mxfeKSUm2LX+6iyi4saupT8I2I0HU8UC/HscqWRMFHKYWjRkxmoZdyU5T2Gvx5Q LTzVwWoIB3sHqj76PPmytzRNb3gv5n1il06MQJ4TO8t25UNmC6nP26iaQstJgxXznNMRyfsiYwOe JtpcT/T/tjhxIkuJ0Ejg8zzfinNA6+uBLp9oqfi9zjzip4ThTWT4YcHFD1RfAAAA//8DAFBLAwQU AAYACAAAACEAgT6Ul/QAAAC6AgAAGgAIAXhsL19yZWxzL3dvcmtib29rLnhtbC5yZWxzIKIEASig AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsQwEMbvgu8Q5m7TriIim+5FhL1qfYCQ TJuybRIy45++vaGi24VlvfQS+GbI9/0yme3uaxzEBybqg1dQFSUI9CbY3ncK3prnmwcQxNpbPQSP CiYk2NXXV9sXHDTnS+T6SCK7eFLgmOOjlGQcjpqKENHnThvSqDnL1MmozUF3KDdleS/T0gPqE0+x twrS3t6CaKaYk//3Dm3bG3wK5n1Ez2ciJPE05AeIRqcOWcGPLjIjyPPxmzXjOY8Fj+mzlPNZXWKo 1mT4DOlADpGPHH8lknPnIszdmjDkdEL7yimv2/JbluXfyciTjau/AQAA//8DAFBLAwQUAAYACAAA ACEAc0cF2kYBAAAUAgAADwAAAHhsL3dvcmtib29rLnhtbIxRwW7CMAy9T9o/RLmPlo4yQLRI0zaN yzRpDM5Z49KINImSdIW/nxNUxm472c92Xvyel6tjK8k3WCe0Kuh4lFICqtJcqH1BPzcvdzNKnGeK M6kVFPQEjq7K25tlr+3hS+sDQQLlCtp4bxZJ4qoGWuZG2oDCTq1tyzxCu0+cscC4awB8K5MsTadJ y4SiZ4aF/Q+HrmtRwZOuuhaUP5NYkMzj+q4RxtFyWQsJ27Miwox5Yy3ufZSUSOb8MxceeEEnCHUP fwq2M4+dkKGbp1OalBeR75ZwqFkn/QblDezoVzbJsjgZrNgK6N3vowDJcScU131B76do7WlAAfSx sxPcN8iUT2aX2iuIfeMLOk/naVgjuWKP/uEvMRIVxX0ET8d4qBDXuD/mdiEwsWs+jgzDs4rJCtWE EAez/CHL48Rw0PIHAAD//wMAUEsDBBQABgAIAAAAIQAlIJ3ImTYAAOyVAAAUAAAAeGwvc2hhcmVk U3RyaW5ncy54bWzMndtuHNmVpu8N+B3CNNCm0GRSPEhyyVUqsCixi4YObJHVgm0Yg2BmkEwrT87I FKW+8jv01QAzwFz1g8yj+Enm+9fae8eOiKRKdrUbU11oFzMj9mEd/3XYO7/+9uN0UnyolvV4Pvtm a3/wcKuoZsP5aDy7+Wbrh8vT3V9vFfWqnI3KyXxWfbP1qaq3vn328599Xdergndn9Tdbt6vV4une Xj28raZlPZgvqhnfXM+X03LFn8ubvXqxrMpRfVtVq+lk7+Dhw8d703I82yqG8/Vs9c3W4VeHW8V6 Nv7zujrxTw6OjraefV2Pn329enZRDVcs7+u91bOv9/RR+Hi+Xg6r7qcn8+m0mq2qUXFZfVx1vz1f zhfzupx0P9db/Rl4euVzFxerclUVJ/P5EtKUWk6xfX5x8qA70OVtVYzmw7XWUKzrqmaLs3pcr/h7 8qlY8fWqWk6Lu/nyPTQuFuXqdqe4Wq+KMWTPnlxWwzl8+RSeSH+uluWsXsyXq+4XTDBefdopNjwZ v1o0+9G8g+7ij4tRdT2ejW178+vitBxP1suq4D9FivlwPtETkKQuxnUxHdc1exgUbJqn+GQ+Y49l oc2LQuNZcTQ4GBxCqmbm1adFVVyPq8noQTFfxmeOiu23FftdjT+kb1e3ZYssw096WiT8UE7WVXFV re6qalZczVe3SO2oWMzHM5Y2kawVq3lRzopyUkLti++PX77k+aJmZfpGg0zLWXlTGaPqTzBo6nxY 3bIR/p3NV0W9vr4eD8e89Bu9wiZLkUP/WYiYRhGUQ0y+Ht+sly4ZEAbRRx3q4u52PLwt6tv5ejLS Amw91ahH+ssoGH/9y/9C31bVX//yv+MqygVzLZZjPjVaF2hYmGlU1cPl+AppN8qw7NGyvF4hgsyt HZQrNrawPQ+j8Fa29iDYNtmgOGOvNzcVSr0WTxtBzTh3cTdmU/o214OuEP1Qu4i3Jd8XbqLPDkW7 ML8EMewVI3FdLZdsZgR34dIYZg5NM6VKtsUk/TOYjw7VPUqevjkPQsr/xFkgEnOPy4wTtvE+I16M jbuITvVxMYH5ENOIvIhacTufjHbn19fFajxFDpBhhl1UwzGigvaxBSyorb8sRuNr+1sccaOwJ/2U iRq5rNyZWDFncb2emZ0T21k5uie2wsaqGvUlRsb3ab0ohxhlCFdXyw/V1jOJ0XANDRHzOKPpKeLQ rNJnxkDz2fet3SAIqFxQZKR2KaMV1NmFrA58OxzsD/aL7QUqVHz1AFWztQYD8Or4d85wzH4tQ1BL 5K7KKzOBaLUp2U01gyfDQEeeaU306vzlxe7leXGxXn4YfyivxhPMW3G6LKeVGN9sbzsu6Wjw1YMB G7qTITEJNsLkpMgUEVswud5FcaH0TEKd6CXCjKeLidkGXONOMRm/r4qzyx92L4t/Gfz64eG+dqTH XkhYEMVBURwnIXDypuHq23IycduUZEpmEoqhUFgGtHR6hfXQ/sxqfWpkQU+g2tKEeojea38t8WMh wWhXDBoelzjZ4zLdRms3Cy6mn7TbsmUEkmZLM2XVBkVXry8qZJpxJxX2ZVhNJj3Nk0BoV2bzu6+/ rlyxfDXRQ86goQb9YmYHEQncTVakThuQUhbYR4Mf0sP51Z8ksrgVaPHo4RRFqFHTP6/HS2MwrDtz r/Kli9jR7PgBSG/yDjCKossH+GVU4vBhgZ07ZXuPHu4yZ2bx0lp3eOQ/sX1xBWJlIEx3ivFsxHKH qzQPMhHG3zRylANtdwfh0VLfvjh58+rVi9fPXzxn/aaDQJXqulxP+B7EtMSrurzIAy9xBavbJUwH 5jBtXbOtGk/65oeXz+XJZvMC33pjmoa1PBwcTuuBLDn/YETqqmLbRm8m/9Oa4XhqblZ0UHwnwGPL KourspYR6Fr2No8Y8Q6+lZO78lOdq1HLZriKZhRpG9s6mrfWS0Gjpc7Vx1J6PyhOWCvrk8MeYXwL 8fvb4uza0dyIv0aFFBeRcj3T2y3R3sH1S0iqSV1921WGS2GM4KmFuCCsgZj9f3YN2n+6LzjsPAdJ wRgpVv71Vf4t+8qN03Y0S26X2eA+JsvMBOvWKO3BdwpNGGdojWzQdAaQ6C9pULxDjP76l/8J1kKF HZGUE+EyTNbIPgTUTgAUaAWU6g/xbQMdEaf3s/kdiG0ht9u4qPFqBxfoxgOpn1Q3JUCwJy6CO4Ym 496Ly65E9bGC2Ky1l2vs8BJ1bllLCe342kF7tiq3/ONVj6vnDaoplwAlgY81ImDIEBZnzseEit2Y yAT/1RWSc3AsqMcQhVDGshIIOho8GXwUFPqDHOPu9d37PxZnu897xlimR5weMoaZgFqKs3U228B/ UG22XNRsIUBhQVScaPzhlJl2cBsb4gthOJkYNEWcQ8YCxI5RTsMtizu2uluVOTgVfq6KA+2tszkP pN5lIZMJa0ZvG7a4JLIaz+aT+c24Te7J+GbWh1DP3lZTYqzibfXnQfH4sY35+EmPksfD5Xz2aSp7 +/LF24BVFa0Bs4bCR0Gxei+e3JYzXAHvJeSst6ENH70Y3Qjj9166jK4FhZhWQ4YgmNA79XphYd/1 fDKZ38mFZ06MiCUIk1kVPEqxm/a1DQJZ6gXEu2Uba4uga1ns+PSTYnv/KT4siXIvws3IgWf4G8gR qM3exTiBjE37f54iUNezl292iuev3xpz9D+IiOLODdw8HhE4NG/3KNta+GVY+MywIoo1cgriEhVA 9V7OFn+hd3sPZMKYuE2cNFstCZpfIpHDjtBvBvBBCwxgyuwSK+CQFPjhAcmWeBRZzZCLIWsW3pOL spAdL7Ei52GkuprMh+8N6mR+TVvMHcVTM374sYW7MplCefvWsqXYWolDe49QEEcD7+h6Dg8kptfl cpfgxk2Oh73lpEZ8b+d3Nh0LkztLA9WVgAa40j6/Wo5RjD2wObo1X3oUIeKHmdDVtaLUYEsdp9wo oF/O1zfQorWefysnuElg9cltNXzfx7S/m68tvNLCoWLxqkkJKEjDI9Z745mowwNapJG1mBGDjMwe 2JrjmozLkg28GkTjX95Ckz6MRzgB7HGAF/6ZvGJQyndvL6WxWs20JDIQvRT16X0ClJr3efkDFhkn siafgIlGjU4mykwUFxg3KKpkTWvy6DTxcW+OX8mDXChIjCP1JDiKXkdOn8XPey+cGQatBmSAEqY1 Kl0E7hXfGTe1DWeofRudAgtqzEzIZgmDmLOYgr6a4FnPWa4l4lADmmhELpviT5SbwuUopl9sPQ5T 4uyaqTN9jT7Mhflwf8NxcJtDyMdHGry7rYCh3YqKvs1DCjfS4/G58ey9I4xWAmY0Vyq0S9zN1mEf yb9aTzAIT6XLyMAbSwUxd5BXDLlWEbIjIVPE15IrzCZ5lSjYPKeFLcekfVqcSLxEJi9FU3c8iGN6 VVYYgCEL5MZuR6qzRgrjnyeAl+UOhm/4PuDk8+RSdgpCdos9Qq7RvNcf3p6eHB0dPPnjA5lmbcIt grycNF5efehWCL4NCUjw8Z4Ja7YvrWOTI38X3wzyNIyF5xYiJ6diQ/ff48GlmxkeNTeDEFTwcVR8 IG8ksxiFzwwsBnhkCRpHkLnZtJWGCA61B35pNwaoFJAmK06OAePABEjd38XKYEpHgB4yzALgiF1i km29KrSd/69Z3bU3B2hmFHKLJDMvgiYOiTpJtVW4GE+uys6Kvm4Go18aFUi3ZcWWxKmfEPFtxITP lEopR+WCJKviEvvugSJKHI7zgkkMELiVbY3h6WRF4x6hmMHFDrpXfUFSYaHYspMKMgm8i847xmEo 8BpPoszPfM0eAK+EgZ8QQ1KGhteQC+3s5Ox/XFycwljAxJhSgZZ9vZyDCk2szKbbNjyuttlaD0Mh covSyOKOwkFMEJ69uDw11xCzl0aRQfFcyWPsrwVvHdd1fHZR3O29fH7Gt5EI3xbP2xlSTGYWLxEh VzN4Jl8m/GLuLa3P0rrOU8tLaU8xE9o1is8s6diVlyMgUJSXYBRxd83yMInyf57oyJL+iEOeJ5oS bRGAGPtW8/mEdCQ201PIwIrrWAtZ8tnNsoQu7MGBl1uZJotlHszAuuISMxfGlJA8cUQBkbI1BlZj LzGiLUAhV9fd8kXI1fPWslrcLonxZEH+/jXK5BqWzEaRh+xtVSmvIkTj97jS9u7rDcu/hMcSd605 N5wRQMmt5wGWtLEnCyG6ctvZOJfggYSsTnL0LU3tkjFfB6Y4FguSA3SfI9r8zQvawMhNKwiIzA1U 17gkrCelkzDOgOEyTgtqB5gqrM3w/YSSH3ARdQ2QOD6kkEYZs+TiA04ZXyPLlLskxyrl5VIYwaX0 5eREuy4/IPfk7ase8UBfTULDiynBzwj8BthkdpRE2EzDyQBr5EbsH2gKLXgjh9H2Qs5gUS7LLuu8 /CA8tOnbz5K1O5SkgPkFzTqlHRbXZAoVl3uFsPNUDG9ihU/5K3ck2qznXzAoPQK2BBh56QOlYvvl mwcoyX8UME2GMcGWAIp8GuCqYoMchFvcEeXZjBCWsZx9suVIJXurQRUNs8Vw4rkbuSD8HnKbPJHK SwHjBinvDWwBPSk2GKkQ6/55em+eeIbFdo56IoRTrE9FIhhc52jbSrHdFzdjZ7w0c18BakXJgPUi uAzQrnGr4ftUVY7AvW3cdkSerjwpD9GUAQ3qxgqVpPaApKwS/WwEnmgtJAqnxS/LL9wGfFYmj720 IHex/eriR2XFEX+porYMiRs6hMjQhFVbQ+3QRCb4pFDuxpNJbpQs4p9QZSPMnxHoeDB/NDjk/x5b 5ntWvLowq+lwnKdI4jgQRnxuKNTfRDytx15dbO/v7FO9O8u6IFjibflhDKtRzVcXmrpLaxH0cNOH Rxs/LO4zGK9DtO3YbC+W1QGbgKbJpy5rninzrXXDBQsNxjOAPjV/oJlEojjDgRFcwdwJtrY4KuaA S4AnG5HDo2z7vuonkN9dvu0uGyvLNDNMZLCacCtmUnhcXyqIGCubgJPcWMfPMI83OvS248ulM6Ye o2WKRyYEFK4olsNk3dZzUeNsVtUCv2DgwDGVUhvaqtaTauIszDCPlQsZ8HptufBXZ9+1wXEvi46e GpresfF8VovHYj2eqM62TLb5abFPNnC2Jjnky4otIY9sgfsH4dva2jfk8KzaZYOKdI/i9z2KmEBM Cd54SS0WVrfqFxAuVvNFjLieUg9RkC3Oe83+W2nKG8V8DWn4vualBXwE6wesbqmmHWPsaF7cYZ7W bhqa98obsgQa8A1htU8iupuASpl40oBAKu3JKVhbl/ni+RDUT1WbxJX6SEKpWKH5XUnykAE0mqaD zGOv5fRYc9licnDxrd1syB/Gzg8SkyxbkuyRSNellcp63WIaXQy93I/gqAuKNJLH7Rk9EEBZrBw/ eooAsiaqIPpkJdhtSz6p71kwhFRrQJZVQqRF7DGQWe7WjnoCcnlHUms+sWiMxFEqUJHvHa3heBnm 0AQxNwOFBTS0lpoUYngifsvWDS612Pryzd7pxR62NLn++DikEek7O+vaD7FsrdKtTI861iIqflBc qM0or0qZuKfwGluCq7EqLlPhLajTIrTAfxldr5Yg6RBPMZIKL3IkbFG+I7a0Gd7Q1Fs/zBKU9Jm3 5DrcZRwEYBHyo1m5SqTKkLnnykz8XT8IoCNAhRrsZyskX4nmZrJASnGJ3PrOVrc53WaR5aMu8Wyj 3Q8Nz6QWucB3/MB5CCBQpbKdkbHJ5RYgjtz2hf5bFoIFGmVDKWlDkCMWBG8vTvZJ4Z1toBWsgwiq Uolvdk0PHgUB3kqiY7kxE3ZPbmt6MxNUcdWI0N1q9IohPA/5liiAOcQX32XLemryzlJuV2AI69Cb zTGnZs3ztcJwOXjjq+MF2CaApMcFJ9zZai8zFThsg2ZcsYfHQ8inflXtRo+YD08M0rAz5Nghiji6 7/JlHSMsBlU3PGQYKCNwhEAxyrW/6Y1DtzVLTKLYxyhB500hGaOIacAOeE9TtTYgtTDCOFGu1BdW Fa+FIyaBh1D1R8SqZ6ORmJaZzYmH8LlsMPPt+IaIRn1ONHmpmAT/zVTj8swgtslI++GcHrpPGAJv umyS85bOwOs1VJZWH6T0nC2ohK8qmjB0XJHnufhsNY+dl4RYvvoOE+Pse81yI5SyRBIlNt8YizAR CG00MvSWLQz9BO6We0IKXc6uzf3KZzpKVdpU3mji5Sq8TQgJAg5Tu4CZF8/rDcto2TMbG3LWyCXh GcRuaGarBUxZ8aRUmhyek+PDukZ5s4CJVJCVvmJ4GOIUW6Jv1fdtuRvtvMdW0jp0n2G+jS7UNUxV rqm/IVyaQ5/HEoaiTOmap/Z4wF5O9h3WVTyO1BhPnTQ85ZTZlKgyCzrY7xoWCP5OSQHNLXpl8LlQ yVudRqEHVA0HRoIYomkBUUrET7PqGqjECFn6zqAw/SiLMbuTI7dGZUiL2HtLU8zkb1jy5uDxuQUs htYUfSLFI62SmmNtEVHcTVoZDRQLKneQncpirEbFaFPW0pwt1J7RI1VMsU/F9nhQDXZU3bbm4aRp oZQFLApGjY1gGxWain+p5JU/IHp43MZjD3aa7KV3AFgtrcnejCpZeAsfGHs5gsMms8qHQrExgup0 c5pG6mX5n5R1D/HhMWCOWdmnVlKXtE9C/FpdlWqpJWcVoUMN2Awxh3yYmjHDOxjDFAAu6fpZUm+p LYTSmBK+2JGrv80K9Su8l3wlE0GQYEn2XBxS0xvsbHXHmVN+JKdBhhcGN8GuyX1IlyN62AdE2dO6 cuqZDZTkHw0KuVBz81Sib3pVvmfvrI9/WZJQXtxqLK332uRkRpeTCaxYoD68DvGT7lbKgAnddF8L +8aytLQgZKExCTxwbV3rYoBFIw1YGKjAl3u1JisqY8NOvblQtI9xVSJoWPe9XYQbCb6xodAqkD+R gebZFIrpHxGYyp63YMPCEGCy4sPBIS2MovnVWt2PU8CHWSdR+pF3o9S03mRfSN1nuxOgr2fPIyjI myza4W67bTiLMzSJyqrz90nepAeaQVET/o0upFbPj3R0Ks3isemP8PJYHciWdMim7BaJcc0laUQ0 k5Gd3ZJo75lleSRjsLK4xPFqhcAk6TE15POYPzDsE0mxWKrVA9BkuWUJquO/mQLBTP5+A7TzJj9R gS1hZUMmIPRcB3QiK6/vJZvMiHRDIBZMIWRCN7x91VJKBLs03H38u6CjettlMxZle5DgUo9s6rSi he5a/EBucC9yXrF6xnpZmyeBtKZYP3Y8YXkgfyl+0XoB14Xpgzbe/ohGBgiJpbfsLu37XuFUlUek C7UnZvIiFcKMjwuUyXO/voA0671rbhxCJa2AVaMBp7/S2RVCBboiRk+73txoZQ3DkZzavgTZweh4 hhyT5Ax5xvuVQxyHhEMwvzUMO0sF7Y/PKTuq14nFiy4jOf7WQNsTiRZNI2rfeuBRk/lrxsS7CZ0B /akoXOYuwLRuOKyoBgvYo/vM9LRoM5mPdv9hTN5ys5QyqsZA9zw4IGCj1qW2TTH2p0iC+QCBfYFR c8Ea8e+SCkJ3erBdW1OdTtEt2IXEihCmmoMBeEDajny2zh3EjvuXF+cupBS2Sr2h8J1RzOGTFgry KElw3CDrEZ65XnNYIfvnzZosCwKCCYe79kpA6iYOXdKGydzmAe0wHSi4N3z8ONPvbucIlp1ms/NO gi8KhVzRpUWVgaeQB07Uzk1FX/NBR0BBt/ry7A6JRZfQroPwx+Sh2ZU4YQCYPcvh3QMbDIZsI/Vc jDumoxPCOkcuTnfPY3AVoiHSaRbPsArpj8ToXpvCmiXFbqANxzOZVQjk2Qjlk3VpbI6sNDaF+FCm Xvqr+ja62TaByeoRscQEQ11st9vX/SEiAkBw85CFNbYHzvYo9lIVVftodhvD1xUeVtF9CH+VjWTX QDMeV+TjzUnb1UcZkc39Tg8s+8wMGO1aL9hRUCNLVdLN50PBB5s9DBnnF/jGg1oWk0Z45D4JUYiQ tG6AdTleWu/CZh+QVOQVNNUmfL/XBMoBUhunPEsiQbOGSKIY6Y7y0aii4XlZYgRF/VfoFquUVbZe ZT/zyYt6IakOe9bZV3YRSARTpWSmIeK0/xkk2B10bCwBCflROgZMjJQguHo1iDSoBdwHhoiK1NiC ZLIFDrjIDJgB9BCKDYauNFurDlZp2GggBGgGdLTZCV2vibsKGIERyPxBAvZY+SVmVXwjlWW0XMeb LKXOgxBGu2Br9njkx7xlow5WN2GRiXGNiXutZlhbuJLIo3END+2MBVXm94WjIBbp7vFfv9rbfySD wM7BSuGwy23pemtp6MZqJ49DE9DaW5BY4RtyBVcI+8HD/YfsikzGeIr1rUTVnXwamER+AbMg/KhY T81M1mKv1VpvMuvyJWx/OHxgUvZhDo4SErRzIhu2K4OesJ6kx6hvft5M4hwSJnI83TBxx+T3sN4R qIB/7ms1CF8XxUuV8hRsdQFQVg28zxBKsL+0LKjFnOFFsJqQzViEWKMzGjyTKlcWhamGwC3i7OUD LxnCfIQW7mFmEDIruISSvLm8zP7LI9hp6mhtrNCyGQWlVrSYuULdY4gfpgK4OmpH8bINhFy9WWNb jcCDhKKl7OVnzqFDgi4zjAOGlBFP73C3jk4/OeYYGkOBIL4NxjscRhexPaVlSTTxOlr9aOYxKm7F 44F+Sm42lbZVnJ5T+XAwgLVzeGQcdNzOaVkUv+VmIYeG5mifH4YPCP9heFIvZ0zh6azeQbEc3tox NcsXYZ/t+VjEpRHfHPt9m8Effgqrl3UUQZr1o5pR9AzEyJ4132qzInOIKKND6ilW6HDZxm7sU29y MiDHlFCQWYkvvLa/raGOD3pD9E+d9h553hRohWIYTxM+fBBbkt1NmLJ4/dFSMViplDRtp7o3VAx+ NI+jI68HXUlUOXh4OxdC5EYNWEkSkYplkwUOmqMHyoluyPjkFUDIm8c2PZ3+bXYwzVKgcKcZNZur R6vLT4v508gJZ0Ox+083XG8QuBPafrpbuXjuOF5nFS3t1bSVySI3QpqSFzHDNwOxANFxBVR+8rsK 8FwbT9o4O69EMz/6wquwlRUIBvYrTB5jahqaNMMRehyd1bq8riCjgzJHxUDmZPVKgSm8Em2pViPw GrGRk8/eV5VKq2avXK+iLVBnRI8jCN2TWFUOlDwlTN8L5Cy2aQXbOwn9iOeTclbthR41YtnQS2x9 70yoCZzImGzqYN76lWyRvpY/DyKi5BOa3nAgQS9Lj2KuVOqO0e3F6Z6zUvQKE2V9FQie25yAdvWE ISmWJSCsEqPIR8ltDahPMgeLeq9au75QmFcopiBdltqTyBcfq6UOWzRVylhfZE5L3CuYTE/xoRXJ WYXCfUPJ5KKYfUx6GHsGUpY3FLwlLmhFm7FU14AxB4k857tOHaDNwTv5NMF/1VDZpUyGkGNE5HnP HQYTiGm1RBoTuFygveyFn6nUUnUfgKFRC8djGi5jof5TOXqldlzleMtNwtuYu7RtAqtjz6Zg1a/D CXyHWAlLuYq4v48OJ0JZTl0Ujx4/OkpH8OUVw9F43CR/rYpf/vroQY9xx7ohw3m3TJn+uPBiiolS 1Yn0wGQNJAxrOcVYXK+XkJsiUpYuC0FLGlDX2FzzDGzetO3eYqzi+HXngiC2HYvn34UCNClOlcMU FACdCcEsQRCP4cunpeKG0pDhuLnxihNJUst+JcLlGzXNGSgkYLf6kKdoOnejpyyCyIXDcpl7Ca0A vQ2+psXXDqLJ3Kb2ltQOY1gg6zIKtXl7kEVbsmBjb86JNcL83V0w9rrgg0ZoghcFujq0lvj+IiaL /jvbY2z3ptoNnboyconWWvqDrmhLYSaYDHTEWQpOKJKRupjGCUe4xwzfWMkxfrVp+PLqSplTe6Q4 IRUjFjrdM1cR8EkWi4H59TQWj9RACx8QgU3DKN0TgEhJ9Cf8p9qte6KkLTep7foTG+NAuYycVE7F OBDC6bDYZnJbZl/3Q9tOd7f+ca+N5phuN1b1sTjuvtB801tlprwqXjgwD60GBtyoxGAgklu0Uqo5 7Fh58FcidDe9xyDZCU7kUvT2f1KJLuIAULoZKP5ffDzMHwYLVoTRVNtQUeQalpik2fBSiDiveghu qNcOiuN4rNOyK3EyW7Il/UOCxbJUrbVjhi9Od0BAntXw76KXVNtvj3hi8T3JY+wUF3R1a8xsFRe8 EvMlbgRhjBAD9hhgGns9b+Rf8ahdnDCWanyommLBDHQBdZAorQK0sipueAAcxpE3ZY7M3gcjGC9f 0LRSlAq+1l5s0jhco0Wz7EjSTFio2ofWZhYGnKQqaWxJuXfNzY58g9CgkTxTJMvDuSE3Y29pIjOq XH8kV2a1L2vadhmz88RdcX7bJDsi9TeyxhuyRATEdzYcc8Jb28vobCtuASc9kC062NpoaCEcHTa6 Po1BDSfLdUJrKx3dULEjz7idJczuKMltlpvr+XwF3aviD0/+CPAG9ETpZMTz06fvnr50SOc+J25U hpIsgniA3biqpANmgMU6T8oFE4dXWHP7FXLRpd+ZQlAgL5Fypu9tAEkedywRVtOUaPLD8dOXb1hS cK118eaEJzwWbprFoid//a0ucWGBkCmmK/wUofT0ym6TY2rJGz7z5RuNFEnLZ67nmiHz9Q1VrcmW qUVcBmt6gpyTsbOFmeKq3ZO8Dh7FqdsjS6/DrSUY3ifdiBQrltrE3TGZG3ugYkEJLGYClfFWXkR3 /qlYKBaJKu9M9PTN763/idRuMGUG4Q4G4S3orTQyo+skYnhXj/igOrQShGUvGE85M9+v3PGe9Tgn x1z8Ezfv/MYQmbCEzXXoc/2+4a0et/lsEh7ydabJGFaPJJiVT4egkmcM5xtiM9H267dKTYR/jrLN 6ehvXejrZsbf57vTRHv+QGe+VxSBrI8lzub88t5BveZN8jCqpkUTNLqeqdilPZOpbT1gzdgIHozJ t3yMtv2HPRmJy1svPi5a9LUN2wa0vcc9Yrb3dpwT8yfvTdokKTSNYvtLoLPxlJUQKLuMyOA7Ax1r E7Qjf9DH6aWvtQdZEl8rOURErqcfIc3U0gqZv2sgh4ZLutF7k9iia4Muo+OLqUvHUzR42E2OLccs 63Az4V47v0J1DYaqgAEqMFtkZwHndtTEVp7kwVP3O37hFM7dzvc2FToogd2xK++oZ7wLV98whKob RIee8+0uPgNNL3/CgTJKCt6TBS0yQ6ftYMPFRyxjeMiC49ht0JhCMS9dQhnH64xFVsbC5O4udIAK b0I0Zh7DDjuTbcBr82lMosSzoj2e/nZeTYrvywmsmHVG3tzbx4hDXeKXwiRabdZ+cxNTyqF55sqO gOR+moS7FFNPNCzJMgI4Z7v9xY4lICNldsvSgFc8CLU8BUc+pAMzVGa19HPQau7RJZEGMnW1gsKQ JthAScIq4Udnn88QYkYzT6DzHH6NpWE2m82iYvsvrT0NZBiNRIoX+tKmwbeL9ZL0WYCGqn521mJj wV2dfHDXa1ULerUhLEtPfXyMTfJI7RZqcGkve6m7fn/rn/Hf+vec/1f/u8p93E38cGvv2dckRVAC lj3l3st9fbI8hcz+yAkKQ7ekPr0up2Ogi715oA/sdmK7OfabLV0StdSHezbD6llPZJi3uWl4s9i8 uaauYvffwWcJkAiXiGrEDgysd+wKiYP9/a94ZXaz5jiGw+jqo3J9ofMEp+HUSimICGzTN0qJEkuQ Rd7c6UhqTGrSmkkSa5jVMxeYVF3MxyXGCxgG/kTC2nxYPfM4rneEzjo6zDBZIT/TZje9akxaI3dm uNdccWbgcYbxFmmSk3TcEROturuH226s692g3QwdKAUZ3gvkB4tohFL7McPH5lfG3LiYuAxfVPd4 kxYnqfeiuzCBj+Mr6IjkSpqUBcvG1SbNQRoZq8HyL9wch+Ms3GWsOyAPnmDkAyxuFhotBU6ttVC/ Ws0IC70iPvHjHQ2QlLtkPoiGTHjV83V+YEC783dizgpavn67/XCHekgY9Iubni9eORw/6NmXt9UE sbGtKw5FIGUIs/iFAwA98cmP85r+F0uaKZUMMaBoG8ub+H41/pWXaH71+lfiNGRB+9fTWVdcFXZh Jt9xkG13Nd/FrtLbLrsm4wl3TaJGIwWerFlSr1wuZhN3yddaPmETX7EHu7zz4IkXDrRJDp+GTw8P +E9syrsIUPJ3e4JzFjupNbtYxjVX9WqNVDeyINnsr5j5LAcg2WzwDywEqPJudgMfqq6WmCkNDlQU 1N+cJZS07gA93Ng0OZ+oe1foqokwj7rIfoXIeiD3Y6tEh3wtf6PI9sT1qrphriiu1qnxJSL7LLzh yQQo0RQkae4AJpqWZzbKwJjlwAm5FdPJnX3AZIVjf12pUtm/SQl2v4VIZg5lSjRznsyOcd5/ywkG 72j23hoF/5tPct1RipQgWr/wGEk0B26WOuS4FeSR9pd4fcHBCQmXcIC27tuV34mOq6cMUOs4RIEZ Ls2Y47nte6ydN8hJ9h19944S2j6iBLGDl29aBk/qJz6FbLvFHNtY0t3fP9hgCznbrVuiIBL6HVPI pKoIhMNO+TzZFlCSqvd2QWzKO/gy405jpm5Z6SJimRk6yAwE8d+4NKlR+42Y7DWvJ+VleiYVA31B jBAarMLUGhOW+NXDB5+jPxWYIS85UoemutzuC+l+HuIOXNemE45dLpz6mf4oFWD5rhI5zuid3/+v YkBrq+z5yxlxepES7v8IHuRWOsvXw0CJaaYWZrPu4U7EAH2dcOG040Tx9LRiaI1Nb8My+O7ITWny hvOqnmtuGedkakui0JaGbVKjS6aDjgEtmeFN/iYopHdaaF3xZkQMxX3rRsJPOTn7n70LSTPj8sov odsg3ExN+wmwALyn1jzIYI4rUuE+mUbtuma8JVZRqIQmPFhsJ33y90NSk4345J0OlV4FHHvyj9LN cN9G1M1N/PvpWgh7nRN/k+7x1n+5/dtSq1S4aFzqZeffxBqst24GNhSq4AnBIOj4U2gjaTqEdHV1 ppd5JF9sC8IaYmvfqm32sN2N3Azh6qU3dUlz87ncKOcF88u9seoUk/+uWZpkBN1ivVuX31nj6idu HSWxoBZrpQrIXeKUaFyKvxYiUCHnw4mLSKj2zeTZ4pv8D6N82ca+Lb4LifImfHgyAGqjTYvd2n78 odI111bLf2pHIfo3mOcUbBaBZQHRaPH5farhJ3yobyET+eItXogxd+fLkMuZKOONN44APfROt8YJ NwzYwY6z4oYTAHUhIuu8Qpco1hugsywtcmMevf8otJPAgSFxDY0nPClpIKOg5gIDBqn9uCM0wVnz biIIRup7gh/egyZ+GR92cWp32akPANAM3+zb0cbeLGmRmrnsBlyxaAsYtRVtPGNtvSyvSL/pcuvi rda7FBm2zi8u7cwIBODXK/zutxDqWdbt4vzVC4qc66vdc8m6JdCrmTUtvbBmUqo+2nA6I8b6UVds ubvMJrQJQgSB/FI0EZh1yeDqpk0rHpR+oXe/lSzcEG1jd7HKGS1oIco/tHjKJSv9AMSE1PRk94B2 nKsoyNskCFk4C7Ej7+WVOocQOHM8ki9/51Dv0DGr0qte0QUF+h9O0A8GA2uSDoOTIyAm9D9IMuih x0whfBuG6jWmHRWHS8nMsrufmvyWDtjsLsjVc+Fy9gc9rowI1RD68NNVbgljh7S1EfdApgIm3cW4 YbIt9atpxz/lAJME3yPZlEpS+JFOGuQhWJOjaY6V9OyfpNmwkvdC1WQL0VadXELDk1pp2Y6oRHwV /FGpANvlPcqJJXJkZryShpjxhF7LjIsW/23Rt7hEn3M7vWuvMIY1ifbYuFVosacaxRuMA2anyQb9 CL9RYN/GYAH14qxXxH0x1dRk1BxmgYU6i9TCaWW2sViO3c49Lx4iiVs9jvOoa0GgQ7wtUgRqXdav TB2Bhisxxrj/fGcVvaksVOjKMNZVkR2GkZu/zWwhe7Sb0qevdJofSp9wTyIZIXdjTy3NLt5IdFJh yDPeR01DY04V/WAZGzBKc1SooIQcjGRU9EQHtpbS5hDBNT7NIoPpjQbx16KyXWuWYNXJ/NMInB9h iwYnWLPUd5ntwO+S8DP3bU/Qxi6uQcoteX9/8kCovDsKE13sAR433uNtSVM/N7kymQp3EuS5JzUK 5Fex1LrNJGO7sE4HIGll4kV7NWZSY4oqW1IM8PMFvCFryACt1dJpw+4ij2MmlUyat+LFSKQholbW /NXhCZn27XOHR6E3D0ce7mN04ScPguwRQNzZCe3QVY7uqFX05nbVb7O4IAPlEhhXp+KP7Ttt0q1I thhppCXIO59ZlT4zRM5giXcc3FhM7gCL7mU9M+5GEHkkGJ/6EHHWXKjjp81YP5uI+V3+0yjnMi3q tk9QyxXjAZ7+/Gdbl0G9AmbCIei2O5KT8Vf4Wpu8L1Uncmz9/Gdnr/gBiBBapfdEbQmNfjEGp5nO WrgliKFdRgI47HFy5iT8jENrzPSDOwY/2UaX1lCBfdotchadibSKG1rmTpqk1WU8UK8M7+rukK5g uqMJWThY5HzRHR9olGodznhTQVYUNqfxHcGFHgK/rNx5FhnPUrsbiI4g3sncB0Gsjw3x43q5KYP5 SOhMCaiECbo2enOZbCssmAL3+clFlElhRnVBs19PqqGw8yJ/Fub93/8TNrLVK0CEClW8z7HrGOiY ocZYjbqfv40pOL8lP+Q85f59gxCMfmi1Q3ffjCNymbR1EjZkgEuSAH6EL1bljWM9tNEdYTLWbxxI GvwXpNj/48Pdx48M4z052n3y1X1rwMDp/EJAsRa7Uo/3BprX1NqaSsxB/+qduIxB8TZg4jDQ/bMB fJE7adovuVHR59nvd3kGmoOf1NQScqVg1AAmrXaGBwQ9S5YNJ9tZWCcokjBbTzlmiOHLSpMb7t5s dmB0aBDclhmsWG3nLKKqpeHSHJTPFMpsfTwwlFe2FW/Ci+YEiR1h+0ytW7/q4bXu1jtBa67YRsaI I8HD0ihkle+edETJDIaCp2coG/GS0vILA6gR6FojcVf5niWqdPmYjyzzYWiI1SWPFzqTmdIiwXzV vVnOwVccI3VfbyrmvevicdPRCnz2Uyai9nVo96f4xfkmsV5GExbr2AqTUcGKN9iko7DdPaTNuWwh I3YsQulMJkZ0thxkMV2zQSz75otuxeeuwdZnHQ0e9JjULOM7YqYE8/m1TZNcvNL9C0dleaMR1t3C /OSkmt2A6YP0eWOY6MOeWE681zU28Mddfm5p/NaNrqZyBNTMZ7OpG8rn4Bc6NQffqzVL5QNdJplu JXV0chIaWKzXhu5eaG06ku5FkU6TkrmEeNHZh500M5lc6Zd2U3+N/GJraHCvG1FeTr0ODmnQMLyp VulWg0XieHU7AuXcCpivBaXJPkeXaO70gnW6W99F2FKIXHry3nA83iTHNhBaDRINWowCuPq4dcNm uGBTMAOF0BvGDVkC6YU+yCTOs0Y6z4QJpHtOXxtk2QsOlNfUXUbChTRObmJbrihEQ4brGOELNCqn C1uh5cIgiKhzvzQ3QkZPcIazts0Es1Qt3wGtQWMjQTiUgpf3H1bZ6qXyI7nxskr3jNQYsjKU5ykU Bk76/YtfdJfXWLof4q9dhMqZtyOnV3tsbt5EMNNp/k60ElCfVEVtiESC3kMS2q01lTTXmzVURgXj i5zeS95dbNxquqIQwWKztF3vP/lj5+HNyKoZIecGuTZKskFxXeA6V5A/ftDHUw0BLmGcd2dExGly LvgnnobCsQ9s2Nm2R5RkGYrwI9IWbIcgOQ8gmkOY+iHQ6fjf/VCMS0ckfOot00+82BkqO0PmqQwk wAHzDCHiN0mX6vIKJG9+Bi11wGPi4gk0sx/+7g0aph/uE0AI9zXY3iwBnG0K/cTI0JbV//WJhmCO 7I0gMY/Ez0LrhuUlTfBo+tBXrvrzUHYgGINjrC3CYUdvUlSisyQo4ObVBLtzNZcfDfygpKUbp3gv 2bTPSfdr/QiL3TYtM4Qmekl6C4Wz0flQtLMFeG2YT1g2wrlekNHwrHPI+pDtqPh5azZlRt+fhPW9 BWxCDdFLbYUDOeZdtkKNrud5L8QFBc0yhkrk7qKE/EUD0S8fPeyoy7MecyRS+s0g+30dtEwWbiS2 8NtW/FTwxO4GDMGGgKLtP5zL7O2m0bt3uvYNrDst+T3qPtYRFxNXotdwsN+Ii34Ly3OK/tMAgfvX k5K7jhokb7+pnJCyJoQI1tsvhGVXq6vbknztBvq36BEcl877a4F2RmIR74Z4EFCcSGWSql117GCn rqNBMhfggRQRkRfVOCdOYksC8vb52WdI2ZgwhjOLg2fechFM5/TD5abpzFfLsCkkPHjA/c9Kz9HW ZHaJWMN79HRtsJBEoLU9rA8a0CpvHI49wzVav6BkfTvmrvtYErLVhAMPVgDylIIUNvjogFl6++ww gBswIU9cS7Cl7Dv+Sj0oQK7bnJ8lwhSGBGcTfsje7C0a592cdploFjWZMLaCh3uBQGtpDHgXsId+ 4zA0BEMmMVlgxQunLjkXVpuLl6anH2b/sc2HcFP2R5qY23HNYj8JR6YpQWKddZTZIU7Q79Hzm/Fc 2kgZTj4mgE3KTFPxnSje7zq/BwVF6OWnwrWXzy1WUa9WZFXRmXsqlMZTD48/a3MaA2nskxLphnkO Ye0q63H6JlyptWH6Otwp3x3/X6o5zcb8uhEDzO+633qCDJ9gVLWERKDN8cn3xeXLfzNEZnzj0g+/ c0vUz/wjBPyeX9vAKLLpqV8jBGQP1z2LEMcnt/Q5US1sLg7GNag1fVF+msy5ukVQFP+pO9D4ydnR nbxUcueuUeKZmQuaxal4dTfiaNTonlYePSLbCPP36NbYZHfHORALmYggxVF0PGSLEqQVRfk21aqc aGbeIVI8ho9y+E+Y26az2xmcAN3dbHJ8EDlLekFWs3YUCRlbLGGdCxCyTs272tm9Ff5zCNAuei4x ZOO9sCqxmf77vi1hGc2TAM7naBedsgaPFkMLMi8W8DwLLbZiZUDAwcos3GGhrEC8H8FzFXaQgYCG 4RAZYR8ApP3msAJO+4syw2cW9FYnkj1O49V7DM6XEJ2anpr6GrOKW2AfdrzZwseIinjCjnq6X7Df cRJga15MvOnKtbnLADbZG4oYx5T2NwY8Xr2vYdMJmXIkuYSApCwEqIw2BkfvuzejZbdBqQEWS6PR WfUtJ+CL0SoL/fCKSXE42lpculW/ojYmLeiXnPo/L7uWOgOcws3LbBHgENAf14Txa1f1GtdWbEd1 CRhD37yt/gw0wFXqj+QsHthHDCQRiff9+Y0RQj886xUtWU1lBqjhaIxwHgW5VIv2SCJqFI8y2xOp TYp4iUgF2S0WYwwZu/O0FAut4++RH2odxo4AHXA76dSueammvqelqT07Ci37MvjRW47Ga5gh8mcX OzVpAlIrea+rA4VdC7SyzEEs1eZD7Mb7p9iIVqQ78DQNmCDmkNJdhbmYEqPYGY69WMpNASzr1Skv iB3gcWcFpIdCsGbUajqn/c4xs1yOc92BHgw4jyo6ePC2kQRJPaJaBS73fn/xx9bWNRGZ8lxkiFAZ HK/fohWecdAKs2PEHj9ekX4SFxAYx1/IH3pXcvs+aBNt048dpONiyRZIelP4Z6Ug4U+lQTWLfrkj Di+B9l/rRXEvTOR5RGrsFsusJ/aD71Ibj0Fu3gsVU+t0yXjEN+k0QLxpGaLf2alGBLX5lV+7LIRP 7lWmzNmaM4sxmXahswh2nj2rgycsF+tSFmLb3T6SJRyK3QEoG4m4+T2A+BUNZymkHIBR8EtKimJG DE3l8TM8fiGXqOHIGKp6bAs6HBwaYSm4wEdWAQc1vS5Er0a/SBfyGhg3n2DpcQ0jqzcerjn+pQNm dBfAmIvv3/zw8rmMRbpAHyhk2d0wucCRLkUxHNQzCZlI/kA529t1aYvFGdhZuuxWrwid041WPE9o HK52TBLpRhiHC5BPsa0QRovVIJ8AePIZuIIhAylwSKDThxpOOAmIR9N99pbwMKunuy3ESX+Oiq+2 4CFxOzjF1OtkLvZclMznLPPugRDTCj5DXZl8D84ITD9HuhN4Yj8OzOjoh1chTmlDlqyIEGHcJNtF ltfNXjG50+6IMjB5ZkXpjRxWu/rxR3Ouvv5wnjyN15XCTY7HDHi46khkCnlR7V95ivqWGS3mDXVt BXIxthf1zKBEtCokZdlzjYS/NGaivfwb2jkZjd0zSAyKwa4p+bStrZEP84fm19d2mX1zp2i/eWHj jt7BSiM9CMbRi3WO2w/cJ5MXLmyWH9oyE7AgnrO+wFSLwvwqKyZLGdxMTB9kpqxsnaNtfp3B6MK+ JeOiWaqcZbbICwaxMyg5cq2pZZX0N/I5CvdRN6SULI48NEfTsJ+q6DNp7HNv8FtcebR6yiT2ctab qKnA0zJbRw+Tn7Ft4cjT3VwpxI9nbPtY1rhO4sC3kr+LzFwvCfDlEZKd/0LFYtTQCKMI3NyMLfZJ ryKcmbQLZRMQNX/yMwm7L37w0txvJAsiraqJuxNTI9CK4LSslCtTMI/iH5zFvPEuiQA/2SwNwca7 3eUL/hT7U0bIL8Lj81V4LV4maDmhnkVqPGTiZZ88XD6wQ6vrcqiLZTGpy1695bNfflxXt+sxEjru 2pw/jRW95cXIvbpePft/AgAAAP//AwBQSwMEFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAB4bC93 b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc4SPwYrCMBRF9wP+Q3h7k9aFDENTNyK4VecD YvraBtuXkPcU/XuzHGXA5eVwz+U2m/s8qRtmDpEs1LoCheRjF2iw8HvaLb9BsTjq3BQJLTyQYdMu vpoDTk5KiceQWBULsYVRJP0Yw37E2bGOCamQPubZSYl5MMn5ixvQrKpqbfJfB7QvTrXvLOR9V4M6 PVJZ/uyOfR88bqO/zkjyz4RJOZBgPqJIOchF7fKAYkHrd/aea30OBKZtzMvz9gkAAP//AwBQSwME FAAGAAgAAAAhAOmmJbiCBgAAUxsAABMAAAB4bC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2Hcg dG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0wbCvQArt0nyZbh60D+hX2 SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4aHt3hv1LGx6SCsdjzHhM 2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCCVxFUxgIfAd2IVdaq1WYl wjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWXCXSIWdsDPmN+NCQPlIcY lgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy+gbA1DKu1+t1e7WcngFg 3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+1pfwG9VmfXvNwRuQxTeW 8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8o5rCFyiIhjy6NIsJj9Wq WIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVNVNv7MMGQEQt6r55//+r5 U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX5XhZxP/6wye//Px5ORAy aCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNxvhXDEFNnBQ6Bdgnpngod 4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/MqWHg4i4Ny5mJWxB1gfFjG u4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJLPlHoHkUdTEtNMqQjJ5AW i3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRziiBUNfhOrsEzIwVz4RVxP KvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3xFFShh3QOCxiP5BTCFGM 9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpkJ7Uso1E79jWj8d8WYUajGNgbeFeO2tw1b U1lK7J4owatw/8HCu4Nn8T6BWF/eeN7V3Xd113vr6+6qXD5rtV0UWKi9unmwfbHpkqOVTfKEMjZQ c0ZuStMnS9gsxn0Y1OvMAZHkh6YkhMe0uDu4QGCzBgmuPqIqHIQ4gR675mkigUxJBxIlXMLZzgyX 0tZ46NOVPRk29JnB1gOJ1R4f2+F1PZwdDXIyZssJzPkzY7SuCZyV2fqVlCio/TrMalqoM3OrGdFM qXO45SqDD5dVg8HcmtCFIOhdwMpNOKJr1nA2wYyMtd3tBpy5xXjhIl0kQzwmqY+03ss+qhknZbFi LgMgdkp8pM95p1itwK2lyb4Bt7M4qciuvoJd5r038VIWwQsv6bw9kY4sLiYni9FR22s11hoe8nHS 9iZwrIXHKAGvS934YRbA3ZCvhA37U5PZZPnCm61MMTcJanBTYe2+pLBTBxIh1Q6WoQ0NM5WGAIs1 Jyv/WgPMelEK2Eh/DSnWNyAY/jUpwI6ua8lkQnxVdHZhRNvOvqallM8UEYNwfIRGbCYOMLhfhyro M6YSbidMRdAvcJWmrW2m3OKcJl3xAsvg7DhmSYjTcqtTNMtkCzd5nMtg3grigW6lshvlzq+KSfkL UqUYxv8zVfR+AtcF62PtAR9ucgVGOl/bHhcq5FCFkpD6fQGNg6kdEC1wHQvTEFRwn2z+C3Ko/9uc szRMWsOpTx3QAAkK+5EKBSH7UJZM9J1CrJbuXZYkSwmZiCqIKxMr9ogcEjbUNbCp93YPhRDqppqk ZcDgTsaf+55m0CjQTU4x35waku+9Ngf+6c7HJjMo5dZh09Bk9s9FLNlV7XqzPNt7i4roiUWbVc+y ApgVtoJWmvavKcI5t1pbsZY0XmtkwoEXlzWGwbwhSuDSB+k/sP9R4TP7cUJvqEN+ALUVwbcGTQzC BqL6km08kC6QdnAEjZMdtMGkSVnTpq2Ttlq2WV9wp5vzPWFsLdlZ/H1OY+fNmcvOycWLNHZqYcfW dmylqcGzJ1MUhibZQcY4xnzVKn544qP74OgduOKfMSVNMMFnJYGh9RyYPIDktxzN0q2/AAAA//8D AFBLAwQUAAYACAAAACEAbmfUDggDAAAODAAADQAAAHhsL3N0eWxlcy54bWy8Vm1vmzAQ/j5p/wHx fSXQvDQTUE2Vok3aqknNpH01YMCaX5DtdKS/fmcbCOmSppHSfkiwD989d8fdc45vW0a9RywVETzx w6uJ72Gei4LwKvF/rVefbnxPacQLRAXHib/Fyr9NP36Ild5S/FBjrD0wwVXi11o3n4NA5TVmSF2J BnN4UwrJkIatrALVSIwKZZQYDaLJZB4wRLifxqXgWnm52HCd+PNOkMbqyXtEFPwK/SCNc0GF9DSY B0eshCOG3Yk7REkmiTlWIkbo1okjq1cjqcBPZ2qxMDLrZafLCBfSCAPjhnMmjTNzqse/tnbG+Fby lvgD9uQ/7DeP/TLYp3N8GZy9z7Zv8nUf6CVHrXEFRUEoHSr02lQoCNK4QVpjyVew8br1ettAfXJo F1dT9tyJ05VE2zCavV5BCUoK40V1N65K6FZNTA9Nrq6Xy+ViNruZhctoCj9bNFl3nPACt7iAXnOY ozBMG1iX7QMiz4QsgCD67owA1YnSmOJSQ5tIUtXmqUUD/5nQWjBYFARVgiMKy6DX6J8vaALfALUk vq5J/gfA9tp+ugtwCgHeTBfTyWI6i+a20wHGYB+G7nyAiHJM6YMB+V3uhdWWHt+wFdPfIDPAhIYO +iWkpFu6ENwGQjumFIL+ISWQo6ah2/sNy7BcWXq0aFZqCmm3+0JJxRm2H7RT+ymFxrm2dG2ZIRhH 42IbhQXMedxFE+IhF0HelicDjE5ru0hXkMaOsI8l62xbzvIoPyZOmAEuXV4tJHkCWDM8csgfdvze lseTcWkX/krUrHHbRx68hD2qFXBjV2Agdx+iLxpXHv3ukuG/gwveOSm59Oc4UBFn+fOKXjm/Jt/Z g3PyD0R7ihv2u/tE9Odgz94B29ImEOVoGuzNgoFVPXOHSPyvcHOFS7EHdTm0ZLYhFMatYcrQ3iqf K90bdqe9BpTQSOMZeYMjRbsbR/atRhncsc2gGlwDGwUu0Ybq9fAy8XfrH7ggG7YcTv0kj0JbE4m/ W383Azuc2+uGnbb2Ip/+AwAA//8DAFBLAwQUAAYACAAAACEA/+HKAyIRAACvWAAAGAAAAHhsL3dv cmtzaGVldHMvc2hlZXQxLnhtbIyc33PjuA3H3zvT/8Hj9yYiZfnHziY3K0s7vZl2ptO7ts++xNl4 LolT27t7/e8LEpAIgKC1+5BkrY9IfAkQhGhJH3/64/Vl9m1/Oh+Ob3dzd1PNZ/u3h+Pj4e3L3fxf v37+y3o+O192b4+7l+Pb/m7+v/15/tP9n//08fvx9Pv5eb+/zKCFt/Pd/Plyef9we3t+eN6/7s43 x/f9Gxx5Op5edxf47+nL7fn9tN89xpNeX259VS1vX3eHtzm28OH0I20cn54OD/vu+PD1df92wUZO +5fdBew/Px/ez/P7j48HOBYEzU77p7v5J/fhs1tU89v7j7Hvfx/238/s79ll99sv+5f9w2X/CEMw n12O73/bP122+5cXOHu9mM+C2N+Ox9/DqT8DVEEv53hK6GX3cDl82yPeLsOA/Td23LoPrasW62a1 DJ3fjr3zvwdLPseB+sdp9rh/2n19ufzz+P2v+8OX5wuY1ITTH44vwMLP2eshuGo+e939EX9/Pzxe nuGvxc26aRbL9aqZzx6+ni/H1//QETofz/R0JvwezqxvmlVVOw8nni//ewE/r642UVMT8JuaqH3W BBy8YgWMarQ/jC5auXA3ft24ZsnMuN4GmBvbgN/Uhl/dLHyzWnMp19tYUhvwe2iDjUYu4Bb9EH3Z 7S67+4+n4/cZxC445Py+CzPBfYDG4DdIw/PRtxGJ/oQQuTwfHn5vj8G7EEsPoYFPoYV4Fnwa4vjb ffXx9hsEywMRLRIgdyScJLY54SXR5UQtiT4nvGtG5hb0jqIhhrjooK6BSCB9vx7fub4A383h52j9 Ymw1jkCLBMTeSDi/lMwWGXDqyCTbYitdTqxlG31OeJdGUiiEjrTC5QIUDk4Lx6+LQuK6KGTg5yhK ye5yYqNE5YRbpaERoiAytSjn1zcw8QZZgbguCwkuyy9UvG6R4bJW0uguJ5xqpM8RzxihCwJP6/Ju xbwVgOuykLguCxkuy+lZZiApwGKY9jnivWrm88CE5YPPu5BgWLIJ884v10woZiCI8zGg9FxD4rpQ ZITQFFE42QxE5xMDWaXwFrrAHK3LLVKGDIel+5yWhch1WcgIWckelGUgKnR7RBxUTOMY+ypBQlco CpS/RBYJx4OwkPTdjavEPxU4LcJcYp4lkRESVRLsDESnlBzxPgWAULiZUBiO/7BChK8rRIYr9Cpz dAaixrLPEbcq+DB4WjuxcTdQbQ1JMxJJpJrMLR2+LosgoSsNOQanxajOeoNxqxQCwncurPgqPF1T C2lYFAwRqnprYwuxakxzYaHywJYgLs01abBJG3YkoWR3hHpqKWhM/VWJkurCap/Ujc7CIgAV+RsV GK3DwxPOQogb65XqjhoSjEpavcEU124HLTE5s5D7RS6JwBCFhrBwvnRVnj6oDWG0TpEWo7zZWwxb K6WfwkKf/BSF+SUvShyWAkWX4eEJlxnlRAocikGD0amRbOEj5FYJksrCMn5dGS70RWV4eELZUCyk OVHrjAiXksH53OpaRX5vMG6dGpLKwtqulMlgxMW/KAwPc2E+zxtGAbFMBpHPDKhJ/qC8YUDrpF9K A6NGaTBs8dpGpvtADBNNTfvW4cGryjqCuDvcMtlDRmNLAlqnBCyNDiv24A8y2tWrMInoWnTcVEir Fq7ykMrGXFqrFad1yHA1RtLIy4U62UluMpgsG+aM9wmSgsMCrgRvXLgCxUtvQy4u+RiRdZ738TAE yjgaTk+jrTPKBj2POhNS49Fb0DrFktDqeQEyRCSkqpLSyI/xmSmlw8Kndeo6+mtLkAi+OvkCnWpC KoR6Cypdn3pekAxh7ML1TVnsUKAkv9VqxWpjs3Lpy69ZCeKK9ah0BuPUyPUWs04jJz0b6ggVxc41 7HrOY6VRilo6zH1pKMurlVot2B01xNXnyvJ2vE9ZSyqDlrQyeaXqAxGiNDlO7yO0xEzIw4a46bVe 2akhzuTy8naKxZgPlYJ23GrDi5aITOnDgmNCX16V1GqB66iz6/rydlwxMGHGaX2bsPsdJ/6nuFM7 pS00MTnpEOJ2L1JEUZYxGJ1OySDejlunTCRDMxQDyneidvFYLVyPTGQmPIeQsMpnM8+AspxiMOuU 5aQ8sEnLk+W0D4TyngqolhiuL1/4CeL6dBHXWUzKhtHDvcGUZ14oEpT3lDwsI7j7GlU1th6ZCXl5 PbJIMUXBaTDJMSQvZ8ryjLpGBudQxlxLm8hMqMtrmUUWmwajUmvvc6aYVmqjkqk3Y1qJh1Vgas8R c10bQTwwG51WLEanFWLEfkPRdbVRvKyqa7VLPGNKL9Y3E3oR4nphX19tuVNvHGp0ojGYYh6tQzmg ZqLcF4vElL7Qilwm8kRDDQnTVRLpLEbN1t5g3DoFvcijNfQ2yoP8G64D2RIYD09pC01MakNIaFPZ uKPOBKOzjMG4dYoBqY2XL6SNz0OsFHgG1dfdbY0Mj8u88iRI2J2GGzOoxSSzMYMajFunQZLaeOmy TLkFqwihSU33tkaGazJiMS9HnE+2kCgDyuaawZQujOpQAAxzjRwmV71IyHjUOwotMRP6Qldyq2iZ zTWDyeTlDNz6MeYk6TMwScvj8RgOS20rZVJbIzOhDSEej0uVIzpqSDDZXMvbcZuStrD6K9dxbVgc 8LjMtSHDtRlzLa8yltlcM5hsruVMeT0Pa7/S5qomfIFQvGAH7dPORIYLNiZiXniskg9oHubMUs3V ngziDnebVC2IQIXbiQzBnn9jEpGJYCWG68sdShC3a5XMQn0Wo7JabzCefVsh9fEahvKMqyEiSntN 8CVt5k01o1pipFpl5ZYgrtbre0A6A3Ir1VJvQZsESb2h+sgCWPozIMqfmUJkuMI8XhcIcYUrlTQ7 g8n2KSxmkxqS+qC3TB8M0HAhvwjHp8QhMyEOIfg5bp+yb0UoWA1GZ1YyiLfj2SWzFHe9ilnkVQxb XqNJLTET2rAhbhP7rpi0GYzOrNQZb8cz70ptoTjQgSl2BhdYPkBQjSPOvh0gechweUaeQYibxb4b IXkGo3JtTwaJiyVfpWwr9YXqQOmTBc0C6weuzy3TNCaBCEmBaS6Q8QhxgW6poJ66ExALF2k89KeN d2GLsZglwwlymrHylaQgw6UYOQQhbiX71oDkGoyqlvpFznh9G8XnEdJ3IS1CiaCct4pfNo15BYsI 3LZe3FQb8U9N+ja2N3WdRJCQrvJwZzBsgsXh6Q3Gs2tl6ehQPgxCYQqEa8Dawf2q8HfR11hy/Kh0 pLnXjRmaVzFs94+8njO59Jzx7NJFSG94pYOzfywD1H2ti2pzbZcjtgT3KsCi8+1+MhaIvj4gBIlY 0LWuxeiMbDBuk+aKHBBeGlEsNPE2hWIoNFgcwc8xRbOrBJz2xHC9+bQniOtlFSoGgMFkSc5g3CZN Iqk3lCsq9qf0YoXD9Tq9Y9o2CHHBXu/5bwnigt1CpY3OhFQY9Abkq9SSlAz9acnrCReHU0Jm/7Hg RlpqV+votkEIfqaoUeteZzDZbDcYz26blMp5KUXBvYhlcDm4h/Lqx5QjLZXrq5kmL6LcIk1HzN8W tCk5NCQuHcPQSSl3N5joZM2hDGgJklJUObEliDvRZVsNJpSkkF60ibfkq9Kc5VUVudGFTc+i4KHI QieqMGsbq7zK4jUvr9jlCCWnnMnj1WA2aTrLeIXR145dV1fX5SackmZqJhUPC6865YsttSF84ZKJ pBVbklC28lhQoVZueLlFXpW1ciRkfclGLprVEsMFGgsN1m3cdrYekj6DSfEYmZ464+0UvzdpQlWi JinbIIuHp7RhYTOhLa9+WN4gbTmTx6nBlK4UlqqKCgWkeuIiIhP6iOH68iqRID7mGxV2ncWkqEPf GYxnd0KJebg0iiL40my4DIiHp7RhkTShDSGuDW6WHzeT0XnUm4BUXu4tpnSjwDJUKiow3SYs9bG/ T/H4lDqr2lFGbakhYXi2d2tBej+wtyAWBNJ30F8mD57nu7Z5uwznBMm4XighLR3mvsxzDEFCbaVL ARNSObs3IM9ux5NqQ22hnCm+WF9i8SHWfvZYR3R5SxAXmN232hEkBC7VTOwNqGx7KAEG22GVjFmk EruUS6wSJqxHSFqvZtGWWhLWV6oG6kxIRUNvQJ7dmSXdExZ/LVE+irDE+mBCIkITEhGSEtUS1lF3 ElIFQW9AXt/7+nmE9D7KEszMRCu/BkTmGJdHJUJctDHtEBJ6nIrKLlokv/zL1j+D8SxApFt56QKj HiOXp1CsJYRP9Rc0+Gi13B4yJl1elTj9dVAfH9KW8jy7yVOaHpZ5FZFyk2uJhYAwnl1gUcZAaMI3 RknBHmuh5c2AsilnMKXlbcVrE/KNyIgRULGX6SOI68sv5wkSsbfQsWdCujgxIF+lURAeXPHixBSI VYVwoL5PqI2t6OhTy9WWICFQ33TWmZBe0wzIsxuapUCw/HqIrgKhXJgrRGjChQhJhWngMUSpOwmp taO3oFL9vIKmtEJ5g3QkJhWGZiZ9iJA0Xq8K1J2E9KpgQJ7dcS19yOsSClJ5cbcyCpPsFgGCpA9V bG0JEsbrryB7E0rDII03ChOZI0MxqQOQhTPmSIKk8dkUw5aE8WxQKQARgiw47p3B19fyOqGn7sQX VcWrU3iHRxaBMksGQAUge20CKUSIK8xX6NiVXJ0c+/6MFGJLYhjYY/ER6o2WPHt6Q/oQjNJTjN3n tgqHJ+UhxOUZiwBCwvKFCtGOupOQSjO9AXn26JKUZ1QgdXzEtbgptjKKEr0V1BIkJetamiChhr1w gjxqVC6ZYoMp5sxQA6jCRd6XucIqATJ6miV6G6slaEKgUW+w5zxJoAVlChH6sUm5NkoXta0SER23 KlG3BF3XSJB0oqpLOgvSX6j2BuSrNANE3K558QJZzdg5isikRKxxuMQ881BLQiK7RQjdaEIqS/cE CTd6dnUvNYaaYohU0sh2/tZYcsgwzVyI0IQ+hKS+NPCkz4B0lJJJQl5x6VhDf1qeXNojoTyon+1p CeIK8+RKkFCoH6fqTCjzYLBarkKe2SQdyIsXcqBv4v1/wyZZeI1Wtn5kTkSISzSCFCEhkT0eSk60 oFS9RKgnm0RLmzSjpcRQUagYhftwrm2SrcMpwav6en/Na4n0+oj4scnDgLC+xyENH5s8X+tY+8N6 ltkTcm7SNraPqTi3H8oCi48fW/ZsZA4b2o8fm3yYgbk9sF9g692EUDV4jGDD/hAcBo8xY/DS96P9 Jf9ubP/Gj0293L/pprxNyb8b7l/Gl/y74f5lfMm/sKXOBiidgJ9bClzFXczPwGUnH1NXcSfzM0pe dhV3Mz+j5Gd4+V5BR8nTcNNy4YySr13Fnc2twgLdUm67G/bzoG97dG2Hu6rkcbheKOgo+jysZeOk YDri56ZV4rUx/Iyiz+N7ToaJx88o+jy+QMQ6o+jz+GIO64yiz+MLL6wzij53BZ/Hz+2xKvic3gBh REl85YJlVdHn8V0C1hlFn8dn8o0z6Fl9w6r4VLt1RtHnvjDP4+fmWMWHtK0+ij4Xj2GzuBqfvdYr Hr4f0uqj6PP4NLB1RnGex8dZrTOK8zw+jmqdUfR5fOrSOqPo8/gso3EGPeNo+Fw80MhGd3xsMRvd +Hyd1Udxnoun7HgfRZ/HZ8GsPorzPD7WZZ1R9Ll43IpbVfR5fGrI6qPo8/BUhZV34+fm/IgPqlh9 FH0eH/0wzqBHQpjP8SW1+GLT992X/d93py+Ht/PsBV6IC++9vQEZJ3wrbfwbXpUbP4UR/O14gTfO Dv97hjf97uGlptUNOPDpeLwM/4FYCe3+sr98fZ8dTwd4i298ee/d/P14upx2hwv08OHweDc//fzo Yuk8vmr4/v8CAAAA//8DAFBLAwQUAAYACAAAACEApG5j6RwLAAC0GwAAJwAAAHhsL3ByaW50ZXJT ZXR0aW5ncy9wcmludGVyU2V0dGluZ3MxLmJpbuxXZ1BT2xbeoBQBKVcUASNFuYiU0JGaR1OUekMJ FxEMEEIIELqJSFAUUKoFBAKIipoLKIhUpSlFRCJN6RAFKdINCIgIeSeWmTf+uHNn3vv1hrVn7fWt tffa5+xvzppZxxk4g6PAAtgBQ2ALLIE1UIaGChQ1g7DZtyhrVgOqwAiK/ypsWwHnIOgVs2UCdjbA BqZ4CNwekBUAjpDPDs3skGcBMCAYGhgQCCTBAXAIKAENCBEhVYGGNJD79eC/8dl+rG2FLDukP/1f U2yQRx1GlH+N/vf+7m9HCMqyBgAs/S5PQfKWn5hl/9P5iU1EBIGz+RbgZcx6++/C4u1XUXmvtoUD CjKhNZb+zP9136b//83Ar1/GU+i6tpZ2x1i3FgQPgeO3miJ8qyQUIED1hQfGUMwPqrZAyEpCdaYJ Ve8hCNlAFQ6ABQbtgfPDmnpgMQDYoLEYW9xpDBQNDsYEfvORGCyO4AeASYi/D4b4w1gR7EJ83Xww AIkJIviEBLN2aCorEyH18Mex3uafiYkIACpWSEfWvfgg/E+l5FVCCCdUB4htglAKG+CS5BX+9I0c S1vjw6xTpLexZgAUvhuwhe17XWkrA4CEYizPGv5j8YeBw+393Am+/oGYoCCMh6IJOhgNhwMBVVzP C25ruLF5oxPOxxm102CedAkmi4uFOT1PVLOkNOAyMcsq7Xllr9sbQzqLcHwnIvG6CZfcdXfoFpnL yZlP1iFzvTF1nYfZQzr+ZR5RYmkeJ8hubyO1FbnN1M7QSJLNW7KUx4hnWHdiUGvRs9mrk0gfzJ9Y q64krwwGtVVPJOhWnl4To4wrGn2YeVJALZbvsG0jbDchvAl0ud1Us2de055ZtrPZqXHlgdEj/opo hTD9Tu9RzgNmoRmkvlgvQns/Kmg24al9Q/hAhnrYEs/+jJ0EtyrTgOQAG0aAnxhysG0VdbBg/KuL KK/k8Fk2Rf1mDQJXAZUtYzRXeu3mruUTkaNSjVS46cLD1lPak2fwR1ueP565UochBPS5x0r4HlaV Lb7WmUNZP4iNsPVPaKz7fB1NjxwdiNV1kF5NdENMIJSG+IJad4gSLfA+o/0Id6PrY4KPXLsf5ROR CDhymTf94tIf1JlUnaLQlQYb+kjyKR1pffZhxV27L0a5LRNKXApt5yt17rWRrNnedLQqj66Hn/Nd MYaRb1qEQg+9PxIjyjRhiF7vmhd2bQk8JJVnujyvMb/zxupxpa9cjeUBQ7UHN+TeM2PbHVVm1ShD tK7U45GnHnEW2p15mXSnqxPtRjmlL28/OKIkBt8y87Azrt+9uST7IU2dUGK3ElY6xlVRDovNdquy ZSzGE5BVVwPq4nuxneRrZOfp++91tI4XrJe0BM5S2eSLsw3Q6Rxf7mzx6+ikPv7k0NimWqOoljDA UdPqX57+jGqh45U2iO6UusavO5SUFq9v9ZwaEg+jkbJfTlzM4XS3urvu4MkVr5u+gz8t+Ckb136Y MgZT1lKS0icdI1xO5m5Gp7eawN7FP61VHM9yv7hXbZLXMxpO+SRzrSZXX59+cTTpJWL4o5Y3PeXu eHL+eDn9ssNi9ZDjXeqB+lcPxgn4+bDA00k1TLq1Ew7/RfaKo+JSO7elVKLNbxTfoHEescs92yhS iFkjyp3wNwlVAXYW0ku2F24L3z7Ul3/nqEaezIFonwECtcmMO7NcjDJjoPvAcv1eI59wiPjt6oFd 0fIOi2LyNzB6uF4TL7USnQvY4ncP3vByGv4xx09KGiFc5qqVHZjR+6u6Orr4xUZl1pV6uUbCiPOj 6bzg6uP5++HsaicLkVXbK2qOWdILNPdh1BsF0WbhSjVjQxsZKL7VVgh9bvL7gE/Nec8rHO0JM73W omKnxdf8+rzXMbS/35YW8PmL6SPDh0lSQ0kV516KT32Iq8PBaV8pCi5S9eaPlQsfvugWd9keLFHN zyimdXsyYrkLQW/D6wUe4nP8tvD0XfUKDalCD4IYT24U5Bj4fzhWiN2vWC74SdnZk2w+Sfb+06TO N9zQJXFw5N34C0VkqP6AlcBlgTWrblU8LCe6zQH9/EymxpIbjOuDYR9dodjLkKT9NRKnH+SBsiK7 Gp151ntJoJI4e9PYLUyg88AQhzrfXtEBoeQhJ6sB9K1TBqKrZh62j199DJTYQZNRKuu9gjrrkEqS wXs5ENdJclcQMT1Z6mbuHI5RLa2x/mfJifduudJmVUUKDV5424yWvs3MoMFHRqjOLY3+QrBbksFk ie6A0rgejd1hF6K9xOIPm/akoWiZ2YmjZdcTBlSfoDyWUmVMfJVc+uRF6nrp0XGTeztWywMMCgIZ U00H6WyzlLMl0Ql3ue+Qnr8sQM9+Ip1ummm6GYc60k1fNBiM+mz9oQcxdamA5tQUz28f2YMVJCFu RON1pkbG6KQiHuVKcUa199jSFQWXlPcNw8UXY57h96pW9jfiZdU3JH0aBD8hcOqImavoEhrlrYVr zt6PlPNzrujWJmwDOSGuawSmLdeNF28FWFdPv+6xJ8/K2ntyJfBEsSrNXWNdWTWXTE9oFd2cGYya 6DIT6NhWcbCWvTCgODGKtMTue7hfasboaUDAoCr1ag2c9kWzA/UBef89uffSdhlGp72dL2+F1d1E Dv1r3Z0oUxeuk/VlwmMh+9orZiKl+o/beBZxeDgkpU0j7sUzzXYuSUwvfG1KZkjk3t5wN77BTFPd 2Gf/JsL56gRCFd5EsGOe/5M4i1B6tSiRgtofk1q+4a7mVlBtnfWafi1muUamjU5txc03q4XVwlR6 3lqJRmQcnCIIjK4O5Ll27Flf6H5bJhi03m+X6Gq+k4HHL3ztt7sOwQU8fhGChrXX9ZbxImOrpbmR ZEXSTI9SyyI+vSe0N0ZFmfLOuhNKgbdCEZHp5XjiQzuh2jIhlZUap96CgnMcMgLz+Zakla4ghlu4 dNtcPn5xLj/3t7l8u/E1b123uZVLyWey04QSbvOEZ588nx2WROaveoKW6i3MOru+UE+ZRDnMR56Q R0gwBB7kxEwPzLsUT+u3PuYWYGYOyXHGN2+PlRK/uu9kvGeUAlxN/HEujXGOvNFFy869+pe2fEZ5 sk1CKLW4n8PcGxUVOu9Zypui6VuS0eYtopQge8P21ZnwtKjTAm6T/Nc16WJCi8oOzKwvTD1SszhT 94vhqF47cUPahdg4WijvvjtEeK1EdTjGYFw5gdF3OP4FM44I+3zKzj4mQGHqjuN9IbT6tGjMERN+ vbnfi/i+prjUfj4tUjPRUhO1cJrvdJW0dWR9qeqclBlTuf2AX3ZYSwXvQn3cu8uXq7XisPelnbQn 3G3rJ7AyoReij5hKOHL17UrxnNulozffL5KZ+NLy7cBOEi01opKhUzXaUq3yqcVQHblgGDY8TBTi vwvrF9nrolR3q4T3aVQMKtb/wKxqwPDwEdNDJnojH72F+P9IOlTlcMGYto//7UdGhLlFMyk9WOWj 6h6N0M6ipKOrBtpGYSdrqejSe3rvlvDaWrLK9KyFNRMJG+RuPtLv2wfgPb70aNnfEDcqPCctg7CK 1VOBFV7hnIVq1rbyuljZ1LU8rPdMRPbY+OKLmimaGmpPXOnevwIjbNWZ8bAU5ucMlVwJasf+/RFk rfmJvKVtaUyJzKM5i9NJa3nH7whE1AZ/ia0V8GNysTMhAQBubWxtqcEOdgMc1BgSgT/w+dYwYqCf MZaPAVuhlpIETkEIBzWQWICGWkjOv9nPB2WwZDu0iw0QuKd4fvRVm2aTgU0GNhnYZGCTgU0GNhnY ZGCTgU0GNhnYZOB/wcC/AQAA//8DAFBLAwQUAAYACAAAACEAnZ4Sz2YBAAClAgAAEQAIAWRvY1By b3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlJJfS8MwFMXf Bb9DyJOCXZoNdCttBypjwjaEVaa+heRuKzZJSeK6fXvT7o+VCSL0JT3n/jj3JPFwKwu0AWNzrRJM OyFGoLgWuVol+CUbBX2MrGNKsEIrSPAOLB6mlxcxLyOuDTwbXYJxOVjkScpGvEzw2rkyIsTyNUhm O96hvLjURjLnj2ZFSsY/2ApINwxviQTHBHOM1MCgPBHxASn4CVl+mqIBCE6gAAnKWUI7lHx7HRhp fx1olJZT5m5X+p0Ocdtswffiyb21+clYVVWn6jUxfH5KXqeTebNqkKu6Kw44jQWPuAHmtEkX4Ntk xoG6QW+Mcb1BV7P5DAXoaULGWqAxm6+Z0eo6Jq2xuuKCWTf1t7HMQdzv/kU6n/aZmgr2wUAgv1S0 r+CoLHoPj9kIp92Q0iDs+S+j3SjsR9279zrcj/l6yf0PeYj4J/E2CGlGBxH1xEGLeASkMTl7WOkX AAAA//8DAFBLAwQUAAYACAAAACEAaY+T3pkBAAAnAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcksFu2zAMhu8D9g6G7o2cYCiGQFYxpBt6 6LoATtuzJtOxEFkSRNZL9vSTbbhx1p6qE8Wf+PWRorg5tjbrIKLxrmDLRc4ycNpXxu0L9rj7cfWV ZUjKVcp6BwU7AbIb+fmT2EYfIJIBzJKFw4I1RGHNOeoGWoWLJLuk1D62itI17rmva6Ph1uuXFhzx VZ5fczgSuAqqq/BqyEbHdUcfNa287vnwaXcKCViKbyFYoxWlLuVPo6NHX1P2/ajBCj4XRaIrQb9E QyeZCz6/ilIrC5tkLGtlEQQ/J8QdqH5oW2UiStHRugNNPmZo/qaxrVj2WyH0OAXrVDTKUcLqy8bL ENuAFOWzjwdsAAgFTwVjcgjntfPYfJHLoSAFl4W9wQiShEvEnSEL+KveqkjvEC/nxAPDyDvilD3f +Oacb2g5vfSf98a3QbmTfPAHo7LSQPp+zB6A/vStCj7p4t64Az6Gnb9VBNOQL5OibFSEKv3LpJ8T 4i7NN9reZNMot4dqqnkr9CvxNO69XK4WeTrDJkw5wc8bLv8BAAD//wMAUEsBAi0AFAAGAAgAAAAh AMijzTR2AQAABAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAACEAwAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAgT6Ul/QAAAC6AgAAGgAAAAAAAAAAAAAAAABwBgAAeGwvX3JlbHMvd29ya2Jvb2su eG1sLnJlbHNQSwECLQAUAAYACAAAACEAc0cF2kYBAAAUAgAADwAAAAAAAAAAAAAAAACkCAAAeGwv d29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhACUgnciZNgAA7JUAABQAAAAAAAAAAAAAAAAAFwoA AHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAAAAAAA AAAAAAAA4kAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAOmmJbiCBgAAUxsAABMAAAAAAAAAAAAAAAAA5EEAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEAbmfUDggDAAAODAAADQAAAAAAAAAAAAAAAACXSAAAeGwvc3R5bGVzLnhtbFBL AQItABQABgAIAAAAIQD/4coDIhEAAK9YAAAYAAAAAAAAAAAAAAAAAMpLAAB4bC93b3Jrc2hlZXRz L3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEApG5j6RwLAAC0GwAAJwAAAAAAAAAAAAAAAAAiXQAA eGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAJ2e Es9mAQAApQIAABEAAAAAAAAAAAAAAAAAg2gAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgA AAAhAGmPk96ZAQAAJwMAABAAAAAAAAAAAAAAAAAAIGsAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAA AAwADAAmAwAA720AAAAA ------_=_NextPart_001_01CC2090.EBA7F664-- From internet-drafts@ietf.org Thu Jun 2 02: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 DEB2EE076E; Thu, 2 Jun 2011 02:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 YqR5uRwzxYgw; Thu, 2 Jun 2011 02:42:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C57E0751; Thu, 2 Jun 2011 02:42:26 -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.55 Message-ID: <20110602094226.11424.22021.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 02:42:26 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-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: Thu, 02 Jun 2011 09:42:47 -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 : A Thesaurus for the Terminology used in Multiprotocol La= bel Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Trans= port Network Recommendations. Author(s) : Huub van Helvoort Loa Andersson Nurit Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-04.txt Pages : 21 Date : 2011-06-02 MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-rosetta-stone-04.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-rosetta-stone-04.txt From huubatwork@gmail.com Thu Jun 2 03:17: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 38AF1E0697 for ; Thu, 2 Jun 2011 03:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 pMdY9Aj1G0T6 for ; Thu, 2 Jun 2011 03:17: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 1A6B2E064A for ; Thu, 2 Jun 2011 03:17:11 -0700 (PDT) Received: by ewy19 with SMTP id 19so298240ewy.31 for ; Thu, 02 Jun 2011 03:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=yD6LpOeXF+eozVSQ1vtsSsYD8PWcimjHprsU9YMbCtE=; b=IQAuqa/bAmBMaSFOu19Pv8jo89km3PXmPyydNzBlPbxeYbd5RZ7Qa61EaPr4/y9pcL tUHZEHVmMzjeoh7yOiIQufTK1BgjXO/Z018IfvUBJsA86vB9h4gqrMmNGGqdh8CGINkb 8DakJZMZxJ0IgfMzpsspZh43tKwgbFbW44hJg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=BI75IsbQfHfzd5JOtPXUDWh75cbUvDgyYqlvlXSxu6zyh1XjHmsBuJXfp7nqwtmWpm a6c5EEvc16xYJO+wt7qIoVwFNAiNBxVWEjuZUNqrreooAPxUu2UsffkKJKVLrjOnAvAN y3cUGoEmvSUpSbKHZuxLX742MdVXtEWumutq8= Received: by 10.14.2.27 with SMTP id 27mr236113eee.9.1307009830683; Thu, 02 Jun 2011 03:17:10 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id s11sm297568eef.15.2011.06.02.03.17.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 03:17:09 -0700 (PDT) Message-ID: <4DE76323.6080206@gmail.com> Date: Thu, 02 Jun 2011 12:17:07 +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.Farrel@huawei.com References: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> In-Reply-To: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org Subject: Re: [mpls] AD review of daft-ietf-mpls-loss-delay 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: Thu, 02 Jun 2011 10:17:13 -0000 Hello Adrian, You commented: > --- > > 2.9.11 > > There are two significant timestamp formats in common use: the > timestamp format of the Internet standard Network Time Protocol > (NTP), described in [RFC5905], and the timestamp format used in the > IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. > > Please avoid the word "standard" as RFC 5905 is not an Internet > Standard. Suggest you delete "Internet standard" without any loss of > meaning. > > Can you please add to this section some text such as... > > To ensure interop it is necessary that support of at least one > format is mandatory. This specification requires the support of > the PTP format as discussed in Section 3.4 and Appendix A. > > --- Would it be possible to mix the two timestamp formats? In case of "dyadic" measurements the operator at A can use one timestamp format while the operator at B can use the other format. Regards, Huub. -- ***************************************************************** 我爱外点一七三一 From Alexander.Vainshtein@ecitele.com Thu Jun 2 04:52: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 442FFE0779 for ; Thu, 2 Jun 2011 04:52:53 -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 w-ehK+rTG8Hp for ; Thu, 2 Jun 2011 04:52:52 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id F18B6E06CB for ; Thu, 2 Jun 2011 04:52:50 -0700 (PDT) X-AuditID: 93eaf2e8-b7b4fae00000179b-e9-4de7792c8c48 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 72.5F.06043.C2977ED4; Thu, 2 Jun 2011 14:51:08 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 2 Jun 2011 14:52:48 +0300 From: Alexander Vainshtein To: "huubatwork@gmail.com" Date: Thu, 2 Jun 2011 14:52:45 +0300 Thread-Topic: [mpls] AD review of daft-ietf-mpls-loss-delay Thread-Index: AcwhDmhnUN15oxAVQACspdAlXVidDAAC846A Message-ID: References: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> <4DE76323.6080206@gmail.com> In-Reply-To: <4DE76323.6080206@gmail.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="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTWWgTURT1ZZJ0Gjsyja15RoXpVJSq0cQqRm1U/KpIqdqCdnEZJ89kMJmE zFQaEa24YfpRV6xxqZVa6hpo/ai2IIZ8uMQFFNG2FqTaFZWWiOiH9U2GLuJ8nffOOffcN9xL EsZuvZkURBkFRM7D6g3as4MjCcuiYF+Btavabj/THdfbay+90dk7btzUrSPyH4Q/puQfjX3V 5Tc0/NJsIkqrQB4nij6ZkxHjRBLvYDcFhH0cH2QZwelgbSzj93A88iJRdrCc349EJ7vGwPz3 5WGZIDJI5H1OQXQ52A1FhRa7fflKi41dMy/blrvaUOwWJAZZvJzgYbxIkjgXYvDNrvuE+1VN r87/elZl9YWVVSBhDgGShPQyePOHNwRSMZwBX3dH9CFgII10G4An4+816uE8gKOH+7SKSk87 YPPtj3oFZ9A22POtHSiYoMthTWNL8l5Lz4Vvn7QRSsB0ejX8U0eo8jzY8aJeq+KlcLglkbRS dCGMXq5LUbCR3gqjjZ3JMql0DnwX60tqAG7u57M7GjXKBDs+12nUpmnY0P6KUHEmHOj5o1P1 mbDrRAQoLRC4TuThEtWaBc9Vf0pRY9Ph04uftap1Jnzc9F57CpjCkxLCE+7wJHd4kvsa0N4C mYLHL+/2uqxLFyNekJEHLeZ93magTkp/K+iM50QBTQI2jWpt7S0w6rh9UtAbBTNJDZtJGfAg Gaft9jmDbk5y7wxUeJAUBZAk2AzKxn0pMFJOLrgfBXxjlB3/4tOEeSrvwzMpyjtzrdZ/DqyJ il3tKTDSLjxwexHyo8CYdTZJspBaL+HE9AByoco9gkeeoDVkqpKchpNjlVhDSX7OKwkulX8G sswmaqACE7RCuCvEca+yFodGR0cHgQm/czpFKY9Kw0sz7h7EhTW4sHV+sjBehnHKXAXOzn4e KbpetnZ7bU5nq/Hlqiv8tbYLHS2PT1vLLtYUxz4s3J57ZDgkDzMjhVXk0O9Hv06JU8+dOFCS s2NBYii2N/H9DP+tob74bjpHxraktstXjm0biTP5pU1+a25kyb0ttXeOX75Rurl3ysbsnqaS H7N6j+85OGdKV9aKoa+DoYzyflYruTnbAiIgcX8BIRwm2/EDAAA= Cc: "mpls@ietf.org" , "Adrian.Farrel@huawei.com" Subject: Re: [mpls] AD review of daft-ietf-mpls-loss-delay 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, 02 Jun 2011 11:52:53 -0000 SHV1YiwNCkkndmUgcmFpc2VkIHRoaXMgaXNzdWUgd2l0aCB0aGUgYXV0aG9ycyBhbHJlYWR5 LiBJTUhPIGFuZCBGV0lXOg0KDQooYSkgRm9yIDItd2F5IGRlbGF5IG1lYXN1cmVtZW50cyBk aXNwYXJhdGUgdGltZXN0YW1wIGZvcm1hdHMgYXJlIGEgbm9uLWlzc3VlIHNpbmNlIGFsbCB0 aGF0IGlzIHJlcXVpcmVkIGlzIHRoZSBhYmlsaXR5IHRvIGNvbXB1dGUgZGlmZmVyZW5jZXMg YmV0d2VlbiB0d28gdGltZXN0YW1wcyBpbiB0aGUgc2FtZSBmb3JtYXQgZm9yIGJvdGggZm9y bWF0cywgYW5kIHRoaXMgY29tcHV0YXRpb24gZG9lcyBub3QgaGF2ZSB0byBiZSBkb25lIGlu IHJlYWwtdGltZS4NCg0KKGIpIEZvciAxLXdheSBkZWxheSBtZWFzdXJlbWVudHMgZGlzcGFy YXRlIHRpbWVzdGFtcCBmb3JtYXRzIGFyZSBhIG1pbm9yIGltcGxlbWVudGF0aW9uIGlzc3Vl OiB3aGlsZSBhYmlsaXR5IHRvIGNvbXB1dGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0d28g dGltZXN0YW1wcyBpbiBkaWZmZXJlbnQgZm9ybWF0cyBpcyByZXF1aXJlZCwgdGhlcmUgaXMg c3RpbGwgbm8gbmVlZCB0byBkbyB0aGlzIGNvbXB1dGF0aW9uIGluIHJlYWwgdGltZS4gDQoN CkJhc2VkIG9uIHRoaXMgSSd2ZSBjbGFpbWVkIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCB0byBk ZWZpbmUgdGhlIGRlZmF1bHQgdGltZXN0YW1wIGZvcm1hdCwgYnV0IHRoZSBhdXRob3JzIGRp ZCBub3QgYWdyZWUgZXZlbiBpZiB0aGV5IGhhdmUsIHRvIHRoZSBiZXN0IG9mIG15ICByZWNv bGxlY3Rpb24sIGFjY2VwdGVkIChhKSBhbmQgKGIpLg0KDQpBc2lkZT09PiBUaGlzIGNhc2Ug aXMgdmVyeSBtdWNoIGRpZmZlcmVudCBmcm9tIHRoZSBjYXNlIG9mICBtaXhlZCBNUExTLVRQ IGlkZW50aWZpZXJzOiANCmRpZmZlcmVudCB0aW1lc3RhbXAgZm9ybWF0cyByZXByZXNlbnQg dGhlIHNhbWUgcmVhbGl0eSAoYWJzb2x1dGUgdGltZSkuDQoNClJlZ2FyZHMsDQogICAgIFNh c2hhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbXBscy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gSHV1YiB2YW4gSGVsdm9vcnQNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMDIsIDIw MTEgMToxNyBQTQ0KPiBUbzogQWRyaWFuLkZhcnJlbEBodWF3ZWkuY29tDQo+IENjOiBtcGxz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gQUQgcmV2aWV3IG9mIGRhZnQtaWV0 Zi1tcGxzLWxvc3MtZGVsYXkNCj4gDQo+IEhlbGxvIEFkcmlhbiwNCj4gDQo+IFlvdSBjb21t ZW50ZWQ6DQo+IA0KPiA+IC0tLQ0KPiA+DQo+ID4gMi45LjExDQo+ID4NCj4gPiAgICAgVGhl cmUgYXJlIHR3byBzaWduaWZpY2FudCB0aW1lc3RhbXAgZm9ybWF0cyBpbiBjb21tb24gdXNl OiB0aGUNCj4gPiAgICAgdGltZXN0YW1wIGZvcm1hdCBvZiB0aGUgSW50ZXJuZXQgc3RhbmRh cmQgTmV0d29yayBUaW1lIFByb3RvY29sDQo+ID4gICAgIChOVFApLCBkZXNjcmliZWQgaW4g W1JGQzU5MDVdLCBhbmQgdGhlIHRpbWVzdGFtcCBmb3JtYXQgdXNlZCBpbg0KPiB0aGUNCj4g PiAgICAgSUVFRSAxNTg4IFByZWNpc2lvbiBUaW1lIFByb3RvY29sIChQVFApIFtJRUVFMTU4 OF0uDQo+ID4NCj4gPiBQbGVhc2UgYXZvaWQgdGhlIHdvcmQgInN0YW5kYXJkIiBhcyBSRkMg NTkwNSBpcyBub3QgYW4gSW50ZXJuZXQNCj4gPiBTdGFuZGFyZC4gU3VnZ2VzdCB5b3UgZGVs ZXRlICJJbnRlcm5ldCBzdGFuZGFyZCIgd2l0aG91dCBhbnkgbG9zcyBvZg0KPiA+IG1lYW5p bmcuDQo+ID4NCj4gPiBDYW4geW91IHBsZWFzZSBhZGQgdG8gdGhpcyBzZWN0aW9uIHNvbWUg dGV4dCBzdWNoIGFzLi4uDQo+ID4NCj4gPiAgICAgVG8gZW5zdXJlIGludGVyb3AgaXQgaXMg bmVjZXNzYXJ5IHRoYXQgc3VwcG9ydCBvZiBhdCBsZWFzdCBvbmUNCj4gPiAgICAgZm9ybWF0 IGlzIG1hbmRhdG9yeS4gVGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHRoZSBzdXBwb3J0 IG9mDQo+ID4gICAgIHRoZSBQVFAgZm9ybWF0IGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMu NCBhbmQgQXBwZW5kaXggQS4NCj4gPg0KPiA+IC0tLQ0KPiANCj4gV291bGQgaXQgYmUgcG9z c2libGUgdG8gbWl4IHRoZSB0d28gdGltZXN0YW1wIGZvcm1hdHM/DQo+IEluIGNhc2Ugb2Yg ImR5YWRpYyIgbWVhc3VyZW1lbnRzIHRoZSBvcGVyYXRvciBhdCBBIGNhbiB1c2Ugb25lDQo+ IHRpbWVzdGFtcCBmb3JtYXQgd2hpbGUgdGhlIG9wZXJhdG9yIGF0IEIgY2FuIHVzZSB0aGUg b3RoZXIgZm9ybWF0Lg0KPiANCj4gUmVnYXJkcywgSHV1Yi4NCj4gDQo+IA0KPiANCj4gLS0N Cj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICDmiJHniLHlpJbn grnkuIDkuIPkuInkuIANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQpUaGlzIGUt bWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNv bnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5 IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWws IHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNv cGllcyB0aGVyZW9mLg0KDQo= From loa@pi.nu Thu Jun 2 06:52: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 526C6E0692 for ; Thu, 2 Jun 2011 06:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 LO04pYsfIEdi for ; Thu, 2 Jun 2011 06:52:39 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id A4E24E065B for ; Thu, 2 Jun 2011 06:52:39 -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 C488F2A8001 for ; Thu, 2 Jun 2011 15:52:37 +0200 (CEST) Message-ID: <4DE795A3.5050106@pi.nu> Date: Thu, 02 Jun 2011 15:52:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 02 Jun 2011 13:52:40 -0000 Working Group, this is to start a two week poll on making draft-raza-mpls-ldp-ip-pw-capability-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends 2011-06-16. /Loa -- 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 internet-drafts@ietf.org Thu Jun 2 07:17:55 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 3B3E5E077F; Thu, 2 Jun 2011 07:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 GXmPNGB32raV; Thu, 2 Jun 2011 07:17:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE46E0699; Thu, 2 Jun 2011 07:17:54 -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.55 Message-ID: <20110602141754.11380.8161.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 07:17:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-fastreroute-mib-18.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, 02 Jun 2011 14:17:55 -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 (MPLS) Traffic Engineering= Management Information Base for Fast Reroute Author(s) : Thomas D. Nadeau Cisco Systems Riza Cetin Filename : draft-ietf-mpls-fastreroute-mib-18.txt Pages : 50 Date : 2011-06-02 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-18.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-fastreroute-mib-18.txt From internet-drafts@ietf.org Thu Jun 2 13:52: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 B5DFBE08C3; Thu, 2 Jun 2011 13:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 oyT-s4O1WnOY; Thu, 2 Jun 2011 13:52:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519B5E08B7; Thu, 2 Jun 2011 13:52: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.55 Message-ID: <20110602205223.5062.15785.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 13:52:23 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-fastreroute-mib-19.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, 02 Jun 2011 20:52:23 -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 (MPLS) Traffic Engineering= Management Information Base for Fast Reroute Author(s) : Thomas D. Nadeau Cisco Systems Riza Cetin Filename : draft-ietf-mpls-fastreroute-mib-19.txt Pages : 50 Date : 2011-06-02 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-19.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-fastreroute-mib-19.txt From internet-drafts@ietf.org Thu Jun 2 23:41: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 931FDE06B9; Thu, 2 Jun 2011 23:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 UuqClsPe88Nu; Thu, 2 Jun 2011 23:41:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174E2E0659; Thu, 2 Jun 2011 23:41:29 -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.55 Message-ID: <20110603064129.32673.63092.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 23:41:29 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-07.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, 03 Jun 2011 06:41: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 : MPLS-TP Linear Protection Author(s) : Stewart Bryant Eric Osborne Nurit Sprecher Annamaria Fulignoli Yaacov Weingarten Filename : draft-ietf-mpls-tp-linear-protection-07.txt Pages : 40 Date : 2011-06-02 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-07= .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-07.= txt From loa@pi.nu Fri Jun 3 01:33:50 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 E0409E070C for ; Fri, 3 Jun 2011 01:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 1PIN4+rgcM1H for ; Fri, 3 Jun 2011 01:33:50 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0D75CE06F1 for ; Fri, 3 Jun 2011 01:33:50 -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 493352A8001; Fri, 3 Jun 2011 10:33:48 +0200 (CEST) Message-ID: <4DE89C6B.5070108@pi.nu> Date: Fri, 03 Jun 2011 10:33:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon Subject: [mpls] wg last call on resolution of last call 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, 03 Jun 2011 08:33:51 -0000 working Group, the authors of the linear protection draft has updated after working group last call and published a new version. This is a one week limited working group last call to verify that the comments been appropriately addressed. The new draft will be found here: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-07.txt And the specification on how the comments been addressed here: http://www.pi.nu/~loa/LastCallCommentsResolved-linear-protection Please send comments to the mpls working group mailing list on June 10th the latest. /Loa for the MPSL wg 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 danfrost@cisco.com Fri Jun 3 03:25: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 BC3F2E068D for ; Fri, 3 Jun 2011 03:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sekehX3yn3HG for ; Fri, 3 Jun 2011 03:25:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 05907E0689 for ; Fri, 3 Jun 2011 03:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=625; q=dns/txt; s=iport; t=1307096748; x=1308306348; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=D/jEr+pI2X1kQFAZGldzVwiKmbEe89erMA4ENn8C7cQ=; b=FW45J0ftb8xxBaoCW8kUe9hnLvWhEMUxi8iG4kfSzqi5G7dw8fM0Y2Yz xBQWVM8J0SowF32hk05YNXxP82Y2tNM45dLCVwGXFG/aoNj5T5bRTEE3T btRVJPp8A/h3QoDpLYfEmpOxAOifoqyGnOETbE3d0bsoNnDMfDUBHjzxw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYHANy16E2tJV2c/2dsb2JhbABTmBqOHnetQp18hiEEkHSPOg X-IronPort-AV: E=Sophos;i="4.65,314,1304294400"; d="scan'208";a="235146000" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 03 Jun 2011 10:25:47 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p53APlMY007901; Fri, 3 Jun 2011 10:25:47 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p53APkDu012871; Fri, 3 Jun 2011 06:25:46 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p53APi9k012870; Fri, 3 Jun 2011 11:25:44 +0100 X-Authentication-Warning: isolaria.cisco.com: danfrost set sender to danfrost@cisco.com using -f From: Dan Frost To: Adrian.Farrel@huawei.com In-Reply-To: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> (Adrian Farrel's message of "Thu, 26 May 2011 12:20:43 +0100") References: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Fri, 03 Jun 2011 11:25:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-loss-delay 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, 03 Jun 2011 10:25:49 -0000 Hi Adrian, Thanks for the review. The authors have made these changes in -03 following the review comments: * Add reference to draft-ietf-mpls-tp-loss-delay-profile * Clarify scope of Message Length field and size of counter/timestamp fields * Clarify that error response codes imply invalid measurement data * Replace "Implementation-specific" TLV slots with a single slot for experimental use * s/Reserved/Unallocated/ in TLV range list * Clarify positional constraints of padding TLVs * Fix IEEE 1588 version references * Revise security considerations * Minor editorial fixes -d From danfrost@cisco.com Fri Jun 3 03:39: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 D5770E0743 for ; Fri, 3 Jun 2011 03:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 MA4LIvGF9NgK for ; Fri, 3 Jun 2011 03:39:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2D3E06A8 for ; Fri, 3 Jun 2011 03:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=396; q=dns/txt; s=iport; t=1307097579; x=1308307179; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=whNGrz9vCsarYFq53JpwG+pm+GvnAX4OPX24uZOLbyU=; b=MnjghCq33VlTCefnYN/+cR/OK6zFgVZw06hn8eUPAOHdctLfBTOvi14B Mst85D+M3f/Ur65tn46Pe3Fe1YPm31MH0eDNFOTjA47McyucJNZJY6Gsz p0pq1Kj+IKzJx02OLxZkieifDHmSJHYQdFhRsg8S5P6JzX7/dsMc0k7G9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK+46E2tJV2a/2dsb2JhbABTpjh3iHGkZp18hiEEkHSPOg X-IronPort-AV: E=Sophos;i="4.65,314,1304294400"; d="scan'208";a="459169569" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 03 Jun 2011 10:39:39 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p53AdcHI003298; Fri, 3 Jun 2011 10:39:38 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p53AdbI4013004; Fri, 3 Jun 2011 06:39:37 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p53AdbAu013003; Fri, 3 Jun 2011 11:39:37 +0100 Date: Fri, 3 Jun 2011 11:39:37 +0100 From: Dan Frost To: Huub van Helvoort Message-ID: <20110603103937.GB12271@cisco.com> References: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> <4DE76323.6080206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE76323.6080206@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-loss-delay 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, 03 Jun 2011 10:39:39 -0000 Huub, On Thu, Jun 02, 2011 at 12:17:07PM +0200, Huub van Helvoort wrote: > Would it be possible to mix the two timestamp formats? > In case of "dyadic" measurements the operator at A can use one > timestamp format while the operator at B can use the other format. Yes, it is possible. The draft explains how multiple formats can coexist in the same message. -d > Regards, Huub. From stbryant@cisco.com Fri Jun 3 03:48: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 C50C5E0743 for ; Fri, 3 Jun 2011 03:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.425 X-Spam-Level: X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 i4Z8JNc33i6E for ; Fri, 3 Jun 2011 03:48:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E348CE073A for ; Fri, 3 Jun 2011 03:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1410; q=dns/txt; s=iport; t=1307098110; x=1308307710; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iPQG57CJxiBT0BIZXE4pec7onpu8IH6mR9vF/wB7z1c=; b=fgxr7F1MhZVUmZJXzoluIR/xQd/5wFOqsJeZ2jw1G0daPPGt14lGiY8a hDafXMvdFTVnrXqQaF0XMMVywvQlw8Rk/4OSIf6cbblMiD1PynJwK1PLw ANpdqV/5jzXfVrH7uknqtiNX5el18jSAlIY3p9keIYgRtZkM6WH8wQa2o I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALe76E2Q/khL/2dsb2JhbABThEmhb3etSIJ6DwGJfZB2gSuDbIEKBJB0jzo X-IronPort-AV: E=Sophos;i="4.65,314,1304294400"; d="scan'208";a="92123808" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2011 10:48:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p53AmSEc010428; Fri, 3 Jun 2011 10:48:28 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p53AmQW15286; Fri, 3 Jun 2011 11:48:27 +0100 (BST) Message-ID: <4DE8BC0D.4050708@cisco.com> Date: Fri, 03 Jun 2011 11:48:45 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Vainshtein References: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> <4DE76323.6080206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "Adrian.Farrel@huawei.com" , "huubatwork@gmail.com" Subject: Re: [mpls] AD review of daft-ietf-mpls-loss-delay X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 10:48:30 -0000 On 02/06/2011 12:52, Alexander Vainshtein wrote: > Huub, > I've raised this issue with the authors already. IMHO and FWIW: > > (a) For 2-way delay measurements disparate timestamp formats are a non-issue since all that is required is the ability to compute differences between two timestamps in the same format for both formats, and this computation does not have to be done in real-time. > > (b) For 1-way delay measurements disparate timestamp formats are a minor implementation issue: while ability to compute the difference between two timestamps in different formats is required, there is still no need to do this computation in real time. > > Based on this I've claimed that there is no need to define the default timestamp format, but the authors did not agree even if they have, to the best of my recollection, accepted (a) and (b). > > Aside==> This case is very much different from the case of mixed MPLS-TP identifiers: > different timestamp formats represent the same reality (absolute time). Sasha Whilst we have the ability to interwork TS formats it is not as simple as operating with a common format, and thus we believe that the specification of a default is of benefit to both the network operator and the vendor. If nothing else it useful in providing guidance on the time distribution protocol that is currently considered to provide the higher accuracy. Stewart From danfrost@cisco.com Fri Jun 3 03:51: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 411EDE06F1 for ; Fri, 3 Jun 2011 03:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JHgDr8ZPIokB for ; Fri, 3 Jun 2011 03:51:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 97554E067A for ; Fri, 3 Jun 2011 03:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=1480; q=dns/txt; s=iport; t=1307098265; x=1308307865; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ozRce8EC90mOX1i3XsVj25nOH7WjAonEqP4RmxjQSvE=; b=D8uzr5bhgh/badLTDbKH2Oted8cNG1fYlr8W9q0R8nZKll7BX42V7Wcx +dSw3VR41y2ej9leWRvnPRv8GCzliLnICF8h7ibguTqb2fvLNHcO+DEiw ud+XRAixHx21Cw+8c/gSpVhh+xpz/OXNs6+3B5VeSjViF0b9Envr+g9m4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPK76E2tJXHB/2dsb2JhbABTpjh3iHGkWJ19hiEEkHSPOg X-IronPort-AV: E=Sophos;i="4.65,314,1304294400"; d="scan'208";a="286511382" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 03 Jun 2011 10:51:05 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p53Ap4d6025067; Fri, 3 Jun 2011 10:51:04 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p53Ap3tw013112; Fri, 3 Jun 2011 06:51:04 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p53Ap3Jp013111; Fri, 3 Jun 2011 11:51:03 +0100 Date: Fri, 3 Jun 2011 11:51:03 +0100 From: Dan Frost To: Alexander Vainshtein Message-ID: <20110603105103.GC12271@cisco.com> References: <068901cc1b96$f9344b20$eb9ce160$@huawei.com> <4DE76323.6080206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-loss-delay 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, 03 Jun 2011 10:51:06 -0000 Hi Sasha, On Thu, Jun 02, 2011 at 02:52:45PM +0300, Alexander Vainshtein wrote: > I've raised this issue with the authors already. IMHO and FWIW: > > (a) For 2-way delay measurements disparate timestamp formats are a > non-issue since all that is required is the ability to compute > differences between two timestamps in the same format for both > formats, and this computation does not have to be done in real-time. > > (b) For 1-way delay measurements disparate timestamp formats are a > minor implementation issue: while ability to compute the difference > between two timestamps in different formats is required, there is > still no need to do this computation in real time. > > Based on this I've claimed that there is no need to define the default > timestamp format, but the authors did not agree even if they have, to > the best of my recollection, accepted (a) and (b). We agree that things could be made to work by making further format reconciliation requirements of implementations rather than mandating a default. But as we discussed, we think it is important to provide guidance to hardware implementors as to the preferred format to support, and consensus from the timing people at present is that 1588 is preferred. Cheers, -d > Aside==> This case is very much different from the case of mixed > MPLS-TP identifiers: different timestamp formats represent the same > reality (absolute time). > > Regards, > Sasha From lizhong.jin@zte.com.cn Fri Jun 3 06:12: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 AB919E0714 for ; Fri, 3 Jun 2011 06:12:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPKCYlTNT2dn for ; Fri, 3 Jun 2011 06:12:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD72E066C for ; Fri, 3 Jun 2011 06:12:51 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 1834806486374; Fri, 3 Jun 2011 21:02:47 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 79161.1180738496; Fri, 3 Jun 2011 21:12:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p53DCT8M060238; Fri, 3 Jun 2011 21:12:29 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: loa@pi.nu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 3 Jun 2011 21:12:19 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-03 21:12:29, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-03 21:12:29, Serialize complete at 2011-06-03 21:12:29, S/MIME Sign failed at 2011-06-03 21:12:29: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-03 21:12:33, Serialize complete at 2011-06-03 21:12:33 Content-Type: multipart/alternative; boundary="=_alternative 00488DF1482578A4_=" X-MAIL: mse02.zte.com.cn p53DCT8M060238 Cc: mpls@ietf.org Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 03 Jun 2011 13:12:53 -0000 This is a multipart message in MIME format. --=_alternative 00488DF1482578A4_= Content-Type: text/plain; charset="US-ASCII" Yes, support. Lizhong > ------------------------------ > > Date: Thu, 02 Jun 2011 15:52:35 +0200 > From: Loa Andersson > To: "mpls@ietf.org" > Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 > Message-ID: <4DE795A3.5050106@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group, > > this is to start a two week poll on making > > draft-raza-mpls-ldp-ip-pw-capability-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends 2011-06-16. > > /Loa > > > -- > > > 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 > > -------------------------------------------------------- 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 00488DF1482578A4_= Content-Type: text/html; charset="US-ASCII"
Yes, support.

Lizhong


> ------------------------------
>
> Date: Thu, 02 Jun 2011 15:52:35 +0200
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf.org" <mpls@ietf.org>
> Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01
> Message-ID: <4DE795A3.5050106@pi.nu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Working Group,
>
> this is to start a two week poll on making
>
> draft-raza-mpls-ldp-ip-pw-capability-01
>
> an mpls working group document.
>
> If you support the document becoming a working group document
> please respond to this poll with "yes/support"
>
> If you do not support the document becoming a working group
> document please respond to this poll with "no/do not support"
> and at the same time give the technical reasons why you are
> not supporting the document.
>
> If you have technical comments or in any other way want to
> discuss the document, please send these comments to the mpls
> working group mailing list, but with another subject than what
> is on this mail.
>
>   The poll ends 2011-06-16.
>
>   /Loa
>
>
> --
>
>
> 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
>
> 
--------------------------------------------------------
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 00488DF1482578A4_=-- From venkatflex@gmail.com Sat Jun 4 12:20: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 9619B228009 for ; Sat, 4 Jun 2011 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 dX988q8qABAA for ; Sat, 4 Jun 2011 12:20:19 -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 6C5F3228006 for ; Sat, 4 Jun 2011 12:20:16 -0700 (PDT) Received: by vxg33 with SMTP id 33so2611244vxg.31 for ; Sat, 04 Jun 2011 12:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9m0NgUz0iuZAheqG7H4KL0ZWEGAqiXwoohsqh8C17xo=; b=k2z4zYtK60nMAxBoFCP4yRlakDTt5iGGTpgA3lr2nRjskDFnGH8oeynNtw63UghCpi UrdEGLpfSf6zcxNCrVL2SQUzzlHcwySpQAOSu4sUaLUptMgUN6+D93GqBE7WHc1US5cW SVDS2ZHc33a9GvVdH8V0+OCbQSASYOoKxF0Vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jgy0mxIYmhZ2IcdcmZi4A0D/Rur6CzPI2+Y1xzHWKFdZlhvWHPL85PTTt5DqtqW//R n1IiWHvaTyCYA+fEwHUiNoQ8F4YiEKjOtzLM9D61NrCJqsW+9621g8Kq8+mcYcxgZCEb QQdZqlX/bWdZxk6Gt+jiJ7nevK7ZXx9KAskOA= MIME-Version: 1.0 Received: by 10.52.76.170 with SMTP id l10mr4067320vdw.77.1307215215339; Sat, 04 Jun 2011 12:20:15 -0700 (PDT) Received: by 10.52.113.163 with HTTP; Sat, 4 Jun 2011 12:20:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Jun 2011 15:20:15 -0400 Message-ID: From: venkatesan mahalingam To: Adrian Farrel , jcucchiara@mindspring.com, mpls Content-Type: multipart/alternative; boundary=bcaec50160438e277c04a4e7c2ea Cc: rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: [mpls] Fwd: poll on draft-vkst-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: Sat, 04 Jun 2011 19:20:21 -0000 --bcaec50160438e277c04a4e7c2ea Content-Type: text/plain; charset=ISO-8859-1 Dear Adrian and Joan, We have addressed the 3 major comments identified by you during WG adoption poll. Apologies for the delayed response as we wanted to address each item carefully and get consensus among authors of this document. 1. MPLS-TE-STD-MIB is extended by MPLS-TP-TE-STD-MIB mib module The 'extends' relationship is a sparse augmentation so that the entry in the mplsTpTunnelTable has the same index values. Redefining of the index definitions is now removed and the table is referenced with the same indices as in mplsTunnelTable. 2. Separate mib module for textual conventions created for MPLS-TP mib modules. This is part of the present MIB, which will be published separately, later. 3. Separate mib modules for MPLS-TP-TC-STD-MIB, MPLS-TP-ID-STD-MIB, MPLS-TP-LSR-STD-MIB and MPLS-TP-TE-STD-MIB have been created. These are presently part of this MIB, so as overcome the mib compilation issues. These mibs will be published as separate drafts, after the adoption. Apart from the above we have taken care of minor issues as well. We think, the issues raised were addressed, and the document is ready to be adopted as WG doc. Any changes, if needed, we will address in the subsequent revisions. Kindly let us know if you have any questions. New version can be accessed through this below URL, http://tools.ietf.org/html/draft-vkst-mpls-tp-te-mib-01 Thanks, Venkat. ---------- Forwarded message ---------- From: venkatesan mahalingam Date: Mon, May 9, 2011 at 5:29 PM Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt To: adrian@olddog.co.uk, loa@pi.nu, mpls Cc: swallow@cisco.com, rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Hi Adrian and all, Please find the responses inlined with the tag <> Thanks, TP-MIB-Authors. ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Saturday, May 07, 2011 3:40 AM To: loa@pi.nu; mpls@ietf.org Cc: swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt >[speaking as an individual WG participant] >I support the idea of constructing a MIB module for MPLS-TP LSPs and for other >elements of MPLS-TP, but I have significant reservations about adopting this >document in its current form. I recognise that once adopted, the WG will be able >to enforce changes in content, but I am concerned that this document does not >correctly reflect the relationship with other MIB modules, and that taking this >as a starting point will encourage us to go down the wrong path resulting in a >starting direction that will be hard to change. >I would be happy to see the authors spend a little more time on this and then >adopt it into the WG. >In overview my concerns are as follows: > mplsGlobalId, mplsIcc and mplsNodeId are node properties that will turn out > to > be equally applicable for PWs. They should appear in a MIB module dedicated > to > the LSR not just to the MPLS-TP LSPs. Given that these three objects and > mplsNodeConfigTable and mplsNodeIpMapTable are all related to MPLS-TP > identifiers, why not have a separate module for them all? <> We agree that mplsGlobalId, mplsIcc and mplsNodeId can be kept in a common mib module. mplsNodeConfigTable is created specifically to map the [Global-id_Node-id] and Icc-id into Local-Num. This Local-Num will be used as the tunnel source/destination identifier. This idea has been followed to retain the MPLS tunnel table for MPLS-TP TE extensions also. We think that mplsNodeConfigTable/mplsNodeIpMapTable is not applicable for PWs. The reason is that we already have the 129 FEC PWs with variable length of SAII & TAII. And the SAII & TAII already includes the Global-Id and Node-Id (or ICC Id) Since the MPLS-TP PWs are always FEC129 Type2 based PWs, the flexibility in SAII & TAII can be used to configure Global-id/Node-id or ICC id. > A number of objects related to Global IDs and Node IDs appear to be of the > wrong > max value compared to draft-ietf-mpls-tp-identifiers. You could usefully > define > TCs for them and for the ICC ID. What will zero Global IDs and Node IDs > mean? <> Yes, the Max value of Global-Id and Node-id are wrong. Max value should be max of 4 bytes value. We will correct them. Yes, we can keep the TCs for Global-id/Node-id and ICC-id in a seperate mib module. 1) A Global_ID of zero means that no Global_ID is present. 2) A Node_ID of zero is the default value that indicates the Node_ID is invalid. > I see the value of the ICC entries in mplsNodeConfigTable and the use of > mplsNodeIccMapTable to generate a unique index to use in defining entries in > the > various pre-existing tables. (But see my comment on the use of > mplsNodeConfigLocalNum in mplsTunnelExtEntry, below). I do not see the value > of > the Global entries in mplsNodeConfigTable and the use of mplsNodeIpMapEntry > since you say in the preamble to mplsTunnelExtEntry that Source-Tunnel_Num > is > mapped with mplsTunnelIndex. Quite possibly there is descriptive text > missing. <> mplsNodeConfigTable is the configuration table that is used to configure Global-id/Node-id and/or ICC-id with the local map number. i.e. This table is used to configure the global-id/Node-id and/or ICC-id for the given local map number. The other two tables mplsNodeIpMapEntry and mplsNodeIccMapTable are just READ-ONLY tables. These read only tables are meant for users who want to view the reverse mapping of Global-id/Node-id or ICC-id to the LocalNum. > There seems to be some ambiguity about whether the objects in this document > refer to MPLS-TP or to extensions to MPLS-TE. it would be really nice to > sort > this out. <> This document is created to address the requirements of TE extensions for MPLS-TP and this will also be applicable for MPLS TE and hence the mib modules are named generically. Since we are augmenting the TE mib, we named it as TE extension. If many others prefer to name this as TP extension, we can change the names accordingly. > mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm guessing > you > actually want a sparse augmentation since in a "mixed" environment you will > not > want to have all these objects present but unused. So you need to change the > way > you define this. <> Yes, we actually meant sparse augmentation. This mplsTunnelExtEntry will have entries only when required. For example, this table will have entries for the MPLS-TP tunnels, but not for MPLS tunnels. Does it answer your question? Do you expect few more description to be added to this table? Also, do you foresee any issue of augmentation? Is it possible to explain the same? > In mplsTunnelExtTable you do not state what DstTunnelNum is mapped with. > This is > key and could completely break your augmentation unless you get it right! <> There are two ways to look at this problem. One way is to force the DstTunnelNum as key. Other way is NOT to force it as key. Let us take an example to demonstrate this. Let us say that we have a forward LSP with SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200. Option1: Force DstTunnelNum as key: If we mandate DstTunnelNum as key, then the following combination is theoretically valid. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 LSP2: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300. Even though the LSP2 is theoretically valid, it is not correct to have same indices for the forward LSP. i.e Treating the LSP2 as separate independent LSP is not looking correct. Hence, the Option1 is dropped. Option2: Do not force DstTunnelNum as key: This is the option that we choose. i.e User can configure DstTunnelNum as read-write column, but it is not part of indices to mplsTunnelTable. If we try to include that as key, even the existing MPLS based mplsTunnelTable will have problems in interpretation. Also, we do not see a real need to force that as index/key. According to this option, the LSP1 is a valid combination. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 If user wants to use a different reverse LSP, they can modify the DstTunnel value as 300. But, it will still be called as LSP1. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300 (modified). If required, we can discuss with mpls-tp-identifiers authors to confirm whether this approach is fine. > For mplsTunnelExtEntry you have... > Source Global identifier/ICC and Destination > Global identifier/ICC are maintained in the > mplsNodeConfigTable and mplsNodeConfigLocalNum is used to > create an entry in mplsTunnelTable. > This is possibly too vague to be actually practical. <> We created a word document to explain the various options that were considered before taking this option. We will share the same with you. In principle, the idea is to reuse the mplsTunnelTable without disturbing its existing meaning for MPLS based tunnels. Even though we can think of alternate designs based on separate new table for MPLS_TP tunnels, we thought that reusing the existing table is a better option since MPLS_TP is just an extension of existing MPLS. You can go through our document and provide your comments. > How will mplsTunnelExtDestTnlIndex actually be used? > - What value will it have for unidirecitonal tunnels? > (Or for bidriectional associated tunnels where the reverse > direction is not present on this LSR) <> A zero value will be held by this (mplsTunnelExtDestTnlIndex) object when the unidirectional tunnel is desired. This object contains the source tunnel index value incase of co-routed bidirectional tunnel and for associated bidirectional tunnel this object contains the reverse direction tunnel index and reverse lsp index object will be added in the next version of this draft. > - Is this actually meant to be the object that gives us the > DstTunnelNum? If so, what has this to do with the reverse > direction? <> Yes, this helps to associate the forward/reverse direction tunnels for associated bi-directional tunnel. For co-routed bidirectional case, SrcTunnelNum = DstTunnelNum and SrcTunnelLspNum = DstTunnelLspNum, this is because we use same tunnel entry with two different XC entries for both forward and reverse direction LSPs. > It is completely unclear to me what mplsTunnelExtTnlApp is for! <> This object provides the information on whether the tunnel entry is MPLS tunnel or the MPLS-TP tunnel (tunnel application is either MPLS or MPLS-TP). > It certainly makes a nonsense of mplsTpTunnelsConfigured and > mplsTpTunnelsActive <> This is to keep the tunnel count for MPLS-TP specific tunnels which are configured as mplsTp in mplsTunnelExtTnlApp object. If the object is not going to be useful for users, this can be removed. >Cheers, >Adrian > -----Original Message----- > From: loa@pi.nu [mailto:loa@pi.nu] > Sent: 03 May 2011 18:48 > To: mpls@ietf.org > Cc: Adrian Farrel; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp- > te-mib@tools.ietf.org > Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt > > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends 2011-05-18. > > /Loa --bcaec50160438e277c04a4e7c2ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Adrian and Joan,

We have addressed the 3= major comments identified by you during WG adoption poll. Apologies for th= e delayed response as we wanted to address each item=A0carefully and get co= nsensus among authors of this document.

1. MPLS-TE-STD-MIB is extended by MPLS-TP-TE-STD-MIB mi= b module
=A0 =A0 The 'extends' relationship is a sparse a= ugmentation so that the entry in the
=A0 =A0 mplsTpTunnelTable ha= s the same index values. Redefining of the index definitions is now removed= and the table is referenced
=A0 =A0 with the same indices as in mplsTunnelTable.

2. Separate mib module for textual conventions created for MPLS-TP = mib modules. This is part of the present MIB,=A0
=A0 =A0 which wi= ll be published separately, later.

3. Separate mib modules for MPLS-TP-TC-STD-MIB, MPLS-TP= -ID-STD-MIB, MPLS-TP-LSR-STD-MIB and=A0
=A0 =A0 MPLS-TP-TE-STD-MI= B have been created. These are presently part of this MIB, so as overcome t= he mib compilation issues.
=A0 =A0 These mibs will be published as separate drafts, after the ado= ption.

Apart from the above we have taken care of = minor issues as well. We think, the issues raised were addressed, and the d= ocument is ready to be adopted as WG doc. Any changes, if needed, we will a= ddress in the subsequent revisions. Kindly let us know if you have any ques= tions.

New version can be accessed through this below URL,

Thanks,
Venkat.

--= -------- Forwarded message ----------
From: venkatesan mahalingam <venkatflex@gmail.com>
Date: Mon, May 9, 2011 at 5:29 PM
Subject: RE: poll on draft-vkst-mpls-t= p-te-mib-00.txt
To: adrian@olddog= .co.uk, loa@pi.nu, mpls <mpls@ietf.org>
Cc: swallow@cisco.com, rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.= org


Hi Adrian and all,
Please find the responses inlined= with the tag <<TP-MIB-Authors>>

Thank= s,
TP-MIB-Authors.
____________________________________= ____
From: Adrian Farrel [adrian@olddog.co.uk]
Sent: Saturday, May 07, 2011 3:4= 0 AM
To: loa@pi.nu= ; mpls@ietf.org<= /div>
Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt

>[speaking as an individual WG participant]<= /div>

>I support the idea of constructing a MIB modul= e for MPLS-TP LSPs and for other
>elements of MPLS-TP, but I have significant reservations about ado= pting this
>document in its current form. I recognise that onc= e adopted, the WG will be able
>to enforce changes in content,= but I am concerned that this document does not
>correctly reflect the relationship with other MIB modules, and tha= t taking this
>as a starting point will encourage us to go dow= n the wrong path resulting in a
>starting direction that will = be hard to change.

>I would be happy to see the authors spend a little = more time on this and then
>adopt it into the WG.
>In overview my concerns are as follows:

> mplsGlobalId, mplsIcc and mplsNodeId are node properties th= at will turn out
> to
> be equally applicable for= PWs. They should appear in a MIB module dedicated
> to
> the LSR not just to the MPLS-TP LSPs. Given that these three obje= cts and
> mplsNodeConfigTable and mplsNodeIpMapTable are all r= elated to MPLS-TP
> identifiers, why not have a separate modul= e for them all?

=A0
<<TP-MIB-Authors>> We a= gree that mplsGlobalId, mplsIcc and mplsNodeId can be kept in a common mib = module.
mplsNodeConfigTable is created specifically to map the [G= lobal-id_Node-id]
and Icc-id into Local-Num. This Local-Num will be used as the tunnel s= ource/destination identifier.

This idea has been f= ollowed to retain the MPLS tunnel table for MPLS-TP TE extensions also.
We think that mplsNodeConfigTable/mplsNodeIpMapTable is not applicable= for PWs.
The reason is that we already have the 129 FEC PWs with= variable length of SAII & TAII.
And the SAII & TAII alre= ady includes the Global-Id and Node-Id (or ICC Id)
Since the MPLS-TP PWs are always FEC129 Type2 based PWs, the flexibili= ty in SAII & TAII=A0
can be used to configure Global-id/Node-= id or ICC id.
=A0

>= A number of objects related to Global IDs and Node IDs appear to be of the=
> wrong
> max value compared to draft-ietf-mpls-tp-ide= ntifiers. You could usefully
> define
> TCs for t= hem and for the ICC ID. =A0What will zero Global IDs and Node IDs
> mean?
=A0

<<TP-MIB-Auth= ors>> Yes, the Max value of Global-Id and Node-id are wrong. Max valu= e should be max
of 4 bytes value. We will correct them.

Yes, we can keep the TCs for Global-id/Node-id and ICC-id in a s= eperate mib
module.
1) A Global_ID of zero means that n= o Global_ID is present.
2) A Node_ID of zero is the default value= that indicates the Node_ID is
invalid.


>= ; I see the value of the ICC entries in mplsNodeConfigTable and the use of<= /div>
> mplsNodeIccMapTable to generate a unique index to use in def= ining entries in
> the
> various pre-existing tables. (But see my comme= nt on the use of
> mplsNodeConfigLocalNum in mplsTunnelExtEntr= y, below). I do not see the value
> of
> the Glob= al entries in mplsNodeConfigTable and the use of mplsNodeIpMapEntry
> since you say in the preamble to mplsTunnelExtEntry that Source-T= unnel_Num
> is
> mapped with mplsTunnelIndex. Qui= te possibly there is descriptive text
> missing.

<<TP-MIB-Authors>>=A0mplsNodeConfigTable i= s the configuration table that is used to configure Global-id/Node-id and/o= r ICC-id with
the local map number. i.e. This table is used to co= nfigure the global-id/Node-id and/or ICC-id for the
given local map number.
=A0
The other two tables m= plsNodeIpMapEntry and mplsNodeIccMapTable are just READ-ONLY tables.
<= div>These read only tables are meant for users who want to view the reverse= mapping of Global-id/Node-id=A0
or ICC-id to the LocalNum.
=A0
&= gt; There seems to be some ambiguity about whether the objects in this docu= ment
> refer to MPLS-TP or to extensions to MPLS-TE. it would = be really nice to
> sort
> this out.

<= <TP-MIB-Authors>> This document is created to address the requirem= ents of TE extensions
for MPLS-TP and this will also be applicabl= e for MPLS TE and hence the mib modules are
named generically. Since we are augmenting the TE mib, we named it as = TE extension.
If many others prefer to name this as TP extension,= we can change the names accordingly.
=A0

> mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm g= uessing
> you
> actually want a sparse augmentati= on since in a "mixed" environment you will
> not
> want to have all these objects present but unused. So you need to= change the
> way
> you define this.
<<TP-MIB-Authors>> Yes, we actually meant sp= arse augmentation. This mplsTunnelExtEntry=A0
will have entries only when required.
For example, this tabl= e will have entries for the MPLS-TP tunnels, but not for MPLS tunnels.
Does it answer your question?
Do you expect few more descri= ption to be added to this table?
Also, do you foresee any issue of augmentation? Is it possible to expl= ain the same?

> In mplsTunnel= ExtTable you do not state what DstTunnelNum is mapped with.
> = This is
> key and could completely break your augmentation unless you get it rig= ht!

<<TP-MIB-Authors>> There are= two ways to look at this problem. One way is to force the DstTunnelNum as = key.=A0
Other way is NOT to force it as key. Let us take an example to demonst= rate this.
Let us say that we have a forward LSP with SrcTunnel_1= 00, Instance_1, Source_R1, Destination_R5, DstTunnel_200.
Option1= : Force DstTunnelNum as key:
If we mandate DstTunnelNum as key, then the following combination is t= heoretically valid.
LSP1: SrcTunnel_100, Instance_1, Source_R1, D= estination_R5, DstTunnel_200
LSP2: SrcTunnel_100, Instance_1, Sou= rce_R1, Destination_R5, DstTunnel_300. Even though the LSP2 is theoreticall= y valid,
it is not correct to have same indices for the forward LSP. i.e Treati= ng the LSP2 as separate=A0
independent LSP is not looking correct= . Hence, the Option1 is dropped.
=A0
Option2: Do not fo= rce DstTunnelNum as key:
This is the option that we choose. i.e User can configure DstTunnelNum= as read-write column,=A0
but it is not part of indices to mplsTu= nnelTable. If we try to include that as key,
even the existing MP= LS based mplsTunnelTable will have problems in interpretation.=A0
Also, we do not see a real need to force that as index/key. According = to this option, the LSP1 is a valid combination.
LSP1: SrcTunnel_= 100, Instance_1, Source_R1, Destination_R5, DstTunnel_200
If user= wants to use a different reverse LSP, they can modify the DstTunnel value = as 300.
But, it will still be called as LSP1.
LSP1: SrcTunnel_100, I= nstance_1, Source_R1, Destination_R5, DstTunnel_300 (modified).
I= f required, we can discuss with mpls-tp-identifiers authors to confirm whet= her this approach is fine.
=A0
=A0
> For mplsTunnelExtEntry you have...
> =A0 =A0 =A0 =A0 =A0 =A0 Source Global identifier/ICC and Desti= nation
> =A0 =A0 =A0 =A0 =A0 =A0 Global identifier/ICC are mai= ntained in the
> =A0 =A0 =A0 =A0 =A0 =A0 mplsNodeConfigTable and mplsNodeConfigLocalNum= is used to
> =A0 =A0 =A0 =A0 =A0 =A0 create an entry in mplsT= unnelTable.
> This is possibly too vague to be actually practi= cal.

<<TP-MIB-Authors>> We created a word document to exp= lain the various options that were considered
before taking this = option. We will share the same with you.=A0
In principle, the ide= a is to reuse the mplsTunnelTable without disturbing its existing meaning f= or MPLS based tunnels.=A0
Even though we can think of alternate designs based on separate new ta= ble for MPLS_TP tunnels,
we thought that reusing the existing tab= le is a better option since MPLS_TP is just an extension of existing MPLS.<= /div>
You can go through our document and provide your comments.
=A0

> How will mplsTunnelExtDe= stTnlIndex actually be used?
> - What value will it have for u= nidirecitonal tunnels?
> =A0 (Or for bidriectional associated tunnels where the reverse
> =A0 =A0direction is not present on this LSR)

<<TP-MIB-Authors>> A zero value will be held by t= his (mplsTunnelExtDestTnlIndex) object
when the unidirectional tunnel is desired.
This object conta= ins the source tunnel index value incase of co-routed
bidirection= al tunnel and for associated bidirectional
tunnel this object con= tains the reverse direction tunnel index and
reverse lsp index object will be added in the next version of this dra= ft.

=A0
> - Is this= actually meant to be the object that gives us the
> =A0 =A0Ds= tTunnelNum? If so, what has this to do with the reverse
> =A0 =A0direction?

<<TP-MIB-A= uthors>> Yes, this helps to associate the forward/reverse direction t= unnels for
associated bi-directional tunnel.
For co-rou= ted bidirectional case, SrcTunnelNum =3D DstTunnelNum and
SrcTunnelLspNum =3D DstTunnelLspNum,
this is because we use = same tunnel entry with two different XC entries for
both forward = and reverse direction LSPs.

>= It is completely unclear to me what mplsTunnelExtTnlApp is for!

<<TP-MIB-Authors>> This object provid= es the information on whether the tunnel entry is
MPLS tunnel or = the MPLS-TP tunnel (tunnel application is either MPLS
or MPLS-TP)= .
=A0

> It certainly makes a nonsense of mpl= sTpTunnelsConfigured and
> mplsTpTunnelsActive

<= /div>
<<TP-MIB-Authors>> This is to keep the tunnel c= ount for MPLS-TP specific tunnels which are
configured as mplsTp in mplsTunnelExtTnlApp object. If the object is n= ot going
to be useful for users, this can be removed.
<= div>


>Cheers,<= /div>
>Adrian


> -----Original Message-----
>= ; From: loa@pi.nu [mailt= o:loa@pi.nu]
&= gt; Sent: 03 May 2011 18:48
> Subject: poll on draft-vkst-mpls-tp-te-m= ib-00.txt
>
>
> Working Group,
>
> this is to start a two week poll on making
>
&g= t; draft-vkst-mpls-tp-te-mib-00.txt
>
> an mpls w= orking group document.
>
> If you support the doc= ument becoming a working group document
> please respond to this poll with "yes/support"
>
> If you do not support the document becoming a working= group
> document please respond to this poll with "no/do= not support"
> and at the same time give the technical reasons why you are
=
> not supporting the document.
>
> If you= have technical comments or in any other way want to
> discuss= the document, please send these comments to the mpls
> working group mailing list, but with another subject than what
> is on this mail.
>
> The poll ends 2= 011-05-18.
>
> /Loa


--bcaec50160438e277c04a4e7c2ea-- From erminio.ottone_69@libero.it Sun Jun 5 08:37:34 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 871E521F849A for ; Sun, 5 Jun 2011 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.481 X-Spam-Level: ** X-Spam-Status: No, score=2.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6] 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 9Aya4wT8DHLg for ; Sun, 5 Jun 2011 08:37:33 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1784021F8498 for ; Sun, 5 Jun 2011 08:37:29 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0208.4DEBA2B6.00A6,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail34 (172.31.0.222) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD237D501876DFF; Sun, 5 Jun 2011 17:37:26 +0200 Message-ID: <7427101.1226881307288246015.JavaMail.defaultUser@defaultHost> Date: Sun, 5 Jun 2011 17:37:26 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.31.158.224 Subject: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 15:37:34 -0000 >I am tired of this discussion. There seems to be no forward progress only= =20 restatement of a "want". I always wanted a pony when I was a little girl, b= ut I=20 never got one. > The problem is that there are a lot of technical questions on the table tha= t=20 can be easily answered by supporting mixed ICC and IP identifiers that are = now=20 waiting for an answer, >----Messaggio originale---- >Da: adrian@olddog.co.uk >Data: 25-mag-2011 11.13 >A: >Ogg: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Hi Neil, > >I'm not assuming peering. I am actually pointing out to Huub that (despite= =20 what he keeps saying) he is also not assuming peering. > >The consequence of not peering is that a single identifier mode is used fo= r=20 both ends of an OAM "session". And that means that one end has to understan= d=20 *and* use the "foreign" format at the remote end of the session. > >I am tired of this discussion. There seems to be no forward progress only= =20 restatement of a "want". I always wanted a pony when I was a little girl, b= ut I=20 never got one. > >Adrian > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> neil.2.harrison@bt.com >> Sent: 22 May 2011 20:36 >> To: huubatwork@gmail.com; mpls@ietf.org >> Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? >>=20 >> Hi Adrian/Huub, >>=20 >> You are largely assuming some form of peering (single partitioned layer= =20 network) >> here...and that model will generate a whole raft of problems for operato= rs=20 IMO. >> A more important model for a co-ps transport network is client/server. = And=20 now >> not only have we the usual intra-layer misconnectivity to deal with but = we=20 also >> have inter-layer misconnectivity...and this means each operating party= =20 must >> understand the OAM formats (and CV IDs) of each other anyway... not simp= ly=20 to >> detect there is a misconnectivity problems but also to identify which ot= her=20 parties >> are involved. >>=20 >> regards, Neil >>=20 >> BT Design >> This email contains BT information, which may be privileged or=20 confidential. >> It's meant only for the individual(s) or entity named above. If you're n= ot=20 the >> intended >> recipient, note that disclosing, copying, distributing or using this=20 information >> is prohibited. If you've received this email in error, please let me kno= w >> immediately >> 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 >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O= f >> > Huub van Helvoort >> > Sent: 22 May 2011 19:15 >> > To: mpls@ietf.org >> > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP >> > Identifiers? >> > >> > Hi Adrian, >> > >> > See my response in-line [hvh] >> > >> > > We have already been round this loop on this list once. >> > > Want to do it again? >> > >> > [hvh] If it helps to get to the focal point, why not. >> > >> > > As Huub said, this is about identifiers, not OAM. However, the model >> > for OAM >> > > interworking shows "layering" not gatewaying, and certainly not >> > mixing. That is, >> > > one end of the e2e path must be capable of operating both systems, >> > but the other >> > > does not need to. >> > >> > [hvh] OK if you mean "OAM toolsets" by "systems" >> > >> > > To extend this model to identifiers means that one end of the e2e >> > path must >> > > support both identifier formats and the other does not need to. >> > >> > [hvh] to be more specific the originating end of an e2e path must >> > be able to support one of the possible identifier formats, normally >> > the identifier format of the local operator. The terminating end and >> > the intermediate points of an e2e path must be able to verify the >> > format inserted at the origin independent of the locally used >> > identifier >> > format. This means that it must be possible to support different >> > identifier formats in the A-->Z ans Z-->A direction of an e2e path. >> > I.e. mixing of identifier formats must be supported. >> > >> > > This becomes particularly important to the transit nodes that may >> > have to >> > > inspect the identifiers. >> > >> > [hvh] the inspection will consist of comparing a received value >> > with an expected value which can have any format. >> > >> > > None of this is new or specific to MPLS-TP. >> > >> > [hvh] I agree, mixing of identifier formats it not restricted to >> > MPLS-TP. >> > >> > Regards, Huub. >> > >> > >> -----Original Message----- >> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f >> > Of >> > >> erminio.ottone_69@libero.it >> > >> Sent: 18 May 2011 22:25 >> > >> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn >> > >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP >> > Identifiers? >> > >> >> > >> Appendix II of Y.1731 provides a good example about how inter-domai= n >> > >> connectivity with e2e OAM can be provided using transport-oriented >> > OAM >> > >> functions. >> > >> >> > >> You can download the latest version of Y.1731 (the pdr version is >> > for free) at >> > >> the following URL: >> > >> >> > >> http://www.itu.int/rec/T-REC-Y.1731/en >> > >> >> > >> It is a pity that with the current version of the identifier draft, >> > MPLS-TP is >> > >> not capable to support such a network scenario. >> > >> >> > >>> ----Messaggio originale---- >> > >>> Da: loa@pi.nu >> > >>> Data: 4-mag-2011 8.00 >> > >>> A:, >> > >> "Malcolm.BETTS@zte.com.cn" >> > >>> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> > >>> >> > >>> Malcolm, >> > >>> >> > >>> are you saying that operators today allow OAM to control node (MIP= s >> > and >> > >>> MEPs) on each others networks? >> > >>> >> > >>> Do we have an operator that can verify this? >> > >>> >> > >>> /Loa >> > >>> >> > >>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >> > >>>> >> > >>>> All, >> > >>>> >> > >>>> I share your concerns and doubts about a multi carrier control >> > plane. >> > >>>> However, I think that it is essential that a transport network >> > supports >> > >>>> multi carrier data plane interconnection with end to end OAM. In >> > today's >> > >>>> transport network this interconnection is supported by SDH and >> > OTN. The >> > >>>> objective for MPLS-TP is to allow for packet based interconnectio= n >> > as >> > >> well. >> > >>>> >> > >>>> Regards, >> > >>>> >> > >>>> Malcolm >> > >>>> >> > >>>> >> > >>>> >> > >>>> *George Swallow* >> > >>>> Sent by: mpls-bounces@ietf.org >> > >>>> >> > >>>> 03/05/2011 11:09 AM >> > >>>> >> > >>>> >> > >>>> To >> > >>>> =09"Andrew G. Malis", >> > >>>> cc >> > >>>> =09mpls@ietf.org >> > >>>> Subject >> > >>>> =09Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> Andy - >> > >>>> >> > >>>> > Such >> > >>>> > an E-NNI definition does not yet exist for MPLS-TP (somethin= g >> > else to >> > >>>> > put on the to-do list). This E-NNI would also include simila= r >> > >>>> > identifier mapping/translation for MS-PWs, to answer an >> > earlier >> > >>>> > question from Erminio that I saw on the list. >> > >>>> >> > >>>> You are quite correct here! I think much of this debate surrounds >> > a >> > >> problem >> > >>>> that is yet to be solved. So there are arguments for pieces of a >> > solution >> > >>>> without and overall architecture. >> > >>>> >> > >>>> Based on all that I am seeing my inclination is to NOT say that w= e >> > >> disallow >> > >>>> mixed identifiers, but to say that they are for future study. >> > >>>> >> > >>>> ...George >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: >> > >>>> >> > >>>> > Neil, >> > >>>> > >> > >>>> > To your case 1, we're in complete agreement. We (VZ) don't >> > see at >> > >>>> > least a short-term need for peer-layer interworking, given >> > where we >> > >>>> > intend to deploy MPLS-TP in our infrastructure (as an >> > internal server >> > >>>> > layer in the transport core). If peer layer interworking eve= r >> > becomes >> > >>>> > a necessity, then obviously we'll need a well-defined E-NNI >> > which >> > >>>> > would include LSP identifier mapping/translation at the >> > boundary, for >> > >>>> > LSP provisioning (whether static or dynamic) and end-to-end >> > OAM. Such >> > >>>> > an E-NNI definition does not yet exist for MPLS-TP (somethin= g >> > else to >> > >>>> > put on the to-do list). This E-NNI would also include simila= r >> > >>>> > identifier mapping/translation for MS-PWs, to answer an >> > earlier >> > >>>> > question from Erminio that I saw on the list. >> > >>>> > >> > >>>> > I also agree that both intra-layer and inter-layer mis- >> > connectivity >> > >>>> > detection and amelioration are required, but I'm not >> > convinced that >> > >>>> > the already defined mechanisms can't do that. Do you have >> > some >> > >>>> > specific analysis on the inter-layer case? >> > >>>> > >> > >>>> > Cheers, >> > >>>> > Andy >> > >>>> > >> > >>>> > On Tue, May 3, 2011 at 3:36 AM, >> > wrote: >> > >>>> >> Hi Andy, >> > >>>> >> >> > >>>> >> 2 points: >> > >>>> >> >> > >>>> >> 1 I agree with your view of only having a single addressing >> > scheme in >> > >> a >> > >>>> >> single layer network solely belonging to one party. Though >> > you may >> > >>>> need to >> > >>>> >> be rather careful if you also advocate that one can also >> > have peer >> > >> layer >> > >>>> >> interworking between different parties, ie E-NNIs (I believ= e >> > this is >> > >>>> >> something you may support, eg old MPLSF case?). In such a >> > peer >> > >>>> interworking >> > >>>> >> case it would seem one must allow different addressing >> > schemes (and >> > >>>> indeed >> > >>>> >> any other variations in DP/CP functional components) if the= y >> > exist >> > >>>> in the >> > >>>> >> standards. >> > >>>> >> >> > >>>> >> Of course, having an E-NNI and peer interworking between >> > different >> > >>>> parties in >> > >>>> >> any non-TOS layer network (not just MPLS) is not technicall= y >> > >>>> necessary (this >> > >>>> >> is trivial to prove), and this provides a strong argument >> > for only >> > >>>> having a >> > >>>> >> single addressing scheme in a non-TOS layer network. >> > >>>> >> >> > >>>> >> >> > >>>> >> 2 You should also be aware that in client/server >> > interworking of the >> > >>>> >> co-ps mode using variable size traffic units, and therefore >> > >>>> something rather >> > >>>> >> important for MPLS-TP in the role of a transport network >> > (I'll >> > >>>> ignore issues >> > >>>> >> of transparency here), there could be inter-layer >> > misconnectivity >> > >>>> (Aside=3D> >> > >>>> >> This case cannot occur in the co-cs mode). To date, however= , >> > we have >> > >>>> only >> > >>>> >> really considered intra-layer misconnectivity, ie between >> > different >> > >> LSPs >> > >>>> >> belonging to the same party (note this also includes all >> > cases of >> > >>>> nested LSP >> > >>>> >> sublayer misconnectivity). >> > >>>> >> >> > >>>> >> In the case of inter-layer misconnectivity one may receive >> > traffic >> > >>>> units and >> > >>>> >> OAM messages from some other party's layer network. The OAM >> > >> messages >> > >> may >> > >>>> >> come from (i) networks using different OAM/addressing >> > solutions or >> > >> (ii) >> > >>>> >> networks using the same OAM/addressing solutions. In both >> > cases >> > >>>> there are >> > >>>> >> different issues wrt inter-layer misconnectivity one has to >> > deal >> > >>>> with. I'm >> > >>>> >> not aware that these cases have been considered yet. >> > >>>> >> >> > >>>> >> >> > >>>> >> I'd like to hear your comments on both these points, but in >> > >>>> particular the >> > >>>> >> first one.....especially if you also support the notion of >> > E-NNIs in >> > >>>> MPLS-TP, >> > >>>> >> as there seems to a possible logical conflict here. >> > >>>> >> >> > >>>> >> Thanks. >> > >>>> >> >> > >>>> >> regards, Neil Harrison >> > >>>> >> >> > >>>> >> BT Design >> > >>>> >> >> > >>>> >> 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 >> > >>>> >> information >> > >>>> >> is prohibited. If you've received this email in error, >> > please let me >> > >>>> know >> > >>>> >> immediately >> > >>>> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> > On Behalf >> > >> Of >> > >>>> >>> Andrew G. Malis >> > >>>> >>> Sent: 02 May 2011 20:48 >> > >>>> >>> To: George Swallow >> > >>>> >>> Cc: mpls@ietf.org >> > >>>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >> > Identifiers? >> > >>>> >>> >> > >>>> >>> George et al, >> > >>>> >>> >> > >>>> >>> Verizon does not have any requirement for mixed use of >> > Global IDs and >> > >>>> >>> ICCs. We are fine with specifications that require both >> > ends of an >> > >> LSP >> > >>>> >>> to use one or the other. >> > >>>> >>> >> > >>>> >>> Thanks, >> > >>>> >>> Andy >> > >>>> >>> >> > >>>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George >> > Swallow >> > >>>> >>> wrote: >> > >>>> >>>> All - >> > >>>> >>>> >> > >>>> >>>> Many of the comments received from the ITU on >> > >>>> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the >> > Global and ICC >> > >>>> >>>> identifiers. >> > >>>> >>>> >> > >>>> >>>> The identifiers for Tunnel, LSP, PW, and MEG include >> > fields to >> > >>>> >>> identify each >> > >>>> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, >> > PW, or MEG >> > >>>> >>> to use >> > >>>> >>>> either the Global-ID for both ends or or the ICC for both >> > ends. >> > >>>> >>> Mixed use >> > >>>> >>>> is not permitted. >> > >>>> >>>> >> > >>>> >>>> The ITU liaison requests that we allow mixed use. >> > >>>> >>>> >> > >>>> >>>> The authors of the draft are very reluctant to do this. >> > >>>> >>>> >> > >>>> >>>> Obtaining an AS Number (from which the Global-ID is >> > derived) is a >> > >>>> >>> fairly >> > >>>> >>>> trivial procedure. Many organizations if not most already >> > have AS >> > >>>> >>> Numbers. >> > >>>> >>>> Such an addition will add numerous object formats, and >> > test cases. >> > >>>> >>>> The extent inter-provider MPLS-TP is as yet unknown. If >> > mixed modes >> > >>>> >>> of ICC >> > >>>> >>>> and Global-ID identification is required, they can be >> > added later. >> > >>>> >>>> For signaled connections, there is no plan to allow >> > routing based on >> > >>>> >>> either >> > >>>> >>>> the Global-ID or ICC. That would be a radical change to >> > how IP >> > >>>> >>> works. >> > >>>> >>>> However for IP routing to work (in order to forward the >> > signaling >> > >>>> >>>> messages), the providers involved will need to run BGP an= d >> > have AS >> > >>>> >>> numbers. >> > >>>> >>>> >> > >>>> >>>> We are looking for input/consensus from the WG. >> > >>>> >>>> >> > >>>> >>>> George, Eric,& Matthew >> > >> > >> > -- >> > >> ************************************************************** >> *** >> > =E6=88=91=E7=88=B1=E5=A4=96=E7=82=B9=E4=B8= =80=E4=B8=83=E4=B8=89=E4=B8=80 >> > _______________________________________________ >> > 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 nurit.sprecher@nsn.com Sun Jun 5 08:41: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 8FD4C11E8072 for ; Sun, 5 Jun 2011 08:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 xnAbXO3rTg6w for ; Sun, 5 Jun 2011 08:41:40 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 64FB711E8071 for ; Sun, 5 Jun 2011 08:41:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p55FfcsQ013984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Jun 2011 17:41:38 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p55FfbOp017342; Sun, 5 Jun 2011 17:41:37 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Jun 2011 17:41:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 5 Jun 2011 17:41:33 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403E8A40C@DEMUEXC014.nsn-intra.net> In-Reply-To: <7427101.1226881307288246015.JavaMail.defaultUser@defaultHost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: Acwjlomy2RbRMYSPQ9aYhZVZ7tvS3AAAHi6w References: <7427101.1226881307288246015.JavaMail.defaultUser@defaultHost> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , , X-OriginalArrivalTime: 05 Jun 2011 15:41:37.0364 (UTC) FILETIME=[0E499940:01CC2397] Subject: Re: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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: Sun, 05 Jun 2011 15:41:41 -0000 U28gY29tZSB3aXRoIGEgZHJhZnQgYW5kIHByZXNlbnQgaXQuIA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IGVybWluaW8ub3R0b25lXzY5QGxpYmVyby5p dA0KU2VudDogU3VuZGF5LCBKdW5lIDA1LCAyMDExIDY6MzcgUE0NClRvOiBhZHJpYW5Ab2xkZG9n LmNvLnVrOyBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBbbXBsc10gUjogUmU6IFI6IFJlOiBNaXhp bmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFAgSWRlbnRpZmllcnM/DQoNCj5JIGFtIHRp cmVkIG9mIHRoaXMgZGlzY3Vzc2lvbi4gVGhlcmUgc2VlbXMgdG8gYmUgbm8gZm9yd2FyZCBwcm9n cmVzcyBvbmx5IA0KcmVzdGF0ZW1lbnQgb2YgYSAid2FudCIuIEkgYWx3YXlzIHdhbnRlZCBhIHBv bnkgd2hlbiBJIHdhcyBhIGxpdHRsZSBnaXJsLCBidXQgSSANCm5ldmVyIGdvdCBvbmUuDQo+DQoN ClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUgYXJlIGEgbG90IG9mIHRlY2huaWNhbCBxdWVzdGlv bnMgb24gdGhlIHRhYmxlIHRoYXQgDQpjYW4gYmUgZWFzaWx5IGFuc3dlcmVkIGJ5IHN1cHBvcnRp bmcgbWl4ZWQgSUNDIGFuZCBJUCBpZGVudGlmaWVycyB0aGF0IGFyZSBub3cgDQp3YWl0aW5nIGZv ciBhbiBhbnN3ZXIsDQoNCj4tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0NCj5EYTogYWRyaWFu QG9sZGRvZy5jby51aw0KPkRhdGE6IDI1LW1hZy0yMDExIDExLjEzDQo+QTogPG1wbHNAaWV0Zi5v cmc+DQo+T2dnOiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGlu IE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+DQo+SGkgTmVpbCwNCj4NCj5JJ20gbm90IGFzc3VtaW5n IHBlZXJpbmcuIEkgYW0gYWN0dWFsbHkgcG9pbnRpbmcgb3V0IHRvIEh1dWIgdGhhdCAoZGVzcGl0 ZSANCndoYXQgaGUga2VlcHMgc2F5aW5nKSBoZSBpcyBhbHNvIG5vdCBhc3N1bWluZyBwZWVyaW5n Lg0KPg0KPlRoZSBjb25zZXF1ZW5jZSBvZiBub3QgcGVlcmluZyBpcyB0aGF0IGEgc2luZ2xlIGlk ZW50aWZpZXIgbW9kZSBpcyB1c2VkIGZvciANCmJvdGggZW5kcyBvZiBhbiBPQU0gInNlc3Npb24i LiBBbmQgdGhhdCBtZWFucyB0aGF0IG9uZSBlbmQgaGFzIHRvIHVuZGVyc3RhbmQgDQoqYW5kKiB1 c2UgdGhlICJmb3JlaWduIiBmb3JtYXQgYXQgdGhlIHJlbW90ZSBlbmQgb2YgdGhlIHNlc3Npb24u DQo+DQo+SSBhbSB0aXJlZCBvZiB0aGlzIGRpc2N1c3Npb24uIFRoZXJlIHNlZW1zIHRvIGJlIG5v IGZvcndhcmQgcHJvZ3Jlc3Mgb25seSANCnJlc3RhdGVtZW50IG9mIGEgIndhbnQiLiBJIGFsd2F5 cyB3YW50ZWQgYSBwb255IHdoZW4gSSB3YXMgYSBsaXR0bGUgZ2lybCwgYnV0IEkgDQpuZXZlciBn b3Qgb25lLg0KPg0KPkFkcmlhbg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+PiBuZWlsLjIuaGFycmlzb25AYnQuY29tDQo+PiBTZW50OiAyMiBN YXkgMjAxMSAyMDozNg0KPj4gVG86IGh1dWJhdHdvcmtAZ21haWwuY29tOyBtcGxzQGlldGYub3Jn DQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURz IGluIE1QTFMtVFAgDQpJZGVudGlmaWVycz8NCj4+IA0KPj4gSGkgQWRyaWFuL0h1dWIsDQo+PiAN Cj4+IFlvdSBhcmUgbGFyZ2VseSBhc3N1bWluZyBzb21lIGZvcm0gb2YgcGVlcmluZyAoc2luZ2xl IHBhcnRpdGlvbmVkIGxheWVyIA0KbmV0d29yaykNCj4+IGhlcmUuLi5hbmQgdGhhdCBtb2RlbCB3 aWxsIGdlbmVyYXRlIGEgd2hvbGUgcmFmdCBvZiBwcm9ibGVtcyBmb3Igb3BlcmF0b3JzIA0KSU1P Lg0KPj4gQSBtb3JlIGltcG9ydGFudCBtb2RlbCBmb3IgYSBjby1wcyB0cmFuc3BvcnQgbmV0d29y ayBpcyBjbGllbnQvc2VydmVyLiAgQW5kIA0Kbm93DQo+PiBub3Qgb25seSBoYXZlIHdlIHRoZSB1 c3VhbCBpbnRyYS1sYXllciBtaXNjb25uZWN0aXZpdHkgdG8gZGVhbCB3aXRoIGJ1dCB3ZSANCmFs c28NCj4+IGhhdmUgaW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5Li4uYW5kIHRoaXMgbWVhbnMg ZWFjaCBvcGVyYXRpbmcgcGFydHkgDQptdXN0DQo+PiB1bmRlcnN0YW5kIHRoZSBPQU0gZm9ybWF0 cyAoYW5kIENWIElEcykgb2YgZWFjaCBvdGhlciBhbnl3YXkuLi4gbm90IHNpbXBseSANCnRvDQo+ PiBkZXRlY3QgdGhlcmUgaXMgYSBtaXNjb25uZWN0aXZpdHkgcHJvYmxlbXMgYnV0IGFsc28gdG8g aWRlbnRpZnkgd2hpY2ggb3RoZXIgDQpwYXJ0aWVzDQo+PiBhcmUgaW52b2x2ZWQuDQo+PiANCj4+ IHJlZ2FyZHMsIE5laWwNCj4+IA0KPj4gQlQgRGVzaWduDQo+PiBUaGlzIGVtYWlsIGNvbnRhaW5z IEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciANCmNvbmZpZGVudGlh bC4NCj4+IEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5h bWVkIGFib3ZlLiBJZiB5b3UncmUgbm90IA0KdGhlDQo+PiBpbnRlbmRlZA0KPj4gcmVjaXBpZW50 LCBub3RlIHRoYXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRo aXMgDQppbmZvcm1hdGlvbg0KPj4gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdw0KPj4gaW1tZWRpYXRlbHkNCj4+ IG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3UuDQo+PiBXZSBtb25pdG9yIG91 ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KPj4gQnJpdGlzaCBU ZWxlY29tbXVuaWNhdGlvbnMgcGxjDQo+PiBSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBT dHJlZXQgTG9uZG9uIEVDMUEgN0FKDQo+PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAw MDANCj4+IA0KPj4gDQo+PiANCj4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4g RnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4+ID4gSHV1YiB2YW4gSGVsdm9vcnQNCj4+ID4gU2VudDogMjIgTWF5 IDIwMTEgMTk6MTUNCj4+ID4gVG86IG1wbHNAaWV0Zi5vcmcNCj4+ID4gU3ViamVjdDogUmU6IFtt cGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+PiA+IElk ZW50aWZpZXJzPw0KPj4gPg0KPj4gPiBIaSBBZHJpYW4sDQo+PiA+DQo+PiA+IFNlZSBteSByZXNw b25zZSBpbi1saW5lIFtodmhdDQo+PiA+DQo+PiA+ID4gV2UgaGF2ZSBhbHJlYWR5IGJlZW4gcm91 bmQgdGhpcyBsb29wIG9uIHRoaXMgbGlzdCBvbmNlLg0KPj4gPiA+IFdhbnQgdG8gZG8gaXQgYWdh aW4/DQo+PiA+DQo+PiA+IFtodmhdIElmIGl0IGhlbHBzIHRvIGdldCB0byB0aGUgZm9jYWwgcG9p bnQsIHdoeSBub3QuDQo+PiA+DQo+PiA+ID4gQXMgSHV1YiBzYWlkLCB0aGlzIGlzIGFib3V0IGlk ZW50aWZpZXJzLCBub3QgT0FNLiBIb3dldmVyLCB0aGUgbW9kZWwNCj4+ID4gZm9yIE9BTQ0KPj4g PiA+IGludGVyd29ya2luZyBzaG93cyAibGF5ZXJpbmciIG5vdCBnYXRld2F5aW5nLCBhbmQgY2Vy dGFpbmx5IG5vdA0KPj4gPiBtaXhpbmcuIFRoYXQgaXMsDQo+PiA+ID4gb25lIGVuZCBvZiB0aGUg ZTJlIHBhdGggbXVzdCBiZSBjYXBhYmxlIG9mIG9wZXJhdGluZyBib3RoIHN5c3RlbXMsDQo+PiA+ IGJ1dCB0aGUgb3RoZXINCj4+ID4gPiBkb2VzIG5vdCBuZWVkIHRvLg0KPj4gPg0KPj4gPiBbaHZo XSBPSyBpZiB5b3UgbWVhbiAiT0FNIHRvb2xzZXRzIiBieSAic3lzdGVtcyINCj4+ID4NCj4+ID4g PiBUbyBleHRlbmQgdGhpcyBtb2RlbCB0byBpZGVudGlmaWVycyBtZWFucyB0aGF0IG9uZSBlbmQg b2YgdGhlIGUyZQ0KPj4gPiBwYXRoIG11c3QNCj4+ID4gPiBzdXBwb3J0IGJvdGggaWRlbnRpZmll ciBmb3JtYXRzIGFuZCB0aGUgb3RoZXIgZG9lcyBub3QgbmVlZCB0by4NCj4+ID4NCj4+ID4gW2h2 aF0gdG8gYmUgbW9yZSBzcGVjaWZpYyB0aGUgb3JpZ2luYXRpbmcgZW5kIG9mIGFuIGUyZSBwYXRo IG11c3QNCj4+ID4gYmUgYWJsZSB0byBzdXBwb3J0IG9uZSBvZiB0aGUgcG9zc2libGUgaWRlbnRp ZmllciBmb3JtYXRzLCBub3JtYWxseQ0KPj4gPiB0aGUgaWRlbnRpZmllciBmb3JtYXQgb2YgdGhl IGxvY2FsIG9wZXJhdG9yLiBUaGUgdGVybWluYXRpbmcgZW5kIGFuZA0KPj4gPiB0aGUgaW50ZXJt ZWRpYXRlIHBvaW50cyBvZiBhbiBlMmUgcGF0aCBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRoZQ0K Pj4gPiBmb3JtYXQgaW5zZXJ0ZWQgYXQgdGhlIG9yaWdpbiBpbmRlcGVuZGVudCBvZiB0aGUgbG9j YWxseSB1c2VkDQo+PiA+IGlkZW50aWZpZXINCj4+ID4gZm9ybWF0LiBUaGlzIG1lYW5zIHRoYXQg aXQgbXVzdCBiZSBwb3NzaWJsZSB0byBzdXBwb3J0IGRpZmZlcmVudA0KPj4gPiBpZGVudGlmaWVy IGZvcm1hdHMgaW4gdGhlIEEtLT5aIGFucyBaLS0+QSBkaXJlY3Rpb24gb2YgYW4gZTJlIHBhdGgu DQo+PiA+IEkuZS4gbWl4aW5nIG9mIGlkZW50aWZpZXIgZm9ybWF0cyBtdXN0IGJlIHN1cHBvcnRl ZC4NCj4+ID4NCj4+ID4gPiBUaGlzIGJlY29tZXMgcGFydGljdWxhcmx5IGltcG9ydGFudCB0byB0 aGUgdHJhbnNpdCBub2RlcyB0aGF0IG1heQ0KPj4gPiBoYXZlIHRvDQo+PiA+ID4gaW5zcGVjdCB0 aGUgaWRlbnRpZmllcnMuDQo+PiA+DQo+PiA+IFtodmhdIHRoZSBpbnNwZWN0aW9uIHdpbGwgY29u c2lzdCBvZiBjb21wYXJpbmcgYSByZWNlaXZlZCB2YWx1ZQ0KPj4gPiB3aXRoIGFuIGV4cGVjdGVk IHZhbHVlIHdoaWNoIGNhbiBoYXZlIGFueSBmb3JtYXQuDQo+PiA+DQo+PiA+ID4gTm9uZSBvZiB0 aGlzIGlzIG5ldyBvciBzcGVjaWZpYyB0byBNUExTLVRQLg0KPj4gPg0KPj4gPiBbaHZoXSBJIGFn cmVlLCBtaXhpbmcgb2YgaWRlbnRpZmllciBmb3JtYXRzIGl0IG5vdCByZXN0cmljdGVkIHRvDQo+ PiA+IE1QTFMtVFAuDQo+PiA+DQo+PiA+IFJlZ2FyZHMsIEh1dWIuDQo+PiA+DQo+PiA+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+PiA+IE9mDQo+ PiA+ID4+IGVybWluaW8ub3R0b25lXzY5QGxpYmVyby5pdA0KPj4gPiA+PiBTZW50OiAxOCBNYXkg MjAxMSAyMjoyNQ0KPj4gPiA+PiBUbzogbG9hQHBpLm51OyBtcGxzQGlldGYub3JnOyBNYWxjb2xt LkJFVFRTQHp0ZS5jb20uY24NCj4+ID4gPj4gU3ViamVjdDogW21wbHNdIFI6IFJlOiBNaXhpbmcg SUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4+ID4gSWRlbnRpZmllcnM/DQo+PiA+ID4+ DQo+PiA+ID4+IEFwcGVuZGl4IElJIG9mIFkuMTczMSBwcm92aWRlcyBhIGdvb2QgZXhhbXBsZSBh Ym91dCBob3cgaW50ZXItZG9tYWluDQo+PiA+ID4+IGNvbm5lY3Rpdml0eSB3aXRoIGUyZSBPQU0g Y2FuIGJlIHByb3ZpZGVkIHVzaW5nIHRyYW5zcG9ydC1vcmllbnRlZA0KPj4gPiBPQU0NCj4+ID4g Pj4gZnVuY3Rpb25zLg0KPj4gPiA+Pg0KPj4gPiA+PiBZb3UgY2FuIGRvd25sb2FkIHRoZSBsYXRl c3QgdmVyc2lvbiBvZiBZLjE3MzEgKHRoZSBwZHIgdmVyc2lvbiBpcw0KPj4gPiBmb3IgZnJlZSkg YXQNCj4+ID4gPj4gdGhlIGZvbGxvd2luZyBVUkw6DQo+PiA+ID4+DQo+PiA+ID4+IGh0dHA6Ly93 d3cuaXR1LmludC9yZWMvVC1SRUMtWS4xNzMxL2VuDQo+PiA+ID4+DQo+PiA+ID4+IEl0IGlzIGEg cGl0eSB0aGF0IHdpdGggdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgaWRlbnRpZmllciBkcmFm dCwNCj4+ID4gTVBMUy1UUCBpcw0KPj4gPiA+PiBub3QgY2FwYWJsZSB0byBzdXBwb3J0IHN1Y2gg YSBuZXR3b3JrIHNjZW5hcmlvLg0KPj4gPiA+Pg0KPj4gPiA+Pj4gLS0tLU1lc3NhZ2dpbyBvcmln aW5hbGUtLS0tDQo+PiA+ID4+PiBEYTogbG9hQHBpLm51DQo+PiA+ID4+PiBEYXRhOiA0LW1hZy0y MDExIDguMDANCj4+ID4gPj4+IEE6PG1wbHNAaWV0Zi5vcmc+LA0KPj4gPiA+PiAiTWFsY29sbS5C RVRUU0B6dGUuY29tLmNuIjxNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+DQo+PiA+ID4+PiBPZ2c6 IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQIElkZW50aWZp ZXJzPw0KPj4gPiA+Pj4NCj4+ID4gPj4+IE1hbGNvbG0sDQo+PiA+ID4+Pg0KPj4gPiA+Pj4gYXJl IHlvdSBzYXlpbmcgdGhhdCBvcGVyYXRvcnMgdG9kYXkgYWxsb3cgT0FNIHRvIGNvbnRyb2wgbm9k ZSAoTUlQcw0KPj4gPiBhbmQNCj4+ID4gPj4+IE1FUHMpIG9uIGVhY2ggb3RoZXJzIG5ldHdvcmtz Pw0KPj4gPiA+Pj4NCj4+ID4gPj4+IERvIHdlIGhhdmUgYW4gb3BlcmF0b3IgdGhhdCBjYW4gdmVy aWZ5IHRoaXM/DQo+PiA+ID4+Pg0KPj4gPiA+Pj4gL0xvYQ0KPj4gPiA+Pj4NCj4+ID4gPj4+IE9u IDIwMTEtMDUtMDMgMjI6NDQsIE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiB3cm90ZToNCj4+ID4g Pj4+Pg0KPj4gPiA+Pj4+IEFsbCwNCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+IEkgc2hhcmUgeW91ciBj b25jZXJucyBhbmQgZG91YnRzIGFib3V0IGEgbXVsdGkgY2FycmllciBjb250cm9sDQo+PiA+IHBs YW5lLg0KPj4gPiA+Pj4+IEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBpdCBpcyBlc3NlbnRpYWwgdGhh dCBhIHRyYW5zcG9ydCBuZXR3b3JrDQo+PiA+IHN1cHBvcnRzDQo+PiA+ID4+Pj4gbXVsdGkgY2Fy cmllciBkYXRhIHBsYW5lIGludGVyY29ubmVjdGlvbiB3aXRoIGVuZCB0byBlbmQgT0FNLiBJbg0K Pj4gPiB0b2RheSdzDQo+PiA+ID4+Pj4gdHJhbnNwb3J0IG5ldHdvcmsgdGhpcyBpbnRlcmNvbm5l Y3Rpb24gaXMgc3VwcG9ydGVkIGJ5IFNESCBhbmQNCj4+ID4gT1ROLiBUaGUNCj4+ID4gPj4+PiBv YmplY3RpdmUgZm9yIE1QTFMtVFAgaXMgdG8gYWxsb3cgZm9yIHBhY2tldCBiYXNlZCBpbnRlcmNv bm5lY3Rpb24NCj4+ID4gYXMNCj4+ID4gPj4gd2VsbC4NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+IFJl Z2FyZHMsDQo+PiA+ID4+Pj4NCj4+ID4gPj4+PiBNYWxjb2xtDQo+PiA+ID4+Pj4NCj4+ID4gPj4+ Pg0KPj4gPiA+Pj4+DQo+PiA+ID4+Pj4gKkdlb3JnZSBTd2FsbG93PHN3YWxsb3dAY2lzY28uY29t PioNCj4+ID4gPj4+PiBTZW50IGJ5OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4+ID4gPj4+Pg0K Pj4gPiA+Pj4+IDAzLzA1LzIwMTEgMTE6MDkgQU0NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+DQo+PiA+ ID4+Pj4gVG8NCj4+ID4gPj4+PiAJIkFuZHJldyBHLiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+ LDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPj4gPiA+Pj4+IGNjDQo+PiA+ID4+Pj4gCW1wbHNA aWV0Zi5vcmcNCj4+ID4gPj4+PiBTdWJqZWN0DQo+PiA+ID4+Pj4gCVJlOiBbbXBsc10gTWl4aW5n IElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KPj4gPiA+Pj4+DQo+ PiA+ID4+Pj4NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+DQo+PiA+ID4+Pj4NCj4+ID4gPj4+Pg0KPj4g PiA+Pj4+DQo+PiA+ID4+Pj4NCj4+ID4gPj4+PiBBbmR5IC0NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+ ICAgPiAgU3VjaA0KPj4gPiA+Pj4+ICAgPiAgYW4gRS1OTkkgZGVmaW5pdGlvbiBkb2VzIG5vdCB5 ZXQgZXhpc3QgZm9yIE1QTFMtVFAgKHNvbWV0aGluZw0KPj4gPiBlbHNlIHRvDQo+PiA+ID4+Pj4g ICA+ICBwdXQgb24gdGhlIHRvLWRvIGxpc3QpLiBUaGlzIEUtTk5JIHdvdWxkIGFsc28gaW5jbHVk ZSBzaW1pbGFyDQo+PiA+ID4+Pj4gICA+ICBpZGVudGlmaWVyIG1hcHBpbmcvdHJhbnNsYXRpb24g Zm9yIE1TLVBXcywgdG8gYW5zd2VyIGFuDQo+PiA+IGVhcmxpZXINCj4+ID4gPj4+PiAgID4gIHF1 ZXN0aW9uIGZyb20gRXJtaW5pbyB0aGF0IEkgc2F3IG9uIHRoZSBsaXN0Lg0KPj4gPiA+Pj4+DQo+ PiA+ID4+Pj4gWW91IGFyZSBxdWl0ZSBjb3JyZWN0IGhlcmUhIEkgdGhpbmsgbXVjaCBvZiB0aGlz IGRlYmF0ZSBzdXJyb3VuZHMNCj4+ID4gYQ0KPj4gPiA+PiBwcm9ibGVtDQo+PiA+ID4+Pj4gdGhh dCBpcyB5ZXQgdG8gYmUgc29sdmVkLiBTbyB0aGVyZSBhcmUgYXJndW1lbnRzIGZvciBwaWVjZXMg b2YgYQ0KPj4gPiBzb2x1dGlvbg0KPj4gPiA+Pj4+IHdpdGhvdXQgYW5kIG92ZXJhbGwgYXJjaGl0 ZWN0dXJlLg0KPj4gPiA+Pj4+DQo+PiA+ID4+Pj4gQmFzZWQgb24gYWxsIHRoYXQgSSBhbSBzZWVp bmcgbXkgaW5jbGluYXRpb24gaXMgdG8gTk9UIHNheSB0aGF0IHdlDQo+PiA+ID4+IGRpc2FsbG93 DQo+PiA+ID4+Pj4gbWl4ZWQgaWRlbnRpZmllcnMsIGJ1dCB0byBzYXkgdGhhdCB0aGV5IGFyZSBm b3IgZnV0dXJlIHN0dWR5Lg0KPj4gPiA+Pj4+DQo+PiA+ID4+Pj4gLi4uR2VvcmdlDQo+PiA+ID4+ Pj4NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+DQo+PiA+ID4+Pj4NCj4+ID4gPj4+Pg0KPj4gPiA+Pj4+ IE9uIDUvMy8xMSA4OjM4IEFNLCAiQW5kcmV3IEcuIE1hbGlzIjxhZ21hbGlzQGdtYWlsLmNvbT4g IHdyb3RlOg0KPj4gPiA+Pj4+DQo+PiA+ID4+Pj4gICA+ICBOZWlsLA0KPj4gPiA+Pj4+ICAgPg0K Pj4gPiA+Pj4+ICAgPiAgVG8geW91ciBjYXNlIDEsIHdlJ3JlIGluIGNvbXBsZXRlIGFncmVlbWVu dC4gV2UgKFZaKSBkb24ndA0KPj4gPiBzZWUgYXQNCj4+ID4gPj4+PiAgID4gIGxlYXN0IGEgc2hv cnQtdGVybSBuZWVkIGZvciBwZWVyLWxheWVyIGludGVyd29ya2luZywgZ2l2ZW4NCj4+ID4gd2hl cmUgd2UNCj4+ID4gPj4+PiAgID4gIGludGVuZCB0byBkZXBsb3kgTVBMUy1UUCBpbiBvdXIgaW5m cmFzdHJ1Y3R1cmUgKGFzIGFuDQo+PiA+IGludGVybmFsIHNlcnZlcg0KPj4gPiA+Pj4+ICAgPiAg bGF5ZXIgaW4gdGhlIHRyYW5zcG9ydCBjb3JlKS4gSWYgcGVlciBsYXllciBpbnRlcndvcmtpbmcg ZXZlcg0KPj4gPiBiZWNvbWVzDQo+PiA+ID4+Pj4gICA+ICBhIG5lY2Vzc2l0eSwgdGhlbiBvYnZp b3VzbHkgd2UnbGwgbmVlZCBhIHdlbGwtZGVmaW5lZCBFLU5OSQ0KPj4gPiB3aGljaA0KPj4gPiA+ Pj4+ICAgPiAgd291bGQgaW5jbHVkZSBMU1AgaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0aW9u IGF0IHRoZQ0KPj4gPiBib3VuZGFyeSwgZm9yDQo+PiA+ID4+Pj4gICA+ICBMU1AgcHJvdmlzaW9u aW5nICh3aGV0aGVyIHN0YXRpYyBvciBkeW5hbWljKSBhbmQgZW5kLXRvLWVuZA0KPj4gPiBPQU0u IFN1Y2gNCj4+ID4gPj4+PiAgID4gIGFuIEUtTk5JIGRlZmluaXRpb24gZG9lcyBub3QgeWV0IGV4 aXN0IGZvciBNUExTLVRQIChzb21ldGhpbmcNCj4+ID4gZWxzZSB0bw0KPj4gPiA+Pj4+ICAgPiAg cHV0IG9uIHRoZSB0by1kbyBsaXN0KS4gVGhpcyBFLU5OSSB3b3VsZCBhbHNvIGluY2x1ZGUgc2lt aWxhcg0KPj4gPiA+Pj4+ICAgPiAgaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0aW9uIGZvciBN Uy1QV3MsIHRvIGFuc3dlciBhbg0KPj4gPiBlYXJsaWVyDQo+PiA+ID4+Pj4gICA+ICBxdWVzdGlv biBmcm9tIEVybWluaW8gdGhhdCBJIHNhdyBvbiB0aGUgbGlzdC4NCj4+ID4gPj4+PiAgID4NCj4+ ID4gPj4+PiAgID4gIEkgYWxzbyBhZ3JlZSB0aGF0IGJvdGggaW50cmEtbGF5ZXIgYW5kIGludGVy LWxheWVyIG1pcy0NCj4+ID4gY29ubmVjdGl2aXR5DQo+PiA+ID4+Pj4gICA+ICBkZXRlY3Rpb24g YW5kIGFtZWxpb3JhdGlvbiBhcmUgcmVxdWlyZWQsIGJ1dCBJJ20gbm90DQo+PiA+IGNvbnZpbmNl ZCB0aGF0DQo+PiA+ID4+Pj4gICA+ICB0aGUgYWxyZWFkeSBkZWZpbmVkIG1lY2hhbmlzbXMgY2Fu J3QgZG8gdGhhdC4gRG8geW91IGhhdmUNCj4+ID4gc29tZQ0KPj4gPiA+Pj4+ICAgPiAgc3BlY2lm aWMgYW5hbHlzaXMgb24gdGhlIGludGVyLWxheWVyIGNhc2U/DQo+PiA+ID4+Pj4gICA+DQo+PiA+ ID4+Pj4gICA+ICBDaGVlcnMsDQo+PiA+ID4+Pj4gICA+ICBBbmR5DQo+PiA+ID4+Pj4gICA+DQo+ PiA+ID4+Pj4gICA+ICBPbiBUdWUsIE1heSAzLCAyMDExIGF0IDM6MzYgQU0sPG5laWwuMi5oYXJy aXNvbkBidC5jb20+DQo+PiA+IHdyb3RlOg0KPj4gPiA+Pj4+ICAgPj4gIEhpIEFuZHksDQo+PiA+ ID4+Pj4gICA+Pg0KPj4gPiA+Pj4+ICAgPj4gIDIgcG9pbnRzOg0KPj4gPiA+Pj4+ICAgPj4NCj4+ ID4gPj4+PiAgID4+ICAxIEkgYWdyZWUgd2l0aCB5b3VyIHZpZXcgb2Ygb25seSBoYXZpbmcgYSBz aW5nbGUgYWRkcmVzc2luZw0KPj4gPiBzY2hlbWUgaW4NCj4+ID4gPj4gYQ0KPj4gPiA+Pj4+ICAg Pj4gIHNpbmdsZSBsYXllciBuZXR3b3JrIHNvbGVseSBiZWxvbmdpbmcgdG8gb25lIHBhcnR5LiBU aG91Z2gNCj4+ID4geW91IG1heQ0KPj4gPiA+Pj4+IG5lZWQgdG8NCj4+ID4gPj4+PiAgID4+ICBi ZSByYXRoZXIgY2FyZWZ1bCBpZiB5b3UgYWxzbyBhZHZvY2F0ZSB0aGF0IG9uZSBjYW4gYWxzbw0K Pj4gPiBoYXZlIHBlZXINCj4+ID4gPj4gbGF5ZXINCj4+ID4gPj4+PiAgID4+ICBpbnRlcndvcmtp bmcgYmV0d2VlbiBkaWZmZXJlbnQgcGFydGllcywgaWUgRS1OTklzIChJIGJlbGlldmUNCj4+ID4g dGhpcyBpcw0KPj4gPiA+Pj4+ICAgPj4gIHNvbWV0aGluZyB5b3UgbWF5IHN1cHBvcnQsIGVnIG9s ZCBNUExTRiBjYXNlPykuIEluIHN1Y2ggYQ0KPj4gPiBwZWVyDQo+PiA+ID4+Pj4gaW50ZXJ3b3Jr aW5nDQo+PiA+ID4+Pj4gICA+PiAgY2FzZSBpdCB3b3VsZCBzZWVtIG9uZSBtdXN0IGFsbG93IGRp ZmZlcmVudCBhZGRyZXNzaW5nDQo+PiA+IHNjaGVtZXMgKGFuZA0KPj4gPiA+Pj4+IGluZGVlZA0K Pj4gPiA+Pj4+ICAgPj4gIGFueSBvdGhlciB2YXJpYXRpb25zIGluIERQL0NQIGZ1bmN0aW9uYWwg Y29tcG9uZW50cykgaWYgdGhleQ0KPj4gPiBleGlzdA0KPj4gPiA+Pj4+IGluIHRoZQ0KPj4gPiA+ Pj4+ICAgPj4gIHN0YW5kYXJkcy4NCj4+ID4gPj4+PiAgID4+DQo+PiA+ID4+Pj4gICA+PiAgT2Yg Y291cnNlLCBoYXZpbmcgYW4gRS1OTkkgYW5kIHBlZXIgaW50ZXJ3b3JraW5nIGJldHdlZW4NCj4+ ID4gZGlmZmVyZW50DQo+PiA+ID4+Pj4gcGFydGllcyBpbg0KPj4gPiA+Pj4+ICAgPj4gIGFueSBu b24tVE9TIGxheWVyIG5ldHdvcmsgKG5vdCBqdXN0IE1QTFMpIGlzIG5vdCB0ZWNobmljYWxseQ0K Pj4gPiA+Pj4+IG5lY2Vzc2FyeSAodGhpcw0KPj4gPiA+Pj4+ICAgPj4gIGlzIHRyaXZpYWwgdG8g cHJvdmUpLCBhbmQgdGhpcyBwcm92aWRlcyBhIHN0cm9uZyBhcmd1bWVudA0KPj4gPiBmb3Igb25s eQ0KPj4gPiA+Pj4+IGhhdmluZyBhDQo+PiA+ID4+Pj4gICA+PiAgc2luZ2xlIGFkZHJlc3Npbmcg c2NoZW1lIGluIGEgbm9uLVRPUyBsYXllciBuZXR3b3JrLg0KPj4gPiA+Pj4+ICAgPj4NCj4+ID4g Pj4+PiAgID4+DQo+PiA+ID4+Pj4gICA+PiAgMiBZb3Ugc2hvdWxkIGFsc28gYmUgYXdhcmUgdGhh dCBpbiBjbGllbnQvc2VydmVyDQo+PiA+IGludGVyd29ya2luZyBvZiB0aGUNCj4+ID4gPj4+PiAg ID4+ICBjby1wcyBtb2RlIHVzaW5nIHZhcmlhYmxlIHNpemUgdHJhZmZpYyB1bml0cywgYW5kIHRo ZXJlZm9yZQ0KPj4gPiA+Pj4+IHNvbWV0aGluZyByYXRoZXINCj4+ID4gPj4+PiAgID4+ICBpbXBv cnRhbnQgZm9yIE1QTFMtVFAgaW4gdGhlIHJvbGUgb2YgYSB0cmFuc3BvcnQgbmV0d29yaw0KPj4g PiAoSSdsbA0KPj4gPiA+Pj4+IGlnbm9yZSBpc3N1ZXMNCj4+ID4gPj4+PiAgID4+ICBvZiB0cmFu c3BhcmVuY3kgaGVyZSksIHRoZXJlIGNvdWxkIGJlIGludGVyLWxheWVyDQo+PiA+IG1pc2Nvbm5l Y3Rpdml0eQ0KPj4gPiA+Pj4+IChBc2lkZT0+DQo+PiA+ID4+Pj4gICA+PiAgVGhpcyBjYXNlIGNh bm5vdCBvY2N1ciBpbiB0aGUgY28tY3MgbW9kZSkuIFRvIGRhdGUsIGhvd2V2ZXIsDQo+PiA+IHdl IGhhdmUNCj4+ID4gPj4+PiBvbmx5DQo+PiA+ID4+Pj4gICA+PiAgcmVhbGx5IGNvbnNpZGVyZWQg aW50cmEtbGF5ZXIgbWlzY29ubmVjdGl2aXR5LCBpZSBiZXR3ZWVuDQo+PiA+IGRpZmZlcmVudA0K Pj4gPiA+PiBMU1BzDQo+PiA+ID4+Pj4gICA+PiAgYmVsb25naW5nIHRvIHRoZSBzYW1lIHBhcnR5 IChub3RlIHRoaXMgYWxzbyBpbmNsdWRlcyBhbGwNCj4+ID4gY2FzZXMgb2YNCj4+ID4gPj4+PiBu ZXN0ZWQgTFNQDQo+PiA+ID4+Pj4gICA+PiAgc3VibGF5ZXIgbWlzY29ubmVjdGl2aXR5KS4NCj4+ ID4gPj4+PiAgID4+DQo+PiA+ID4+Pj4gICA+PiAgSW4gdGhlIGNhc2Ugb2YgaW50ZXItbGF5ZXIg bWlzY29ubmVjdGl2aXR5IG9uZSBtYXkgcmVjZWl2ZQ0KPj4gPiB0cmFmZmljDQo+PiA+ID4+Pj4g dW5pdHMgYW5kDQo+PiA+ID4+Pj4gICA+PiAgT0FNIG1lc3NhZ2VzIGZyb20gc29tZSBvdGhlciBw YXJ0eSdzIGxheWVyIG5ldHdvcmsuIFRoZSBPQU0NCj4+ID4gPj4gbWVzc2FnZXMNCj4+ID4gPj4g bWF5DQo+PiA+ID4+Pj4gICA+PiAgY29tZSBmcm9tIChpKSBuZXR3b3JrcyB1c2luZyBkaWZmZXJl bnQgT0FNL2FkZHJlc3NpbmcNCj4+ID4gc29sdXRpb25zIG9yDQo+PiA+ID4+IChpaSkNCj4+ID4g Pj4+PiAgID4+ICBuZXR3b3JrcyB1c2luZyB0aGUgc2FtZSBPQU0vYWRkcmVzc2luZyBzb2x1dGlv bnMuIEluIGJvdGgNCj4+ID4gY2FzZXMNCj4+ID4gPj4+PiB0aGVyZSBhcmUNCj4+ID4gPj4+PiAg ID4+ICBkaWZmZXJlbnQgaXNzdWVzIHdydCBpbnRlci1sYXllciBtaXNjb25uZWN0aXZpdHkgb25l IGhhcyB0bw0KPj4gPiBkZWFsDQo+PiA+ID4+Pj4gd2l0aC4gSSdtDQo+PiA+ID4+Pj4gICA+PiAg bm90IGF3YXJlIHRoYXQgdGhlc2UgY2FzZXMgaGF2ZSBiZWVuIGNvbnNpZGVyZWQgeWV0Lg0KPj4g PiA+Pj4+ICAgPj4NCj4+ID4gPj4+PiAgID4+DQo+PiA+ID4+Pj4gICA+PiAgSSdkIGxpa2UgdG8g aGVhciB5b3VyIGNvbW1lbnRzIG9uIGJvdGggdGhlc2UgcG9pbnRzLCBidXQgaW4NCj4+ID4gPj4+ PiBwYXJ0aWN1bGFyIHRoZQ0KPj4gPiA+Pj4+ICAgPj4gIGZpcnN0IG9uZS4uLi4uZXNwZWNpYWxs eSBpZiB5b3UgYWxzbyBzdXBwb3J0IHRoZSBub3Rpb24gb2YNCj4+ID4gRS1OTklzIGluDQo+PiA+ ID4+Pj4gTVBMUy1UUCwNCj4+ID4gPj4+PiAgID4+ICBhcyB0aGVyZSBzZWVtcyB0byBhIHBvc3Np YmxlIGxvZ2ljYWwgY29uZmxpY3QgaGVyZS4NCj4+ID4gPj4+PiAgID4+DQo+PiA+ID4+Pj4gICA+ PiAgVGhhbmtzLg0KPj4gPiA+Pj4+ICAgPj4NCj4+ID4gPj4+PiAgID4+ICByZWdhcmRzLCBOZWls IEhhcnJpc29uDQo+PiA+ID4+Pj4gICA+Pg0KPj4gPiA+Pj4+ICAgPj4gIEJUIERlc2lnbg0KPj4g PiA+Pj4+ICAgPj4NCj4+ID4gPj4+PiAgID4+ICBUaGlzIGVtYWlsIGNvbnRhaW5zIEJUIGluZm9y bWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZA0KPj4gPiBvcg0KPj4gPiA+Pj4+IGNvbmZp ZGVudGlhbC4NCj4+ID4gPj4+PiAgID4+ICBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlk dWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4NCj4+ID4gSWYNCj4+ID4gPj4+PiB5b3UncmUg bm90DQo+PiA+ID4+Pj4gICA+PiAgdGhlIGludGVuZGVkDQo+PiA+ID4+Pj4gICA+PiAgcmVjaXBp ZW50LCBub3RlIHRoYXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yDQo+PiA+ IHVzaW5nIHRoaXMNCj4+ID4gPj4+PiAgID4+ICBpbmZvcm1hdGlvbg0KPj4gPiA+Pj4+ICAgPj4g IGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLA0K Pj4gPiBwbGVhc2UgbGV0IG1lDQo+PiA+ID4+Pj4ga25vdw0KPj4gPiA+Pj4+ICAgPj4gIGltbWVk aWF0ZWx5DQo+PiA+ID4+Pj4gICA+PiAgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5r IHlvdS4NCj4+ID4gPj4+PiAgID4+ICBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBt YXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KPj4gPiA+Pj4+ICAgPj4gIEJyaXRpc2ggVGVsZWNvbW11 bmljYXRpb25zIHBsYw0KPj4gPiA+Pj4+ICAgPj4gIFJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdn YXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCj4+ID4gPj4+PiAgID4+ICBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgbm86IDE4MDAwMDANCj4+ID4gPj4+PiAgID4+DQo+PiA+ID4+Pj4gICA+Pj4gIC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ID4+Pj4gICA+Pj4gIEZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCj4+ID4gT24gQmVo YWxmDQo+PiA+ID4+IE9mDQo+PiA+ID4+Pj4gICA+Pj4gIEFuZHJldyBHLiBNYWxpcw0KPj4gPiA+ Pj4+ICAgPj4+ICBTZW50OiAwMiBNYXkgMjAxMSAyMDo0OA0KPj4gPiA+Pj4+ICAgPj4+ICBUbzog R2VvcmdlIFN3YWxsb3cNCj4+ID4gPj4+PiAgID4+PiAgQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+ID4g Pj4+PiAgID4+PiAgU3ViamVjdDogUmU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURz IGluIE1QTFMtVFANCj4+ID4gSWRlbnRpZmllcnM/DQo+PiA+ID4+Pj4gICA+Pj4NCj4+ID4gPj4+ PiAgID4+PiAgR2VvcmdlIGV0IGFsLA0KPj4gPiA+Pj4+ICAgPj4+DQo+PiA+ID4+Pj4gICA+Pj4g IFZlcml6b24gZG9lcyBub3QgaGF2ZSBhbnkgcmVxdWlyZW1lbnQgZm9yIG1peGVkIHVzZSBvZg0K Pj4gPiBHbG9iYWwgSURzIGFuZA0KPj4gPiA+Pj4+ICAgPj4+ICBJQ0NzLiBXZSBhcmUgZmluZSB3 aXRoIHNwZWNpZmljYXRpb25zIHRoYXQgcmVxdWlyZSBib3RoDQo+PiA+IGVuZHMgb2YgYW4NCj4+ ID4gPj4gTFNQDQo+PiA+ID4+Pj4gICA+Pj4gIHRvIHVzZSBvbmUgb3IgdGhlIG90aGVyLg0KPj4g PiA+Pj4+ICAgPj4+DQo+PiA+ID4+Pj4gICA+Pj4gIFRoYW5rcywNCj4+ID4gPj4+PiAgID4+PiAg QW5keQ0KPj4gPiA+Pj4+ICAgPj4+DQo+PiA+ID4+Pj4gICA+Pj4gIE9uIE1vbiwgQXByIDI1LCAy MDExIGF0IDU6MTYgUE0sIEdlb3JnZQ0KPj4gPiBTd2FsbG93PHN3YWxsb3dAY2lzY28uY29tPg0K Pj4gPiA+Pj4+ICAgPj4+ICB3cm90ZToNCj4+ID4gPj4+PiAgID4+Pj4gIEFsbCAtDQo+PiA+ID4+ Pj4gICA+Pj4+DQo+PiA+ID4+Pj4gICA+Pj4+ICBNYW55IG9mIHRoZSBjb21tZW50cyByZWNlaXZl ZCBmcm9tIHRoZSBJVFUgb24NCj4+ID4gPj4+PiAgID4+Pj4gIGRyYWZ0LWlldGYtbXBscy10cC1p ZGVudGlmaWVycy0wNCBoYXZlIHRvIGRvIHdpdGggdGhlDQo+PiA+IEdsb2JhbCBhbmQgSUNDDQo+ PiA+ID4+Pj4gICA+Pj4+ICBpZGVudGlmaWVycy4NCj4+ID4gPj4+PiAgID4+Pj4NCj4+ID4gPj4+ PiAgID4+Pj4gIFRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQgTUVHIGlu Y2x1ZGUNCj4+ID4gZmllbGRzIHRvDQo+PiA+ID4+Pj4gICA+Pj4gIGlkZW50aWZ5IGVhY2gNCj4+ ID4gPj4+PiAgID4+Pj4gIGVuZCBvZiBhbiBMU1AuIEN1cnJlbnRseSB0aGUgZHJhZnQgYWxsb3dz IGEgVHVubmVsLCBMU1AsDQo+PiA+IFBXLCBvciBNRUcNCj4+ID4gPj4+PiAgID4+PiAgdG8gdXNl DQo+PiA+ID4+Pj4gICA+Pj4+ICBlaXRoZXIgdGhlIEdsb2JhbC1JRCBmb3IgYm90aCBlbmRzIG9y IG9yIHRoZSBJQ0MgZm9yIGJvdGgNCj4+ID4gZW5kcy4NCj4+ID4gPj4+PiAgID4+PiAgTWl4ZWQg dXNlDQo+PiA+ID4+Pj4gICA+Pj4+ICBpcyBub3QgcGVybWl0dGVkLg0KPj4gPiA+Pj4+ICAgPj4+ Pg0KPj4gPiA+Pj4+ICAgPj4+PiAgVGhlIElUVSBsaWFpc29uIHJlcXVlc3RzIHRoYXQgd2UgYWxs b3cgbWl4ZWQgdXNlLg0KPj4gPiA+Pj4+ICAgPj4+Pg0KPj4gPiA+Pj4+ICAgPj4+PiAgVGhlIGF1 dGhvcnMgb2YgdGhlIGRyYWZ0IGFyZSB2ZXJ5IHJlbHVjdGFudCB0byBkbyB0aGlzLg0KPj4gPiA+ Pj4+ICAgPj4+Pg0KPj4gPiA+Pj4+ICAgPj4+PiAgT2J0YWluaW5nIGFuIEFTIE51bWJlciAoZnJv bSB3aGljaCB0aGUgR2xvYmFsLUlEIGlzDQo+PiA+IGRlcml2ZWQpIGlzIGENCj4+ID4gPj4+PiAg ID4+PiAgZmFpcmx5DQo+PiA+ID4+Pj4gICA+Pj4+ICB0cml2aWFsIHByb2NlZHVyZS4gTWFueSBv cmdhbml6YXRpb25zIGlmIG5vdCBtb3N0IGFscmVhZHkNCj4+ID4gaGF2ZSBBUw0KPj4gPiA+Pj4+ ICAgPj4+ICBOdW1iZXJzLg0KPj4gPiA+Pj4+ICAgPj4+PiAgU3VjaCBhbiBhZGRpdGlvbiB3aWxs IGFkZCBudW1lcm91cyBvYmplY3QgZm9ybWF0cywgYW5kDQo+PiA+IHRlc3QgY2FzZXMuDQo+PiA+ ID4+Pj4gICA+Pj4+ICBUaGUgZXh0ZW50IGludGVyLXByb3ZpZGVyIE1QTFMtVFAgaXMgYXMgeWV0 IHVua25vd24uIElmDQo+PiA+IG1peGVkIG1vZGVzDQo+PiA+ID4+Pj4gICA+Pj4gIG9mIElDQw0K Pj4gPiA+Pj4+ICAgPj4+PiAgYW5kIEdsb2JhbC1JRCBpZGVudGlmaWNhdGlvbiBpcyByZXF1aXJl ZCwgdGhleSBjYW4gYmUNCj4+ID4gYWRkZWQgbGF0ZXIuDQo+PiA+ID4+Pj4gICA+Pj4+ICBGb3Ig c2lnbmFsZWQgY29ubmVjdGlvbnMsIHRoZXJlIGlzIG5vIHBsYW4gdG8gYWxsb3cNCj4+ID4gcm91 dGluZyBiYXNlZCBvbg0KPj4gPiA+Pj4+ICAgPj4+ICBlaXRoZXINCj4+ID4gPj4+PiAgID4+Pj4g IHRoZSBHbG9iYWwtSUQgb3IgSUNDLiBUaGF0IHdvdWxkIGJlIGEgcmFkaWNhbCBjaGFuZ2UgdG8N Cj4+ID4gaG93IElQDQo+PiA+ID4+Pj4gICA+Pj4gIHdvcmtzLg0KPj4gPiA+Pj4+ICAgPj4+PiAg SG93ZXZlciBmb3IgSVAgcm91dGluZyB0byB3b3JrIChpbiBvcmRlciB0byBmb3J3YXJkIHRoZQ0K Pj4gPiBzaWduYWxpbmcNCj4+ID4gPj4+PiAgID4+Pj4gIG1lc3NhZ2VzKSwgdGhlIHByb3ZpZGVy cyBpbnZvbHZlZCB3aWxsIG5lZWQgdG8gcnVuIEJHUCBhbmQNCj4+ID4gaGF2ZSBBUw0KPj4gPiA+ Pj4+ICAgPj4+ICBudW1iZXJzLg0KPj4gPiA+Pj4+ICAgPj4+Pg0KPj4gPiA+Pj4+ICAgPj4+PiAg V2UgYXJlIGxvb2tpbmcgZm9yIGlucHV0L2NvbnNlbnN1cyBmcm9tIHRoZSBXRy4NCj4+ID4gPj4+ PiAgID4+Pj4NCj4+ID4gPj4+PiAgID4+Pj4gIEdlb3JnZSwgRXJpYywmICBNYXR0aGV3DQo+PiA+ DQo+PiA+DQo+PiA+IC0tDQo+PiA+DQo+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPj4gKioqDQo+PiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAg5oiR54ix5aSW54K55LiA5LiD5LiJ5LiADQo+PiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IG1wbHMgbWFpbGluZyBs aXN0DQo+PiA+IG1wbHNAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+IG1wbHNAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QN Cj5tcGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From erminio.ottone_69@libero.it Sun Jun 5 08:50:34 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 DA7E711E8085; Sun, 5 Jun 2011 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_92=0.6] 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 ncoTfsVemUhk; Sun, 5 Jun 2011 08:50:34 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 0B13111E8071; Sun, 5 Jun 2011 08:50:32 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4DEBA5BD.001B,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail34 (172.31.0.222) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD237D5018797CB; Sun, 5 Jun 2011 17:50:20 +0200 Message-ID: <19746722.1230251307289020806.JavaMail.defaultUser@defaultHost> Date: Sun, 5 Jun 2011 17:50:20 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.31.158.224 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 15:50:35 -0000 Mach, let me try to explain the point/issue with an example. I have my own domain and I name nodes (or tunnel endpoints if you prefer)= =20 using numbers (i.e., 1, 2, 3, 4, ...). Within my domain I can setup any p2p= =20 connection between any paer of numbers (1 to 2; 3 to 4 and so on). You have your own domain and you name nodes (or tunnel endpoints) using lat= in=20 letters (i.e., A, B, C, ...). Within your domain you can setup any p2p=20 connection betwen any pair of letters (A to B; C to D and so on). Now there is a need to setup a connection betwee my node 5 and your node E.= =20 What can we do? We can setup a conection 5 to E (i.e., supporting mixed=20 identifiers on the connection) or mandate one of us to assign two names to = the=20 same node? Would you be happy to assign two names to all your nodes (one following=20 numeric convention and one following latin letters? Woud you be happy to re-number all your nodes with a third convention when = you=20 need to be connected with another operator that is adopting a third naming= =20 convention? If we mix identifiers, what you need is just to provision the peer MEP-ID= =20 information as an unstructure bit string (note that while E has a meaning f= or=20 you, 5 does not have any meanign for you). Note that in any case you must be able to identify a misconnection between= =20 different identifiers scheme. For example, if the traffic coming from my no= de 2=20 leaks out into the 5-E connection, you will receive a source MEP-ID equal t= o 2=20 in the CV packets. >----Messaggio originale---- >Da: mach.chen@huawei.com >Data: 24-mag-2011 10.28 >A: "Malcolm.BETTS@zte.com.cn" >Cc: "mpls-bounces@ietf.org", "mpls@ietf.org" >Ogg: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Hi Malcolm, > >Thanks for your response! > >Firstly, I have to claim that I do not object mixed identifier if there ar= e=20 cases really need it.=20 > >From the discussion on this thread, it's very clear that mixed identifiers= at=20 least require control plane and management plane has to understand and supp= ort=20 the semantic of both ICC and Global_ID based identifiers. This means that t= he=20 operators have to operate both ICC and Global_ID based identifiers when do= =20 mixed identifiers. If the purpose of mixed identifiers is to help one opera= tor=20 (e.g., only prefers to ICC style) to avoid operating/maintaining unfamiliar= =20 identifier scheme (e.g., Global_ID) when do inter-domain connection, obviou= sly,=20 it cannot work. On the contrary, as many other guys on the list pointed out= , if=20 the same format identifier is used for a specific path, the domain one end= =20 hosting can really only need to support and administer one type of=20 identifier.=20 > >Best regards, >Mach > >> From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] >> Sent: Tuesday, May 24, 2011 1:33 PM >> To: Mach Chen >> Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org >> Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? >>=20 >>=20 >> Hi Mach, >>=20 >> Please see in line below. >>=20 >> Mach Chen wrote on 23/05/2011 10:15:32 PM: >>=20 >> > Hi Malcolm, >> > >> > Thanks for your prompt response! >> > >> > Please see my reply inline... >> > >> > > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] >> > > Sent: Tuesday, May 24, 2011 8:42 AM >> > > To: Mach Chen >> > > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org >> > > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? >> > > >> > > Hi Mach, >> > > >> > > Please see in line below - marked by [MB2] >> > > >> > > Regards, >> > > >> > > Malcolm >> > > >> > > Mach Chen >> > > 22/05/2011 11:34 PM >> > > To >> > > "Malcolm.BETTS@zte.com.cn" , >> > > "adrian@olddog.co.uk" >> > > cc >> > > "mpls-bounces@ietf.org" , "mpls@ietf.org" >> > > >> > > Subject >> > > RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> > > >> > > Hi Malcolm, >> > > >> > > See my response inline. >> > > >> > > Ermino, >> > > >> > > We have already been round this loop on this list once. >> > > Want to do it again? >> > > >> > > [MB] well the continuation of this thread indicates that the loop >> > is still open.... >> > > >> > > As Huub said, this is about identifiers, not OAM. However, the model= =20 for >> OAM >> > > interworking shows "layering" not gatewaying, and certainly not=20 mixing. >> That >> > > is, >> > > one end of the e2e path must be capable of operating both systems, b= ut=20 the >> > > other >> > > does not need to. >> > > >> > > [MB] OK >> > > >> > > To extend this model to identifiers means that one end of the e2e pa= th=20 must >> > > support both identifier formats and the other does not need to. >> > > >> > > [MB] It requires that one of the operators must administer both type= s=20 of >> > > identifiers. >> > > [Mach] If mixed identifiers used, seems that all relevant domains >> > (other than >> > > only one domain) of the path must administer both types of=20 identifiers, >> > >> > > [MB2] Why? >> > >> > If it's static provisioning, the operators need to configure(by CLI >> > or NMS) the identifiers(include both ICC and Global_ID) on the related= =20 nodes. >> > If there is control plane, the control plane has to communicate the >> > identifiers, and all the nodes along the LSP need to know the type >> > firstly and hence to interpret and process it >>=20 >> [MB] No need for the nodes to understand the semantics, it may be=20 convenient >> to have an OSS or GUI application that does understand the semantics to= =20 assist >> in provisioning the expected value. =C2=A0The control plane should be ab= le to=20 carry >> an opaque type. =C2=A0I would expect that when the encoding of these ide= ntifiers=20 is >> defined it will include a "type" flag so that the node knows the length = of=20 the >> identifier field. >>=20 >> > >> > >As I have explained several times on this thread a node that >> > > receives an OAM message only needs to check that it is from the=20 expected >> > > entity, no need to understand or administer the format. >> > >> > How could a node do that if it does not know the type of the identifie= r? >>=20 >> [MB] Just match the bit string...... >>=20 >> > >> > > =C2=A0and the operators(only prefer to ICC based Opr_ID) have to sup= port=20 and >> > > configure both ICC and Global_ID style identifier. On the >> > contrary, for a specific >> > > LSP or PW, if only one type of identifiers is used, the operators >> > (only prefer to >> > > ICC based Opr_ID) can really only need to support and administer >> > only one type >> > > of identifiers (ICC) if they get the agreement of using ICC type >> > of identifier with >> > > other operators. >> > > =C2=A0This causes two problems a) A (potentially) new operational pr= ocess=20 must >> be >> > > invoked to assign the second identifier type and; b) Given that a no= de=20 will >> > > terminate/originate traffic from/to the local network and a third >> > party network >> > > that node will have (different) identifiers, this will cause >> > significant issues when >> > > attempting to perform normal operational processes e.g. alarm=20 reporting. >> > > >> > > This becomes particularly important to the transit nodes that may ha= ve=20 to >> > > inspect the identifiers. >> > > >> > > [MB] Why? only the entity inserting the identifier needs to understa= nd=20 the >> > > semantics, all other nodes only need to check if the (bit string)=20 presented >> > > matches the expected string. >> > > [Mach] Here is an example that the transit nodes may require to >> > "inspect" the >> > > identifiers: MPLS-TP control plane. Because Opr_ID is part of the >> > identifier of an >> > > LSP, PW and Section, the control plane has to communicate the Opr_ID= s=20 of >> the >> > > LSP, PW or Section among the relevant nodes when signal the LSP, PW = or >> > > Section. >> > > [MB2] =C2=A0As defined in the architecture the data plane and contro= l plane >> must >> > > be independent, including the identifiers that they use. >> > >> > But, MPLS-TP identifiers should be not exclusive to data plane or >> > control plane or management plane, and actually they are related to >> > all the three planes. >>=20 >> [MB] =C2=A0The identifiers in all three planes are related but the value= s and=20 type >> must be independent. >> > >> > Best regards, >> > Mach >> > > >> > > BTW, we just submitted two drafts that define extensions to RSVP-TE= =20 and >> PW >> > > protocol for communicating Opr_ID when setup an LSP or PW. >> > > http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 >> > > http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 >> > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Sun Jun 5 08:51: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 579FD11E8085 for ; Sun, 5 Jun 2011 08:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6] 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 UQHMEx5nicKo for ; Sun, 5 Jun 2011 08:51:35 -0700 (PDT) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id E6FD811E8071 for ; Sun, 5 Jun 2011 08:51:33 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020B.4DEBA602.0108,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail34 (172.31.0.222) by cp-out3.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD23CD00187CF5A; Sun, 5 Jun 2011 17:51:29 +0200 Message-ID: <9599927.1230581307289089884.JavaMail.defaultUser@defaultHost> Date: Sun, 5 Jun 2011 17:51:29 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.31.158.224 Subject: [mpls] R: RE: R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 15:51:36 -0000 Does the draft has a special status vs mail comments? There is nothing I can put in the draft that has not been said on the maili= ng=20 list. >----Messaggio originale---- >Da: nurit.sprecher@nsn.com >Data: 5-giu-2011 17.41 >A: , , >Ogg: RE: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? > >So come with a draft and present it.=20 > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ex= t=20 erminio.ottone_69@libero.it >Sent: Sunday, June 05, 2011 6:37 PM >To: adrian@olddog.co.uk; mpls@ietf.org >Subject: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? > >>I am tired of this discussion. There seems to be no forward progress only= =20 >restatement of a "want". I always wanted a pony when I was a little girl, = but=20 I=20 >never got one. >> > >The problem is that there are a lot of technical questions on the table=20 that=20 >can be easily answered by supporting mixed ICC and IP identifiers that are= =20 now=20 >waiting for an answer, > >>----Messaggio originale---- >>Da: adrian@olddog.co.uk >>Data: 25-mag-2011 11.13 >>A: >>Ogg: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >>Hi Neil, >> >>I'm not assuming peering. I am actually pointing out to Huub that (despit= e=20 >what he keeps saying) he is also not assuming peering. >> >>The consequence of not peering is that a single identifier mode is used= =20 for=20 >both ends of an OAM "session". And that means that one end has to=20 understand=20 >*and* use the "foreign" format at the remote end of the session. >> >>I am tired of this discussion. There seems to be no forward progress only= =20 >restatement of a "want". I always wanted a pony when I was a little girl, = but=20 I=20 >never got one. >> >>Adrian >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> neil.2.harrison@bt.com >>> Sent: 22 May 2011 20:36 >>> To: huubatwork@gmail.com; mpls@ietf.org >>> Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP=20 >Identifiers? >>>=20 >>> Hi Adrian/Huub, >>>=20 >>> You are largely assuming some form of peering (single partitioned layer= =20 >network) >>> here...and that model will generate a whole raft of problems for=20 operators=20 >IMO. >>> A more important model for a co-ps transport network is client/server. = =20 And=20 >now >>> not only have we the usual intra-layer misconnectivity to deal with but= =20 we=20 >also >>> have inter-layer misconnectivity...and this means each operating party= =20 >must >>> understand the OAM formats (and CV IDs) of each other anyway... not=20 simply=20 >to >>> detect there is a misconnectivity problems but also to identify which= =20 other=20 >parties >>> are involved. >>>=20 >>> regards, Neil >>>=20 >>> BT Design >>> This email contains BT information, which may be privileged or=20 >confidential. >>> It's meant only for the individual(s) or entity named above. If you're= =20 not=20 >the >>> intended >>> recipient, note that disclosing, copying, distributing or using this=20 >information >>> is prohibited. If you've received this email in error, please let me kn= ow >>> immediately >>> 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 >>>=20 >>>=20 >>>=20 >>> > -----Original Message----- >>> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >>> > Huub van Helvoort >>> > Sent: 22 May 2011 19:15 >>> > To: mpls@ietf.org >>> > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP >>> > Identifiers? >>> > >>> > Hi Adrian, >>> > >>> > See my response in-line [hvh] >>> > >>> > > We have already been round this loop on this list once. >>> > > Want to do it again? >>> > >>> > [hvh] If it helps to get to the focal point, why not. >>> > >>> > > As Huub said, this is about identifiers, not OAM. However, the mode= l >>> > for OAM >>> > > interworking shows "layering" not gatewaying, and certainly not >>> > mixing. That is, >>> > > one end of the e2e path must be capable of operating both systems, >>> > but the other >>> > > does not need to. >>> > >>> > [hvh] OK if you mean "OAM toolsets" by "systems" >>> > >>> > > To extend this model to identifiers means that one end of the e2e >>> > path must >>> > > support both identifier formats and the other does not need to. >>> > >>> > [hvh] to be more specific the originating end of an e2e path must >>> > be able to support one of the possible identifier formats, normally >>> > the identifier format of the local operator. The terminating end and >>> > the intermediate points of an e2e path must be able to verify the >>> > format inserted at the origin independent of the locally used >>> > identifier >>> > format. This means that it must be possible to support different >>> > identifier formats in the A-->Z ans Z-->A direction of an e2e path. >>> > I.e. mixing of identifier formats must be supported. >>> > >>> > > This becomes particularly important to the transit nodes that may >>> > have to >>> > > inspect the identifiers. >>> > >>> > [hvh] the inspection will consist of comparing a received value >>> > with an expected value which can have any format. >>> > >>> > > None of this is new or specific to MPLS-TP. >>> > >>> > [hvh] I agree, mixing of identifier formats it not restricted to >>> > MPLS-TP. >>> > >>> > Regards, Huub. >>> > >>> > >> -----Original Message----- >>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf >>> > Of >>> > >> erminio.ottone_69@libero.it >>> > >> Sent: 18 May 2011 22:25 >>> > >> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn >>> > >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP >>> > Identifiers? >>> > >> >>> > >> Appendix II of Y.1731 provides a good example about how inter-doma= in >>> > >> connectivity with e2e OAM can be provided using transport-oriented >>> > OAM >>> > >> functions. >>> > >> >>> > >> You can download the latest version of Y.1731 (the pdr version is >>> > for free) at >>> > >> the following URL: >>> > >> >>> > >> http://www.itu.int/rec/T-REC-Y.1731/en >>> > >> >>> > >> It is a pity that with the current version of the identifier draft= , >>> > MPLS-TP is >>> > >> not capable to support such a network scenario. >>> > >> >>> > >>> ----Messaggio originale---- >>> > >>> Da: loa@pi.nu >>> > >>> Data: 4-mag-2011 8.00 >>> > >>> A:, >>> > >> "Malcolm.BETTS@zte.com.cn" >>> > >>> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> > >>> >>> > >>> Malcolm, >>> > >>> >>> > >>> are you saying that operators today allow OAM to control node (MI= Ps >>> > and >>> > >>> MEPs) on each others networks? >>> > >>> >>> > >>> Do we have an operator that can verify this? >>> > >>> >>> > >>> /Loa >>> > >>> >>> > >>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >>> > >>>> >>> > >>>> All, >>> > >>>> >>> > >>>> I share your concerns and doubts about a multi carrier control >>> > plane. >>> > >>>> However, I think that it is essential that a transport network >>> > supports >>> > >>>> multi carrier data plane interconnection with end to end OAM. In >>> > today's >>> > >>>> transport network this interconnection is supported by SDH and >>> > OTN. The >>> > >>>> objective for MPLS-TP is to allow for packet based interconnecti= on >>> > as >>> > >> well. >>> > >>>> >>> > >>>> Regards, >>> > >>>> >>> > >>>> Malcolm >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> *George Swallow* >>> > >>>> Sent by: mpls-bounces@ietf.org >>> > >>>> >>> > >>>> 03/05/2011 11:09 AM >>> > >>>> >>> > >>>> >>> > >>>> To >>> > >>>> =09"Andrew G. Malis", >>> > >>>> cc >>> > >>>> =09mpls@ietf.org >>> > >>>> Subject >>> > >>>> =09Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> Andy - >>> > >>>> >>> > >>>> > Such >>> > >>>> > an E-NNI definition does not yet exist for MPLS-TP (somethi= ng >>> > else to >>> > >>>> > put on the to-do list). This E-NNI would also include simil= ar >>> > >>>> > identifier mapping/translation for MS-PWs, to answer an >>> > earlier >>> > >>>> > question from Erminio that I saw on the list. >>> > >>>> >>> > >>>> You are quite correct here! I think much of this debate surround= s >>> > a >>> > >> problem >>> > >>>> that is yet to be solved. So there are arguments for pieces of a >>> > solution >>> > >>>> without and overall architecture. >>> > >>>> >>> > >>>> Based on all that I am seeing my inclination is to NOT say that = we >>> > >> disallow >>> > >>>> mixed identifiers, but to say that they are for future study. >>> > >>>> >>> > >>>> ...George >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: >>> > >>>> >>> > >>>> > Neil, >>> > >>>> > >>> > >>>> > To your case 1, we're in complete agreement. We (VZ) don't >>> > see at >>> > >>>> > least a short-term need for peer-layer interworking, given >>> > where we >>> > >>>> > intend to deploy MPLS-TP in our infrastructure (as an >>> > internal server >>> > >>>> > layer in the transport core). If peer layer interworking ev= er >>> > becomes >>> > >>>> > a necessity, then obviously we'll need a well-defined E-NNI >>> > which >>> > >>>> > would include LSP identifier mapping/translation at the >>> > boundary, for >>> > >>>> > LSP provisioning (whether static or dynamic) and end-to-end >>> > OAM. Such >>> > >>>> > an E-NNI definition does not yet exist for MPLS-TP (somethi= ng >>> > else to >>> > >>>> > put on the to-do list). This E-NNI would also include simil= ar >>> > >>>> > identifier mapping/translation for MS-PWs, to answer an >>> > earlier >>> > >>>> > question from Erminio that I saw on the list. >>> > >>>> > >>> > >>>> > I also agree that both intra-layer and inter-layer mis- >>> > connectivity >>> > >>>> > detection and amelioration are required, but I'm not >>> > convinced that >>> > >>>> > the already defined mechanisms can't do that. Do you have >>> > some >>> > >>>> > specific analysis on the inter-layer case? >>> > >>>> > >>> > >>>> > Cheers, >>> > >>>> > Andy >>> > >>>> > >>> > >>>> > On Tue, May 3, 2011 at 3:36 AM, >>> > wrote: >>> > >>>> >> Hi Andy, >>> > >>>> >> >>> > >>>> >> 2 points: >>> > >>>> >> >>> > >>>> >> 1 I agree with your view of only having a single addressin= g >>> > scheme in >>> > >> a >>> > >>>> >> single layer network solely belonging to one party. Though >>> > you may >>> > >>>> need to >>> > >>>> >> be rather careful if you also advocate that one can also >>> > have peer >>> > >> layer >>> > >>>> >> interworking between different parties, ie E-NNIs (I belie= ve >>> > this is >>> > >>>> >> something you may support, eg old MPLSF case?). In such a >>> > peer >>> > >>>> interworking >>> > >>>> >> case it would seem one must allow different addressing >>> > schemes (and >>> > >>>> indeed >>> > >>>> >> any other variations in DP/CP functional components) if th= ey >>> > exist >>> > >>>> in the >>> > >>>> >> standards. >>> > >>>> >> >>> > >>>> >> Of course, having an E-NNI and peer interworking between >>> > different >>> > >>>> parties in >>> > >>>> >> any non-TOS layer network (not just MPLS) is not technical= ly >>> > >>>> necessary (this >>> > >>>> >> is trivial to prove), and this provides a strong argument >>> > for only >>> > >>>> having a >>> > >>>> >> single addressing scheme in a non-TOS layer network. >>> > >>>> >> >>> > >>>> >> >>> > >>>> >> 2 You should also be aware that in client/server >>> > interworking of the >>> > >>>> >> co-ps mode using variable size traffic units, and therefor= e >>> > >>>> something rather >>> > >>>> >> important for MPLS-TP in the role of a transport network >>> > (I'll >>> > >>>> ignore issues >>> > >>>> >> of transparency here), there could be inter-layer >>> > misconnectivity >>> > >>>> (Aside=3D> >>> > >>>> >> This case cannot occur in the co-cs mode). To date, howeve= r, >>> > we have >>> > >>>> only >>> > >>>> >> really considered intra-layer misconnectivity, ie between >>> > different >>> > >> LSPs >>> > >>>> >> belonging to the same party (note this also includes all >>> > cases of >>> > >>>> nested LSP >>> > >>>> >> sublayer misconnectivity). >>> > >>>> >> >>> > >>>> >> In the case of inter-layer misconnectivity one may receive >>> > traffic >>> > >>>> units and >>> > >>>> >> OAM messages from some other party's layer network. The OA= M >>> > >> messages >>> > >> may >>> > >>>> >> come from (i) networks using different OAM/addressing >>> > solutions or >>> > >> (ii) >>> > >>>> >> networks using the same OAM/addressing solutions. In both >>> > cases >>> > >>>> there are >>> > >>>> >> different issues wrt inter-layer misconnectivity one has t= o >>> > deal >>> > >>>> with. I'm >>> > >>>> >> not aware that these cases have been considered yet. >>> > >>>> >> >>> > >>>> >> >>> > >>>> >> I'd like to hear your comments on both these points, but i= n >>> > >>>> particular the >>> > >>>> >> first one.....especially if you also support the notion of >>> > E-NNIs in >>> > >>>> MPLS-TP, >>> > >>>> >> as there seems to a possible logical conflict here. >>> > >>>> >> >>> > >>>> >> Thanks. >>> > >>>> >> >>> > >>>> >> regards, Neil Harrison >>> > >>>> >> >>> > >>>> >> BT Design >>> > >>>> >> >>> > >>>> >> This email contains BT information, which may be privilege= d >>> > or >>> > >>>> confidential. >>> > >>>> >> It's meant only for the individual(s) or entity named abov= e. >>> > If >>> > >>>> you're not >>> > >>>> >> the intended >>> > >>>> >> recipient, note that disclosing, copying, distributing or >>> > using this >>> > >>>> >> information >>> > >>>> >> is prohibited. If you've received this email in error, >>> > please let me >>> > >>>> know >>> > >>>> >> immediately >>> > >>>> >> 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org= ] >>> > On Behalf >>> > >> Of >>> > >>>> >>> Andrew G. Malis >>> > >>>> >>> Sent: 02 May 2011 20:48 >>> > >>>> >>> To: George Swallow >>> > >>>> >>> Cc: mpls@ietf.org >>> > >>>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >>> > Identifiers? >>> > >>>> >>> >>> > >>>> >>> George et al, >>> > >>>> >>> >>> > >>>> >>> Verizon does not have any requirement for mixed use of >>> > Global IDs and >>> > >>>> >>> ICCs. We are fine with specifications that require both >>> > ends of an >>> > >> LSP >>> > >>>> >>> to use one or the other. >>> > >>>> >>> >>> > >>>> >>> Thanks, >>> > >>>> >>> Andy >>> > >>>> >>> >>> > >>>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George >>> > Swallow >>> > >>>> >>> wrote: >>> > >>>> >>>> All - >>> > >>>> >>>> >>> > >>>> >>>> Many of the comments received from the ITU on >>> > >>>> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the >>> > Global and ICC >>> > >>>> >>>> identifiers. >>> > >>>> >>>> >>> > >>>> >>>> The identifiers for Tunnel, LSP, PW, and MEG include >>> > fields to >>> > >>>> >>> identify each >>> > >>>> >>>> end of an LSP. Currently the draft allows a Tunnel, LSP, >>> > PW, or MEG >>> > >>>> >>> to use >>> > >>>> >>>> either the Global-ID for both ends or or the ICC for bot= h >>> > ends. >>> > >>>> >>> Mixed use >>> > >>>> >>>> is not permitted. >>> > >>>> >>>> >>> > >>>> >>>> The ITU liaison requests that we allow mixed use. >>> > >>>> >>>> >>> > >>>> >>>> The authors of the draft are very reluctant to do this. >>> > >>>> >>>> >>> > >>>> >>>> Obtaining an AS Number (from which the Global-ID is >>> > derived) is a >>> > >>>> >>> fairly >>> > >>>> >>>> trivial procedure. Many organizations if not most alread= y >>> > have AS >>> > >>>> >>> Numbers. >>> > >>>> >>>> Such an addition will add numerous object formats, and >>> > test cases. >>> > >>>> >>>> The extent inter-provider MPLS-TP is as yet unknown. If >>> > mixed modes >>> > >>>> >>> of ICC >>> > >>>> >>>> and Global-ID identification is required, they can be >>> > added later. >>> > >>>> >>>> For signaled connections, there is no plan to allow >>> > routing based on >>> > >>>> >>> either >>> > >>>> >>>> the Global-ID or ICC. That would be a radical change to >>> > how IP >>> > >>>> >>> works. >>> > >>>> >>>> However for IP routing to work (in order to forward the >>> > signaling >>> > >>>> >>>> messages), the providers involved will need to run BGP a= nd >>> > have AS >>> > >>>> >>> numbers. >>> > >>>> >>>> >>> > >>>> >>>> We are looking for input/consensus from the WG. >>> > >>>> >>>> >>> > >>>> >>>> George, Eric,& Matthew >>> > >>> > >>> > -- >>> > >>> ************************************************************** >>> *** >>> > =E6=88=91=E7=88=B1=E5=A4=96=E7=82=B9=E4=B8= =80=E4=B8=83=E4=B8=89=E4=B8=80 >>> > _______________________________________________ >>> > 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 >> > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From jdrake@juniper.net Sun Jun 5 11:26: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 F147811E8071 for ; Sun, 5 Jun 2011 11:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 o6R+ETwOq3NZ for ; Sun, 5 Jun 2011 11:26:19 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E83E622800E for ; Sun, 5 Jun 2011 11:26:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTevKQT4GGfxAbNWyJ2564Tk4Xl7d664x@postini.com; Sun, 05 Jun 2011 11:26:19 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; Sun, 5 Jun 2011 11:21:24 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" Date: Sun, 5 Jun 2011 11:20:08 -0700 Thread-Topic: [mpls] R: RE: R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwjrWAWKjp6pJvUSpyADhu8lKzMBw== Message-ID: <1C3AA947-B21F-4566-9713-7346B2220C16@juniper.net> References: <9599927.1230581307289089884.JavaMail.defaultUser@defaultHost> In-Reply-To: <9599927.1230581307289089884.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] R: RE: R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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: Sun, 05 Jun 2011 18:26:21 -0000 SWYgdGhpcyB3YXMgdGhlIElUVSwgd291bGRuJ3QgeW91IGJlIGV4cGVjdGVkIHRvIHdyaXRlIGEN CmNvbnRyaWJ1dGlvbj8gIFRoaW5rIG9mIGFuIEktRCBhcyBhIHNpbWlsYXIgY29uY2VwdC4NCg0K U2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBKdW4gNSwgMjAxMSwgYXQgMTE6NTEgQU0sICJlcm1p bmlvLm90dG9uZV82OUBsaWJlcm8uaXQiIDxlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQNCiA+ IHdyb3RlOg0KDQo+IERvZXMgdGhlIGRyYWZ0IGhhcyBhIHNwZWNpYWwgc3RhdHVzIHZzIG1haWwg Y29tbWVudHM/DQo+DQo+IFRoZXJlIGlzIG5vdGhpbmcgSSBjYW4gcHV0IGluIHRoZSBkcmFmdCB0 aGF0IGhhcyBub3QgYmVlbiBzYWlkIG9uDQo+IHRoZSBtYWlsaW5nDQo+IGxpc3QuDQo+DQo+PiAt LS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0NCj4+IERhOiBudXJpdC5zcHJlY2hlckBuc24uY29t DQo+PiBEYXRhOiA1LWdpdS0yMDExIDE3LjQxDQo+PiBBOiA8ZXJtaW5pby5vdHRvbmVfNjlAbGli ZXJvLml0PiwgPGFkcmlhbkBvbGRkb2cuY28udWs+LCA8bXBsc0BpZXRmLm9yZw0KPj4gPg0KPj4g T2dnOiBSRTogW21wbHNdIFI6IFJlOiBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBp biBNUExTLVRQDQo+IElkZW50aWZpZXJzPw0KPj4NCj4+IFNvIGNvbWUgd2l0aCBhIGRyYWZ0IGFu ZCBwcmVzZW50IGl0Lg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u DQo+PiBCZWhhbGYgT2YgZXh0DQo+IGVybWluaW8ub3R0b25lXzY5QGxpYmVyby5pdA0KPj4gU2Vu dDogU3VuZGF5LCBKdW5lIDA1LCAyMDExIDY6MzcgUE0NCj4+IFRvOiBhZHJpYW5Ab2xkZG9nLmNv LnVrOyBtcGxzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbbXBsc10gUjogUmU6IFI6IFJlOiBNaXhp bmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4gSWRlbnRpZmllcnM/DQo+Pg0KPj4+ IEkgYW0gdGlyZWQgb2YgdGhpcyBkaXNjdXNzaW9uLiBUaGVyZSBzZWVtcyB0byBiZSBubyBmb3J3 YXJkDQo+Pj4gcHJvZ3Jlc3Mgb25seQ0KPj4gcmVzdGF0ZW1lbnQgb2YgYSAid2FudCIuIEkgYWx3 YXlzIHdhbnRlZCBhIHBvbnkgd2hlbiBJIHdhcyBhIGxpdHRsZQ0KPj4gZ2lybCwgYnV0DQo+IEkN Cj4+IG5ldmVyIGdvdCBvbmUuDQo+Pj4NCj4+DQo+PiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZXJl IGFyZSBhIGxvdCBvZiB0ZWNobmljYWwgcXVlc3Rpb25zIG9uIHRoZQ0KPj4gdGFibGUNCj4gdGhh dA0KPj4gY2FuIGJlIGVhc2lseSBhbnN3ZXJlZCBieSBzdXBwb3J0aW5nIG1peGVkIElDQyBhbmQg SVAgaWRlbnRpZmllcnMNCj4+IHRoYXQgYXJlDQo+IG5vdw0KPj4gd2FpdGluZyBmb3IgYW4gYW5z d2VyLA0KPj4NCj4+PiAtLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0NCj4+PiBEYTogYWRyaWFu QG9sZGRvZy5jby51aw0KPj4+IERhdGE6IDI1LW1hZy0yMDExIDExLjEzDQo+Pj4gQTogPG1wbHNA aWV0Zi5vcmc+DQo+Pj4gT2dnOiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9i YWwtSURzIGluIE1QTFMtVFANCj4+PiBJZGVudGlmaWVycz8NCj4+Pg0KPj4+IEhpIE5laWwsDQo+ Pj4NCj4+PiBJJ20gbm90IGFzc3VtaW5nIHBlZXJpbmcuIEkgYW0gYWN0dWFsbHkgcG9pbnRpbmcg b3V0IHRvIEh1dWIgdGhhdA0KPj4+IChkZXNwaXRlDQo+PiB3aGF0IGhlIGtlZXBzIHNheWluZykg aGUgaXMgYWxzbyBub3QgYXNzdW1pbmcgcGVlcmluZy4NCj4+Pg0KPj4+IFRoZSBjb25zZXF1ZW5j ZSBvZiBub3QgcGVlcmluZyBpcyB0aGF0IGEgc2luZ2xlIGlkZW50aWZpZXIgbW9kZSBpcw0KPj4+ IHVzZWQNCj4gZm9yDQo+PiBib3RoIGVuZHMgb2YgYW4gT0FNICJzZXNzaW9uIi4gQW5kIHRoYXQg bWVhbnMgdGhhdCBvbmUgZW5kIGhhcyB0bw0KPiB1bmRlcnN0YW5kDQo+PiAqYW5kKiB1c2UgdGhl ICJmb3JlaWduIiBmb3JtYXQgYXQgdGhlIHJlbW90ZSBlbmQgb2YgdGhlIHNlc3Npb24uDQo+Pj4N Cj4+PiBJIGFtIHRpcmVkIG9mIHRoaXMgZGlzY3Vzc2lvbi4gVGhlcmUgc2VlbXMgdG8gYmUgbm8g Zm9yd2FyZA0KPj4+IHByb2dyZXNzIG9ubHkNCj4+IHJlc3RhdGVtZW50IG9mIGEgIndhbnQiLiBJ IGFsd2F5cyB3YW50ZWQgYSBwb255IHdoZW4gSSB3YXMgYSBsaXR0bGUNCj4+IGdpcmwsIGJ1dA0K PiBJDQo+PiBuZXZlciBnb3Qgb25lLg0KPj4+DQo+Pj4gQWRyaWFuDQo+Pj4NCj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+PiBCZWhhbGYgT2YNCj4+Pj4gbmVp bC4yLmhhcnJpc29uQGJ0LmNvbQ0KPj4+PiBTZW50OiAyMiBNYXkgMjAxMSAyMDozNg0KPj4+PiBU bzogaHV1YmF0d29ya0BnbWFpbC5jb207IG1wbHNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6 IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+PiBJ ZGVudGlmaWVycz8NCj4+Pj4NCj4+Pj4gSGkgQWRyaWFuL0h1dWIsDQo+Pj4+DQo+Pj4+IFlvdSBh cmUgbGFyZ2VseSBhc3N1bWluZyBzb21lIGZvcm0gb2YgcGVlcmluZyAoc2luZ2xlIHBhcnRpdGlv bmVkDQo+Pj4+IGxheWVyDQo+PiBuZXR3b3JrKQ0KPj4+PiBoZXJlLi4uYW5kIHRoYXQgbW9kZWwg d2lsbCBnZW5lcmF0ZSBhIHdob2xlIHJhZnQgb2YgcHJvYmxlbXMgZm9yDQo+IG9wZXJhdG9ycw0K Pj4gSU1PLg0KPj4+PiBBIG1vcmUgaW1wb3J0YW50IG1vZGVsIGZvciBhIGNvLXBzIHRyYW5zcG9y dCBuZXR3b3JrIGlzIGNsaWVudC8NCj4+Pj4gc2VydmVyLg0KPiBBbmQNCj4+IG5vdw0KPj4+PiBu b3Qgb25seSBoYXZlIHdlIHRoZSB1c3VhbCBpbnRyYS1sYXllciBtaXNjb25uZWN0aXZpdHkgdG8g ZGVhbA0KPj4+PiB3aXRoIGJ1dA0KPiB3ZQ0KPj4gYWxzbw0KPj4+PiBoYXZlIGludGVyLWxheWVy IG1pc2Nvbm5lY3Rpdml0eS4uLmFuZCB0aGlzIG1lYW5zIGVhY2ggb3BlcmF0aW5nDQo+Pj4+IHBh cnR5DQo+PiBtdXN0DQo+Pj4+IHVuZGVyc3RhbmQgdGhlIE9BTSBmb3JtYXRzIChhbmQgQ1YgSURz KSBvZiBlYWNoIG90aGVyIGFueXdheS4uLiBub3QNCj4gc2ltcGx5DQo+PiB0bw0KPj4+PiBkZXRl Y3QgdGhlcmUgaXMgYSBtaXNjb25uZWN0aXZpdHkgcHJvYmxlbXMgYnV0IGFsc28gdG8gaWRlbnRp ZnkNCj4+Pj4gd2hpY2gNCj4gb3RoZXINCj4+IHBhcnRpZXMNCj4+Pj4gYXJlIGludm9sdmVkLg0K Pj4+Pg0KPj4+PiByZWdhcmRzLCBOZWlsDQo+Pj4+DQo+Pj4+IEJUIERlc2lnbg0KPj4+PiBUaGlz IGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBv cg0KPj4gY29uZmlkZW50aWFsLg0KPj4+PiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlk dWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYNCj4+Pj4geW91J3JlDQo+IG5vdA0KPj4g dGhlDQo+Pj4+IGludGVuZGVkDQo+Pj4+IHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3Npbmcs IGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZw0KPj4+PiB0aGlzDQo+PiBpbmZvcm1hdGlv bg0KPj4+PiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIGxldA0KPj4+PiBtZSBrbm93DQo+Pj4+IGltbWVkaWF0ZWx5DQo+Pj4+IG9u IHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3UuDQo+Pj4+IFdlIG1vbml0b3Igb3Vy IGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMuDQo+Pj4+IEJyaXRpc2gg VGVsZWNvbW11bmljYXRpb25zIHBsYw0KPj4+PiBSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0 ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQo+Pj4+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzog MTgwMDAwMA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10gT24NCj4+Pj4+IEJlaGFsZiBPZg0KPj4+Pj4gSHV1YiB2YW4gSGVsdm9vcnQN Cj4+Pj4+IFNlbnQ6IDIyIE1heSAyMDExIDE5OjE1DQo+Pj4+PiBUbzogbXBsc0BpZXRmLm9yZw0K Pj4+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlE cyBpbiBNUExTLVRQDQo+Pj4+PiBJZGVudGlmaWVycz8NCj4+Pj4+DQo+Pj4+PiBIaSBBZHJpYW4s DQo+Pj4+Pg0KPj4+Pj4gU2VlIG15IHJlc3BvbnNlIGluLWxpbmUgW2h2aF0NCj4+Pj4+DQo+Pj4+ Pj4gV2UgaGF2ZSBhbHJlYWR5IGJlZW4gcm91bmQgdGhpcyBsb29wIG9uIHRoaXMgbGlzdCBvbmNl Lg0KPj4+Pj4+IFdhbnQgdG8gZG8gaXQgYWdhaW4/DQo+Pj4+Pg0KPj4+Pj4gW2h2aF0gSWYgaXQg aGVscHMgdG8gZ2V0IHRvIHRoZSBmb2NhbCBwb2ludCwgd2h5IG5vdC4NCj4+Pj4+DQo+Pj4+Pj4g QXMgSHV1YiBzYWlkLCB0aGlzIGlzIGFib3V0IGlkZW50aWZpZXJzLCBub3QgT0FNLiBIb3dldmVy LCB0aGUNCj4+Pj4+PiBtb2RlbA0KPj4+Pj4gZm9yIE9BTQ0KPj4+Pj4+IGludGVyd29ya2luZyBz aG93cyAibGF5ZXJpbmciIG5vdCBnYXRld2F5aW5nLCBhbmQgY2VydGFpbmx5IG5vdA0KPj4+Pj4g bWl4aW5nLiBUaGF0IGlzLA0KPj4+Pj4+IG9uZSBlbmQgb2YgdGhlIGUyZSBwYXRoIG11c3QgYmUg Y2FwYWJsZSBvZiBvcGVyYXRpbmcgYm90aA0KPj4+Pj4+IHN5c3RlbXMsDQo+Pj4+PiBidXQgdGhl IG90aGVyDQo+Pj4+Pj4gZG9lcyBub3QgbmVlZCB0by4NCj4+Pj4+DQo+Pj4+PiBbaHZoXSBPSyBp ZiB5b3UgbWVhbiAiT0FNIHRvb2xzZXRzIiBieSAic3lzdGVtcyINCj4+Pj4+DQo+Pj4+Pj4gVG8g ZXh0ZW5kIHRoaXMgbW9kZWwgdG8gaWRlbnRpZmllcnMgbWVhbnMgdGhhdCBvbmUgZW5kIG9mIHRo ZSBlMmUNCj4+Pj4+IHBhdGggbXVzdA0KPj4+Pj4+IHN1cHBvcnQgYm90aCBpZGVudGlmaWVyIGZv cm1hdHMgYW5kIHRoZSBvdGhlciBkb2VzIG5vdCBuZWVkIHRvLg0KPj4+Pj4NCj4+Pj4+IFtodmhd IHRvIGJlIG1vcmUgc3BlY2lmaWMgdGhlIG9yaWdpbmF0aW5nIGVuZCBvZiBhbiBlMmUgcGF0aCBt dXN0DQo+Pj4+PiBiZSBhYmxlIHRvIHN1cHBvcnQgb25lIG9mIHRoZSBwb3NzaWJsZSBpZGVudGlm aWVyIGZvcm1hdHMsDQo+Pj4+PiBub3JtYWxseQ0KPj4+Pj4gdGhlIGlkZW50aWZpZXIgZm9ybWF0 IG9mIHRoZSBsb2NhbCBvcGVyYXRvci4gVGhlIHRlcm1pbmF0aW5nIGVuZA0KPj4+Pj4gYW5kDQo+ Pj4+PiB0aGUgaW50ZXJtZWRpYXRlIHBvaW50cyBvZiBhbiBlMmUgcGF0aCBtdXN0IGJlIGFibGUg dG8gdmVyaWZ5IHRoZQ0KPj4+Pj4gZm9ybWF0IGluc2VydGVkIGF0IHRoZSBvcmlnaW4gaW5kZXBl bmRlbnQgb2YgdGhlIGxvY2FsbHkgdXNlZA0KPj4+Pj4gaWRlbnRpZmllcg0KPj4+Pj4gZm9ybWF0 LiBUaGlzIG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBwb3NzaWJsZSB0byBzdXBwb3J0IGRpZmZlcmVu dA0KPj4+Pj4gaWRlbnRpZmllciBmb3JtYXRzIGluIHRoZSBBLS0+WiBhbnMgWi0tPkEgZGlyZWN0 aW9uIG9mIGFuIGUyZQ0KPj4+Pj4gcGF0aC4NCj4+Pj4+IEkuZS4gbWl4aW5nIG9mIGlkZW50aWZp ZXIgZm9ybWF0cyBtdXN0IGJlIHN1cHBvcnRlZC4NCj4+Pj4+DQo+Pj4+Pj4gVGhpcyBiZWNvbWVz IHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgdG8gdGhlIHRyYW5zaXQgbm9kZXMgdGhhdCBtYXkNCj4+ Pj4+IGhhdmUgdG8NCj4+Pj4+PiBpbnNwZWN0IHRoZSBpZGVudGlmaWVycy4NCj4+Pj4+DQo+Pj4+ PiBbaHZoXSB0aGUgaW5zcGVjdGlvbiB3aWxsIGNvbnNpc3Qgb2YgY29tcGFyaW5nIGEgcmVjZWl2 ZWQgdmFsdWUNCj4+Pj4+IHdpdGggYW4gZXhwZWN0ZWQgdmFsdWUgd2hpY2ggY2FuIGhhdmUgYW55 IGZvcm1hdC4NCj4+Pj4+DQo+Pj4+Pj4gTm9uZSBvZiB0aGlzIGlzIG5ldyBvciBzcGVjaWZpYyB0 byBNUExTLVRQLg0KPj4+Pj4NCj4+Pj4+IFtodmhdIEkgYWdyZWUsIG1peGluZyBvZiBpZGVudGlm aWVyIGZvcm1hdHMgaXQgbm90IHJlc3RyaWN0ZWQgdG8NCj4+Pj4+IE1QTFMtVFAuDQo+Pj4+Pg0K Pj4+Pj4gUmVnYXJkcywgSHV1Yi4NCj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+Pj4gQmVoYWxmDQo+Pj4+PiBPZg0KPj4+Pj4+PiBl cm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQNCj4+Pj4+Pj4gU2VudDogMTggTWF5IDIwMTEgMjI6 MjUNCj4+Pj4+Pj4gVG86IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZzsgTWFsY29sbS5CRVRUU0B6 dGUuY29tLmNuDQo+Pj4+Pj4+IFN1YmplY3Q6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQg R2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+Pj4+PiBJZGVudGlmaWVycz8NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gQXBwZW5kaXggSUkgb2YgWS4xNzMxIHByb3ZpZGVzIGEgZ29vZCBleGFtcGxlIGFib3V0IGhv dyBpbnRlci0NCj4+Pj4+Pj4gZG9tYWluDQo+Pj4+Pj4+IGNvbm5lY3Rpdml0eSB3aXRoIGUyZSBP QU0gY2FuIGJlIHByb3ZpZGVkIHVzaW5nIHRyYW5zcG9ydC0NCj4+Pj4+Pj4gb3JpZW50ZWQNCj4+ Pj4+IE9BTQ0KPj4+Pj4+PiBmdW5jdGlvbnMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFlvdSBjYW4gZG93 bmxvYWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIFkuMTczMSAodGhlIHBkciB2ZXJzaW9uDQo+Pj4+ Pj4+IGlzDQo+Pj4+PiBmb3IgZnJlZSkgYXQNCj4+Pj4+Pj4gdGhlIGZvbGxvd2luZyBVUkw6DQo+ Pj4+Pj4+DQo+Pj4+Pj4+IGh0dHA6Ly93d3cuaXR1LmludC9yZWMvVC1SRUMtWS4xNzMxL2VuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IEl0IGlzIGEgcGl0eSB0aGF0IHdpdGggdGhlIGN1cnJlbnQgdmVyc2lv biBvZiB0aGUgaWRlbnRpZmllcg0KPj4+Pj4+PiBkcmFmdCwNCj4+Pj4+IE1QTFMtVFAgaXMNCj4+ Pj4+Pj4gbm90IGNhcGFibGUgdG8gc3VwcG9ydCBzdWNoIGEgbmV0d29yayBzY2VuYXJpby4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4+IC0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLQ0KPj4+Pj4+Pj4gRGE6 IGxvYUBwaS5udQ0KPj4+Pj4+Pj4gRGF0YTogNC1tYWctMjAxMSA4LjAwDQo+Pj4+Pj4+PiBBOjxt cGxzQGlldGYub3JnPiwNCj4+Pj4+Pj4gIk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiI8TWFsY29s bS5CRVRUU0B6dGUuY29tLmNuPg0KPj4+Pj4+Pj4gT2dnOiBSZTogW21wbHNdIE1peGluZyBJQ0Mg YW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPj4+Pj4+Pj4gSWRlbnRpZmllcnM/DQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gTWFsY29sbSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBhcmUgeW91IHNheWluZyB0 aGF0IG9wZXJhdG9ycyB0b2RheSBhbGxvdyBPQU0gdG8gY29udHJvbCBub2RlDQo+Pj4+Pj4+PiAo TUlQcw0KPj4+Pj4gYW5kDQo+Pj4+Pj4+PiBNRVBzKSBvbiBlYWNoIG90aGVycyBuZXR3b3Jrcz8N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBEbyB3ZSBoYXZlIGFuIG9wZXJhdG9yIHRoYXQgY2FuIHZlcmlm eSB0aGlzPw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IC9Mb2ENCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiAy MDExLTA1LTAzIDIyOjQ0LCBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24gd3JvdGU6DQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBBbGwsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHNoYXJlIHlvdXIgY29u Y2VybnMgYW5kIGRvdWJ0cyBhYm91dCBhIG11bHRpIGNhcnJpZXIgY29udHJvbA0KPj4+Pj4gcGxh bmUuDQo+Pj4+Pj4+Pj4gSG93ZXZlciwgSSB0aGluayB0aGF0IGl0IGlzIGVzc2VudGlhbCB0aGF0 IGEgdHJhbnNwb3J0IG5ldHdvcmsNCj4+Pj4+IHN1cHBvcnRzDQo+Pj4+Pj4+Pj4gbXVsdGkgY2Fy cmllciBkYXRhIHBsYW5lIGludGVyY29ubmVjdGlvbiB3aXRoIGVuZCB0byBlbmQNCj4+Pj4+Pj4+ PiBPQU0uIEluDQo+Pj4+PiB0b2RheSdzDQo+Pj4+Pj4+Pj4gdHJhbnNwb3J0IG5ldHdvcmsgdGhp cyBpbnRlcmNvbm5lY3Rpb24gaXMgc3VwcG9ydGVkIGJ5IFNESCBhbmQNCj4+Pj4+IE9UTi4gVGhl DQo+Pj4+Pj4+Pj4gb2JqZWN0aXZlIGZvciBNUExTLVRQIGlzIHRvIGFsbG93IGZvciBwYWNrZXQg YmFzZWQNCj4+Pj4+Pj4+PiBpbnRlcmNvbm5lY3Rpb24NCj4+Pj4+IGFzDQo+Pj4+Pj4+IHdlbGwu DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTWFs Y29sbQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICpHZW9yZ2Ug U3dhbGxvdzxzd2FsbG93QGNpc2NvLmNvbT4qDQo+Pj4+Pj4+Pj4gU2VudCBieTogbXBscy1ib3Vu Y2VzQGlldGYub3JnDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAwMy8wNS8yMDExIDExOjA5IEFNDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRvDQo+Pj4+Pj4+Pj4gICAgICJBbmRyZXcg Ry4gTWFsaXMiPGFnbWFsaXNAZ21haWwuY29tPiw8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbQ0KPj4+ Pj4+Pj4+ID4NCj4+Pj4+Pj4+PiBjYw0KPj4+Pj4+Pj4+ICAgICBtcGxzQGlldGYub3JnDQo+Pj4+ Pj4+Pj4gU3ViamVjdA0KPj4+Pj4+Pj4+ICAgICBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEds b2JhbC1JRHMgaW4gTVBMUy1UUA0KPj4+Pj4+Pj4+IElkZW50aWZpZXJzPw0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBbmR5IC0NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBTdWNoDQo+Pj4+Pj4+Pj4+IGFuIEUtTk5JIGRlZmluaXRpb24gZG9lcyBub3QgeWV0IGV4aXN0 IGZvciBNUExTLVRQIChzb21ldGhpbmcNCj4+Pj4+IGVsc2UgdG8NCj4+Pj4+Pj4+Pj4gcHV0IG9u IHRoZSB0by1kbyBsaXN0KS4gVGhpcyBFLU5OSSB3b3VsZCBhbHNvIGluY2x1ZGUgc2ltaWxhcg0K Pj4+Pj4+Pj4+PiBpZGVudGlmaWVyIG1hcHBpbmcvdHJhbnNsYXRpb24gZm9yIE1TLVBXcywgdG8g YW5zd2VyIGFuDQo+Pj4+PiBlYXJsaWVyDQo+Pj4+Pj4+Pj4+IHF1ZXN0aW9uIGZyb20gRXJtaW5p byB0aGF0IEkgc2F3IG9uIHRoZSBsaXN0Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gWW91IGFyZSBx dWl0ZSBjb3JyZWN0IGhlcmUhIEkgdGhpbmsgbXVjaCBvZiB0aGlzIGRlYmF0ZQ0KPj4+Pj4+Pj4+ IHN1cnJvdW5kcw0KPj4+Pj4gYQ0KPj4+Pj4+PiBwcm9ibGVtDQo+Pj4+Pj4+Pj4gdGhhdCBpcyB5 ZXQgdG8gYmUgc29sdmVkLiBTbyB0aGVyZSBhcmUgYXJndW1lbnRzIGZvciBwaWVjZXMNCj4+Pj4+ Pj4+PiBvZiBhDQo+Pj4+PiBzb2x1dGlvbg0KPj4+Pj4+Pj4+IHdpdGhvdXQgYW5kIG92ZXJhbGwg YXJjaGl0ZWN0dXJlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQmFzZWQgb24gYWxsIHRoYXQgSSBh bSBzZWVpbmcgbXkgaW5jbGluYXRpb24gaXMgdG8gTk9UIHNheQ0KPj4+Pj4+Pj4+IHRoYXQgd2UN Cj4+Pj4+Pj4gZGlzYWxsb3cNCj4+Pj4+Pj4+PiBtaXhlZCBpZGVudGlmaWVycywgYnV0IHRvIHNh eSB0aGF0IHRoZXkgYXJlIGZvciBmdXR1cmUgc3R1ZHkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAu Li5HZW9yZ2UNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT24gNS8zLzExIDg6MzggQU0sICJBbmRyZXcgRy4gTWFsaXMiPGFn bWFsaXNAZ21haWwuY29tPg0KPj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IE5laWwsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRvIHlvdXIgY2FzZSAxLCB3ZSdyZSBpbiBj b21wbGV0ZSBhZ3JlZW1lbnQuIFdlIChWWikgZG9uJ3QNCj4+Pj4+IHNlZSBhdA0KPj4+Pj4+Pj4+ PiBsZWFzdCBhIHNob3J0LXRlcm0gbmVlZCBmb3IgcGVlci1sYXllciBpbnRlcndvcmtpbmcsIGdp dmVuDQo+Pj4+PiB3aGVyZSB3ZQ0KPj4+Pj4+Pj4+PiBpbnRlbmQgdG8gZGVwbG95IE1QTFMtVFAg aW4gb3VyIGluZnJhc3RydWN0dXJlIChhcyBhbg0KPj4+Pj4gaW50ZXJuYWwgc2VydmVyDQo+Pj4+ Pj4+Pj4+IGxheWVyIGluIHRoZSB0cmFuc3BvcnQgY29yZSkuIElmIHBlZXIgbGF5ZXIgaW50ZXJ3 b3JraW5nIGV2ZXINCj4+Pj4+IGJlY29tZXMNCj4+Pj4+Pj4+Pj4gYSBuZWNlc3NpdHksIHRoZW4g b2J2aW91c2x5IHdlJ2xsIG5lZWQgYSB3ZWxsLWRlZmluZWQgRS1OTkkNCj4+Pj4+IHdoaWNoDQo+ Pj4+Pj4+Pj4+IHdvdWxkIGluY2x1ZGUgTFNQIGlkZW50aWZpZXIgbWFwcGluZy90cmFuc2xhdGlv biBhdCB0aGUNCj4+Pj4+IGJvdW5kYXJ5LCBmb3INCj4+Pj4+Pj4+Pj4gTFNQIHByb3Zpc2lvbmlu ZyAod2hldGhlciBzdGF0aWMgb3IgZHluYW1pYykgYW5kIGVuZC10by1lbmQNCj4+Pj4+IE9BTS4g U3VjaA0KPj4+Pj4+Pj4+PiBhbiBFLU5OSSBkZWZpbml0aW9uIGRvZXMgbm90IHlldCBleGlzdCBm b3IgTVBMUy1UUCAoc29tZXRoaW5nDQo+Pj4+PiBlbHNlIHRvDQo+Pj4+Pj4+Pj4+IHB1dCBvbiB0 aGUgdG8tZG8gbGlzdCkuIFRoaXMgRS1OTkkgd291bGQgYWxzbyBpbmNsdWRlIHNpbWlsYXINCj4+ Pj4+Pj4+Pj4gaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0aW9uIGZvciBNUy1QV3MsIHRvIGFu c3dlciBhbg0KPj4+Pj4gZWFybGllcg0KPj4+Pj4+Pj4+PiBxdWVzdGlvbiBmcm9tIEVybWluaW8g dGhhdCBJIHNhdyBvbiB0aGUgbGlzdC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSSBhbHNvIGFn cmVlIHRoYXQgYm90aCBpbnRyYS1sYXllciBhbmQgaW50ZXItbGF5ZXIgbWlzLQ0KPj4+Pj4gY29u bmVjdGl2aXR5DQo+Pj4+Pj4+Pj4+IGRldGVjdGlvbiBhbmQgYW1lbGlvcmF0aW9uIGFyZSByZXF1 aXJlZCwgYnV0IEknbSBub3QNCj4+Pj4+IGNvbnZpbmNlZCB0aGF0DQo+Pj4+Pj4+Pj4+IHRoZSBh bHJlYWR5IGRlZmluZWQgbWVjaGFuaXNtcyBjYW4ndCBkbyB0aGF0LiBEbyB5b3UgaGF2ZQ0KPj4+ Pj4gc29tZQ0KPj4+Pj4+Pj4+PiBzcGVjaWZpYyBhbmFseXNpcyBvbiB0aGUgaW50ZXItbGF5ZXIg Y2FzZT8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+PiBBbmR5DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uIFR1ZSwgTWF5IDMsIDIwMTEgYXQgMzozNiBBTSw8bmVp bC4yLmhhcnJpc29uQGJ0LmNvbT4NCj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4gSGkgQW5keSwN Cj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAyIHBvaW50czoNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiAxIEkgYWdyZWUgd2l0aCB5b3VyIHZpZXcgb2Ygb25seSBoYXZpbmcgYSBzaW5nbGUgYWRk cmVzc2luZw0KPj4+Pj4gc2NoZW1lIGluDQo+Pj4+Pj4+IGENCj4+Pj4+Pj4+Pj4+IHNpbmdsZSBs YXllciBuZXR3b3JrIHNvbGVseSBiZWxvbmdpbmcgdG8gb25lIHBhcnR5LiBUaG91Z2gNCj4+Pj4+ IHlvdSBtYXkNCj4+Pj4+Pj4+PiBuZWVkIHRvDQo+Pj4+Pj4+Pj4+PiBiZSByYXRoZXIgY2FyZWZ1 bCBpZiB5b3UgYWxzbyBhZHZvY2F0ZSB0aGF0IG9uZSBjYW4gYWxzbw0KPj4+Pj4gaGF2ZSBwZWVy DQo+Pj4+Pj4+IGxheWVyDQo+Pj4+Pj4+Pj4+PiBpbnRlcndvcmtpbmcgYmV0d2VlbiBkaWZmZXJl bnQgcGFydGllcywgaWUgRS1OTklzIChJIGJlbGlldmUNCj4+Pj4+IHRoaXMgaXMNCj4+Pj4+Pj4+ Pj4+IHNvbWV0aGluZyB5b3UgbWF5IHN1cHBvcnQsIGVnIG9sZCBNUExTRiBjYXNlPykuIEluIHN1 Y2ggYQ0KPj4+Pj4gcGVlcg0KPj4+Pj4+Pj4+IGludGVyd29ya2luZw0KPj4+Pj4+Pj4+Pj4gY2Fz ZSBpdCB3b3VsZCBzZWVtIG9uZSBtdXN0IGFsbG93IGRpZmZlcmVudCBhZGRyZXNzaW5nDQo+Pj4+ PiBzY2hlbWVzIChhbmQNCj4+Pj4+Pj4+PiBpbmRlZWQNCj4+Pj4+Pj4+Pj4+IGFueSBvdGhlciB2 YXJpYXRpb25zIGluIERQL0NQIGZ1bmN0aW9uYWwgY29tcG9uZW50cykgaWYgdGhleQ0KPj4+Pj4g ZXhpc3QNCj4+Pj4+Pj4+PiBpbiB0aGUNCj4+Pj4+Pj4+Pj4+IHN0YW5kYXJkcy4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBPZiBjb3Vyc2UsIGhhdmluZyBhbiBFLU5OSSBhbmQgcGVlciBpbnRl cndvcmtpbmcgYmV0d2Vlbg0KPj4+Pj4gZGlmZmVyZW50DQo+Pj4+Pj4+Pj4gcGFydGllcyBpbg0K Pj4+Pj4+Pj4+Pj4gYW55IG5vbi1UT1MgbGF5ZXIgbmV0d29yayAobm90IGp1c3QgTVBMUykgaXMg bm90IHRlY2huaWNhbGx5DQo+Pj4+Pj4+Pj4gbmVjZXNzYXJ5ICh0aGlzDQo+Pj4+Pj4+Pj4+PiBp cyB0cml2aWFsIHRvIHByb3ZlKSwgYW5kIHRoaXMgcHJvdmlkZXMgYSBzdHJvbmcgYXJndW1lbnQN Cj4+Pj4+IGZvciBvbmx5DQo+Pj4+Pj4+Pj4gaGF2aW5nIGENCj4+Pj4+Pj4+Pj4+IHNpbmdsZSBh ZGRyZXNzaW5nIHNjaGVtZSBpbiBhIG5vbi1UT1MgbGF5ZXIgbmV0d29yay4NCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gMiBZb3Ugc2hvdWxkIGFsc28gYmUgYXdhcmUgdGhh dCBpbiBjbGllbnQvc2VydmVyDQo+Pj4+PiBpbnRlcndvcmtpbmcgb2YgdGhlDQo+Pj4+Pj4+Pj4+ PiBjby1wcyBtb2RlIHVzaW5nIHZhcmlhYmxlIHNpemUgdHJhZmZpYyB1bml0cywgYW5kIHRoZXJl Zm9yZQ0KPj4+Pj4+Pj4+IHNvbWV0aGluZyByYXRoZXINCj4+Pj4+Pj4+Pj4+IGltcG9ydGFudCBm b3IgTVBMUy1UUCBpbiB0aGUgcm9sZSBvZiBhIHRyYW5zcG9ydCBuZXR3b3JrDQo+Pj4+PiAoSSds bA0KPj4+Pj4+Pj4+IGlnbm9yZSBpc3N1ZXMNCj4+Pj4+Pj4+Pj4+IG9mIHRyYW5zcGFyZW5jeSBo ZXJlKSwgdGhlcmUgY291bGQgYmUgaW50ZXItbGF5ZXINCj4+Pj4+IG1pc2Nvbm5lY3Rpdml0eQ0K Pj4+Pj4+Pj4+IChBc2lkZT0+DQo+Pj4+Pj4+Pj4+PiBUaGlzIGNhc2UgY2Fubm90IG9jY3VyIGlu IHRoZSBjby1jcyBtb2RlKS4gVG8gZGF0ZSwgaG93ZXZlciwNCj4+Pj4+IHdlIGhhdmUNCj4+Pj4+ Pj4+PiBvbmx5DQo+Pj4+Pj4+Pj4+PiByZWFsbHkgY29uc2lkZXJlZCBpbnRyYS1sYXllciBtaXNj b25uZWN0aXZpdHksIGllIGJldHdlZW4NCj4+Pj4+IGRpZmZlcmVudA0KPj4+Pj4+PiBMU1BzDQo+ Pj4+Pj4+Pj4+PiBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgcGFydHkgKG5vdGUgdGhpcyBhbHNvIGlu Y2x1ZGVzIGFsbA0KPj4+Pj4gY2FzZXMgb2YNCj4+Pj4+Pj4+PiBuZXN0ZWQgTFNQDQo+Pj4+Pj4+ Pj4+PiBzdWJsYXllciBtaXNjb25uZWN0aXZpdHkpLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ IEluIHRoZSBjYXNlIG9mIGludGVyLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSBvbmUgbWF5IHJlY2Vp dmUNCj4+Pj4+IHRyYWZmaWMNCj4+Pj4+Pj4+PiB1bml0cyBhbmQNCj4+Pj4+Pj4+Pj4+IE9BTSBt ZXNzYWdlcyBmcm9tIHNvbWUgb3RoZXIgcGFydHkncyBsYXllciBuZXR3b3JrLiBUaGUgT0FNDQo+ Pj4+Pj4+IG1lc3NhZ2VzDQo+Pj4+Pj4+IG1heQ0KPj4+Pj4+Pj4+Pj4gY29tZSBmcm9tIChpKSBu ZXR3b3JrcyB1c2luZyBkaWZmZXJlbnQgT0FNL2FkZHJlc3NpbmcNCj4+Pj4+IHNvbHV0aW9ucyBv cg0KPj4+Pj4+PiAoaWkpDQo+Pj4+Pj4+Pj4+PiBuZXR3b3JrcyB1c2luZyB0aGUgc2FtZSBPQU0v YWRkcmVzc2luZyBzb2x1dGlvbnMuIEluIGJvdGgNCj4+Pj4+IGNhc2VzDQo+Pj4+Pj4+Pj4gdGhl cmUgYXJlDQo+Pj4+Pj4+Pj4+PiBkaWZmZXJlbnQgaXNzdWVzIHdydCBpbnRlci1sYXllciBtaXNj b25uZWN0aXZpdHkgb25lIGhhcyB0bw0KPj4+Pj4gZGVhbA0KPj4+Pj4+Pj4+IHdpdGguIEknbQ0K Pj4+Pj4+Pj4+Pj4gbm90IGF3YXJlIHRoYXQgdGhlc2UgY2FzZXMgaGF2ZSBiZWVuIGNvbnNpZGVy ZWQgeWV0Lg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJJ2QgbGlrZSB0 byBoZWFyIHlvdXIgY29tbWVudHMgb24gYm90aCB0aGVzZSBwb2ludHMsIGJ1dCBpbg0KPj4+Pj4+ Pj4+IHBhcnRpY3VsYXIgdGhlDQo+Pj4+Pj4+Pj4+PiBmaXJzdCBvbmUuLi4uLmVzcGVjaWFsbHkg aWYgeW91IGFsc28gc3VwcG9ydCB0aGUgbm90aW9uIG9mDQo+Pj4+PiBFLU5OSXMgaW4NCj4+Pj4+ Pj4+PiBNUExTLVRQLA0KPj4+Pj4+Pj4+Pj4gYXMgdGhlcmUgc2VlbXMgdG8gYSBwb3NzaWJsZSBs b2dpY2FsIGNvbmZsaWN0IGhlcmUuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gVGhhbmtzLg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IHJlZ2FyZHMsIE5laWwgSGFycmlzb24NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBCVCBEZXNpZ24NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGlz IGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZA0K Pj4+Pj4gb3INCj4+Pj4+Pj4+PiBjb25maWRlbnRpYWwuDQo+Pj4+Pj4+Pj4+PiBJdCdzIG1lYW50 IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4NCj4+Pj4+ IElmDQo+Pj4+Pj4+Pj4geW91J3JlIG5vdA0KPj4+Pj4+Pj4+Pj4gdGhlIGludGVuZGVkDQo+Pj4+ Pj4+Pj4+PiByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmli dXRpbmcgb3INCj4+Pj4+IHVzaW5nIHRoaXMNCj4+Pj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+Pj4+ Pj4+Pj4+PiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwNCj4+Pj4+IHBsZWFzZSBsZXQgbWUNCj4+Pj4+Pj4+PiBrbm93DQo+Pj4+Pj4+Pj4+PiBp bW1lZGlhdGVseQ0KPj4+Pj4+Pj4+Pj4gb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5r IHlvdS4NCj4+Pj4+Pj4+Pj4+IFdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSBy ZWNvcmQgeW91ciBlbWFpbHMuDQo+Pj4+Pj4+Pj4+PiBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9u cyBwbGMNCj4+Pj4+Pj4+Pj4+IFJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBM b25kb24gRUMxQSA3QUoNCj4+Pj4+Pj4+Pj4+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgw MDAwMA0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+Pj4+Pj4+Pj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10NCj4+Pj4+IE9uIEJlaGFsZg0KPj4+Pj4+PiBPZg0KPj4+Pj4+Pj4+ Pj4+IEFuZHJldyBHLiBNYWxpcw0KPj4+Pj4+Pj4+Pj4+IFNlbnQ6IDAyIE1heSAyMDExIDIwOjQ4 DQo+Pj4+Pj4+Pj4+Pj4gVG86IEdlb3JnZSBTd2FsbG93DQo+Pj4+Pj4+Pj4+Pj4gQ2M6IG1wbHNA aWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5k IEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPj4+Pj4gSWRlbnRpZmllcnM/DQo+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+PiBHZW9yZ2UgZXQgYWwsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBW ZXJpem9uIGRvZXMgbm90IGhhdmUgYW55IHJlcXVpcmVtZW50IGZvciBtaXhlZCB1c2Ugb2YNCj4+ Pj4+IEdsb2JhbCBJRHMgYW5kDQo+Pj4+Pj4+Pj4+Pj4gSUNDcy4gV2UgYXJlIGZpbmUgd2l0aCBz cGVjaWZpY2F0aW9ucyB0aGF0IHJlcXVpcmUgYm90aA0KPj4+Pj4gZW5kcyBvZiBhbg0KPj4+Pj4+ PiBMU1ANCj4+Pj4+Pj4+Pj4+PiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlci4NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+Pj4+PiBBbmR5DQo+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+PiBPbiBNb24sIEFwciAyNSwgMjAxMSBhdCA1OjE2IFBNLCBHZW9yZ2UNCj4+ Pj4+IFN3YWxsb3c8c3dhbGxvd0BjaXNjby5jb20+DQo+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+ Pj4+Pj4+Pj4+IEFsbCAtDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IE1hbnkgb2YgdGhl IGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gdGhlIElUVSBvbg0KPj4+Pj4+Pj4+Pj4+PiBkcmFmdC1p ZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMtMDQgaGF2ZSB0byBkbyB3aXRoIHRoZQ0KPj4+Pj4gR2xv YmFsIGFuZCBJQ0MNCj4+Pj4+Pj4+Pj4+Pj4gaWRlbnRpZmllcnMuDQo+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+IFRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQgTUVH IGluY2x1ZGUNCj4+Pj4+IGZpZWxkcyB0bw0KPj4+Pj4+Pj4+Pj4+IGlkZW50aWZ5IGVhY2gNCj4+ Pj4+Pj4+Pj4+Pj4gZW5kIG9mIGFuIExTUC4gQ3VycmVudGx5IHRoZSBkcmFmdCBhbGxvd3MgYSBU dW5uZWwsIExTUCwNCj4+Pj4+IFBXLCBvciBNRUcNCj4+Pj4+Pj4+Pj4+PiB0byB1c2UNCj4+Pj4+ Pj4+Pj4+Pj4gZWl0aGVyIHRoZSBHbG9iYWwtSUQgZm9yIGJvdGggZW5kcyBvciBvciB0aGUgSUND IGZvciBib3RoDQo+Pj4+PiBlbmRzLg0KPj4+Pj4+Pj4+Pj4+IE1peGVkIHVzZQ0KPj4+Pj4+Pj4+ Pj4+PiBpcyBub3QgcGVybWl0dGVkLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBUaGUg SVRVIGxpYWlzb24gcmVxdWVzdHMgdGhhdCB3ZSBhbGxvdyBtaXhlZCB1c2UuDQo+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IFRoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBhcmUgdmVyeSByZWx1 Y3RhbnQgdG8gZG8gdGhpcy4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gT2J0YWluaW5n IGFuIEFTIE51bWJlciAoZnJvbSB3aGljaCB0aGUgR2xvYmFsLUlEIGlzDQo+Pj4+PiBkZXJpdmVk KSBpcyBhDQo+Pj4+Pj4+Pj4+Pj4gZmFpcmx5DQo+Pj4+Pj4+Pj4+Pj4+IHRyaXZpYWwgcHJvY2Vk dXJlLiBNYW55IG9yZ2FuaXphdGlvbnMgaWYgbm90IG1vc3QgYWxyZWFkeQ0KPj4+Pj4gaGF2ZSBB Uw0KPj4+Pj4+Pj4+Pj4+IE51bWJlcnMuDQo+Pj4+Pj4+Pj4+Pj4+IFN1Y2ggYW4gYWRkaXRpb24g d2lsbCBhZGQgbnVtZXJvdXMgb2JqZWN0IGZvcm1hdHMsIGFuZA0KPj4+Pj4gdGVzdCBjYXNlcy4N Cj4+Pj4+Pj4+Pj4+Pj4gVGhlIGV4dGVudCBpbnRlci1wcm92aWRlciBNUExTLVRQIGlzIGFzIHll dCB1bmtub3duLiBJZg0KPj4+Pj4gbWl4ZWQgbW9kZXMNCj4+Pj4+Pj4+Pj4+PiBvZiBJQ0MNCj4+ Pj4+Pj4+Pj4+Pj4gYW5kIEdsb2JhbC1JRCBpZGVudGlmaWNhdGlvbiBpcyByZXF1aXJlZCwgdGhl eSBjYW4gYmUNCj4+Pj4+IGFkZGVkIGxhdGVyLg0KPj4+Pj4+Pj4+Pj4+PiBGb3Igc2lnbmFsZWQg Y29ubmVjdGlvbnMsIHRoZXJlIGlzIG5vIHBsYW4gdG8gYWxsb3cNCj4+Pj4+IHJvdXRpbmcgYmFz ZWQgb24NCj4+Pj4+Pj4+Pj4+PiBlaXRoZXINCj4+Pj4+Pj4+Pj4+Pj4gdGhlIEdsb2JhbC1JRCBv ciBJQ0MuIFRoYXQgd291bGQgYmUgYSByYWRpY2FsIGNoYW5nZSB0bw0KPj4+Pj4gaG93IElQDQo+ Pj4+Pj4+Pj4+Pj4gd29ya3MuDQo+Pj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIgZm9yIElQIHJvdXRpbmcg dG8gd29yayAoaW4gb3JkZXIgdG8gZm9yd2FyZCB0aGUNCj4+Pj4+IHNpZ25hbGluZw0KPj4+Pj4+ Pj4+Pj4+PiBtZXNzYWdlcyksIHRoZSBwcm92aWRlcnMgaW52b2x2ZWQgd2lsbCBuZWVkIHRvIHJ1 biBCR1AgYW5kDQo+Pj4+PiBoYXZlIEFTDQo+Pj4+Pj4+Pj4+Pj4gbnVtYmVycy4NCj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gV2UgYXJlIGxvb2tpbmcgZm9yIGlucHV0L2NvbnNlbnN1cyBm cm9tIHRoZSBXRy4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gR2VvcmdlLCBFcmljLCYg IE1hdHRoZXcNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+DQo+Pj4+ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pj4+ ICoqKg0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4 ieS4gA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbXBscyBtYWlsaW5n IGxpc3QNCj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+PiBtcGxzQGlldGYu b3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4N Cj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+PiBtcGxzQGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+DQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0 DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo= From internet-drafts@ietf.org Sun Jun 5 18:01:35 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 B6DFE11E80A0; Sun, 5 Jun 2011 18:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 skojSTgYNbPx; Sun, 5 Jun 2011 18:01:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374511E807A; Sun, 5 Jun 2011 18:01:35 -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.55 Message-ID: <20110606010135.10779.85693.idtracker@ietfa.amsl.com> Date: Sun, 05 Jun 2011 18:01:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-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: Mon, 06 Jun 2011 01:01:35 -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-02.txt Pages : 20 Date : 2011-06-05 This document specifies an extension to MPLS Operation, administration, and Maintenance (OAM) to operate an Label Switched Path (LSP), bi-directional RSVP-TE tunnels, Pseudowires (PW), or Multi-segment PWs in loopback mode for management purpose in an MPLS based Transport. This extension includes mechanism to lock and unlock MPLS-TP Tunnels (i.e. data and control traffic) and can be used to loop all traffic (i.e, data and control traffic) at a specified LSR on the path of the LSP in an MPLS based Transport Network back to the source. However, the mechanisms are intended to be applicable to other aspects of MPLS as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-02.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-02.txt From ice@cisco.com Mon Jun 6 07:57: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 F184B11E8157 for ; Mon, 6 Jun 2011 07:57:09 -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 WnLFWZzmp7yW for ; Mon, 6 Jun 2011 07:57:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7BA11E8145 for ; Mon, 6 Jun 2011 07:57:09 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p56Ev5tN018833; Mon, 6 Jun 2011 16:57:06 +0200 (CEST) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p56Ev0C7028544; Mon, 6 Jun 2011 16:57:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <4DE795A3.5050106@pi.nu> Date: Mon, 6 Jun 2011 16:57:00 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4DE795A3.5050106@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1081) Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 06 Jun 2011 14:57:10 -0000 yes/support On 02 Jun 2011, at 15:52, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-raza-mpls-ldp-ip-pw-capability-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends 2011-06-16. > > /Loa > > > -- > > > 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 eric.gray@ericsson.com Mon Jun 6 08:55: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 4992111E815C for ; Mon, 6 Jun 2011 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 Xhqs7GQN7OWt for ; Mon, 6 Jun 2011 08:55:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D611E8137 for ; Mon, 6 Jun 2011 08:55:05 -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 p56FsX4F008600 for ; Mon, 6 Jun 2011 10:55:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 6 Jun 2011 11:55:00 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Mon, 6 Jun 2011 11:54:58 -0400 Thread-Topic: poll on draft-vkst-mpls-tp-te-mib-00.txt Thread-Index: AQInbMd/Fp4zgM/z/mPvm8yZHSieeAJPDELXk+Sjs4CAAs5iwA== 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: poll on draft-vkst-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, 06 Jun 2011 15:55:08 -0000 Forwarding in plain text... ________________________________ From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Saturday, June 04, 2011 5:05 PM To: 'venkatesan mahalingam'; jcucchiara@mindspring.com; 'mpls' Cc: loa@pi.nu; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-t= e-mib@tools.ietf.org Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt Thanks Venkat, =20 [Recalling that I am speaking as an individual contributor and not as AD] =20 This revision is much improved and I think the I-D would form a good basis = for further WG work. =20 Adrian =20 From: venkatesan mahalingam [mailto:venkatflex@gmail.com]=20 Sent: 04 June 2011 20:20 To: Adrian Farrel; jcucchiara@mindspring.com; mpls Cc: loa@pi.nu; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-t= e-mib@tools.ietf.org Subject: Fwd: poll on draft-vkst-mpls-tp-te-mib-00.txt =20 Dear Adrian and Joan, =20 We have addressed the 3 major comments identified by you during WG adoption= poll. Apologies for the delayed response as we wanted to address each item= carefully and get consensus among authors of this document. =20 1. MPLS-TE-STD-MIB is extended by MPLS-TP-TE-STD-MIB mib module The 'extends' relationship is a sparse augmentation so that the entry i= n the mplsTpTunnelTable has the same index values. Redefining of the index de= finitions is now removed and the table is referenced with the same indices as in mplsTunnelTable. =20 2. Separate mib module for textual conventions created for MPLS-TP mib modu= les. This is part of the present MIB,=20 which will be published separately, later. =20 3. Separate mib modules for MPLS-TP-TC-STD-MIB, MPLS-TP-ID-STD-MIB, MPLS-TP= -LSR-STD-MIB and=20 MPLS-TP-TE-STD-MIB have been created. These are presently part of this = MIB, so as overcome the mib compilation issues. These mibs will be published as separate drafts, after the adoption. =20 Apart from the above we have taken care of minor issues as well. We think, = the issues raised were addressed, and the document is ready to be adopted a= s WG doc. Any changes, if needed, we will address in the subsequent revisio= ns. Kindly let us know if you have any questions. =20 New version can be accessed through this below URL, http://tools.ietf.org/html/draft-vkst-mpls-tp-te-mib-01 =20 Thanks, Venkat. =20 ---------- Forwarded message ---------- From: venkatesan mahalingam Date: Mon, May 9, 2011 at 5:29 PM Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt To: adrian@olddog.co.uk, loa@pi.nu, mpls Cc: swallow@cisco.com, rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools= .ietf.org Hi Adrian and all, Please find the responses inlined with the tag <> =20 Thanks, TP-MIB-Authors. ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Saturday, May 07, 2011 3:40 AM To: loa@pi.nu; mpls@ietf.org Cc: swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools= .ietf.org Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt =20 >[speaking as an individual WG participant] =20 >I support the idea of constructing a MIB module for MPLS-TP LSPs and for o= ther >elements of MPLS-TP, but I have significant reservations about adopting th= is >document in its current form. I recognise that once adopted, the WG will b= e able >to enforce changes in content, but I am concerned that this document does = not >correctly reflect the relationship with other MIB modules, and that taking= this >as a starting point will encourage us to go down the wrong path resulting = in a >starting direction that will be hard to change. =20 >I would be happy to see the authors spend a little more time on this and t= hen >adopt it into the WG. =20 >In overview my concerns are as follows: =20 > mplsGlobalId, mplsIcc and mplsNodeId are node properties that will turn o= ut > to > be equally applicable for PWs. They should appear in a MIB module dedicat= ed > to > the LSR not just to the MPLS-TP LSPs. Given that these three objects and > mplsNodeConfigTable and mplsNodeIpMapTable are all related to MPLS-TP > identifiers, why not have a separate module for them all? =20 =20 <> We agree that mplsGlobalId, mplsIcc and mplsNodeId can b= e kept in a common mib module. mplsNodeConfigTable is created specifically to map the [Global-id_Node-id] and Icc-id into Local-Num. This Local-Num will be used as the tunnel source= /destination identifier. =20 This idea has been followed to retain the MPLS tunnel table for MPLS-TP TE = extensions also. We think that mplsNodeConfigTable/mplsNodeIpMapTable is not applicable for = PWs. The reason is that we already have the 129 FEC PWs with variable length of = SAII & TAII. And the SAII & TAII already includes the Global-Id and Node-Id (or ICC Id) Since the MPLS-TP PWs are always FEC129 Type2 based PWs, the flexibility in= SAII & TAII=20 can be used to configure Global-id/Node-id or ICC id. =20 =20 > A number of objects related to Global IDs and Node IDs appear to be of th= e > wrong > max value compared to draft-ietf-mpls-tp-identifiers. You could usefully > define > TCs for them and for the ICC ID. What will zero Global IDs and Node IDs > mean? =20 =20 <> Yes, the Max value of Global-Id and Node-id are wrong. M= ax value should be max of 4 bytes value. We will correct them. =20 Yes, we can keep the TCs for Global-id/Node-id and ICC-id in a seperate mib module. 1) A Global_ID of zero means that no Global_ID is present. 2) A Node_ID of zero is the default value that indicates the Node_ID is invalid. =20 =20 > I see the value of the ICC entries in mplsNodeConfigTable and the use of > mplsNodeIccMapTable to generate a unique index to use in defining entries= in > the > various pre-existing tables. (But see my comment on the use of > mplsNodeConfigLocalNum in mplsTunnelExtEntry, below). I do not see the va= lue > of > the Global entries in mplsNodeConfigTable and the use of mplsNodeIpMapEnt= ry > since you say in the preamble to mplsTunnelExtEntry that Source-Tunnel_Nu= m > is > mapped with mplsTunnelIndex. Quite possibly there is descriptive text > missing. =20 <> mplsNodeConfigTable is the configuration table that is u= sed to configure Global-id/Node-id and/or ICC-id with the local map number. i.e. This table is used to configure the global-id/No= de-id and/or ICC-id for the given local map number. =20 The other two tables mplsNodeIpMapEntry and mplsNodeIccMapTable are just RE= AD-ONLY tables. These read only tables are meant for users who want to view the reverse map= ping of Global-id/Node-id=20 or ICC-id to the LocalNum. =20 > There seems to be some ambiguity about whether the objects in this docume= nt > refer to MPLS-TP or to extensions to MPLS-TE. it would be really nice to > sort > this out. =20 <> This document is created to address the requirements of = TE extensions for MPLS-TP and this will also be applicable for MPLS TE and hence the mib = modules are named generically. Since we are augmenting the TE mib, we named it as TE ex= tension. If many others prefer to name this as TP extension, we can change the names= accordingly. =20 =20 > mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm guessing > you > actually want a sparse augmentation since in a "mixed" environment you wi= ll > not > want to have all these objects present but unused. So you need to change = the > way > you define this. =20 <> Yes, we actually meant sparse augmentation. This mplsTun= nelExtEntry=20 will have entries only when required. For example, this table will have entries for the MPLS-TP tunnels, but not = for MPLS tunnels. Does it answer your question? Do you expect few more description to be added to this table? Also, do you foresee any issue of augmentation? Is it possible to explain t= he same? =20 > In mplsTunnelExtTable you do not state what DstTunnelNum is mapped with. > This is > key and could completely break your augmentation unless you get it right! =20 <> There are two ways to look at this problem. One way is t= o force the DstTunnelNum as key.=20 Other way is NOT to force it as key. Let us take an example to demonstrate = this. Let us say that we have a forward LSP with SrcTunnel_100, Instance_1, Sourc= e_R1, Destination_R5, DstTunnel_200. Option1: Force DstTunnelNum as key: If we mandate DstTunnelNum as key, then the following combination is theore= tically valid. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 LSP2: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300. = Even though the LSP2 is theoretically valid, it is not correct to have same indices for the forward LSP. i.e Treating th= e LSP2 as separate=20 independent LSP is not looking correct. Hence, the Option1 is dropped. =20 Option2: Do not force DstTunnelNum as key: This is the option that we choose. i.e User can configure DstTunnelNum as r= ead-write column,=20 but it is not part of indices to mplsTunnelTable. If we try to include that= as key, even the existing MPLS based mplsTunnelTable will have problems in interpre= tation.=20 Also, we do not see a real need to force that as index/key. According to th= is option, the LSP1 is a valid combination. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 If user wants to use a different reverse LSP, they can modify the DstTunnel= value as 300. But, it will still be called as LSP1. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300 (= modified). If required, we can discuss with mpls-tp-identifiers authors to confirm whe= ther this approach is fine. =20 =20 > For mplsTunnelExtEntry you have... > Source Global identifier/ICC and Destination > Global identifier/ICC are maintained in the > mplsNodeConfigTable and mplsNodeConfigLocalNum is used to > create an entry in mplsTunnelTable. > This is possibly too vague to be actually practical. =20 <> We created a word document to explain the various option= s that were considered before taking this option. We will share the same with you.=20 In principle, the idea is to reuse the mplsTunnelTable without disturbing i= ts existing meaning for MPLS based tunnels.=20 Even though we can think of alternate designs based on separate new table f= or MPLS_TP tunnels, we thought that reusing the existing table is a better option since MPLS_TP= is just an extension of existing MPLS. You can go through our document and provide your comments. =20 =20 > How will mplsTunnelExtDestTnlIndex actually be used? > - What value will it have for unidirecitonal tunnels? > (Or for bidriectional associated tunnels where the reverse > direction is not present on this LSR) =20 <> A zero value will be held by this (mplsTunnelExtDestTnlI= ndex) object when the unidirectional tunnel is desired. This object contains the source tunnel index value incase of co-routed bidirectional tunnel and for associated bidirectional tunnel this object contains the reverse direction tunnel index and reverse lsp index object will be added in the next version of this draft. =20 =20 > - Is this actually meant to be the object that gives us the > DstTunnelNum? If so, what has this to do with the reverse > direction? =20 <> Yes, this helps to associate the forward/reverse directi= on tunnels for associated bi-directional tunnel. For co-routed bidirectional case, SrcTunnelNum =3D DstTunnelNum and SrcTunnelLspNum =3D DstTunnelLspNum, this is because we use same tunnel entry with two different XC entries for both forward and reverse direction LSPs. =20 > It is completely unclear to me what mplsTunnelExtTnlApp is for! =20 <> This object provides the information on whether the tunn= el entry is MPLS tunnel or the MPLS-TP tunnel (tunnel application is either MPLS or MPLS-TP). =20 =20 > It certainly makes a nonsense of mplsTpTunnelsConfigured and > mplsTpTunnelsActive =20 <> This is to keep the tunnel count for MPLS-TP specific tu= nnels which are configured as mplsTp in mplsTunnelExtTnlApp object. If the object is not go= ing to be useful for users, this can be removed. =20 =20 >Cheers, >Adrian =20 =20 > -----Original Message----- > From: loa@pi.nu [mailto:loa@pi.nu] > Sent: 03 May 2011 18:48 > To: mpls@ietf.org > Cc: Adrian Farrel; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpl= s-tp- > te-mib@tools.ietf.org > Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-vkst-mpls-tp-te-mib-00.txt >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document > please respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. >=20 > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. >=20 > The poll ends 2011-05-18. >=20 > /Loa =20 =20 From gregory.mirsky@ericsson.com Mon Jun 6 10:49: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 4C2E621F8454; Mon, 6 Jun 2011 10:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_92=0.6, 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 tt1Fs6Mkhn+N; Mon, 6 Jun 2011 10:49:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8E211E81BF; Mon, 6 Jun 2011 10:49:40 -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 p56HnXhl000323; Mon, 6 Jun 2011 12:49:35 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 6 Jun 2011 13:49:33 -0400 From: Gregory Mirsky To: "erminio.ottone_69@libero.it" , "mach.chen@huawei.com" , "Malcolm.BETTS@zte.com.cn" Date: Mon, 6 Jun 2011 13:49:26 -0400 Thread-Topic: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwjmFQdYoCYeI+uRTebUSI+4q806gA2L6wg Message-ID: References: <19746722.1230251307289020806.JavaMail.defaultUser@defaultHost> In-Reply-To: <19746722.1230251307289020806.JavaMail.defaultUser@defaultHost> 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 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP 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: Mon, 06 Jun 2011 17:49:45 -0000 Dear Erminio, Please find my comments in-line tagged by GIM>>. Regards, Greg=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erm= inio.ottone_69@libero.it Sent: Sunday, June 05, 2011 8:50 AM To: mach.chen@huawei.com; Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? Mach, let me try to explain the point/issue with an example. I have my own domain and I name nodes (or tunnel endpoints if you prefer) u= sing numbers (i.e., 1, 2, 3, 4, ...). Within my domain I can setup any p2p = connection between any paer of numbers (1 to 2; 3 to 4 and so on). You have your own domain and you name nodes (or tunnel endpoints) using lat= in letters (i.e., A, B, C, ...). Within your domain you can setup any p2p c= onnection betwen any pair of letters (A to B; C to D and so on). Now there is a need to setup a connection betwee my node 5 and your node E.= =20 What can we do? We can setup a conection 5 to E (i.e., supporting mixed ide= ntifiers on the connection) or mandate one of us to assign two names to the= same node? Would you be happy to assign two names to all your nodes (one following num= eric convention and one following latin letters? GIM>> If both or any of addressing schemes uses locally unique addressing s= cheme then re-numbering or secondary addressing will be required. Woud you be happy to re-number all your nodes with a third convention when = you need to be connected with another operator that is adopting a third nam= ing convention? If we mix identifiers, what you need is just to provision the peer MEP-ID i= nformation as an unstructure bit string (note that while E has a meaning fo= r you, 5 does not have any meanign for you). Note that in any case you must be able to identify a misconnection between = different identifiers scheme. For example, if the traffic coming from my no= de 2 leaks out into the 5-E connection, you will receive a source MEP-ID eq= ual to 2 in the CV packets. GIM>> The MPLS-TP dataplane will be able to identify the fact of misconnect= ion defect but I don't see it is required to identify the source of misconn= etion, i.e. interpret source MEP-ID being leaked into the monitored connect= ion. I believe that such interpretation is function of not the dataplane bu= t NMS or control plane. >----Messaggio originale---- >Da: mach.chen@huawei.com >Data: 24-mag-2011 10.28 >A: "Malcolm.BETTS@zte.com.cn" >Cc: "mpls-bounces@ietf.org", "mpls@ietf.org" >Ogg: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Hi Malcolm, > >Thanks for your response! > >Firstly, I have to claim that I do not object mixed identifier if there=20 >are cases really need it.=20 > >From the discussion on this thread, it's very clear that mixed=20 >identifiers at least require control plane and management plane has to understand and supp= ort the semantic of both ICC and Global_ID based identifiers. This means th= at the operators have to operate both ICC and Global_ID based identifiers w= hen do mixed identifiers. If the purpose of mixed identifiers is to help on= e operator (e.g., only prefers to ICC style) to avoid operating/maintaining= unfamiliar identifier scheme (e.g., Global_ID) when do inter-domain connec= tion, obviously, it cannot work. On the contrary, as many other guys on the= list pointed out, if the same format identifier is used for a specific pat= h, the domain one end hosting can really only need to support and administe= r one type of identifier.=20 > >Best regards, >Mach > >> From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] >> Sent: Tuesday, May 24, 2011 1:33 PM >> To: Mach Chen >> Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org >> Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >> Hi Mach, >>=20 >> Please see in line below. >>=20 >> Mach Chen wrote on 23/05/2011 10:15:32 PM: >>=20 >> > Hi Malcolm, >> > >> > Thanks for your prompt response! >> > >> > Please see my reply inline... >> > >> > > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] >> > > Sent: Tuesday, May 24, 2011 8:42 AM >> > > To: Mach Chen >> > > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org >> > > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> > > >> > > Hi Mach, >> > > >> > > Please see in line below - marked by [MB2] >> > > >> > > Regards, >> > > >> > > Malcolm >> > > >> > > Mach Chen >> > > 22/05/2011 11:34 PM >> > > To >> > > "Malcolm.BETTS@zte.com.cn" ,=20 >> > > "adrian@olddog.co.uk" cc=20 >> > > "mpls-bounces@ietf.org" , "mpls@ietf.org" >> > > >> > > Subject >> > > RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> > > >> > > Hi Malcolm, >> > > >> > > See my response inline. >> > > >> > > Ermino, >> > > >> > > We have already been round this loop on this list once. >> > > Want to do it again? >> > > >> > > [MB] well the continuation of this thread indicates that the loop >> > is still open.... >> > > >> > > As Huub said, this is about identifiers, not OAM. However, the=20 >> > > model for >> OAM >> > > interworking shows "layering" not gatewaying, and certainly not mixing. >> That >> > > is, >> > > one end of the e2e path must be capable of operating both=20 >> > > systems, but the >> > > other >> > > does not need to. >> > > >> > > [MB] OK >> > > >> > > To extend this model to identifiers means that one end of the e2e=20 >> > > path must >> > > support both identifier formats and the other does not need to. >> > > >> > > [MB] It requires that one of the operators must administer both=20 >> > > types of >> > > identifiers. >> > > [Mach] If mixed identifiers used, seems that all relevant domains >> > (other than >> > > only one domain) of the path must administer both types of identifiers, >> > >> > > [MB2] Why? >> > >> > If it's static provisioning, the operators need to configure(by CLI=20 >> > or NMS) the identifiers(include both ICC and Global_ID) on the=20 >> > related nodes. >> > If there is control plane, the control plane has to communicate the=20 >> > identifiers, and all the nodes along the LSP need to know the type=20 >> > firstly and hence to interpret and process it >>=20 >> [MB] No need for the nodes to understand the semantics, it may be convenient >> to have an OSS or GUI application that does understand the semantics=20 >> to assist >> in provisioning the expected value. =A0The control plane should be able= =20 >> to carry >> an opaque type. =A0I would expect that when the encoding of these=20 >> identifiers is >> defined it will include a "type" flag so that the node knows the=20 >> length of the >> identifier field. >>=20 >> > >> > >As I have explained several times on this thread a node that =20 >> > >receives an OAM message only needs to check that it is from the expected >> > > entity, no need to understand or administer the format. >> > >> > How could a node do that if it does not know the type of the identifie= r? >>=20 >> [MB] Just match the bit string...... >>=20 >> > >> > > =A0and the operators(only prefer to ICC based Opr_ID) have to=20 >> > > support and >> > > configure both ICC and Global_ID style identifier. On the >> > contrary, for a specific >> > > LSP or PW, if only one type of identifiers is used, the operators >> > (only prefer to >> > > ICC based Opr_ID) can really only need to support and administer >> > only one type >> > > of identifiers (ICC) if they get the agreement of using ICC type >> > of identifier with >> > > other operators. >> > > =A0This causes two problems a) A (potentially) new operational=20 >> > > process must >> be >> > > invoked to assign the second identifier type and; b) Given that a=20 >> > > node will >> > > terminate/originate traffic from/to the local network and a third >> > party network >> > > that node will have (different) identifiers, this will cause >> > significant issues when >> > > attempting to perform normal operational processes e.g. alarm reporting. >> > > >> > > This becomes particularly important to the transit nodes that may=20 >> > > have to >> > > inspect the identifiers. >> > > >> > > [MB] Why? only the entity inserting the identifier needs to=20 >> > > understand the >> > > semantics, all other nodes only need to check if the (bit string) presented >> > > matches the expected string. >> > > [Mach] Here is an example that the transit nodes may require to >> > "inspect" the >> > > identifiers: MPLS-TP control plane. Because Opr_ID is part of the >> > identifier of an >> > > LSP, PW and Section, the control plane has to communicate the=20 >> > > Opr_IDs of >> the >> > > LSP, PW or Section among the relevant nodes when signal the LSP,=20 >> > > PW or Section. >> > > [MB2] =A0As defined in the architecture the data plane and control=20 >> > > plane >> must >> > > be independent, including the identifiers that they use. >> > >> > But, MPLS-TP identifiers should be not exclusive to data plane or=20 >> > control plane or management plane, and actually they are related to=20 >> > all the three planes. >>=20 >> [MB] =A0The identifiers in all three planes are related but the values=20 >> and type >> must be independent. >> > >> > Best regards, >> > Mach >> > > >> > > BTW, we just submitted two drafts that define extensions to=20 >> > > RSVP-TE and >> PW >> > > protocol for communicating Opr_ID when setup an LSP or PW. >> > > http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 >> > > http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 >> > > >_______________________________________________ >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 msiva@cisco.com Mon Jun 6 11:35:32 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 D6BE011E816A for ; Mon, 6 Jun 2011 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 x-zsExC0QZit for ; Mon, 6 Jun 2011 11:35:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id E919A11E815E for ; Mon, 6 Jun 2011 11:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=msiva@cisco.com; l=1372; q=dns/txt; s=iport; t=1307385332; x=1308594932; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zi3UknSgfWSrPiZq66t3Zj70XnQ3yiIPz8Y0azc3Z+o=; b=Yv38SBp3M56CSFgzMmaHB4U7F5YxwylaRrMr3JQuRsQDleoCh/kVAawH dE5lM+V584GOPz/S+mmOTf3/DtzpCgYmB6bJ9jHPcY5yXwaEtMp0dATmH fzLexmW97RnW6R3Pcd6n/LbUup+qPbkoNJ87vLfEdCYy/J6s7MpeZiW/3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBADYd7U2tJV2c/2dsb2JhbABTl0SOYnerXZ16AoYfBIZ0jlaLBw X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208";a="235431240" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 06 Jun 2011 18:35:31 +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 p56IZVde017781; Mon, 6 Jun 2011 18:35:31 GMT Received: from xmb-rcd-104.cisco.com ([72.163.62.146]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 13:35:30 -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: Mon, 6 Jun 2011 13:35:28 -0500 Message-ID: <45FC0B0A070BF345870B2710BADC670A06718022@XMB-RCD-104.cisco.com> In-Reply-To: <4DE795A3.5050106@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 thread-index: AcwhLGkCbUnPcrkfTxKRVO+FR5yl6ADTBI8A References: <4DE795A3.5050106@pi.nu> From: "Siva Sivabalan (msiva)" To: "Loa Andersson" , X-OriginalArrivalTime: 06 Jun 2011 18:35:30.0515 (UTC) FILETIME=[8357DA30:01CC2478] Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 06 Jun 2011 18:35:33 -0000 Yes/support. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, June 02, 2011 9:53 AM To: mpls@ietf.org Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 Working Group, this is to start a two week poll on making draft-raza-mpls-ldp-ip-pw-capability-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends 2011-06-16. /Loa --=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 gash5107@yahoo.com Mon Jun 6 12:14: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 4C26011E816B for ; Mon, 6 Jun 2011 12:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 aSH2jFV+fx4s for ; Mon, 6 Jun 2011 12:14:52 -0700 (PDT) Received: from nm30-vm3.bullet.mail.ne1.yahoo.com (nm30-vm3.bullet.mail.ne1.yahoo.com [98.138.91.160]) by ietfa.amsl.com (Postfix) with SMTP id 03C5B11E8179 for ; Mon, 6 Jun 2011 12:14:51 -0700 (PDT) Received: from [98.138.90.53] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2011 19:14:49 -0000 Received: from [98.138.89.199] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2011 19:14:48 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 06 Jun 2011 19:14:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 535713.21191.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 86878 invoked by uid 60001); 6 Jun 2011 19:14:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307387679; bh=CAdWvDJogHkcLqRFeuKn3UxFfLAQ6FvjebZjhSU6/DE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r92JVlsopCD81BS/W+nSkk1WnJhjHbX76AEBLcLESWutQv3n1Jwaws7vnqcM/2YXC+wdtkmp7SqG+vIb76CxpHVypzLlNVQ9PZSckQTafJrVFVIwSbcT1kfLW4VU9BWQKp1A8avJAYWqVmL9GPuQI8sWMLVuo2z8RLdPSSW59fY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wnb29YzZUzK1olWUavmfYFL2/Eg/ubk+Ux9mtrB1gomQgGQIG4ApQA6hwNM9xz9DiFC5fMVsidUFqNOjfVjvXD6VnLMTgYhro4oTb9YY2tQjDz9zRElsXSk5bglLJEGm8Btw3a6hK5PFKMNgnlqFKpjNLezGD+DhUflgJPx1dkU=; Message-ID: <435578.85269.qm@web125906.mail.ne1.yahoo.com> X-YMail-OSG: t.aATosVM1kJRNhNjxCd35DbrLOuY.FPHYCWWPcCAjaeZ2V oucO.rLDi.nMOC9qeeem77EXzjCgx2lGhQXmxYTnXjYt4Pxi0OmX.2RKex9M k8s9qJdaVV9CL9.pLutHIxLVyPkggtMysNgSHl18UN2YKWTLQwSq0rm.D3ro se23C6QgdkN1lX7obJB9fx5yo7BodJo59neYt9Fs9enl06NAtx3ZTRxGKsMS 0j.EtkRNDA_Ndu61LpUUU0uWsvxjxGsCMAlp3IrqHCd0NZaGMw2rhG9XMZp6 lCqa_4UreAHTp5daGy85yGvX6O1zUG6cmpkDiyEzsf.DUaJMXgLJhKnQtx27 G4RLGZgdtCNX86A_HxJOz0e8kLJrPlEBau10_vQmJFH2fQEj1 Received: from [71.233.102.170] by web125906.mail.ne1.yahoo.com via HTTP; Mon, 06 Jun 2011 12:14:39 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Mon, 6 Jun 2011 12:14:39 -0700 (PDT) From: Gerald Ash To: MarlaAzinger In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1049E24E45BC@ROCH-EXCH1.corp.pvt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1924068722-1307387679=:85269" Cc: "mpls@ietf.org" , "rtgwg@ietf.org" Subject: Re: [mpls] Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks 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, 06 Jun 2011 19:14:53 -0000 --0-1924068722-1307387679=:85269 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marla, =A0 Thanks for your email.=A0 Please see responses below. Regards, Jerry >=20 >=20 > --- On Wed, 6/1/11, Azinger, Marla wrote: >=20 >=20 >=A0 From: Azinger, Marla >=A0 Subject: RE: Generic Connection Admission Control (GCAC) Algorithm=20 > Specification for IP/MPLS Networks >=A0 To: "Gerald Ash" , "rtgwg@ietf.org" >=A0 Cc: "mpls@ietf.org" >=A0 Date: Wednesday, June 1, 2011, 11:38 AM >=20 >=20 >=A0 Jerry- >=20 >=A0 Did you get a response from anyone on this yet? =A0 I got one off-line comment=20 "this work looks good to me and seems somewhat over due..." =A0 Given all the experts on this topic in the MPLS WG & RTGWG, it's a bit surp= rising=A0there hasn't been more response.=A0 Not that long ago this topic w= ould probably have generated strong reaction. >=20 >=A0 Cheers >=A0 Marla >=20 >=20 >=20 > -------------------------------------------------------------------------= ----- >=A0 From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf= Of=20 > Gerald Ash >=A0 Sent: Thursday, May 26, 2011 9:51 AM >=A0 To: rtgwg@ietf.org >=A0 Cc: mpls@ietf.org >=A0 Subject: Generic Connection Admission Control (GCAC) Algorithm=20 > Specification for IP/MPLS Networks >=20 >=20 >=A0=A0=A0=A0=A0=A0=A0 Hi, >=20 >=A0=A0=A0=A0=A0=A0=A0 Adrian has suggested that the RTGWG and the MPLS WG = review the draft=20 > "Generic Connection Admission Control (GCAC) Algorithm Specification for= =20 > IP/MPLS Networks", available at=20 > http://www.ietf.org/id/draft-ash-gcac-algorithm-spec-00.txt (abstract=20 > below). >=20 >=A0=A0=A0=A0=A0=A0=A0 The underlying goal of the work is to specify an opt= ional GCAC=20 > algorithm for IP/MPLS networks, to be adopted and implemented by vendors = and=20 > service providers, that interoperates between vendor equipment and across= =20 > multiple service provider domains.=A0 This would be analogous to the PNNI= GCAC=20 > that was widely adopted and helped promote interoperability of ATM networ= ks.=20 > In addition, the approach: >=A0=A0=A0=A0=A0=A0=A0 o is based on CSPF, widely implemented by vendors >=A0=A0=A0=A0=A0=A0=A0 o does NOT include aspects of CAC that might be cons= idered vendor=20 > proprietary implementations, such as detailed path selection mechanisms >=A0=A0=A0=A0=A0=A0=A0 o relies on available standard mechanisms for MPLS b= ased networks,=20 > such as RSVP, DSTE, PCE... >=20 >=A0=A0=A0=A0=A0=A0=A0 Comments appreciated. >=20 >=A0=A0=A0=A0=A0=A0=A0 Thanks, >=A0=A0=A0=A0=A0=A0=A0 Jerry >=20 >=A0=A0=A0=A0=A0=A0=A0 From: Internet-Drafts@ietf.org >=A0=A0=A0=A0=A0=A0=A0 To: i-d-announce@ietf.org >=A0=A0=A0=A0=A0=A0=A0 Reply-to: Internet-Drafts@ietf.org >=A0=A0=A0=A0=A0=A0=A0 Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00= .txt >=A0=A0=A0=A0=A0=A0=A0 X-RSN: 1/0/935/34473/37870 >=20 >=A0=A0=A0=A0=A0=A0=A0 A New Internet-Draft is available from the on-line I= nternet-Drafts >=A0=A0=A0=A0=A0=A0=A0 directories. >=20 >=A0=A0=A0=A0=A0=A0=A0 Title : Generic Connection Admission Control (GCAC) = Algorithm=20 > Specification for IP/MPLS Networks >=A0=A0=A0=A0=A0=A0=A0 Author(s) : G. Ash, D. McDysan >=A0=A0=A0=A0=A0=A0=A0 Filename : draft-ash-gcac-algorithm-spec-00.txt >=A0=A0=A0=A0=A0=A0=A0 Pages : 23 >=A0=A0=A0=A0=A0=A0=A0 Date : 2011-1-11 >=20 >=A0=A0=A0=A0=A0=A0=A0 This document presents a generic connection admissio= n control (GCAC) >=A0=A0=A0=A0=A0=A0=A0 reference model and algorithm for IP/MPLS-based netw= orks. Service >=A0=A0=A0=A0=A0=A0=A0 provider (SP) IP/MPLS networks need an MPLS GCAC mec= hanism, for >=A0=A0=A0=A0=A0=A0=A0 example, to reject voice over Internet Protocol (VoI= P) calls when >=A0=A0=A0=A0=A0=A0=A0 additional calls would adversely affect calls alread= y in progress. >=20 >=A0=A0=A0=A0=A0=A0=A0 Without MPLS GCAC, connections on congested links wi= ll suffer >=A0=A0=A0=A0=A0=A0=A0 degraded quality. The MPLS GCAC algorithm can be opt= ionally >=A0=A0=A0=A0=A0=A0=A0 implemented in vendor equipment and deployed by serv= ice providers. >=A0=A0=A0=A0=A0=A0=A0 MPLS GCAC interoperates between vendor equipment and= across multiple >=A0=A0=A0=A0=A0=A0=A0 service provider domains. The MPLS GCAC algorithm us= es available >=A0=A0=A0=A0=A0=A0=A0 standard mechanisms for MPLS based networks, such as= RSVP, DSTE,=20 > PCE, >=A0=A0=A0=A0=A0=A0=A0 NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm do= es not include >=A0=A0=A0=A0=A0=A0=A0 aspects of CAC that might be considered vendor propr= ietary >=A0=A0=A0=A0=A0=A0=A0 implementations, such as detailed path selection mec= hanisms. MPLS >=A0=A0=A0=A0=A0=A0=A0 GCAC functions are implemented in a distributed mann= er to deliver=20 > the >=A0=A0=A0=A0=A0=A0=A0 objective QoS for specified QoS constraints. The sou= rce is able to >=A0=A0=A0=A0=A0=A0=A0 compute a source route with high likelihood that MPL= S GCAC via >=A0=A0=A0=A0=A0=A0=A0 elements along the selected path will in fact admit = the request. >=A0=A0=A0=A0=A0=A0=A0 MPLS GCAC is applicable to any service or flow that = must meet an >=A0=A0=A0=A0=A0=A0=A0 objective QoS (delay, jitter, packet loss rate) for = a specified >=A0=A0=A0=A0=A0=A0=A0 quantity of traffic. >=20 >=A0=A0=A0=A0=A0=A0=A0 A URL for this Internet-Draft is: >=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-drafts/draft-ash-gcac-a= lgorithm-spec-00.txt >=20 >=A0=A0=A0=A0=A0=A0=A0 Internet-Drafts are also available by anonymous FTP = at: >=A0=A0=A0=A0=A0=A0=A0 ftp://ftp.ietf.org/internet-drafts/ >=20 >=A0=A0=A0=A0=A0=A0=A0 Below is the data which will enable a MIME compliant= mail reader >=A0=A0=A0=A0=A0=A0=A0 implementation to automatically retrieve the ASCII v= ersion of the >=A0=A0=A0=A0=A0=A0=A0 Internet-Draft. >=A0=A0=A0=A0=A0=A0=A0 _______________________________________________ >=A0=A0=A0=A0=A0=A0=A0 I-D-Announce mailing list >=A0=A0=A0=A0=A0=A0=A0 I-D-Announce@ietf.org >=A0=A0=A0=A0=A0=A0=A0 https://www.ietf.org/mailman/listinfo/i-d-announce >=A0=A0=A0=A0=A0=A0=A0 Internet-Draft directories: http://www.ietf.org/shad= ow.html >=A0=A0=A0=A0=A0=A0=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=A0=A0=A0=A0=A0=A0=A0 ***** >=A0=A0=A0=A0=A0=A0=A0 Click below to download the attachment(s) in this me= ssage: >=A0=A0=A0=A0=A0=A0=A0 HREF=3D"http://www.ietf.org/ibin/c5i?mid=3D6&gid=3D0&rid=3D8&k1=3D935&fil= e=3Di-d-announce.37870.1.txt">Attachment:=20 > draft_ash_gcac_algorithm_spec_00.txt (1K) >=20 > --0-1924068722-1307387679=:85269 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marla,
 
Thanks for your email.  Please see responses below.
Regards,
Jerry

>
>
> --- On Wed, 6/1/11, Azinger, Marla <Marla.Azinger@FTR.com> wrote:
> >
>  From: Azinger, Marla <Marla.Azinger@FTR.com>
>  Subject: RE: Generic Connec= tion Admission Control (GCAC) Algorithm
> Specification for IP/MPLS = Networks
>  To: "Gerald Ash" <ga= sh5107@yahoo.com>, "rtgwg@ietf.org" <= ;rtgwg@ietf.org>
>  Cc: "mpls@ietf.org" <mpls@i= etf.org>
>  Date: Wednesday, June 1, 2011, 11:38 AM
&g= t;
>
>  Jerry-
>
>  Did you get a resp= onse from anyone on this yet?
 
I got one off-line comment
"this work looks good to me and seems somewhat over due..."
 
Given all the experts on this topic in the MPLS WG & RTGWG, it's a= bit surprising there hasn't been more response.  Not that long a= go this topic would probably have generated strong reaction.

>
>  Cheers
>  Marla
>
> >
> -----------------------------------------------------------= -------------------
>  From: rt= gwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of
&= gt; Gerald Ash
>  Sent: Thursday, May 26, 2011 9:51 AM
>&n= bsp; To: rtgwg@ietf.org
>  Cc: mpls@ietf.org
>  Subject: Generic Connec= tion Admission Control (GCAC) Algorithm
> Specification for IP/MPLS = Networks
>
>
>       = ; Hi,
>
>        Adrian has suggested that the RTGWG and the MPLS WG review the draft
> "Ge= neric Connection Admission Control (GCAC) Algorithm Specification for
&= gt; IP/MPLS Networks", available at
> http://www.ietf.org/id/draft-ash-gcac-algo= rithm-spec-00.txt (abstract
> below).
>
> &nbs= p;      The underlying goal of the work is to spec= ify an optional GCAC
> algorithm for IP/MPLS networks, to be adopted= and implemented by vendors and
> service providers, that interopera= tes between vendor equipment and across
> multiple service provider = domains.  This would be analogous to the PNNI GCAC
> that was w= idely adopted and helped promote interoperability of ATM networks.
>= In addition, the approach:
>        o is based on = CSPF, widely implemented by vendors
>     &n= bsp;  o does NOT include aspects of CAC that might be considered vendo= r
> proprietary implementations, such as detailed path selection mec= hanisms
>        o relies on avail= able standard mechanisms for MPLS based networks,
> such as RSVP, DS= TE, PCE...
>
>        Comme= nts appreciated.
>
>       = Thanks,
>        Jerry
> >        From: Internet-Drafts@ietf.org
>    =     To: i-d-announce@ietf.org
>  =       Reply-to: Internet-Drafts@ietf.org
>      &n= bsp; Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt
> =        X-RSN: 1/0/935/34473/37870
> >        A New Internet-Draft is ava= ilable from the on-line Internet-Drafts
>    &nbs= p;   directories.
>
>     &= nbsp;  Title : Generic Connection Admission Control (GCAC) Algorithm <= BR>> Specification for IP/MPLS Networks
>    &= nbsp;   Author(s) : G. Ash, D. McDysan
>        Filename : draft= -ash-gcac-algorithm-spec-00.txt
>      =   Pages : 23
>        Date : = 2011-1-11
>
>        This d= ocument presents a generic connection admission control (GCAC)
> = ;       reference model and algorithm for IP/= MPLS-based networks. Service
>      &nb= sp; provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for
>=         example, to reject voice over In= ternet Protocol (VoIP) calls when
>     &nbs= p;  additional calls would adversely affect calls already in progress.=
>
>        Without MPLS GC= AC, connections on congested links will suffer
>        degraded quality.= The MPLS GCAC algorithm can be optionally
>    &= nbsp;   implemented in vendor equipment and deployed by service p= roviders.
>        MPLS GCAC inter= operates between vendor equipment and across multiple
>  &n= bsp;     service provider domains. The MPLS GCAC algori= thm uses available
>        standa= rd mechanisms for MPLS based networks, such as RSVP, DSTE,
> PCE,>        NSIS, DiffServ, and OSPF. T= he MPLS GCAC algorithm does not include
>    &nbs= p;   aspects of CAC that might be considered vendor proprietary>        implementations, such as d= etailed path selection mechanisms. MPLS
>        GCAC functions are = implemented in a distributed manner to deliver
> the
> &n= bsp;      objective QoS for specified QoS constrai= nts. The source is able to
>       = ; compute a source route with high likelihood that MPLS GCAC via
>&nb= sp;       elements along the selected path wi= ll in fact admit the request.
>      &n= bsp; MPLS GCAC is applicable to any service or flow that must meet an
&g= t;        objective QoS (delay, jitter, = packet loss rate) for a specified
>     &nbs= p;  quantity of traffic.
>
>     = ;   A URL for this Internet-Draft is:
>   &n= bsp;    h= ttp://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt=
>
>        Internet-Drafts= are also available by anonymous FTP at:
>    &nb= sp;   ftp://ftp.ietf.org/i= nternet-drafts/
>
>      &nb= sp; Below is the data which will enable a MIME compliant mail reader
>= ;        implementation to automatically= retrieve the ASCII version of the
>     &nb= sp;  Internet-Draft.
>        _______________________________________________
>   &= nbsp;    I-D-Announce mailing list
>   =      I-D-Announce@ietf.= org
>        https://www.ietf.org/mailman/listinfo/= i-d-announce
>        Internet= -Draft directories: http://www.ietf.org/= shadow.html
>        or ftp://ftp.ietf.org/ietf/1shadow-= sites.txt
>
>        **= ***
>        Click below to downlo= ad the attachment(s) in this message:
>     =    <A
> HREF=3D"A= ttachment'>http://www.ietf.org/ibin/c5i?mid=3D6&gid=3D0&rid=3D8&= ;k1=3D935&file=3Di-d-announce.37870.1.txt">Attachment:
> = draft_ash_gcac_algorithm_spec_00.txt</A> (1K)
>
>
<= /td>
--0-1924068722-1307387679=:85269-- From sboutros@cisco.com Mon Jun 6 22:15: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 D6EE821F85AB for ; Mon, 6 Jun 2011 22:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gmG7GQoIc6Ng for ; Mon, 6 Jun 2011 22:15:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E77A121F85AA for ; Mon, 6 Jun 2011 22:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=6060; q=dns/txt; s=iport; t=1307423756; x=1308633356; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=JEC7z8dMHvORlwEuMWu9n1lljKnlka3JkBhfqqUQU9A=; b=SZabgewg+5rOn54+TS11Xk4LE7UUU+UlDemRH+6hp0TdGbQYcaZMf0OP 5g85OXlNBrlH3TvYF9vcKI4x1FwqTQbGKBkByefwo1kk7woJpyJKnW/dY q/x+Zb/plY0UCQc1Hsf+oxwpzdigf50+LsS3OBpEX+hDjdqx4nvxtqqiR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAISy7U2tJXG9/2dsb2JhbABHDIddnjt3qxKeDoMagwcEhniOZ4sQ X-IronPort-AV: E=Sophos;i="4.65,330,1304294400"; d="scan'208,217";a="460869077" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2011 05:15:55 +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 p575FtZp027042; Tue, 7 Jun 2011 05:15:55 GMT Received: from xfe-rcd-202.cisco.com ([72.163.62.205]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 00:15:55 -0500 Received: from sboutros-wxp02.ciswco.com ([10.82.242.13]) by xfe-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 00:15:54 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Jun 2011 22:15:41 -0700 To: Greg Mirsky , "Siva Sivabalan(msiva)" , Rahul Aggarwal , martin.vigoureux@alcatel-lucent.com, dai.xuehui@zte.com.cn, swallow@cisco.com, David Ward , stbryant@cisco.com, cpignata@cisco.com, "Bitar, Nabil N" , BUSI ITALO , "LEVRAU, LIEVEN (LIEVEN)" , laurent.ciavaglia@alcatel-lucent.com, wu.bo@zte.com.cn, yang_jian@zte.com.cn, mpls@ietf.org From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_390022765==.ALT" Message-ID: X-OriginalArrivalTime: 07 Jun 2011 05:15:54.0937 (UTC) FILETIME=[FA155A90:01CC24D1] Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 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, 07 Jun 2011 05:15:58 -0000 --=====================_390022765==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Greg, Here are responses to your comments please let us know if you are OK with the Responses. > * section 3.2 I think that there are mandatory TLVs for LI-LB > and optional. Mandatory TLV for LI might be Source MEP-ID, > Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. > Optional, e.g. Authentication TLV. Response-1: Correct. > * section 3.3.5 describes Return Code in Return TLV for LSP-ping > option of LI-LB signaling. For in-band option Return Code has > different values and values listed in this section are for field > Cause Code. I think it would be beneficial to have some uniformity > across LI-LB signalling options and in Return TLV have both Return > Code and Cause Code fields with values identical for in-band and > LSP-Ping options. Response-2: Addressed in latest version -02 where we made this section shared by both in-Band and LSP-Ping, we as well limited the # of TLVs used by LSP Ping. > * section 3.3.6 defines Authentication TLV for LSP-Ping option. > Authentication of LB request but in-band option doesn't have > provision to indicate that Authentication is in use. I propose to > allocate MSB of Reserved field as Authentication flag. Response-3: Addressed in latest version -02 by making authentication TLV common to both in-band and LSP Ping. > * section 6.3 mentions that Authentication may be used both in > Lock request and Lock response. I think that if Authentication was > present in Lock request and accepted by remote MEP, then Lock > response must have Authentication. Similar is applicable to use of > Authentication in Unlock request/response, and Setting/Removing LB . Response-4: We described authentication procedures in more details in section 3.5 of latest draft version, please have a look to see if it addresses your concern. > * section 6.5.b I think that there's no guarantee that sender of > LI request will not generate false positive after remote MEP locks > the LSP. Perhaps, if proactive OAM is enabled, the remote MEP > should send LI reply but it might stop sending OAM messages after > 3*TxPeriod interval. Response-5: Addressed in section 6.3 last paragraph MEP-D will lock the LSP, resulting in that all traffic from D to A, including all OAM traffic, stops. a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc packets, but since it has been informed that the LSP will be locked it will take no action(s). b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM traffic, e.g. cv and cc packets. MEP-D will detect this, but since it is in Locked state it will take no action. Thanks, Sami --=====================_390022765==.ALT Content-Type: text/html; charset="us-ascii" Hi Greg,

Here are responses to your comments please let us know if you are OK with the Responses.

  • section 3.2 I think that there are mandatory TLVs for LI-LB and optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication TLV.

Response-1: Correct.

  • section 3.3.5 describes Return Code in Return TLV for LSP-ping option of LI-LB signaling. For in-band option Return Code has different values and values listed in this section are for field Cause Code. I think it would be beneficial to have some uniformity across LI-LB signalling options and in Return TLV have both Return Code and Cause Code fields with values identical for in-band and LSP-Ping options.

Response-2: Addressed in latest version -02 where we made this section shared by both in-Band and LSP-Ping, we as well limited the # of TLVs used by LSP Ping.

  • section 3.3.6 defines Authentication TLV for LSP-Ping option. Authentication of LB request but in-band option doesn't have provision to indicate that Authentication is in use. I propose to allocate MSB of Reserved field as Authentication flag.

Response-3: Addressed in latest version -02 by making authentication TLV common to both in-band and LSP Ping.

  • section 6.3 mentions that Authentication may be used both in Lock request and Lock response. I think that if Authentication was present in Lock request and accepted by remote MEP, then Lock response must have Authentication. Similar is applicable to use of Authentication in Unlock request/response, and Setting/Removing LB .

Response-4: We described authentication procedures in more details in section 3.5 of latest draft version, please have a look to see if it addresses your concern.

  • section 6.5.b I think that there's no guarantee that sender of LI request will not generate false positive after remote MEP locks the LSP. Perhaps, if proactive OAM is enabled, the remote MEP should send LI reply but it might stop sending OAM messages after 3*TxPeriod interval.

Response-5:  Addressed in section 6.3 last paragraph

MEP-D will lock the LSP, resulting in that all traffic from D to A, including all OAM traffic, stops.

a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc packets, but since it has been informed that the LSP will be locked it will take no action(s).
b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM traffic, e.g. cv and cc packets. MEP-D will detect this, but since it is in Locked state it will take no action.

Thanks,

Sami
--=====================_390022765==.ALT-- From zhang.fei3@zte.com.cn Tue Jun 7 02:37: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 690E921F848B for ; Tue, 7 Jun 2011 02:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9Bh1Fwp0Ra4 for ; Tue, 7 Jun 2011 02:37:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C7BF421F8485 for ; Tue, 7 Jun 2011 02:37:01 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 4864806486374; Tue, 7 Jun 2011 17:36:50 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 42106.2553852301; Tue, 7 Jun 2011 17:28:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p579RxOP045122; Tue, 7 Jun 2011 17:27:59 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Ping Pan , ppan@infinera.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 7 Jun 2011 17:27:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-07 17:28:02, Serialize complete at 2011-06-07 17:28:02 Content-Type: multipart/alternative; boundary="=_alternative 0033FBA6482578A8_=" X-MAIL: mse02.zte.com.cn p579RxOP045122 Cc: mpls@ietf.org Subject: Re: [mpls] I-D ACTION:draft-pan-shared-mesh-protection-01.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, 07 Jun 2011 09:37:03 -0000 This is a multipart message in MIME format. --=_alternative 0033FBA6482578A8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGluZw0KDQpJIGp1c3QgcmVhZCB0aGUgZHJhZnQsIHNvbWUgY29uZnVzaW9ucyBsaXN0ZWQg YmVsb3c6DQoNCjEpWW91IGdpdmUgdGhlIGRlZmluaXRvbiBvZiB3YXJtIHN0YW5keSwgc2VlIGJl bG93Og0KDQogICAgICAgIFdhcm0gU3RhbmRieTogVGhlIG5vZGVzIHdpbGwgbmVnb3RpYXRlIGFu ZCByZXNlcnZlIHByb3RlY3RpbmcgcGF0aCANCg0KICAgICAgICBwcmlvciB0byBuZXR3b3JrIGZh aWx1cmUuIEhvd2V2ZXIsIGRhdGEgZm9yd2FyZGluZyBwYXRoIHdpbGwgbm90IA0KYmUgDQogICAg ICAgIHByb2dyYW1tZWQuIFVwb24gdGhlIGRldGVjdGlvbiBvZiBuZXR3b3JrIGZhaWx1cmUsIHRo ZSBub2RlcyB3aWxsIA0KICAgICAgICBzZW5kIGV4cGxpY2l0IG1lc3NhZ2VzIHRvIHJlbGV2YW50 IG5vZGVzIHRvICJ3YWtlIHVwIiB0aGUgDQpwcm90ZWN0aW5nIA0KICAgICAgICBwYXRoLiANCg0K U2luY2UgdGhlIGRhdGEgZm9yd2FyZGluZyBwYXRoIGlzIG5vdCBwcm9ncmFtbWVkLCB3aGljaCBt ZWFucyB0aGF0IHRoZSANCmRhdGEgdHJhZmZpYyBhbmQgT0FNIHRyYWZmaWMgY2FuIG5vdCBiZSB0 cmFucG9ydGVkIGJlZm9yZSB0aGUgYWN0aXZhdGlvbj8NCkJ1dCBhY2NvcmRpbmcgdG8gdGhlIGRl c2NyaWJ0aW9uIG9mIHNlY3Rpb24gNy4yDQoNCiAgICAgICAgQXMgYSBwYXJ0IG9mIHRoZSBjbGVh bi11cCBwcm9jZWR1cmUsIGVhY2ggRElTQUJMRSBtZXNzYWdlIG11c3QgDQogICAgICAgIHRyYXZl cnNlIHRocm91Z2ggYW5kIGJlIHByb2Nlc3NlZCBvbiBhbGwgdGhlIG5vZGVzIG9mIHRoZSANCiAg ICAgICAgY29ycmVzcG9uZGluZyBwYXRoLiBXaGVuIHRoZSBESVNBQkxFIG1lc3NhZ2UgcmVhY2hl cyB0byB0aGUgDQp0YWlsZW5kIA0KICAgICAgICBub2RlLCB0aGUgdGFpbGVuZCBpcyByZXF1aXJl ZCB0byByZXBseSB3aXRoIGEgU1RBVFVTIG1lc3NhZ2UgdG8gDQp0aGUNCiAgICAgICAgaGVhZGVu ZC4NCg0KV2hpY2ggbWVhbnMgdGhhdCB0aGUgU1RBVFVTIG1lc3NhZ2UgY2FuIGJlIHNlbnQgdG8g dGhlIGhlYWRlbmQsIGJ1dCB0aGUgDQpzd2l0aGluZyBmYWJyaWMgaGFzIGJlZW4gZGVwcm9ncmFt ZWQgYXQgdGhhdCB0aW1lLi4uDQoNCklmIEkgY2F0Y2ggdGhlIGlkZWEgY2xlYXJseSwgYSByZXBs eSBtZXNzYWdlIGlzIG5lY2Vzc2FyeSwgYnV0IGl0IFNIT1VMRCANCmJlIHNlbnQgYnkgb3RoZXIg bWVzc2FnZSBhbG9uZyB0aGUgd29ya2luZyBwYXRoLg0KDQoyKSBZb3Ugc2FpZCB0aGF0ICJTaGFy ZWQgbWVzaCBwcm90ZWN0aW9uIGlzIGEgY29tbW9uIHByb3RlY3Rpb24gYW5kIA0KcmVjb3Zlcnkg bWVjaGFuaXNtIiwgYnV0IHJlY292ZXJ5IGluY2x1ZGVzIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0 aW9uIA0KKFJGQzQ0MjcpLCB0aGlzIHNlbnRlbmNlIE1heWJlIG5lZWQgdG8gYmUgcmV2aXNlZC4N Cg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMNCg0KRmVpDQoNCg0KDQpQaW5nIFBhbiA8cGluZ0Bw aW5ncGFuLm9yZz4gDQq3orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDMtMTEg MDM6MTgNCg0KytW8/sjLDQptcGxzQGlldGYub3JnLCBjY2FtcEBpZXRmLm9yZw0Ks63LzQ0KDQrW 98ziDQpSZTogW21wbHNdIEktRCBBQ1RJT046ZHJhZnQtcGFuLXNoYXJlZC1tZXNoLXByb3RlY3Rp b24tMDAudHh0DQoNCg0KDQoNCg0KDQpDb3JyZWN0aW9uOiB0aGUgZ29hbCBpcyB0byByZWNvdmVy IGluIG1pbGxpc2Vjb25kcy4gDQoNCkRpZCBub3QgbWVhbiB0byB1c2UgVVMgUG9zdGFsIFNlcnZp Y2Ugb3IgUG9ueSBFeHByZXNzIGZvciBwcm90ZWN0aW5nIHBhdGggDQphY3RpdmF0aW9uLiA7LSkN Cg0KUGluZw0KDQpPbiBUaHUsIE1hciAxMCwgMjAxMSBhdCA4OjE5IEFNLCBQaW5nIFBhbiA8cGlu Z0BwaW5ncGFuLm9yZz4gd3JvdGU6DQpIaSwNCg0KU2hhcmVkIE1lc2ggUHJvdGVjdGlvbiBoYXMg dGhlIGJlbmVmaXQgb2Ygb3B0aW1pemluZyBuZXR3b3JrIHJlc291cmNlcyBpbiANCnRyYW5zcG9y dCBuZXR3b3Jrcy4gSG93ZXZlciwgYWN0aXZhdGluZyB0aGUgcHJvdGVjdGlvbiBoYXMgYWx3YXlz IGJlZW4gYSANCmNoYWxsZW5nZS4NCg0KTVBMUy1UUCBoYXMgb3V0bGluZWQgdGhlIHJlcXVpcmVt ZW50cyBhbmQgZnJhbWV3b3JrLiBIZXJlIGlzIGEgcHJvcG9zYWwgDQp0aGF0IHdlIGhhdmUgcHV0 IHRvZ2V0aGVyIHRvIHNvbHZlIHRoZSBwZXJmb3JtYW5jZSBpc3N1ZSBpbiBzaGFyZWQgbWVzaGVk IA0KbmV0d29ya3MuDQoNCkdpdmVuIGl0cyBzaW1wbGljaXR5IChhY3R1YWxseSBpdCdzIGRlc2ln bmVkIGZvciBlbWJlZGRlZCBkYXRhLXBsYW5lKSwgDQp0aGlzIGNhbiBhY2hpZXZlIHJhcGlkIHRy YWZmaWMgcmVjb3ZlcnkgYW5kIHN3aXRjaC1vdmVyLiBUaGUgcGVyZm9ybWFuY2UgDQpnb2FsIGlz IHRvIHJlY292ZXIgdHJhZmZpYyBpbiBtaWxsaW9uIHNlY29uZHMgZm9yIGVuZC10by1lbmQgdHJh bnNwb3J0IA0KdHVubmVscy4NCg0KV2UgYXJlIHN0aWxsIHdvcmtpbmcgb24gZGV0YWlscy4gTG9v ayBmb3J3YXJkIHRvIGhlYXIgeW91ciBmZWVkYmFjay4NCg0KQmVzdCByZWdhcmRzLA0KDQpQaW5n DQoNCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IDxJ bnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc+DQpEYXRlOiBNb24sIE1hciA3LCAyMDExIGF0IDY6MDAg UE0NClN1YmplY3Q6IEktRCBBQ1RJT046ZHJhZnQtcGFuLXNoYXJlZC1tZXNoLXByb3RlY3Rpb24t MDAudHh0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQoNCg0KQSBuZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0 b3JpZXMuDQoNCg0KICAgVGl0bGUgICAgICAgICA6IFN1cHBvcnRpbmcgU2hhcmVkIE1lc2ggUHJv dGVjdGlvbiBpbiBNUExTLVRQIE5ldHdvcmtzDQogICBBdXRob3IocykgICAgIDogUi4gUmFvLCBl dCBhbA0KICAgRmlsZW5hbWUgICAgICA6IGRyYWZ0LXBhbi1zaGFyZWQtbWVzaC1wcm90ZWN0aW9u LTAwLnR4dA0KICAgUGFnZXMgICAgICAgICA6IDE1DQogICBEYXRlICAgICAgICAgIDogMjAxMS0w My0wNw0KDQpTaGFyZWQgbWVzaCBwcm90ZWN0aW9uIGlzIGEgY29tbW9uIHByb3RlY3Rpb24gYW5k IHJlY292ZXJ5IG1lY2hhbmlzbQ0KICAgICAgIGluIHRyYW5zcG9ydCBuZXR3b3Jrcywgd2hlcmUg bXVsdGlwbGUgcGF0aHMgY2FuIHNoYXJlIHRoZSBzYW1lIHNldA0KICAgICAgIG9mIG5ldHdvcmsg cmVzb3VyY2VzIGZvciBwcm90ZWN0aW9uIHB1cnBvc2VzLg0KDQogICAgICAgSW4gdGhlIGNvbnRl eHQgb2YgTVBMUy1UUCwgaXQgaGFzIGJlZW4gZXhwbGljaXRseSByZXF1ZXN0ZWQgYXMgYQ0KICAg ICAgIHBhcnQgb2YgdGhlIG92ZXJhbGwgc29sdXRpb24gKFJlcS4gNjcsIDY4IGFuZCA2OSBpbiBS RkM1NjU0IFsxXSkuDQoNCiAgICAgICBJdCdzIGltcG9ydGFudCB0byBub3RlIHRoYXQgZWFjaCBN UExTLVRQIExTUCBtYXkgYmUgYXNzb2NpYXRlZCB3aXRoDQogICAgICAgdHJhbnNwb3J0IG5ldHdv cmsgcmVzb3VyY2VzLiBJbiBldmVudCBvZiBuZXR3b3JrIGZhaWx1cmUsIGl0IG1heQ0KICAgICAg IHJlcXVpcmUgZXhwbGljaXQgYWN0aXZhdGlvbiBvbiB0aGUgcHJvdGVjdGluZyBwYXRocyBiZWZv cmUgDQpzd2l0Y2hpbmcNCiAgICAgICB1c2VyIHRyYWZmaWMgb3Zlci4NCg0KICAgICAgIEluIHRo aXMgbWVtbywgd2UgZGVmaW5lIGEgbGlnaHR3ZWlnaHQgc2lnbmFsaW5nIG1lY2hhbmlzbSBmb3IN CiAgICAgICBwcm90ZWN0aW5nIHBhdGggYWN0aXZhdGlvbiBpbiBzaGFyZWQgbWVzaCBwcm90ZWN0 aW9uLWVuYWJsZWQgDQpNUExTLVRQDQogICAgICAgbmV0d29ya3MuDQoNCg0KQSBVUkwgZm9yIHRo aXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1wYW4tc2hhcmVkLW1lc2gtcHJvdGVjdGlvbi0wMC50eHQNCg0KDQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxs IGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlvbiB0byBh dXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50ZXJuZXQt RHJhZnQuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJu ZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0K b3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxp c3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQoNCg== --=_alternative 0033FBA6482578A8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBpbmc8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkkganVzdCByZWFkIHRoZSBkcmFm dCwgc29tZSBjb25mdXNpb25zDQpsaXN0ZWQgYmVsb3c6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4xKVlvdSBnaXZlIHRoZSBkZWZpbml0b24gb2Ygd2Fy bSBzdGFuZHksDQpzZWUgYmVsb3c6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2FybSBTdGFuZGJ5Og0K VGhlIG5vZGVzIHdpbGwgbmVnb3RpYXRlIGFuZCByZXNlcnZlIHByb3RlY3RpbmcgcGF0aCA8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJpb3IgdG8gbmV0d29yayBmYWlsdXJlLiBI b3dldmVyLCBkYXRhIGZvcndhcmRpbmcNCnBhdGggd2lsbCBub3QgYmUgPGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3Byb2dyYW1tZWQuIFVwb24gdGhlIGRldGVjdGlvbiBvZiBuZXR3 b3JrIGZhaWx1cmUsDQp0aGUgbm9kZXMgd2lsbCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7c2VuZCBleHBsaWNpdCBtZXNzYWdlcyB0byByZWxldmFudCBub2RlcyB0bw0KJnF1b3Q7 d2FrZSB1cCZxdW90OyB0aGUgcHJvdGVjdGluZyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cGF0aC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQpTaW5jZSB0aGUgZGF0YSBmb3J3YXJkaW5nIHBhdGggaXMgbm90IHByb2dyYW1tZWQsIHdo aWNoIG1lYW5zIHRoYXQgdGhlDQpkYXRhIHRyYWZmaWMgYW5kIE9BTSB0cmFmZmljIGNhbiBub3Qg YmUgdHJhbnBvcnRlZCBiZWZvcmUgdGhlIGFjdGl2YXRpb24/PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5CdXQgYWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlidGlvbiBv Zg0Kc2VjdGlvbiA3LjI8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBcyBhIHBhcnQNCm9mIHRoZSBjbGVh bi11cCBwcm9jZWR1cmUsIGVhY2ggRElTQUJMRSBtZXNzYWdlIG11c3QgPGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3RyYXZlcnNlIHRocm91Z2ggYW5kIGJlIHByb2Nlc3NlZCBvbiBh bGwgdGhlDQpub2RlcyBvZiB0aGUgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nv cnJlc3BvbmRpbmcgcGF0aC4gV2hlbiB0aGUgRElTQUJMRSBtZXNzYWdlDQpyZWFjaGVzIHRvIHRo ZSB0YWlsZW5kIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtub2RlLCB0aGUgdGFp bGVuZCBpcyByZXF1aXJlZCB0byByZXBseSB3aXRoDQphIFNUQVRVUyBtZXNzYWdlIHRvIHRoZTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGhlYWRlbmQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj5XaGljaCBtZWFucyB0aGF0IHRoZSBTVEFUVVMgbWVzc2FnZQ0KY2FuIGJl IHNlbnQgdG8gdGhlIGhlYWRlbmQsIGJ1dCB0aGUgc3dpdGhpbmcgZmFicmljIGhhcyBiZWVuIGRl cHJvZ3JhbWVkDQphdCB0aGF0IHRpbWUuLi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPklmIEkgY2F0Y2ggdGhlIGlkZWEgY2xlYXJseSwgYSByZXBseQ0K bWVzc2FnZSBpcyBuZWNlc3NhcnksIGJ1dCBpdCBTSE9VTEQgYmUgc2VudCBieSBvdGhlciBtZXNz YWdlIGFsb25nIHRoZQ0Kd29ya2luZyBwYXRoLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+MikgWW91IHNhaWQgdGhhdCAmcXVvdDtTaGFyZWQgbWVzaCBw cm90ZWN0aW9uDQppcyBhIGNvbW1vbiBwcm90ZWN0aW9uIGFuZCByZWNvdmVyeSBtZWNoYW5pc20m cXVvdDssIGJ1dCByZWNvdmVyeSBpbmNsdWRlcw0KcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24g KFJGQzQ0MjcpLCB0aGlzIHNlbnRlbmNlIE1heWJlIG5lZWQgdG8gYmUgcmV2aXNlZC48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz5UaGFua3MgYW5kIGJlc3QgcmVnYXJkczwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTM+RmVpPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UGluZyBQYW4gJmx0O3Bp bmdAcGluZ3Bhbi5vcmcmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTAzLTExIDAzOjE4PC9mb250Pg0K PHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHNAaWV0 Zi5vcmcsIGNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHNdIEktRCBBQ1RJT046ZHJhZnQtcGFuLXNo YXJlZC1tZXNoLXByb3RlY3Rpb24tMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkNvcnJlY3Rpb246IHRoZSBnb2FsIGlzIHRvIHJlY292 ZXIgaW4gbWlsbGlzZWNvbmRzLiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ RGlkIG5vdCBtZWFuIHRvIHVzZSBVUyBQb3N0YWwgU2VydmljZSBvciBQb255IEV4cHJlc3MNCmZv ciBwcm90ZWN0aW5nIHBhdGggYWN0aXZhdGlvbi4gOy0pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mz5QaW5nPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5PbiBUaHUsIE1hciAx MCwgMjAxMSBhdCA4OjE5IEFNLCBQaW5nIFBhbiAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnBp bmdAcGluZ3Bhbi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+cGluZ0BwaW5ncGFuLm9y ZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPkhpLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+U2hhcmVkIE1lc2gg UHJvdGVjdGlvbiBoYXMgdGhlIGJlbmVmaXQgb2Ygb3B0aW1pemluZyBuZXR3b3JrDQpyZXNvdXJj ZXMgaW4gdHJhbnNwb3J0IG5ldHdvcmtzLiBIb3dldmVyLCBhY3RpdmF0aW5nIHRoZSBwcm90ZWN0 aW9uIGhhcw0KYWx3YXlzIGJlZW4gYSBjaGFsbGVuZ2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mz5NUExTLVRQIGhhcyBvdXRsaW5lZCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdv cmsuIEhlcmUNCmlzIGEgcHJvcG9zYWwgdGhhdCB3ZSBoYXZlIHB1dCB0b2dldGhlciB0byBzb2x2 ZSB0aGUgcGVyZm9ybWFuY2UgaXNzdWUNCmluIHNoYXJlZCBtZXNoZWQgbmV0d29ya3MuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5HaXZlbiBpdHMgc2ltcGxpY2l0eSAoYWN0dWFsbHkg aXQncyBkZXNpZ25lZCBmb3IgZW1iZWRkZWQNCmRhdGEtcGxhbmUpLCB0aGlzIGNhbiBhY2hpZXZl IHJhcGlkIHRyYWZmaWMgcmVjb3ZlcnkgYW5kIHN3aXRjaC1vdmVyLiBUaGUNCnBlcmZvcm1hbmNl IGdvYWwgaXMgdG8gcmVjb3ZlciB0cmFmZmljIGluIG1pbGxpb24gc2Vjb25kcyBmb3IgZW5kLXRv LWVuZA0KdHJhbnNwb3J0IHR1bm5lbHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5X ZSBhcmUgc3RpbGwgd29ya2luZyBvbiBkZXRhaWxzLiBMb29rIGZvcndhcmQgdG8gaGVhcg0KeW91 ciBmZWVkYmFjay48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkJlc3QgcmVnYXJkcyw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlBpbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzwvZm9udD48YSBocmVmPSJt YWlsdG86SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlPjx1PkludGVybmV0LURyYWZ0c0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9Mz4mZ3Q7PGJyPg0KRGF0ZTogTW9uLCBNYXIgNywgMjAxMSBhdCA2OjAwIFBNPGJy Pg0KU3ViamVjdDogSS1EIEFDVElPTjpkcmFmdC1wYW4tc2hhcmVkLW1lc2gtcHJvdGVjdGlvbi0w MC50eHQ8YnI+DQpUbzogPC9mb250PjxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5v cmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aS1kLWFubm91bmNl QGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+QSBuZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy48YnI+DQo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7VGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogU3VwcG9y dGluZyBTaGFyZWQgTWVzaA0KUHJvdGVjdGlvbiBpbiBNUExTLVRQIE5ldHdvcmtzPGJyPg0KJm5i c3A7ICZuYnNwO0F1dGhvcihzKSAmbmJzcDsgJm5ic3A7IDogUi4gUmFvLCBldCBhbDxicj4NCiZu YnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtcGFuLXNoYXJl ZC1tZXNoLXByb3RlY3Rpb24tMDAudHh0PGJyPg0KJm5ic3A7ICZuYnNwO1BhZ2VzICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IDE1PGJyPg0KJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMS0wMy0wNzxicj4NCjxicj4NClNoYXJlZCBt ZXNoIHByb3RlY3Rpb24gaXMgYSBjb21tb24gcHJvdGVjdGlvbiBhbmQgcmVjb3ZlcnkgbWVjaGFu aXNtPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW4gdHJhbnNwb3J0IG5ldHdvcmtz LCB3aGVyZSBtdWx0aXBsZSBwYXRocw0KY2FuIHNoYXJlIHRoZSBzYW1lIHNldDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mIG5ldHdvcmsgcmVzb3VyY2VzIGZvciBwcm90ZWN0aW9u IHB1cnBvc2VzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIHRoZSBj b250ZXh0IG9mIE1QTFMtVFAsIGl0IGhhcyBiZWVuIGV4cGxpY2l0bHkNCnJlcXVlc3RlZCBhcyBh PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGFydCBvZiB0aGUgb3ZlcmFsbCBzb2x1 dGlvbiAoUmVxLiA2NywgNjggYW5kDQo2OSBpbiBSRkM1NjU0IFsxXSkuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXQncyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGVhY2gg TVBMUy1UUCBMU1ANCm1heSBiZSBhc3NvY2lhdGVkIHdpdGg8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0cmFuc3BvcnQgbmV0d29yayByZXNvdXJjZXMuIEluIGV2ZW50IG9mIG5ldHdv cmsNCmZhaWx1cmUsIGl0IG1heTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlcXVp cmUgZXhwbGljaXQgYWN0aXZhdGlvbiBvbiB0aGUgcHJvdGVjdGluZw0KcGF0aHMgYmVmb3JlIHN3 aXRjaGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZXIgdHJhZmZpYyBvdmVy Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIHRoaXMgbWVtbywgd2Ug ZGVmaW5lIGEgbGlnaHR3ZWlnaHQgc2lnbmFsaW5nDQptZWNoYW5pc20gZm9yPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvdGVjdGluZyBwYXRoIGFjdGl2YXRpb24gaW4gc2hhcmVk IG1lc2ggcHJvdGVjdGlvbi1lbmFibGVkDQpNUExTLVRQPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7bmV0d29ya3MuPGJyPg0KPGJyPg0KPGJyPg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJu ZXQtRHJhZnQgaXM6PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48 L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt cGFuLXNoYXJlZC1tZXNoLXByb3RlY3Rpb24tMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MyBjb2xvcj1ibHVlPjx1Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXBhbi1zaGFyZWQtbWVzaC1wcm90ZWN0aW9uLTAwLnR4dDwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9Mz48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4N CjwvdT48L2ZvbnQ+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8i IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy88L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPGJy Pg0KQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBt YWlsIHJlYWRlcjxicj4NCmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUg dGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlPGJyPg0KSW50ZXJuZXQtRHJhZnQuPGJyPg0KPGJyPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPSJtYWlsdG86 SS1ELUFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlPjx1PkktRC1Bbm5vdW5jZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlSW50ZXJu ZXQtRHJhZnQiIHRhcmdldD1fYmxhbms+PC9hPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVl Pjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC91 PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5JbnRlcm5ldC1EcmFmdDwv dT48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiBkaXJlY3RvcmllczoNCjwvZm9udD48YSBocmVmPWh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZT48dT5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC91PjwvZm9udD48L2E+ DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCm9yIDwvZm9udD48YSBocmVmPSJmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZT48dT5mdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pg0K --=_alternative 0033FBA6482578A8_=-- From agmalis@gmail.com Tue Jun 7 06:52: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 B491211E80E7 for ; Tue, 7 Jun 2011 06:52:39 -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=[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 CknnZ4wgW7F3 for ; Tue, 7 Jun 2011 06:52:39 -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 82A9111E808E for ; Tue, 7 Jun 2011 06:52:38 -0700 (PDT) Received: by qwc23 with SMTP id 23so3667594qwc.31 for ; Tue, 07 Jun 2011 06:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=XugVj9YxsvU4SniZ+p2z20rZg66AdZhn6LGgMN9MFcs=; b=OOOJiy2+5smY6ak4aQXu8vfDBfUJPm7S1EfFkFeXOraDBn5uzDof3dFRnqShJEP7UE UiRgFxLMiz2heZGgg7iHGfZ4CBkGvEIDySkIilQNwmza8pCW2fvn4zXRIK/gNmMFm6hy uVGrVFy2ZI47TuO0J8iGQxtcEIV8IaLgOcx5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=XBXjAnJBtLRPFCVo0Uy355gsCZd4XTcCN8HzqEPAh24fEEsmEkY/JTs90XbNsAg2/E ZrYfNxemAWytiqz7xayh8BSdni+rV38tD+KjhRTpxk7xCEgHX2MIFJhTGLb0iRkxccEk SIso8kkeKFrnEFqZ9oEr2vFIdYsBWJrrJjBUI= Received: by 10.229.78.89 with SMTP id j25mr227858qck.190.1307454757933; Tue, 07 Jun 2011 06:52:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.100.7 with HTTP; Tue, 7 Jun 2011 06:52:17 -0700 (PDT) In-Reply-To: <45FC0B0A070BF345870B2710BADC670A06718022@XMB-RCD-104.cisco.com> References: <4DE795A3.5050106@pi.nu> <45FC0B0A070BF345870B2710BADC670A06718022@XMB-RCD-104.cisco.com> From: "Andrew G. Malis" Date: Tue, 7 Jun 2011 09:52:17 -0400 Message-ID: To: "Siva Sivabalan (msiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 07 Jun 2011 13:52:39 -0000 Yes/support On Mon, Jun 6, 2011 at 2:35 PM, Siva Sivabalan (msiva) wr= ote: > Yes/support. > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Thursday, June 02, 2011 9:53 AM > To: mpls@ietf.org > Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 > > Working Group, > > this is to start a two week poll on making > > draft-raza-mpls-ldp-ip-pw-capability-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > =A0The poll ends 2011-06-16. > > =A0/Loa > > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 > _______________________________________________ > 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 gregory.mirsky@ericsson.com Tue Jun 7 16: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 0B65721F8581 for ; Tue, 7 Jun 2011 16:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rIWt9F6yMutD for ; Tue, 7 Jun 2011 16:52:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DB35421F8584 for ; Tue, 7 Jun 2011 16:52:55 -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 p57NqmkT017132; Tue, 7 Jun 2011 18:52:49 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 7 Jun 2011 19:52:42 -0400 From: Gregory Mirsky To: Sami Boutros , "Siva Sivabalan(msiva)" , Rahul Aggarwal , "martin.vigoureux@alcatel-lucent.com" , "dai.xuehui@zte.com.cn" , "swallow@cisco.com" , David Ward , "stbryant@cisco.com" , "cpignata@cisco.com" , "Bitar, Nabil N" , BUSI ITALO , "LEVRAU, LIEVEN (LIEVEN)" , "laurent.ciavaglia@alcatel-lucent.com" , "wu.bo@zte.com.cn" , "yang_jian@zte.com.cn" , "mpls@ietf.org" Date: Tue, 7 Jun 2011 19:52:39 -0400 Thread-Topic: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 Thread-Index: Acwk0gKKjtzv8N9PSXeEbU9DuleYgQAa7ujQ 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_FE60A4E52763E84B935532D7D9294FF121F39EECBFEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 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, 07 Jun 2011 23:52:57 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F39EECBFEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sami, thank you for your response. Please find my notes below and in-lined with t= ag GIM>>: * second paragraph of Introduction refers to use of LSP-Ping "either over GAC= h or using native IP addressing". I think that this is in reference to diff= erent encapsulations of LSP-Ping and the text might benefit from the clarif= ication and note that with either type of encapsulation an LSP-Ping is alwa= ys transported in-band over MPLS-TP network. Considering that characterizin= g G-ACh encapsulation as exclusively "in-band option" for LI-LB transport m= ight be misleading. Perhaps it can be referred as "G-ACh option". * Section 3.3 What is application of Informational Return Code? * Section 3.5 Which Operation and Return Code values should be used when nego= tiating CHAP Authentication? * section 3.6.2 states that "only LI-LB response TLV might be present in LSP = Ping Echo request message". I think it is a typo and this clarification is = in regard to LSP Ping Echo reply message, not request. * In 6.3.g it might be "back to MEP-A' in place of "back to A" to be con= sistent with terminology used. * I find draft-ietf-mpls-tp-ach-tlv-02 expired and IANA's ACH TLV Registry is= empty. The document doesn't request IANA allocation of ACH TLV types for S= ource MEP-ID, Destination MEP-ID, Destination MIP-ID, and Authentication. H= ow these ACH TLV types will be defined? * Reference 9 is missing mention of RFC 1334. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sam= i Boutros Sent: Monday, June 06, 2011 10:16 PM To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; martin.vigoureux@al= catel-lucent.com; dai.xuehui@zte.com.cn; swallow@cisco.com; David Ward; stb= ryant@cisco.com; cpignata@cisco.com; Bitar, Nabil N; BUSI ITALO; LEVRAU, LI= EVEN (LIEVEN); laurent.ciavaglia@alcatel-lucent.com; wu.bo@zte.com.cn; yang= _jian@zte.com.cn; mpls@ietf.org Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 Hi Greg, Here are responses to your comments please let us know if you are OK with t= he Responses. * section 3.2 I think that there are mandatory TLVs for LI-LB and option= al. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-ID, while = for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication TLV. Response-1: Correct. GIM>> I don't find Source and Destination MEP-ID, MIP-ID TLVs being discus= sed or referenced even though section 6.3 refers to validation of Source an= d Destination/target MEP-IDs. * section 3.3.5 describes Return Code in Return TLV for LSP-ping option = of LI-LB signaling. For in-band option Return Code has different values and= values listed in this section are for field Cause Code. I think it would b= e beneficial to have some uniformity across LI-LB signalling options and in= Return TLV have both Return Code and Cause Code fields with values identic= al for in-band and LSP-Ping options. Response-2: Addressed in latest version -02 where we made this section shar= ed by both in-Band and LSP-Ping, we as well limited the # of TLVs used by L= SP Ping. GIM>> Great * section 3.3.6 defines Authentication TLV for LSP-Ping option. Authenti= cation of LB request but in-band option doesn't have provision to indicate = that Authentication is in use. I propose to allocate MSB of Reserved field = as Authentication flag. Response-3: Addressed in latest version -02 by making authentication TLV co= mmon to both in-band and LSP Ping. GIM>> Agree * section 6.3 mentions that Authentication may be used both in Lock requ= est and Lock response. I think that if Authentication was present in Lock r= equest and accepted by remote MEP, then Lock response must have Authenticat= ion. Similar is applicable to use of Authentication in Unlock request/respo= nse, and Setting/Removing LB . Response-4: We described authentication procedures in more details in secti= on 3.5 of latest draft version, please have a look to see if it addresses y= our concern. GIM>> I was thinking of allocating an Authnetication (A) flag from Reserved= field to indicate whether Authentication is in use for given LB and LI. No= te, that setting of A flag on LI Lock request or LB Set request defines use= of Authentication not only in corresponding replies but in Unlock/Unset as= well. * section 6.5.b I think that there's no guarantee that sender of LI requ= est will not generate false positive after remote MEP locks the LSP. Perhap= s, if proactive OAM is enabled, the remote MEP should send LI reply but it = might stop sending OAM messages after 3*TxPeriod interval. Response-5: Addressed in section 6.3 last paragraph MEP-D will lock the LSP, resulting in that all traffic from D to A, includi= ng all OAM traffic, stops. a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc p= ackets, but since it has been informed that the LSP will be locked it will = take no action(s). b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM tra= ffic, e.g. cv and cc packets. MEP-D will detect this, but since it is in Lo= cked state it will take no action. GIM>> Thank you. Thanks, Sami --_000_FE60A4E52763E84B935532D7D9294FF121F39EECBFEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sami,
thank you for your response. Please find my notes = below and=20 in-lined with tag GIM>>:
  • second paragraph of Introduction refers to use of=20 LSP-Ping "either over GACh or using native IP addressing".= I=20 think that this is in reference to different encapsulations of LSP-Ping a= nd=20 the text might benefit from the clarification and note that with either t= ype=20 of encapsulation an LSP-Ping is always transported in-band over MPLS-TP=20 network. Considering that characterizing G-ACh encapsulation as=20 exclusively "in-band option" for LI-LB transport might be misleading. Per= haps=20 it can be referred as "G-ACh option".
  • Section 3.3 What is application of Informational Return=20 Code?
  • Section 3.5 Which Operation and Return Code values should be use= d when=20 negotiating CHAP Authentication?
  • section 3.6.2 states that "only LI-LB response TLV might be pres= ent in=20 LSP Ping Echo request message". I think it is a typo and this clarificati= on is=20 in regard to LSP Ping Echo reply message, not=20 request.
  • In=20 6.3.g it might be "back to MEP-A' in place of "back to A" to be consisten= t=20 with terminology used.
  • I find draft-ietf-mpls-tp-ach-tlv-02 expired and IANA's ACH TLV= =20 Registry is empty. The document doesn't request IANA allocation of ACH TL= V=20 types for Source MEP-ID, Destination MEP-ID, Destination MIP-ID, and=20 Authentication. How these ACH TLV types will be=20 defined?
  • Reference 9 is missing mention of RFC 1334.
    <= /LI>
  &n= bsp; Regards,
        Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros
Sent:= =20 Monday, June 06, 2011 10:16 PM
To: Greg Mirsky; Siva Sivabalan(ms= iva);=20 Rahul Aggarwal; martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn;= =20 swallow@cisco.com; David Ward; stbryant@cisco.com; cpignata@cisco.com; Bita= r,=20 Nabil N; BUSI ITALO; LEVRAU, LIEVEN (LIEVEN);=20 laurent.ciavaglia@alcatel-lucent.com; wu.bo@zte.com.cn; yang_jian@zte.com.c= n;=20 mpls@ietf.org
Subject: Re: [mpls] LC comments to=20 draft-ietf-mpls-tp-li-lb-01

Hi Greg,

Here are responses to your comments please let u= s=20 know if you are OK with the Responses.

  • section 3.2 I think that there are mandatory TLVs for LI-LB and=20 optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-= ID,=20 while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication=20 TLV.

    Response-1: Correct.
     GIM>> I don't find Source= and=20 Destination MEP-ID, MIP-ID TLVs being discussed=20 or referenced even though section 6.3 refers to validation of Sou= rce=20 and Destination/target MEP-IDs.
    • section 3.3.5 describes Return Code in Return TLV for LSP-ping opti= on of=20 LI-LB signaling. For in-band option Return Code has different values an= d=20 values listed in this section are for field Cause Code. I think it woul= d be=20 beneficial to have some uniformity across LI-LB signalling options and = in=20 Return TLV have both Return Code and Cause Code fields with values iden= tical=20 for in-band and LSP-Ping options.

      Response-2: Addressed in latest version -02 where we made this= =20 section shared by both in-Band and LSP-Ping, we as well limited the # of TL= Vs=20 used by LSP Ping.
       GIM>> Great
      • section 3.3.6 defines Authentication TLV for LSP-Ping option.=20 Authentication of LB request but in-band option doesn't have provision = to=20 indicate that Authentication is in use. I propose to allocate MSB of=20 Reserved field as Authentication flag.

        Response-3: Addressed in latest version -02 by making=20 authentication TLV common to both in-band and LSP Ping.
        &nbs= p;GIM>>=20 Agree 
        • section 6.3 mentions that Authentication may be used both in Lock=20 request and Lock response. I think that if Authentication was present i= n=20 Lock request and accepted by remote MEP, then Lock response must have=20 Authentication. Similar is applicable to use of Authentication in Unloc= k=20 request/response, and Setting/Removing LB .

          Response-4: We described authentication procedures in more det= ails=20 in section 3.5 of latest draft version, please have a look to see if it=20 addresses your concern.
          GIM>> I was thinking of allocating an Authnetica= tion=20 (A) flag from Reserved field to indicate whether Authentication is in use f= or=20 given LB and LI. Note, that setting of A flag on LI Lock request or LB Set= =20 request defines use of Authentication not only in corresponding replies but= in=20 Unlock/Unset as well.
          • section 6.5.b I think that there's no guarantee that sender of LI=20 request will not generate false positive after remote MEP locks the LSP= .=20 Perhaps, if proactive OAM is enabled, the remote MEP should send LI rep= ly=20 but it might stop sending OAM messages after 3*TxPeriod interval.=20

            Response-5:  Addressed in section 6.3 last paragraph

            M= EP-D=20 will lock the LSP, resulting in that all traffic from D to A, including all= OAM=20 traffic, stops.

            a. MEP-A will detect a discontinuation in the OAM=20 traffic, e.g. cv and cc packets, but since it has been informed that the LS= P=20 will be locked it will take no action(s).
            b. When MEP-A receives the LI = ACK,=20 MEP-A discontinues sending other OAM traffic, e.g. cv and cc packets. MEP-D= will=20 detect this, but since it is in Locked state it will take no action. 
            GIM>> Thank you. 

            Thanks,

            S= ami=20
            --_000_FE60A4E52763E84B935532D7D9294FF121F39EECBFEUSAACMS0715e_-- From eric.gray@ericsson.com Tue Jun 7 17: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 A135411E815C for ; Tue, 7 Jun 2011 17:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 7nbwRODNb0E1 for ; Tue, 7 Jun 2011 17:01:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id A5BC011E8120 for ; Tue, 7 Jun 2011 17:01:19 -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 p5801G43017805; Tue, 7 Jun 2011 19:01:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 7 Jun 2011 20:01:16 -0400 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" Date: Tue, 7 Jun 2011 20:01:15 -0400 Thread-Topic: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 Thread-Index: AcwhLGnonbM1OtqRSiiY2veK+nTx3gEQr1lQ Message-ID: References: <4DE795A3.5050106@pi.nu> In-Reply-To: <4DE795A3.5050106@pi.nu> 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: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 08 Jun 2011 00:01:20 -0000 Yes/Support=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, June 02, 2011 9:53 AM To: mpls@ietf.org Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 Working Group, this is to start a two week poll on making draft-raza-mpls-ldp-ip-pw-capability-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends 2011-06-16. /Loa --=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 gregory.mirsky@ericsson.com Wed Jun 8 10:13: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 E2B2921F8526 for ; Wed, 8 Jun 2011 10:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.832 X-Spam-Level: X-Spam-Status: No, score=-6.832 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ygCU7QJmkfZz for ; Wed, 8 Jun 2011 10:13:15 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E1D2021F849D for ; Wed, 8 Jun 2011 10:13:14 -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 p58HDDsX008956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jun 2011 12:13:14 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 8 Jun 2011 13:13:13 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Date: Wed, 8 Jun 2011 13:13:11 -0400 Thread-Topic: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 Thread-Index: Acwl/sz13Fy7JBYcRH+3a/ZtD1UFdQAAHa/w Message-ID: References: <4DE795A3.5050106@pi.nu> 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_FE60A4E52763E84B935532D7D9294FF121F39EEFC1EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 08 Jun 2011 17:13:16 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F39EEFC1EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ---------- Forwarded message ---------- From: Loa Andersson > Date: Thu, Jun 2, 2011 at 6:52 AM Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 To: "mpls@ietf.org" > Working Group, this is to start a two week poll on making draft-raza-mpls-ldp-ip-pw-capability-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends 2011-06-16. /Loa -- 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_FE60A4E52763E84B935532D7D9294FF121F39EEFC1EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
            yes/support

               = ;=20 Regards,
                   =20 Greg

            ---------- Forwarded message ----------
            From: <= B=20 class=3Dgmail_sendername>Loa Andersson <loa@pi.nu>
            Date: Thu, Jun 2, 201= 1 at=20 6:52 AM
            Subject: [mpls] poll on=20 draft-raza-mpls-ldp-ip-pw-capability-01
            To: "mpls@ietf.org" <mpls@ietf.org>


            Working=20 Group,

            this is to start a two week poll on=20 making

            draft-raza-mpls-ldp-ip-pw-capability-01

            an mpls workin= g=20 group document.

            If you support the document becoming a working group= =20 document
            please respond to this poll with "yes/support"

            If you do= not=20 support the document becoming a working group
            document please respond to= this=20 poll with "no/do not support"
            and at the same time give the technical re= asons=20 why you are
            not supporting the document.

            If you have technical=20 comments or in any other way want to
            discuss the document, please send t= hese=20 comments to the mpls
            working group mailing list, but with another subjec= t=20 than what
            is on this mail.

             The poll ends=20 2011-06-16.

             /Loa


            --

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

            --_000_FE60A4E52763E84B935532D7D9294FF121F39EEFC1EUSAACMS0715e_-- From gregimirsky@gmail.com Wed Jun 8 17:34: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 4BF7521F84CC for ; Wed, 8 Jun 2011 17:34:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFRipUPPDfr5 for ; Wed, 8 Jun 2011 17:34:44 -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 3419321F84C9 for ; Wed, 8 Jun 2011 17:34:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so1105083vxg.31 for ; Wed, 08 Jun 2011 17:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JS/hr6v+w+xd0HT95tMJcjNmyM9GVwM9DXH9Eq85s+8=; b=i2Uk2/+4FFJNLCXV3CmzesqiHoH3UuplMUQUOLyGl4hrs6TCfeQLcu2HSLRFpFUKBZ MxsWkoorKwGPl4NKwSTDAyRi+5Ci0NK5gjjoCIQOAvRYekwr42VRZTdc3jHo2j/1zeoX nFpOfBh3QNiSv/vPknVPqMTwyFsVZLM2EJ+Gs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N1/v0WEHwxOcXuK8CiZ80QpL1bvl0ZkboRrqnCTcNi1xESGi/cOz5zeO3MCQr09hqQ qjcWYxUZUgqXPdzt94zbGm6TVv5M/drTwGpCPNRTrZQ1MSyNnaNt/e3EPn3xezEUPq4G ELYYoqiG3k4BpqLQjf1AKPf8R1o4Z+4+iX9aU= MIME-Version: 1.0 Received: by 10.52.177.36 with SMTP id cn4mr156374vdc.26.1307579682611; Wed, 08 Jun 2011 17:34:42 -0700 (PDT) Received: by 10.52.169.165 with HTTP; Wed, 8 Jun 2011 17:34:42 -0700 (PDT) In-Reply-To: <4DE89C6B.5070108@pi.nu> References: <4DE89C6B.5070108@pi.nu> Date: Wed, 8 Jun 2011 17:34:42 -0700 Message-ID: From: Greg Mirsky To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf3071cc8e7f600a04a53c9e53 Cc: Ross Callon , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on resolution of last call 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: Thu, 09 Jun 2011 00:34:45 -0000 --20cf3071cc8e7f600a04a53c9e53 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, I have a minor comments to Section 4.2: - Reserved field of mandatory portion of the PSC packet has no description in the text. I suggest Reserved - SHALL be set to 0 on transmit and ignored on receive. - in Section 4.2.7 Reserved described as not only being set to 0 on transmit but checked on receive. Usually Reserved are being ignored by receiver and suggested above form might be used in this section as well. Regards, Greg On Fri, Jun 3, 2011 at 1:33 AM, Loa Andersson wrote: > working Group, > > the authors of the linear protection draft has updated after > working group last call and published a new version. > > This is a one week limited working group last call to verify that > the comments been appropriately addressed. > > The new draft will be found here: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-07.txt > > And the specification on how the comments been addressed here: > http://www.pi.nu/~loa/LastCallCommentsResolved-linear-protection > > Please send comments to the mpls working group mailing list on > June 10th the latest. > > /Loa > for the MPSL wg 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 > --20cf3071cc8e7f600a04a53c9e53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
            I have a minor comments to Section 4.2:
              Reserved field of mandatory portion of the PSC packet has no description i= n the text. I suggest
            Reserved -= SHALL be set to 0 on transmit and ignored on receive.
            • in Section 4.2.7 Reserved described as not only being set to = 0 on transmit but checked on receive. Usually Reserved are being ignored by= receiver and suggested above form might be used in this section as well.
            Regards,
            Greg

            On Fri, Jun 3, 2011= at 1:33 AM, Loa Andersson <loa@pi.nu> wrote:
            working Group,

            the authors of the linear protection draft has updated after
            working group last call and published a new version.

            This is a one week limited working group last call to verify that
            the comments been appropriately addressed.

            The new draft will be found here:
            http://www.ietf.org/internet-drafts/draf= t-ietf-mpls-tp-linear-protection-07.txt

            And the specification on how the comments been addressed here:
            http://www.pi.nu/~loa/LastCallCommentsResolved-linear= -protection

            Please send comments to the mpls working group mailing list on
            June 10th the latest.

            /Loa
            for the MPSL wg chairs

            --


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

            --20cf3071cc8e7f600a04a53c9e53-- From matthew.bocci@alcatel-lucent.com Thu Jun 9 02:54: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 CCB1B11E809A for ; Thu, 9 Jun 2011 02:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 rmekAWptnODy for ; Thu, 9 Jun 2011 02:54:56 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 204AE11E8071 for ; Thu, 9 Jun 2011 02:54:55 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p599ssYI016391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 9 Jun 2011 11:54:54 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 9 Jun 2011 11:54:54 +0200 From: "Bocci, Matthew (Matthew)" To: "mpls@ietf.org" Date: Thu, 9 Jun 2011 11:54:50 +0200 Thread-Topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: Acwmi0gf+FeWLkF+SPadgbvsLTnjfg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CA16569410C06matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [mpls] FW: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.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, 09 Jun 2011 09:54:56 -0000 --_004_CA16569410C06matthewboccialcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_CA16569410C06matthewboccialcatellucentcom_" --_000_CA16569410C06matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have just started a working group last call for the above MPLS-TP relate= d draft in PWE3. Please post any comments to the PWE3 mailing list. Best regards, Matthew On 09/06/2011 10:48, "Bocci, Matthew (Matthew)" > wrote: This email begins a two week working group last call for draft-ietf-pwe3-mp= ls-tp-gal-in-pw-01.txt Please review the draft and post any comments to the PWE3 mailing list. The working group last call will end on Friday 24th June. Best regards, Matthew & Andy --_000_CA16569410C06matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
            We have just started a w= orking group last call for the above MPLS-TP related draft in PWE3.

            Please post any comments to the PWE3 mailing list.
            <= div>
            Best regards,

            Matthew

            On 09/06/2011 10:48,= "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> wrote:
            This email begins a two week working group last call f= or draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

            P= lease review the draft and post any comments to the PWE3 mailing list.

            The working group last call will end on Friday 24th Ju= ne.

            Best regards,

            Matthew= & Andy
             --_000_CA16569410C06matthewboccialcatellucentcom_-- --_004_CA16569410C06matthewboccialcatellucentcom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Thu, 09 Jun 2011 11:54:53 GMT"; modification-date="Thu, 09 Jun 2011 11:54:53 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFp bGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3B3ZTMNCg== --_004_CA16569410C06matthewboccialcatellucentcom_-- From mach.chen@huawei.com Thu Jun 9 02:58: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 D369F11E80AC for ; Thu, 9 Jun 2011 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJEL+g7aHv8B for ; Thu, 9 Jun 2011 02:58:44 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 20E4511E8071 for ; Thu, 9 Jun 2011 02:58:44 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMI00NV0P1K4J@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 09 Jun 2011 17:58:32 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMI0096GP1K9Z@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 09 Jun 2011 17:58:32 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 09 Jun 2011 17:58:31 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.87]) by szxeml408-hub.china.huawei.com ([169.254.11.86]) with mapi id 14.01.0270.001; Thu, 09 Jun 2011 17:58:32 +0800 Date: Thu, 09 Jun 2011 09:58:31 +0000 From: Mach Chen In-reply-to: <4DE795A3.5050106@pi.nu> X-Originating-IP: [10.110.98.37] To: Loa Andersson , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 Thread-index: AQHMISx/znfb2H7uL06DT/2qD1QlwZS01QgQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DE795A3.5050106@pi.nu> Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 09 Jun 2011 09:58:44 -0000 Yes/support. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Thursday, June 02, 2011 9:53 PM > To: mpls@ietf.org > Subject: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 > > Working Group, > > this is to start a two week poll on making > > draft-raza-mpls-ldp-ip-pw-capability-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends 2011-06-16. > > /Loa > > > -- > > > 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 gregimirsky@gmail.com Thu Jun 9 14:58: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 6B8A821F8470; Thu, 9 Jun 2011 14:58:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS4K+ZjJmwtF; Thu, 9 Jun 2011 14:58:14 -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 5002C21F846C; Thu, 9 Jun 2011 14:58:14 -0700 (PDT) Received: by vxg33 with SMTP id 33so2159468vxg.31 for ; Thu, 09 Jun 2011 14:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TYqoAqv/k4HxTinAazbI8524xLrmkdrWI3ogna1HmyQ=; b=WvWdoDhmjAOwltfRhfz68fDfdoOAQvYLEMCNnkvATAWgoeuDKgvEweM6zRvftXv/hI sDGbi7O1lgL81oN5wkUw5PAwrjH7W1MMic8DHUwstmO3V9CRX3bL0GIaRSEZlmWy0TRH LerNijk+zPpiQN38cjGYngCBNBOl0MfZUirJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Hn1gICBKEtOuBWMamXH/v+sJjfZnLAl0emrXTOn00EN0xIj+td0CaDbkpgP3Du1YOM VkMGWOeD1BqxFRIjhys9ZWYC3jD26SoN6eMhPdW167govJj4dRVWzcvZj74yxQEwydV/ ZruXcVQcGYCtjj8b5Mmrb5LSMZ1AjpKFdTJ60= MIME-Version: 1.0 Received: by 10.52.97.104 with SMTP id dz8mr1893146vdb.146.1307656693593; Thu, 09 Jun 2011 14:58:13 -0700 (PDT) Received: by 10.52.169.165 with HTTP; Thu, 9 Jun 2011 14:58:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jun 2011 14:58:13 -0700 Message-ID: From: Greg Mirsky To: Thomas Nadeau , Luca Martini , pwe3 , mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf307f35f4b5b7a804a54e8ced Subject: Re: [mpls] Comments to draft-nadeau-pwe3-vccv-2-01 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, 09 Jun 2011 21:58:15 -0000 --20cf307f35f4b5b7a804a54e8ced Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, perhaps I've missed your response and I've decided to re-post. Regards, Greg On Fri, Mar 11, 2011 at 2:26 PM, Greg Mirsky wrote: > Dear Authors, > please find my comments below. > > - this proposal is closely related to changes to RFC 5586 put forward > in draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the draft. > - RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains > that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS netowrks > GAL might be not a BoS. In your proposal the GAL precedes the PW and thus is > not BoS. But the document's scope is for all MPLS PWs, including over > MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In MPLS-TP (GAL) ... > MUST always be at the bottom of the label stack (i.e., S bit set to 1)" > updated proposed use of GAL is allowed only in non-TP MPLS PSN. > - Section 2 lists of allowed ACH. Since these are hexadecimal numbers > I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". And > I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or "MUST" be > limited to ... A, B, C"? > - In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and > to appropriate value in MS-PW to reach intended PE. Hence my question, Is > this mechanism to reach MIP, i.e. S-PE, or this is mechanism to generate > exception? But that is how PW VCCV Control Channel Type 3 works. What is the > interpretation of GAL in a label stack? To indicate PW CW after the PW LSE? > - editorial - in Abstract s/The MPLS/the MPLS or a reference to, > perhaps, RFC 5654. > > > Regards, > Greg > > > > --20cf307f35f4b5b7a804a54e8ced Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
            perhaps I've missed your response and I've decided= to re-post.

            Regards,
            Greg

            On F= ri, Mar 11, 2011 at 2:26 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
            Dear Authors,
            please find my comments be= low.
            • this proposal is closely related to changes to RFC 5586 put= forward in draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference= to the draft.
            • RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains th= at in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS netowrks GAL= might be not a BoS. In your proposal the GAL precedes the PW and thus is n= ot BoS. But the document's scope is for all MPLS PWs, including over MP= LS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In MPLS-TP (GAL) = ... MUST always be at the bottom of the label stack (i.e., S bit set to 1= )" updated proposed use of GAL is allowed only in non-TP MPLS PSN.
            • Section 2 lists of allowed ACH. Since these are hexadecimal numbers I&#= 39;d suggest prepending them with '0x' to make as "0x07, 0x21,= and 0x57". And I'd ask for clarification of "allowed". = Is it "MAY", "SHOULD" or "MUST" be limited to= ... A, B, C"?
            • In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and t= o appropriate value in MS-PW to reach intended PE. Hence my question, Is th= is mechanism to reach MIP, i.e. S-PE, or this is mechanism to generate exce= ption? But that is how PW VCCV Control Channel Type 3 works. What is the in= terpretation of GAL in a label stack? To indicate PW CW after the PW LSE?
            • editorial - in Abstract s/The MPLS/the MPLS or a reference to, perhaps,= RFC 5654.

            Regards,
            Greg



            --20cf307f35f4b5b7a804a54e8ced-- From mach.chen@huawei.com Thu Jun 9 18:51:25 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 DBFB111E80CE for ; Thu, 9 Jun 2011 18:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3skGQanv0rJN for ; Thu, 9 Jun 2011 18:51:25 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D79AF11E80BA for ; Thu, 9 Jun 2011 18:51:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMJ003MNX0BZX@szxga04-in.huawei.com> for mpls@ietf.org; Fri, 10 Jun 2011 09:48:11 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMJ00MU0X0B87@szxga04-in.huawei.com> for mpls@ietf.org; Fri, 10 Jun 2011 09:48:11 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 10 Jun 2011 09:48:07 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.87]) by szxeml409-hub.china.huawei.com ([169.254.57.252]) with mapi id 14.01.0270.001; Fri, 10 Jun 2011 09:48:10 +0800 Date: Fri, 10 Jun 2011 01:48:09 +0000 From: Mach Chen X-Originating-IP: [10.110.98.37] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: Question about ICC Thread-index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28A== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: Matthew Wright Subject: [mpls] Question about ICC 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, 10 Jun 2011 01:51:26 -0000 Hi, Are ICCs globally unique? According to the definition of ICC in M.1400, it just says that ICCs are un= ique within a country. And there is an example shows that different operato= rs could have the same ICC (e.g., Teleglobe International (UK) Ltd and T=E9= l=E9globe Canada ULC have the ICC code:"TGB").=20 So, if the ICCs are not globally unique, how to guarantee that the ICC-base= d identifiers are globally unique?=20 Or maybe I missed something? Best regards, Mach From Alexander.Vainshtein@ecitele.com Fri Jun 10 06:39: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 F3E4C11E8174 for ; Fri, 10 Jun 2011 06:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 Gi3Ka63b7W08 for ; Fri, 10 Jun 2011 06:39:52 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id B89F311E8172 for ; Fri, 10 Jun 2011 06:39:51 -0700 (PDT) X-AuditID: 93eaf2e8-b7ba4ae000000a73-ad-4df21e427f0c Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id ED.78.02675.24E12FD4; Fri, 10 Jun 2011 16:38:10 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 10 Jun 2011 16:39:49 +0300 From: Alexander Vainshtein To: Mach Chen , "mpls@ietf.org" Date: Fri, 10 Jun 2011 16:37:25 +0300 Thread-Topic: Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjI 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: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRzm3d3maV675myv68Pjsi9ztpnRImcRBOsPySgItKhze9sud7ex OyODyKKSlL6LSAStTOxDrKXZhwiurDQt/yiLvgiS0FWYUolR2Z1XZnR/Pfd7nuf3vO/L70dg hj6dmeAECQUF1sfoYvBjkcHPluXTB7OspRWz7V21cfanvcO4/fm589plmHPPnY9aZ1XVsMb5 88z8bCynCGSwguCXWAnRbiS6HEx2kNvKugoZmnM7GBtDB3ysC/FIkBwMGwggwc1kxtD/fRmy jBNoJLj8bk7wOJiVa1ZZ7PaFiy02JnPWDNuCJTFrvZxIIwvPcj6aR6LIehAtVzbVY96K0k5t oDVqW2flBU0ROKUrAdEEpNLh0J3qKBVPhl2v6+R6DGGgbgD45MQXoBAG6jiA787mK1hHOWDo 4qtRs5FaAcuvXNUqGKNSYEt5B6ZgnJoJDzbcw0sAQcRRifBB60pVTsMD4WtAKRupNLivJleB JLUK3tqdrAatgf2R7tGG0dRa2Ft7eRQD+WRD7Zc0apAJPu+p0KgnpmBV0yNMxfGw7+3P3/p4 +LK4Dqj6VPjsxHGdiufB6tPvR/UkNQm2nerBVW8CbKl5hh8GprJxEWXj7GXj7GXj7JUAvwDi OV9AyuM91rRU5OIk5EOpLj8fAuqg9F4HLzrmhgFFACaWvB81kGXQslvFQj4MEggNE08apw1m GSbm+d2FXlb0bgwW+JAYBpDAGCPZHy1zpJst3I6C/j+UXX7iI5h5gssvj6QgbVxgtf7zw5jI UteHLAPlkScuH6EACv6xTiUIBpIPlcRJQeRB2zZzPukvrSGileRYOfmjoiHFAMuLnEfl24GF +FEeCgMDLvgFZDaRpLwCBkoReQuEsT7KhuwcGRmJAJN85zjyu9IqVt6fsU4ROUQjh+wLDygh 8maMUeYiMDeSMZDUU1IcSm/acqg5TBQ5s2fVJ87hpP6Klu6LxUhKSHPqt38ZEHs3WM1bJFtV 65SvPQU781c/PrmkPejQ+/TzG28f7ef3F+em2/buykspX/cmB/+efdM40vwpvKiAD/UlJrXp 6/S716NvVzNrG+8mcGCHxrSic2ljUmrDBwYXvawtGQuK7C9EpGyN/AMAAA== Cc: Matthew Wright Subject: Re: [mpls] Question about ICC 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, 10 Jun 2011 13:39:53 -0000 Mach, An excellent question! lots of thanks for picking this up! regards, Sasha ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach Chen [= mach.chen@huawei.com] Sent: Friday, June 10, 2011 4:48 AM To: mpls@ietf.org Cc: Matthew Wright Subject: [mpls] Question about ICC Hi, Are ICCs globally unique? According to the definition of ICC in M.1400, it just says that ICCs are uni= que within a country. And there is an example shows that different operators= could have the same ICC (e.g., Teleglobe International (UK) Ltd and T=E9l= =E9globe Canada ULC have the ICC code:"TGB"). So, if the ICCs are not globally unique, how to guarantee that the ICC-based= identifiers are globally unique? Or maybe I missed something? Best regards, Mach _______________________________________________ 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 amalis@gmail.com Fri Jun 10 07:49: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 32D4911E80B6 for ; Fri, 10 Jun 2011 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pCYvRGI6ruEG for ; Fri, 10 Jun 2011 07:49:21 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A96CB11E80B7 for ; Fri, 10 Jun 2011 07:49:20 -0700 (PDT) Received: by bwz13 with SMTP id 13so2672602bwz.31 for ; Fri, 10 Jun 2011 07:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=nawkobDw3MHrfH7rORUzkA5l1xHgptCqcBzEdZSYg7U=; b=AZOE/26VTBwnD99/EnxJynFynqFc/4wocN5i5h9TZMgUFwXgieU/gV5kKvxY2O6ufh /z2hUCO6jxArmoTK/dDdsY87+qZCSMbZ7UW06iisquinXuNnBqHSzbE33mOSdFIm0mva 4kivORitrdiU55s57u+jeeNKSfDRh/pfCmgFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=efNkcxWrQXgmjGogYFwlrz8sZn9CpC0zbv0Vc2rCktL1KEFtlxR4iHUY65Vx6m9w4I feZSL6kasNpe1XSyDvp04wGZ+fPCslQxWC1gLrmXhJaeFXDCLmAI9pH4yxFSBZwVeRQZ xsZzCKwzF7P8usltEZbhe5Qbbgy0l1wnTWks4= Received: by 10.204.33.73 with SMTP id g9mr474543bkd.171.1307717359084; Fri, 10 Jun 2011 07:49:19 -0700 (PDT) MIME-Version: 1.0 Sender: amalis@gmail.com Received: by 10.205.82.138 with HTTP; Fri, 10 Jun 2011 07:48:58 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 10 Jun 2011 10:48:58 -0400 X-Google-Sender-Auth: K7N2lPZwvxcwiQfs0xBkg9LhdLA Message-ID: To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] Fwd: PWE3 WG last call for draft-ietf-pwe3-static-pw-status-04 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, 10 Jun 2011 14:49:22 -0000 The PWE3 WG has just begun WG last call for draft-ietf-pwe3-static-pw-status-04. I'm forwarding the last call announcement to the MPLS list because MPLS-TP makes use of this draft. Please send all last call comments to pwe3@ietf.org . Thanks, Andy ---------- Forwarded message ---------- From: Andrew G. Malis Date: Fri, Jun 10, 2011 at 10:45 AM Subject: PWE3 WG last call for draft-ietf-pwe3-static-pw-status-04 To: pwe3@ietf.org This email begins a two week WG last call for draft-ietf-pwe3-static-pw-status-04 as a Proposed Standard RFC. Please reply to this thread with any last call comments. The last call closes on Friday 24th June 2011. Regards, Andy & Matthew From rcallon@juniper.net Fri Jun 10 18:07:25 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 2D17B11E8113 for ; Fri, 10 Jun 2011 18:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 H3kki4BSDYel for ; Fri, 10 Jun 2011 18:07:24 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4829C9E802C for ; Fri, 10 Jun 2011 18:07:16 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTfK/vuWAe6mntjE/D/bDHMJTm1whCbf8@postini.com; Fri, 10 Jun 2011 18:07:24 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; Fri, 10 Jun 2011 18:03:29 -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; Fri, 10 Jun 2011 21:03:28 -0400 From: Ross Callon To: "mpls@ietf.org" , MPLS-TP ad hoc team Date: Fri, 10 Jun 2011 21:03:26 -0400 Thread-Topic: End of Last Call RE: wg last call on resolution of last call comments on draft-ietf-mpls-tp-linear-protection Thread-Index: AcwhyPjJn2+8Z5djR7aDKzhcPg9siAF6/ZqQ Message-ID: References: <4DE89C6B.5070108@pi.nu> In-Reply-To: <4DE89C6B.5070108@pi.nu> 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] End of Last Call RE: wg last call on resolution of last call 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, 11 Jun 2011 01:07:25 -0000 This one week limited WG last call has now ended. The document has passed W= G last call and will be submitted for publication.=20 The authors have agreed to update the document to reflect the minor comment= s from Greg Mirsky along with any AD comments that might be received during= the normal document review process.=20 Thanks, Ross (as co-chair) -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Friday, June 03, 2011 4:34 AM To: mpls@ietf.org; MPLS-TP ad hoc team Cc: George Swallow; Ross Callon Subject: wg last call on resolution of last call comments on draft-ietf-mpl= s-tp-linear-protection working Group, the authors of the linear protection draft has updated after working group last call and published a new version. This is a one week limited working group last call to verify that the comments been appropriately addressed. The new draft will be found here: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-07= .txt And the specification on how the comments been addressed here: http://www.pi.nu/~loa/LastCallCommentsResolved-linear-protection Please send comments to the mpls working group mailing list on June 10th the latest. /Loa for the MPSL wg chairs --=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 From internet-drafts@ietf.org Sat Jun 11 18:06: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 85F1821F84F1; Sat, 11 Jun 2011 18:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 F+HCvnfmOCAl; Sat, 11 Jun 2011 18:06:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141CF21F84ED; Sat, 11 Jun 2011 18:06:02 -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.55 Message-ID: <20110612010602.17070.54935.idtracker@ietfa.amsl.com> Date: Sat, 11 Jun 2011 18:06:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-gtsm-01.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: Sun, 12 Jun 2011 01:06:02 -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 : The Generalized TTL Security Mechanism (GTSM) for Label = Distribution Protocol (LDP) Author(s) : Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ldp-gtsm-01.txt Pages : 7 Date : 2011-06-11 The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-01.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-gtsm-01.txt From adrian@olddog.co.uk Sun Jun 12 02:55: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 B1DBA21F8485 for ; Sun, 12 Jun 2011 02:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 KOjGOQiZZ9jQ for ; Sun, 12 Jun 2011 02:55:49 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E6D3621F8486 for ; Sun, 12 Jun 2011 02:55:47 -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 p5C9tkWS015838; Sun, 12 Jun 2011 10:55:46 +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 p5C9tiZR015759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Jun 2011 10:55:45 +0100 From: "Adrian Farrel" To: Date: Sun, 12 Jun 2011 10:55:37 +0100 Message-ID: <0c0a01cc28e6$e2338c80$a69aa580$@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: Acwo5tJ/5sT9Vj2CSH+qsw+Du688jg== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-mldp-recurs-fec 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, 12 Jun 2011 09:55:49 -0000 Hi, Don't panic! I have carried out my usual AD review of your draft. The purpose of the review is to iron out any wrinkles before the document goes to IETF last call and IESG review, the better to ensure smooth passage through those stages and rapid adoption as an RFC. Thank you for a well-written and clear document. I have no technical concerns with your work. There is one relatively important editorial point I would like you to resolve, and while you are at it, there are a few nits that can be mopped up. I think this merits a new revision, if you don't mind. As soon as I see it, I will kick off the IETF last call. I have also asked the document shepherd to find out about the implementation status for me. Implementation is not a requirement, but the write-up needs to give the information. Obviously, at least an intent to implement is strongly desirable. Many thanks, Adrian --- I don't think including Figure 1 here actually adds to the readability of the document. And, as usual, when there is a duplicated definition we have to worry about cross-checking and stating which document contains the normative definition. It would be better if you could delete the figure and simply reference [mLDP]. --- Rather trivially, the text about Figure 2 does not state what R is. Suggest... s/route for R/route for R in the customer network/ --- Section 1 s/from CE1 address to R/from CE1 addressed to R/ --- The term "mLDP" turns up unexplained. Can you insert an expansion? --- Section 2.2 It is not so important, but... PE1 therefore MUST create a new MP FEC element I don't think this is really a "MUST". I'd be happy with... PE1 creates a new MP FEC element Similarly... PE1 then MUST send this FEC element to P1. becomes... PE1 then sends this FEC element to P1. This shows again in 3.2.2 --- Section 2.2 PE2-FEC = , or PE2-FEC = > With my small brain that is easily confused, I found "or" misleading. Would "i.e." be more accurate? --- Section 2.2 This will result in CE1-FEC being sent on to CE2, and presumably further from CE2 to R. Strike "presumably" because [mLDP] makes this clear. --- Section 3.1 This is the second Figure 3! The text about this figure doesn't match the figure itself. The figure shows two explicit fields (RD and FEC), but the text talks about *the* value field. --- Section 5 It might be advisable to include an informational reference to RFC 5920 From loa@pi.nu Sun Jun 12 07:34:50 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 0C10611E80BC for ; Sun, 12 Jun 2011 07:34:50 -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 Hw6IG3XlEy-H for ; Sun, 12 Jun 2011 07:34:49 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id E77FC11E80B8 for ; Sun, 12 Jun 2011 07:34:48 -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 C5118514044; Sun, 12 Jun 2011 16:34:46 +0200 (CEST) Message-ID: <4DF4CE85.4010006@pi.nu> Date: Sun, 12 Jun 2011 07:34:45 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mpls@ietf.org References: <0c0a01cc28e6$e2338c80$a69aa580$@olddog.co.uk> In-Reply-To: <0c0a01cc28e6$e2338c80$a69aa580$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-mldp-recurs-fec@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-recurs-fec 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, 12 Jun 2011 14:34:50 -0000 Working Group, we have requested that draft-ietf-mpls-mldp-recurs-fec is published as an RFC on the standards track. The document shepherd has a question on implementation status, when the shepherd write up was written I had no such info, and really believed that it was not that important. We are filling a rather obvious hole in the spec, and anyone who have am implementation of the base spec should be interested in adding this piece. Anyhow, the shepherding AD has asked for info on the implementation status. Can you send info on this to the mailing list or to the the document shepherd (me): Do you have an implementation of draft-ietf-mpls-mldp-recurs-fec? Do you have intentions to implement the draft? /Loa On 2011-06-12 02:55, Adrian Farrel wrote: > Hi, > > Don't panic! > > I have carried out my usual AD review of your draft. The purpose of the > review is to iron out any wrinkles before the document goes to IETF last > call and IESG review, the better to ensure smooth passage through those > stages and rapid adoption as an RFC. > > Thank you for a well-written and clear document. I have no technical > concerns with your work. There is one relatively important editorial > point I would like you to resolve, and while you are at it, there are > a few nits that can be mopped up. > > I think this merits a new revision, if you don't mind. As soon as I see > it, I will kick off the IETF last call. > > I have also asked the document shepherd to find out about the > implementation status for me. Implementation is not a requirement, but > the write-up needs to give the information. Obviously, at least an > intent to implement is strongly desirable. > > Many thanks, > Adrian > > --- > > I don't think including Figure 1 here actually adds to the readability > of the document. And, as usual, when there is a duplicated definition > we have to worry about cross-checking and stating which document > contains the normative definition. It would be better if you could delete > the figure and simply reference [mLDP]. > > --- > > Rather trivially, the text about Figure 2 does not state what R is. > Suggest... > > s/route for R/route for R in the customer network/ > > --- > > Section 1 > > s/from CE1 address to R/from CE1 addressed to R/ > > --- > > The term "mLDP" turns up unexplained. Can you insert an expansion? > > --- > > Section 2.2 > > It is not so important, but... > > PE1 therefore MUST create a new MP FEC element > > I don't think this is really a "MUST". I'd be happy with... > > PE1 creates a new MP FEC element > > Similarly... > PE1 then MUST send this FEC element to P1. > becomes... > PE1 then sends this FEC element to P1. > > This shows again in 3.2.2 > > --- > > Section 2.2 > > PE2-FEC =, or > > PE2-FEC = opaque_value=Q>> > > With my small brain that is easily confused, I found "or" misleading. > Would "i.e." be more accurate? > > --- > > Section 2.2 > > This will result in CE1-FEC being sent on to CE2, and > presumably further from CE2 to R. > > Strike "presumably" because [mLDP] makes this clear. > > --- > > Section 3.1 > > This is the second Figure 3! > > The text about this figure doesn't match the figure itself. The figure > shows two explicit fields (RD and FEC), but the text talks about *the* > value field. > > --- > > Section 5 > > It might be advisable to include an informational reference to RFC 5920 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- 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 internet-drafts@ietf.org Sun Jun 12 10:12: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 BCB2F11E80FA; Sun, 12 Jun 2011 10:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 TutmMVsP1ojh; Sun, 12 Jun 2011 10:12:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2893211E80F7; Sun, 12 Jun 2011 10:12:38 -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.55 Message-ID: <20110612171238.16501.87864.idtracker@ietfa.amsl.com> Date: Sun, 12 Jun 2011 10:12:38 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-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: Sun, 12 Jun 2011 17:12:38 -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-04.txt Pages : 27 Date : 2011-06-12 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 would be required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overv= iew-04.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-04.txt From daniel@olddog.co.uk Sun Jun 12 14:31: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 4BC5C11E8118 for ; Sun, 12 Jun 2011 14:31:30 -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 Qpwg-VkDsf21 for ; Sun, 12 Jun 2011 14:31:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 613CF11E80C4 for ; Sun, 12 Jun 2011 14:31:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5CLVBYV027523 for ; Sun, 12 Jun 2011 22:31:11 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5CLVARC027517 for ; Sun, 12 Jun 2011 22:31:10 +0100 From: "Daniel King" To: References: <20110612171238.16501.87864.idtracker@ietfa.amsl.com> In-Reply-To: <20110612171238.16501.87864.idtracker@ietfa.amsl.com> Date: Sun, 12 Jun 2011 22:31:26 +0100 Message-ID: <006401cc2948$15e44f90$41aceeb0$@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: AQKFoW/Tbnhh1gyd+SuC2P0q3igA85NHSzMA Content-Language: en-gb Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-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: Sun, 12 Jun 2011 21:31:30 -0000 Hi All, Please find a new version of our MPLS-TP MIB-based Management Overview: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvi ew-04.txt We made a number of changes, specifically: - Addressed comments from ITU-T Study Group 15 (thank you all for comments). - Defined MPLS-TP Management Function. - Cleaned up MPLS and Pseudowire MIB Module text. - Expanded Resiliency section and various options. - Updated Pseudowire Module section. - Clarified dependencies on external MIB Modules. In addition to various grammar and readability updates we have endeavoured to remove superfluous text. The authors now feel the document is relatively stable. Br, mib-management-overview authors. From ma.yuxia@zte.com.cn Mon Jun 13 05:25: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 C925D9E800A for ; Mon, 13 Jun 2011 05:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, 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 bjkna2FBs4dU for ; Mon, 13 Jun 2011 05:25:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5EE9E8009 for ; Mon, 13 Jun 2011 05:25:15 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 39584806486374; Mon, 13 Jun 2011 20:22:46 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 23654.872730635; Mon, 13 Jun 2011 20:24:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5DCOrD2038807; Mon, 13 Jun 2011 20:24:53 +0800 (GMT-8) (envelope-from ma.yuxia@zte.com.cn) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ma.yuxia@zte.com.cn Date: Mon, 13 Jun 2011 20:24:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-13 20:24:56, Serialize complete at 2011-06-13 20:24:56 Content-Type: multipart/alternative; boundary="=_alternative 0044404A482578AE_=" X-MAIL: mse02.zte.com.cn p5DCOrD2038807 Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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: Mon, 13 Jun 2011 12:25:20 -0000 This is a multipart message in MIME format. --=_alternative 0044404A482578AE_= Content-Type: text/plain; charset="US-ASCII" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel --=_alternative 0044404A482578AE_= Content-Type: text/html; charset="US-ASCII"

            Hi all,

            The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.

            BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".

             "
              Figure 1 illustrates such a scenario, where two MS-PWs are
              established between T-PE A and             T-PE B, over S-PEs 1-2 and 3-4
              respectively. Each PW segment is established over an LSP (e.g. PW-
              s12 over LSP12).
             "

            -----Original Message-----
            From: Daniel Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicability to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)

            The abstract goes:

            One of the requirements of the MPLS transport profile [RFC 5654] is
            to provide linear protection for transport paths, which include both
            LSPs and PWs. The functional architecture described in [SurvivFwk]
            is applicable to both LSP and PWs, however [LinearProt] does not
            explicitly describe mechanisms for PW protection in MPLS-TP.

            This document extends the applicability of the linear protection
            mechanism described in [LinearProt] to MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC 6073].

            Could you please review it and send feedback to the mailing list or
            directly to the author?

            Looking forward to your feedback,

            Daniel

            --=_alternative 0044404A482578AE_=-- From Alexander.Vainshtein@ecitele.com Mon Jun 13 05:43:34 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 461E721F8476; Mon, 13 Jun 2011 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396] 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 o94Y5O8mnwRs; Mon, 13 Jun 2011 05:43:33 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id EE28221F847F; Mon, 13 Jun 2011 05:43:31 -0700 (PDT) X-AuditID: 93eaf2e8-b7c74ae000000a6f-b6-4df605903a4c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 48.2F.02671.09506FD4; Mon, 13 Jun 2011 15:41:52 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 13 Jun 2011 15:43:29 +0300 From: Alexander Vainshtein To: "ma.yuxia@zte.com.cn" Date: Mon, 13 Jun 2011 15:43:26 +0300 Thread-Topic: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQ 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_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURjlzszujubUuPm4icU0UqC15WbFRq4UWRioPTGqHznOXncnd2eW mTE0iLaiAiuxpJdFL1TyUYH0frcRsWL2gJ5m/VijspAws/xhNrOT5p/+nXu+c849M3yXxK3b LEmkIKpIFjkva44mqrt7+2xVpv689CtVEx0/jrzGHW/qGkyOyt6LxAI8p7Z2AMtpvv2LWI6t C4BMThQllVMR40IK72SXy8Imji9nGcHlZO0s4/dyPPIhUXWynN+PRBebFZ2pkYLIIJGXXILo drJLVy2zORxz5tnsbNbUFHvG/OjVHkFhkM3HCV7GhxSFcyNGY/Saogu5mGJJZlQPYuTCatxz 7DrvH9hY1j64JgDqCytAFAnp2fB4uAUYOAE+eXfBXAGiSSt9A8BHH0KYcTgE4Pmmp4SuMtNO 2NLUadZxHD0T7jgajrhxOhu++9hq0TFBT4HBgV0mHY+nC2HrvtsWQ8/BS6GzuIFnwWvnnkd4 il4Gh0IfI/lWeiW88rU/oomiV8GOz/ciPNDa/Wxtxoy7EuGbrpOY0ZqGtTcf4waOh5/Dv02G Ph6+3X3hbzcJ9oT6/t4VC0NHuwhDPwHeO/uKqAIJNaNia0ZZakZZDH46PHWj12zgabD+9Bd8 GLfdDWOj+VPA0gjiBa9fLfK502fNQLygIi+awUu+FmDsz6eroKMtNQhoErAxVPBxX57VxG1S yn1BMIHE2HiqkujPs44tklzlHk7xbJBLvUgJAkjibBy1r1uTUy6ufDOSpeHRYu3v78eTxvCS vgLqhoz09P8f2ERqD/81z0q7tcUsQciP5OGcZJJkIZWtbbc1VkZuVFYseNV/Y4yM0mvEaDVy 9YqU4ud8iuA25q1gclIitUI30/rAUyqOePWXs3VoaKgbJGofPZ6y6KoYbWFH3N1aMKYF06Xf 9WDt0YyMkgLgekn44MvvzvzL49oJoXr91TkHYzvrYooLHr4I2NqXdJwJlOR+i8u5H+e8lJJV +cKfNii93ZiWO2327nzHiXUJB/IfPW8kkgu2hK4dLn3wfvvO1JU9HzBkWZu9sMsxd5K6qIdY WP/LB24eaeDaJsL2OxnWinHnOm8pq/c6mp7Zi843s4Ti4expuKxwfwDDXEeLFAQAAA== Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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: Mon, 13 Jun 2011 12:43:34 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of m= any additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses= cases in addition to MS-PW with single-homed CEs (which is listed there as= use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Sta= tic PW Status Messages draft( if, for whatever reason, you do not wa= nt to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.y= uxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appli= cability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be th= e same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel 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_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

            Dear Ma and= all,

            Adding the PWE3 WG to= my response.

             

            The PW redundancy mechanism support= s linear protection of MS-PWs as one of many additional application use case= s:

            Appendix A of the PW redundancy Bit draft describes 5 application uses cases in= addition to MS-PW with single-homed CEs (which is listed there as use case= 5).

            And it is equally appli= cable to IP/MPLS and MPLS - with the help of  the St= atic PW Status Messages draft( if, for whatever reason, you do not want=  to, or cannot, use RFC 4447).

             

            Hence I doubt= the need for yet another PW redundancy  mechanism with narrow scope of= applicability.

             <= /o:p>

            Regards,

                 Sasha

             

            <= p class=3DMsoNormal>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] <= b>On Behalf Of ma.yuxia@zte.com.cn
            Sent: Monday, June 13, 2011= 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [mpls] Seeking f= eedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW"<= o:p>

             

            <= p>Hi all,

            The linear protection mechanism for LSP and PW(including MS-PW) sho= uld be the same and it is valuable to describe it clearly.

            BTW, there i= s a typo, it is "T-PE Z" instead of "T-PE B".

             "
              Figure 1 illustrates such= a scenario, where two MS-PWs are
              established between T-PE A and T-PE B            , over S-PEs 1-2 and 3-4
              respec= tively. Each PW segment is established over an LSP (e.g. PW-
              s12 ove= r LSP12).
             "

            -----Original Message-----
            From: Daniel Cohn
            Sent: Tuesday, May= 17, 2011 4:14 PM
            To: mpls
            Subject: Seeking feedback on I-D "MPLS= -TP Linear Protection
            Applicability to MS-PW"
            Importance: High
            Hi MPLSers,

            I uploaded "MPLS-TP Linear Protection Applicabi= lity to MS-PW" I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw= -protection-00)

            The abstract goes:
            <= br>One of the requirements of the MPLS transport profile [RFC 5654] is
            to= provide linear protection for transport paths, which include both
            LSPs a= nd PWs. The functional architecture described in [SurvivFwk]
            is applicabl= e to both LSP and PWs, however [LinearProt] does not
            explicitly describe= mechanisms for PW protection in MPLS-TP.
            <= br>This document extends the applicability of the linear protection
            mecha= nism described in [LinearProt] to MPLS-TP segmented PWs
            (MS-PWs) as defi= ned in [RFC 6073].

            Could you please review it and send feedback to th= e mailing list or
            directly to the author?

            Looking forward to your= feedback,

            Daniel

            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_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_-- From binnyjeshan@gmail.com Mon Jun 13 05:58: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 DC6FC1F0C44; Mon, 13 Jun 2011 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 K8fOiHVBfQal; Mon, 13 Jun 2011 05:58:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 968611F0C3D; Mon, 13 Jun 2011 05:58:09 -0700 (PDT) Received: by yxt33 with SMTP id 33so643142yxt.31 for ; Mon, 13 Jun 2011 05:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q36mHbhPccEYf6AdrexTUhzXrwvL+RA2MMsSvVl7/aw=; b=jQFVIfGRRV7jsHf3e1NjuZ8Qjd4t+uYJfGAVx0udhKUqRvZCZYlUlAZwSZ7AIvvxX5 r3Wd4kD3g2TWD44oJK1x0C5noFq2snNbbdqDLHhbj4RKfieTOP8uKs9syIIM136Fm4+B +uYkbdi5G0bkb2zuT9Md0M+N+KswI+jyJdGEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jWlWvcdZhsmH6rRRsjnbunYsmHIWGjI3kA5hoXz3ft6gsrR0NCe4T9oyzAl2NSSnKt zR6yMWNaK/8o8IoiIfKAbqDbCkk6BgP8l2/m9W6BI1cMYzvkYxZCWM+cSwSDRLdZBt5u Lvmsn+0FFDsjMxxjN0LuiF99OMChYtWX7VyGw= MIME-Version: 1.0 Received: by 10.101.138.14 with SMTP id q14mr5060715ann.49.1307969888534; Mon, 13 Jun 2011 05:58:08 -0700 (PDT) Received: by 10.100.226.6 with HTTP; Mon, 13 Jun 2011 05:58:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Jun 2011 18:28:08 +0530 Message-ID: From: binny jeshan To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=0016e6d27c62953fac04a5977843 Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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: Mon, 13 Jun 2011 12:58:11 -0000 --0016e6d27c62953fac04a5977843 Content-Type: text/plain; charset=ISO-8859-1 Hello authors, I have a generic question on the *co-existence* of PW monitoring at the MS-PW level (PSMEG) and the individual segment level (PMEG). Firstly, I believe there is no such restriction on having co-existence in monitoring these independently.. Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment MSPW fails, its quite possible that the PSMEG also detects it at the endpoints. Now, what would determine the switching priority? Wouldn't it become * costlier* if the PSMEG does a MS-PW level switching? Instead, one could prefer to switch to a backup path at a segment level itself. Is this addressed? Thanks, Binny. On 13 June 2011 18:13, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Dear Ma and all, > > Adding the PWE3 WG to my response. > > > > The PW redundancy mechanism supports linear protection of MS-PWs as one of > many additional application use cases: > > Appendix A of the PW redundancy Bit draftdescribes 5 application uses cases in addition to MS-PW with single-homed > CEs (which is listed there as use case 5). > > And it is equally applicable to IP/MPLS and MPLS - with the help of the Static > PW Status Messages draft( > if, for whatever reason, you do not want to, or cannot, use RFC 4447 > ). > > > > Hence I doubt the need for yet another PW redundancy mechanism with narrow > scope of applicability. > > > > Regards, > > Sasha > > > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf Of > *ma.yuxia@zte.com.cn > *Sent:* Monday, June 13, 2011 3:25 PM > *To:* mpls@ietf.org > *Subject:* Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > > > > Hi all, > > The linear protection mechanism for LSP and PW(including MS-PW) should be > the same and it is valuable to describe it clearly. > > BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". > > " > Figure 1 illustrates such a scenario, where two MS-PWs are > established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 > respectively. Each PW segment is established over an LSP (e.g. PW- > s12 over LSP12). > " > > -----Original Message----- > From: Daniel Cohn > Sent: Tuesday, May 17, 2011 4:14 PM > To: mpls > Subject: Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > Importance: High > > Hi MPLSers, > > I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D > (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) > > The abstract goes: > > One of the requirements of the MPLS transport profile [RFC 5654] is > to provide linear protection for transport paths, which include both > LSPs and PWs. The functional architecture described in [SurvivFwk] > is applicable to both LSP and PWs, however [LinearProt] does not > explicitly describe mechanisms for PW protection in MPLS-TP. > > This document extends the applicability of the linear protection > mechanism described in [LinearProt] to MPLS-TP segmented PWs > (MS-PWs) as defined in [RFC 6073]. > > Could you please review it and send feedback to the mailing list or > directly to the author? > > Looking forward to your feedback, > > Daniel > > 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 > > --0016e6d27c62953fac04a5977843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello authors,

            I have a generic question on the co-existence = of PW monitoring at the MS-PW level (PSMEG) and the individual segment leve= l (PMEG). Firstly, I believe there is no such restriction on having co-exis= tence in monitoring these independently..

            Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment = MSPW fails, its quite possible that the PSMEG also detects it at the endpoi= nts. Now, what would determine the switching priority? Wouldn't it beco= me costlier if the PSMEG does a MS-PW level switching? Instead, one = could prefer to switch to a backup path at a segment level itself. Is this = addressed?

            Thanks,
            Binny.

            On 13 June 2011 18:= 13, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wro= te:

            Dear Ma and all,

            Addin= g the PWE3 WG to my response.

            =A0

            The PW redundancy mechanism su= pports linear protection of MS-PWs as one of many additional application us= e cases:

            Appen= dix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed= CEs (which is listed there as use case 5).

            And i= t is equally applicable to IP/MPLS and MPLS - with the help of =A0the Static PW Status Messages draft( if, f= or whatever reason, you do not want =A0to, or cannot, use RFC = 4447).

            =A0

            Hence I doubt the need for yet another PW redundancy =A0mechanism with = narrow scope of applicability.

            =A0

            Regards,

            =A0=A0=A0=A0 Sasha

            =A0

            From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf= Of ma.yuxia@z= te.com.cn
            Sent: Monday, June 13, 2011 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [= mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability= to MS-PW"

            =A0

            Hi all,

            The linear protec= tion mechanism for LSP and PW(inclu= ding MS-PW) should be the same and it is valuable to describe it clearly.

            BTW, there is a typo, it is "T-PE= Z" instead of "T-PE B". <= /span>

            =A0"
            =A0 Figure 1 illustrates such a scenario, where two MS-PWs are
            =A0 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
            =A0 respectively. Each PW segment is established over an LSP (e.g. PW-
            =A0 s12 over LSP12).
            =A0"

            -----Original Message-----
            From: Daniel Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Su= bject: Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicabi= lity to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploade= d "MPLS-TP Linear Protection Applicability to MS-PW" I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protect= ion-00)

            The abstract goes:

            One of the requirements of the = MPLS transport profile [RFC 5654] is
            to provide linear protection for tr= ansport paths, which include both
            LSPs and PWs. The functional architect= ure described in [SurvivFwk]
            is applicable to both LSP and PWs, however [LinearProt] does not
            explici= tly describe mechanisms for PW protection in MPLS-TP.

            This document extends the applicability of the linear protection
            mechani= sm described in [LinearProt] to MPLS-TP segmented PWs
            (MS-PWs) as defin= ed in [RFC 6073].

            Could you please review it and send feedback to th= e mailing list or
            directly to the author?

            Looking forward to your feedback,

            D= aniel

            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


            --0016e6d27c62953fac04a5977843-- From nurit.sprecher@nsn.com Mon Jun 13 06:02:34 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 552BB21F84A8; Mon, 13 Jun 2011 06:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 9pFYwjmFGbm8; Mon, 13 Jun 2011 06:02:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17B21F84AC; Mon, 13 Jun 2011 06:02:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5DD2Tdq005836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 15:02:29 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5DD2StM016885; Mon, 13 Jun 2011 15:02:28 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 15:02:28 +0200 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_01CC29CA.26091F69" Date: Mon, 13 Jun 2011 15:02:24 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskA= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" , X-OriginalArrivalTime: 13 Jun 2011 13:02:28.0503 (UTC) FILETIME=[26070A70:01CC29CA] Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-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: Mon, 13 Jun 2011 13:02:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29CA.26091F69 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 ------_=_NextPart_001_01CC29CA.26091F69 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

            Hi,

            I would like to second Sasha.

            End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

            MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

            If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

            When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

            I also doubt why there is a need for additional mechanism. =

            Best regards,

            Nurit

             

            From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
            Sent: Monday, June 13, 2011 3:43 = PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; = pwe3@ietf.org
            Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

             

            Dear Ma and all,

            Adding the PWE3 WG to my response.

             

            The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

            Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

            And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

             

            Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

             

            Regards,

                 Sasha

             

            From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
            Sent: Monday, June 13, 2011 3:25 = PM
            To: mpls@ietf.org
            Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

             

            Hi all,

            The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

            BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

             &qu= ot;
              = Figure 1 illustrates such a scenario, where two MS-PWs are
              = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
              = respectively. Each PW segment is established over an LSP (e.g. = PW-
              = s12 over LSP12).
             &qu= ot;

            -----Original Message-----
            From: Daniel = Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicability = to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
            The abstract goes:

            One of the requirements of the MPLS = transport profile [RFC 5654] is
            to provide linear protection for = transport paths, which include both
            LSPs and PWs. The functional = architecture described in [SurvivFwk]
            is applicable to both LSP and = PWs, however [LinearProt] does not
            explicitly describe mechanisms for = PW protection in MPLS-TP.

            This document extends the applicability = of the linear protection
            mechanism described in [LinearProt] to = MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC = 6073].

            Could you please review it and send feedback to the = mailing list or
            directly to the author?

            Looking forward to = your feedback,

            Daniel

            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.

            ------_=_NextPart_001_01CC29CA.26091F69-- From binnyjeshan@gmail.com Mon Jun 13 06:31: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 EDB799E8012; Mon, 13 Jun 2011 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 yrOPAFa9RBqN; Mon, 13 Jun 2011 06:31:29 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5099E8007; Mon, 13 Jun 2011 06:31:29 -0700 (PDT) Received: by yie30 with SMTP id 30so1205845yie.31 for ; Mon, 13 Jun 2011 06:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zqg45oH2ohCDPaIYxZTNC7ujPGS4+h5d2kLCSSqUpE0=; b=dIsUOwujnmO+5iLY5bMdvXdMorKMlGkOQjZLJqheWmdjUFitEEzZg493dPsER/6mh7 Y1n3zPoJg5yuW7jkuha38h3d3LsWrTRfKiwCHakjfsYkDmry7vM0s1wvMWnS7Ya1Nk6F GtWe/exVtX4LaDTJcWVZQ0s/RzXTY7XK4TGqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NuP8CpQ14OuyNlC/+1jhAVOLez4woWH4lsV5aL9uBEljEhOKXNQTB0feGR5tN5Kitk JPCydTwbX17Wv0swYuxRERMHJxs2gRtu4su0ZTiOlQvUSJiVRIXa2LN7QNDxqEljips2 bMUFPCiDqZDVW8wRm1Na8JMggUCT+GvG5ob5U= MIME-Version: 1.0 Received: by 10.101.175.33 with SMTP id c33mr5054575anp.93.1307971888682; Mon, 13 Jun 2011 06:31:28 -0700 (PDT) Received: by 10.100.226.6 with HTTP; Mon, 13 Jun 2011 06:31:28 -0700 (PDT) In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> Date: Mon, 13 Jun 2011 19:01:28 +0530 Message-ID: From: binny jeshan To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Content-Type: multipart/alternative; boundary=001636c5c006cd168904a597efba Cc: pwe3@ietf.org, mpls@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-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: Mon, 13 Jun 2011 13:31:31 -0000 --001636c5c006cd168904a597efba Content-Type: text/plain; charset=ISO-8859-1 Hello, Though on one side I'd think its costlier to do a MS-PW level protection considering the resource usages, pre-configuration and monitoring overload, on the other i would think - why wouldn't having such a mechanism help in case if a local repair procedure fails ( failure in protection switch) for a underlying broken LSP or a mid-PW segment. A provider would never hesitate look into his pocket to have an end-end level protection considering a risky situation for an high priority service that he runs on the MS-PW. Wouldn't he? I believe he could be only concerned in the view of giving precedence to efficient switching the server layers, and not messing up with multiple switches happening for one failure. -Binny. On 13 June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) < nurit.sprecher@nsn.com> wrote: > Hi, > > I would like to second Sasha. > > End-to-end PW protection (with diverse paths) does not scale, and put hard > restrictions on the utilization of the resources. > > MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, > an obvious way to provide protection for a PW is to protect the LSP that > carries it. > > If the PW is a multi-segment PW, then LSP recovery can only protect the PW > in individual segments. This means that a single LSP recovery action cannot > protect against a failure of a PW switching point (an S-PE). > > When protecting against an AC or T/S-PE failure by dual connectivity, PW > redundancy mechanisms provide means for the PEs to coordinate over which LSP > the traffic of the PW is carried. > > I also doubt why there is a need for additional mechanism. > > Best regards, > > Nurit > > > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf Of > *ext Alexander Vainshtein > *Sent:* Monday, June 13, 2011 3:43 PM > *To:* ma.yuxia@zte.com.cn > *Cc:* mpls@ietf.org; pwe3@ietf.org > *Subject:* Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP > LinearProtection Applicability to MS-PW" > > > > Dear Ma and all, > > Adding the PWE3 WG to my response. > > > > The PW redundancy mechanism supports linear protection of MS-PWs as one of > many additional application use cases: > > Appendix A of the PW redundancy Bit draftdescribes 5 application uses cases in addition to MS-PW with single-homed > CEs (which is listed there as use case 5). > > And it is equally applicable to IP/MPLS and MPLS - with the help of the Static > PW Status Messages draft( > if, for whatever reason, you do not want to, or cannot, use RFC 4447 > ). > > > > Hence I doubt the need for yet another PW redundancy mechanism with narrow > scope of applicability. > > > > Regards, > > Sasha > > > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf Of > *ma.yuxia@zte.com.cn > *Sent:* Monday, June 13, 2011 3:25 PM > *To:* mpls@ietf.org > *Subject:* Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > > > > Hi all, > > The linear protection mechanism for LSP and PW(including MS-PW) should be > the same and it is valuable to describe it clearly. > > BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". > > " > Figure 1 illustrates such a scenario, where two MS-PWs are > established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 > respectively. Each PW segment is established over an LSP (e.g. PW- > s12 over LSP12). > " > > -----Original Message----- > From: Daniel Cohn > Sent: Tuesday, May 17, 2011 4:14 PM > To: mpls > Subject: Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > Importance: High > > Hi MPLSers, > > I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D > (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) > > The abstract goes: > > One of the requirements of the MPLS transport profile [RFC 5654] is > to provide linear protection for transport paths, which include both > LSPs and PWs. The functional architecture described in [SurvivFwk] > is applicable to both LSP and PWs, however [LinearProt] does not > explicitly describe mechanisms for PW protection in MPLS-TP. > > This document extends the applicability of the linear protection > mechanism described in [LinearProt] to MPLS-TP segmented PWs > (MS-PWs) as defined in [RFC 6073]. > > Could you please review it and send feedback to the mailing list or > directly to the author? > > Looking forward to your feedback, > > Daniel > > 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. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001636c5c006cd168904a597efba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

            Though on one side I'd think its costlier to do a MS-PW level protectio= n considering the resource usages, pre-configuration and monitoring=20 overload, on the other i would think - why wouldn't having such a=20 mechanism help in case if a local repair procedure fails ( failure in prote= ction=20 switch) for a underlying broken LSP or a mid-PW segment. A provider=20 would never hesitate look into his pocket to have an end-end level=20 protection considering a risky situation for an high priority service=20 that he runs on the MS-PW. Wouldn't he? I believe he could be only conc= erned in the view of giving precedence to efficient switching the server la= yers, and not messing up with multiple switches happening for one failure.<= br>
            -Binny.

            On 13 June 2011 18:32, Sprecher, = Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com> wrote:

            Hi,

            I would like = to second Sasha.

            End-t= o-end PW protection (with diverse paths) does not scale, and put hard restr= ictions on the utilization of the resources. =A0

            MPLS-TP PWs are carried acro= ss the network inside MPLS-TP LSPs. Therefore, an obvious way to provide pr= otection for a PW is to protect the LSP that carries it.=A0

            If the PW is a multi-segment= PW, then LSP recovery can only protect the PW in individual segments.=A0 T= his means that a single LSP recovery action cannot protect against a failur= e of a PW switching point (an S-PE).

            When = protecting against an AC or T/S-PE failure by dual connectivity, PW redunda= ncy mechanisms provide means for the PEs to coordinate over which LSP the t= raffic of the PW is carried.

            I als= o doubt why there is a need for additional mechanism.

            Best regards,=

            Nurit=

            =A0

            From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of ext Alexander Vainshtein
            Sent: Monday, June 13, 2011 3:43 PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@ietf.org
            Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Lin= earProtection Applicability to MS-PW"

            =

            =A0

            Dear Ma and all,

            Addin= g the PWE3 WG to my response.

            =A0

            The PW redundancy mechanism su= pports linear protection of MS-PWs as one of many additional application us= e cases:

            Appen= dix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed= CEs (which is listed there as use case 5).

            And i= t is equally applicable to IP/MPLS and MPLS - with the help of =A0the Static PW Status Messages draft( if, f= or whatever reason, you do not want =A0to, or cannot, use RFC = 4447).

            =A0

            Hence I doubt the need for yet another PW redundancy =A0mechanism with = narrow scope of applicability.

            =A0

            Regards,

            =A0=A0=A0=A0 Sasha

            =A0

            From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf= Of ma.yuxia@z= te.com.cn
            Sent: Monday, June 13, 2011 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [= mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability= to MS-PW"

            =A0

            Hi all,

            The linear protection mechanism for LSP and PW(including MS-PW) should be the same and= it is valuable to describe it clearly.

            BTW, there is a typo, it is "T-PE= Z" instead of "T-PE B". <= /span>

            =A0"
            =A0 Figure 1 illustrates such a scenario, where two MS-PWs are
            =A0 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
            =A0 respectively. Each PW segment is established over an LSP (e.g. PW-
            =A0 s12 over LSP12).
            =A0"

            -----Original Message-----
            From: Daniel Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Su= bject: Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicabi= lity to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploade= d "MPLS-TP Linear Protection Applicability to MS-PW" I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protect= ion-00)

            The abstract goes:

            One of the requirements of the = MPLS transport profile [RFC 5654] is
            to provide linear protection for tr= ansport paths, which include both
            LSPs and PWs. The functional architect= ure described in [SurvivFwk]
            is applicable to both LSP and PWs, however [LinearProt] does not
            explici= tly describe mechanisms for PW protection in MPLS-TP.

            This document extends the applicability of the linear protection
            mechani= sm described in [LinearProt] to MPLS-TP segmented PWs
            (MS-PWs) as defin= ed in [RFC 6073].

            Could you please review it and send feedback to th= e mailing list or
            directly to the author?

            Looking forward to your feedback,

            D= aniel

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


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


            --001636c5c006cd168904a597efba-- From nurit.sprecher@nsn.com Mon Jun 13 06: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 73CEC9E8028; Mon, 13 Jun 2011 06:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 dPIPI113eM7a; Mon, 13 Jun 2011 06:38:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4C9E8009; Mon, 13 Jun 2011 06:38:54 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5DDcpLg015945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 15:38:51 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5DDcpHr006124; Mon, 13 Jun 2011 15:38:51 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 15:38:50 +0200 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_01CC29CF.3ADAC149" Date: Mon, 13 Jun 2011 15:38:48 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403F64991@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Thread-Index: AcwpzjaHFo2CCA4qTaOKh1pH4XerfgAAG31Q References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext binny jeshan" X-OriginalArrivalTime: 13 Jun 2011 13:38:50.0976 (UTC) FILETIME=[3AE1FE00:01CC29CF] Cc: pwe3@ietf.org, mpls@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-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: Mon, 13 Jun 2011 13:38:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29CF.3ADAC149 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, For end-to-end, you can do it on the client service level.=20 If the intention is to protect against a S/T-PE failure, I think the solution should be efficient and not necessarily on the end-to-end PW level.=20 We may come soon with idea how to do it.=20 Best regards, Nurit =20 From: ext binny jeshan [mailto:binnyjeshan@gmail.com]=20 Sent: Monday, June 13, 2011 4:31 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: ext Alexander Vainshtein; ma.yuxia@zte.com.cn; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Hello, Though on one side I'd think its costlier to do a MS-PW level protection considering the resource usages, pre-configuration and monitoring overload, on the other i would think - why wouldn't having such a mechanism help in case if a local repair procedure fails ( failure in protection switch) for a underlying broken LSP or a mid-PW segment. A provider would never hesitate look into his pocket to have an end-end level protection considering a risky situation for an high priority service that he runs on the MS-PW. Wouldn't he? I believe he could be only concerned in the view of giving precedence to efficient switching the server layers, and not messing up with multiple switches happening for one failure. -Binny. On 13 June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------_=_NextPart_001_01CC29CF.3ADAC149 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

            Hi,

            For end-to-end, you can do it on the client service level. =

            If the intention is to protect against a S/T-PE  failure, I = think the solution should be efficient and not necessarily on the = end-to-end PW level.

            We may come soon with idea how to do it.

            Best regards,

            Nurit

             

            From:= = ext binny jeshan [mailto:binnyjeshan@gmail.com]
            Sent: Monday, = June 13, 2011 4:31 PM
            To: Sprecher, Nurit (NSN - IL/Hod = HaSharon)
            Cc: ext Alexander Vainshtein; ma.yuxia@zte.com.cn; = mpls@ietf.org; pwe3@ietf.org
            Subject: Re: [mpls] [PWE3] = Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

             

            Hello,

            Though on one side I'd = think its costlier to do a MS-PW level protection considering the = resource usages, pre-configuration and monitoring overload, on the other = i would think - why wouldn't having such a mechanism help in case if a = local repair procedure fails ( failure in protection switch) for a = underlying broken LSP or a mid-PW segment. A provider would never = hesitate look into his pocket to have an end-end level protection = considering a risky situation for an high priority service that he runs = on the MS-PW. Wouldn't he? I believe he could be only concerned in the = view of giving precedence to efficient switching the server layers, and = not messing up with multiple switches happening for one = failure.

            -Binny.

            On 13 = June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com> = wrote:

            Hi,

            I would like to second = Sasha.

            End-to-end PW protection (with = diverse paths) does not scale, and put hard restrictions on the = utilization of the resources.  

            MPLS-TP PWs are carried across = the network inside MPLS-TP LSPs. Therefore, an obvious way to provide = protection for a PW is to protect the LSP that carries it.  =

            If the PW is a multi-segment = PW, then LSP recovery can only protect the PW in individual = segments.  This means that a single LSP recovery action cannot = protect against a failure of a PW switching point (an = S-PE).

            When protecting against an AC = or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide = means for the PEs to coordinate over which LSP the traffic of the PW is = carried.

            I also doubt why there is a = need for additional mechanism.

            Best = regards,

            Nurit

             

            From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext = Alexander Vainshtein
            Sent: Monday, June 13, 2011 3:43 = PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@ietf.org
            Subject: Re: [PWE3] [mpls] = Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

             <= /o:p>

            Dear Ma and = all,

            Adding the PWE3 WG to my = response.

             

            The PW redundancy mechanism = supports linear protection of MS-PWs as one of many additional = application use cases:

            Appendix A of the PW redundancy Bit draft describes = 5 application uses cases in addition to MS-PW with single-homed CEs = (which is listed there as use case 5).

            And it is equally applicable to = IP/MPLS and MPLS - with the help of  the Static PW Status Messages = draft( if, for whatever reason, you do not want  to, or cannot, = use RFC 4447).

             

            Hence I doubt the need for yet = another PW redundancy  mechanism with narrow scope of = applicability.

             

            Regards,

                 = Sasha

             

            From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn
            Sent: Monday, June = 13, 2011 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [mpls] = Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

             <= /o:p>

            Hi all, =

            The linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

            BTW, there is a typo, it is "T-PE = Z" instead of "T-PE B". =

             "             =
              Figure 1 illustrates such a = scenario, where two MS-PWs are
              established between T-PE A and = T-PE B, over S-PEs 1-2 and 3-4             =
              respectively. Each PW = segment is established over an LSP (e.g. PW-
              s12 over LSP12).
             "             =

            -----Original = Message-----
            From: Daniel Cohn
            Sent: Tuesday, May 17, 2011 4:14 = PM
            To: mpls
            Subject: Seeking feedback on I-D "MPLS-TP Linear = Protection
            Applicability to MS-PW"
            Importance: High

            Hi = MPLSers,

            I uploaded "MPLS-TP Linear Protection Applicability = to MS-PW" I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protec= tion-00)

            The abstract goes:

            One of the requirements of the MPLS = transport profile [RFC 5654] is
            to provide linear protection for = transport paths, which include both
            LSPs and PWs. The functional = architecture described in [SurvivFwk]
            is applicable to both LSP and = PWs, however [LinearProt] does not
            explicitly describe mechanisms for = PW protection in MPLS-TP.

            This document extends the applicability = of the linear protection
            mechanism described in [LinearProt] to = MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC = 6073].

            Could you please review it and send feedback to the = mailing list or
            directly to the author?

            Looking forward to = your feedback,

            Daniel

            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.


            ______________________________________= _________
            mpls mailing list
            mpls@ietf.org
            https://www.ietf.org/mailman/listinfo/mpls

             

            ------_=_NextPart_001_01CC29CF.3ADAC149-- From DanielC@orckit.com Mon Jun 13 07:55: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 CF60111E8090; Mon, 13 Jun 2011 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] 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 tmGB42tfqr8S; Mon, 13 Jun 2011 07:55:01 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB04411E8075; Mon, 13 Jun 2011 07:55:00 -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_01CC29DA.15F28627" Date: Mon, 13 Jun 2011 17:54:56 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> In-reply-to: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygA== References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> From: "Daniel Cohn" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" , Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-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: Mon, 13 Jun 2011 14:55:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29DA.15F28627 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to meet the sub-50 ms requirement. Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well. Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65 - It's a two-phase protocol, with the consequent impact on timing - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case =20 In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 ------_=_NextPart_001_01CC29DA.15F28627 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

            Hi,

             

            Thanks all for the feedback. I believe we all agree that PW = protection is only required in the event of S-PE failure at an MS-PW = – this  is clearly stated in the draft. Now, both Sasha and = Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW = protection requirements.

             

            First of all a word on scalability. Please note that in an MPLS-TP = environment without a control plane, the PW redundancy mechanism must = also rely on proactive connectivity check for fast failure detection to =  meet the sub-50 ms requirement. Therefore any scalability = considerations that apply to the PW protection draft apply to the PW = redundancy draft as well.

            Also wrt scalability, there is no such thing as “scales” = or “doesn’t scale” – scalability is not a binary = concept. You can say that PW protection scales worse than LSP = protection, just like you can say that LSP protection scales worse than = interface protection. Which didn’t stop IETF from defining LSP = protection for scenarios where interface protection doesn’t do the = job.

             

            Now let’s turn our attention back to whether the PW redundancy = draaft can be used to meet MPLS-TP PW protection requirements. I can = identify the following reasons why in its current form it = doesn’t:

             

            -          = It explicitly (“outside the scope”) does not define = protection triggers and how to handle coexisting triggers, as requested = in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and = #79

            -          = It does not support the ability to distinguish between different = types of triggers (i.e. one end doesn’t know why the other end = triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req = #77

            -          = It does not define revertive/nonrevertive behavior, as requested in = RFC 5654 (MPLS-TP Requirements), req #64

            -          = It does not define holdoff support, which is especially important to = avoid race conditions with LSP protection when it = exists

            -          = It doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP = Requirements), req #65

            -          = It’s a two-phase protocol, with the consequent impact on = timing

            -          = It doesn’t define retransmission of protection coordination = messages, so loss of a single PDU can result in switchover not taking = place, thus not supporting sub-50 ms recovery in this = case

             

            In summary, PW redundancy was not designed with TP requirements in = mind, and as such does not meet the TP requirements. Of course = modifications may be introduced, but why reinvent the wheel when there = is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards = track that supports all the above requirements and can be applied to = MS-PW protection with minor modifications?

             

            Regards,

             

            Daniel

             

             

            From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon)
            Sent: Monday, June = 13, 2011 4:02 PM
            To: ext Alexander Vainshtein; = ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; = pwe3@ietf.org
            Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

             

            Hi,

            I would like to second Sasha.

            End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

            MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

            If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

            When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

            I also doubt why there is a need for additional mechanism. =

            Best regards,

            Nurit

             

            From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
            Sent: Monday, June 13, 2011 3:43 = PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; = pwe3@ietf.org
            Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

             

            Dear Ma and all,

            Adding the PWE3 WG to my response.

             

            The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

            Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

            And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

             

            Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

             

            Regards,

                 Sasha

             

            From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
            Sent: Monday, June 13, 2011 3:25 = PM
            To: mpls@ietf.org
            Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

             

            Hi all,

            The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

            BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

             &qu= ot;
              = Figure 1 illustrates such a scenario, where two MS-PWs are
              = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
              = respectively. Each PW segment is established over an LSP (e.g. = PW-
              = s12 over LSP12).
             &qu= ot;

            -----Original Message-----
            From: Daniel = Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicability = to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
            The abstract goes:

            One of the requirements of the MPLS = transport profile [RFC 5654] is
            to provide linear protection for = transport paths, which include both
            LSPs and PWs. The functional = architecture described in [SurvivFwk]
            is applicable to both LSP and = PWs, however [LinearProt] does not
            explicitly describe mechanisms for = PW protection in MPLS-TP.

            This document extends the applicability = of the linear protection
            mechanism described in [LinearProt] to = MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC = 6073].

            Could you please review it and send feedback to the = mailing list or
            directly to the author?

            Looking forward to = your feedback,

            Daniel

            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.

            ------_=_NextPart_001_01CC29DA.15F28627-- From iesg-secretary@ietf.org Mon Jun 13 08:03: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 C3FB021F8469; Mon, 13 Jun 2011 08:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 6v2bht5rZVPQ; Mon, 13 Jun 2011 08:03:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1914D21F846A; Mon, 13 Jun 2011 08:03:33 -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.55 Message-ID: <20110613150333.29471.94147.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 08:03:33 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol' to Historic (draft-ietf-mpls-mp-ldp-reqs-08.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, 13 Jun 2011 15:03:33 -0000 The IESG has approved the following document: - 'Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol' (draft-ietf-mpls-mp-ldp-reqs-08.txt) as a Historic 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-mp-ldp-reqs/ Technical Summary This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. This work was overtaken by the protocol solution developed by the MPLS working group, and that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. Working Group Summary This document is an output from the MPLS working group and we have good support for it. Document Quality The document is well reviewed. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Please add one paragraph to the end of the Abstarct NEW This work was overtaken by the protocol solution developed by the MPLS working group, and that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. END ---- Please replace the first paragraph of Section 1 OLD This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP)[I-D.ietf-mpls-ldp-p2mp], in order to deliver point-to- multipoint applications over a Multi-Protocol Label Switching (MPLS) infrastructure. It is published with Historic status with the perspective of documenting the work done. NEW This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP)[I-D.ietf-mpls-ldp-p2mp], in order to deliver point-to- multipoint applications over a Multi-Protocol Label Switching (MPLS) infrastructure. This work was overtaken by the protocol solution developed by the MPLS working group and documented in [I-D.ietf-mpls-ldp-p2mp]. That solution did not closely follow the requirements documented here and it was recognized that this document had served its purpose in driving discussions of how the solution should be designed. At this point, no further action is planned to update this document in line with the protocol solution, and this document is published simply as a historic record of the ideas and requirements that shaped the protocol work. END --- Section 1.2 OLD The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. NEW This document is a historic requirements document. For the benefit of clarity of statement of requirements, keywords are used as follows. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. END From Alexander.Vainshtein@ecitele.com Mon Jun 13 08:11: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 42EC711E8090; Mon, 13 Jun 2011 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396] 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 GFYK4UPxd41Q; Mon, 13 Jun 2011 08:11:05 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7C11E808C; Mon, 13 Jun 2011 08:11:03 -0700 (PDT) X-AuditID: 93eaf2e8-b7c74ae000000a6f-06-4df628248b4e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 30.71.02671.42826FD4; Mon, 13 Jun 2011 18:09:24 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 13 Jun 2011 18:11:01 +0300 From: Alexander Vainshtein To: Daniel Cohn Date: Mon, 13 Jun 2011 18:10:59 +0300 Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpw Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> 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_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLsWRmVeSWpSXmKPExsUy+dWnL7oqGt98DRa/krBouLSYyeLrjJvM FreWrmS1uH1/O7tF36ctLA6sHkuW/GTy+Ln+KrtH94bJzB5r9v1gCWCJamC0SczLyy9JLElV SEktTrZVCijKLEtMrlRSyEyxVTJUUijISUxOzU3NK7FVSiwoSM1LUbLjsgEKZuYppOYl56dk 5qXbKnkG++taWJha6hoq2akpGxpbc4VkZBYrpOrmJmbmKOSmFhcnpqcqAEVATs9LSU1RSMsv UijJSFUoSpjMnDHhz2+Wgk+bmSq+TP/I3sDYO4mpi5GTQ0LAROLLtR/MELaYxIV769m6GLk4 hAR2M0rsuDqNEcKZxijR97gBrINNwFZi0+q7bCC2iICKxMZrH9lBbGaBnYwSV874gNgsAqoS bx6fBprKwSEskCqxYkYYRHmaxPSOHqhWN4nJ/UvARvIK+Es8fTwfavFEJomfLy6CJTgFHCQO LTkPNp8R6Lrvp9YwQewSl7j1ZD7UBwISS/ach/pAVOLl43+sEPWiEnfa1zNC1OdLPJvWwAyx TFDi5MwnLBD1khIHV9xgmcAoNgvJ2FlIWmYhaYGI60gs2P2JDcLWlli28DUzjH3mwGMmZPEF jOyrGEUzcwpKknLTDYz0UpMzS1JzUvWS83M3MULS1YsdjLfPaB5iFOBgVOLhPXT+i68Qa2JZ cWXuIUZJDiYlUV4u9W++QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4e18BlfOmJFZWpRblw6Rc gaE/kVmKOzkflAxK4o0NDHBzlMR5u5Pf+AoJpAMTZ3ZqakFqEcwcGQ4OJQnegyDrBYtS01Mr 0jJzShDSTBycIGfwAJ2xE6SGt7ggMbc4Mx0if4rRmOPvnE2HGDkmLwOSQix5+XmpUuK8s0BK BUBKM0rz4KaB8lj9////XzGKA4NBmPcQSBUPMBnDzXsFtIoJaJVA6WeQVcCsBJeSamAUjdZO EDsXxPHg8Yx1ltc8dp8LLQrwnsL6cE9aJtvlOX/YlvuZCatOVT6b4Dzb21moqIe/6aag5uL8 OaXzCl3kdUvDJm2ftPvbycNzjySbB99fd1SuZLZcq6Odpsemq8ePGYfs+qM72cqhMMTzlbV7 iEZh6xU24dV9+/a6HZnPv5Rf3K06KUaJpTgj0VCLuag4EQDhPw/hPgQAAA== Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-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: Mon, 13 Jun 2011 15:11:10 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Daniel and all, Please see some comments inline below. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@= zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, Thanks all for the feedback. I believe we all agree that PW protection is on= ly required in the event of S-PE failure at an MS-PW - this is clearly stat= ed in the draft. Now, both Sasha and Nurit mention that the PW redundancy me= chanism can meet the MPLS-TP PW protection requirements. First of all a word on scalability. Please note that in an MPLS-TP environme= nt without a control plane, the PW redundancy mechanism must also rely on pr= oactive connectivity check for fast failure detection to meet the sub-50 ms= requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Det= ecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection dra= ft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised th= e scalability issue. My issue was limited applicability scope when compared= to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-home= d CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale"= - scalability is not a binary concept. You can say that PW protection scale= s worse than LSP protection, just like you can say that LSP protection scale= s worse than interface protection. Which didn't stop IETF from defining LSP= protection for scenarios where interface protection doesn't do the job. Now let's turn our attention back to whether the PW redundancy draaft can be= used to meet MPLS-TP PW protection requirements. I can identify the followi= ng reasons why in its current form it doesn't: - It explicitly ("outside the scope") does not define protection tr= iggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS= -TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated= protection switching happens. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered sw= itch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important= to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Re= quirements), req #65 [[[Sasha]]] All these claims are correct - and this should not be a surpris= e, because MPLS-TP requirements have been defined much later than the PW red= undancy mechanism. But I do not think that this justifies co-existence of two different mechani= sms. - It's a two-phase protocol, with the consequent impact on timing[[= [Sasha]]] Could you please elaborate? - It doesn't define retransmission of protection coordination messa= ges, so loss of a single PDU can result in switchover not taking place, thus= not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which bene= fits from TCP retransmissions) or on top of static PW status messages (where= retransmission is defined). In summary, PW redundancy was not designed with TP requirements in mind, and= as such does not meet the TP requirements. Of course modifications may be i= ntroduced, but why reinvent the wheel when there is a protocol (draft-ietf-m= pls-tp-linear-protection-06) in the standards track that supports all the ab= ove requirements and can be applied to MS-PW protection with minor modificat= ions? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. Regards, Daniel From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spre= cher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard r= estrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, a= n obvious way to provide protection for a PW is to protect the LSP that carr= ies it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW i= n individual segments. This means that a single LSP recovery action cannot= protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW red= undancy mechanisms provide means for the PEs to coordinate over which LSP th= e traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection= Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of m= any additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses= cases in addition to MS-PW with single-homed CEs (which is listed there as= use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Sta= tic PW Status Messages draft( if, for whatever reason, you do not wa= nt to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.y= uxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appli= cability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be th= e same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel 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_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

            Daniel and a= ll,

            Please see some comments= inline below.

             

            Regards,

                 Sasha=

             

            From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM
            To: Sprecher, Nurit (N= SN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@ietf.org
            Subject: RE: [mpls] [PWE3] Seeking= feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW"<= o:p>

             

            <= p class=3DMsoNormal>Hi,

             

            Thanks all for the= feedback. I believe we all agree that PW protection is only required in the= event of S-PE failure at an MS-PW – this  is clearly stated in t= he draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism= can meet the MPLS-TP PW protection requirements.

             

            First of all a word on scalability. Please note that in an MPLS-TP environm= ent without a control plane, the PW redundancy mechanism must also rely on p= roactive connectivity check for fast failure detection to  meet the sub= -50 ms requirement. [[[Sasha]]] IMO there is nothing spec= ific to MPLS-TP here. Detecting S-PE failures based on the control plane wou= ld  not fast enough.

            = Therefore any scalability considerations that apply to the PW protecti= on draft apply to the PW redundancy draft as well.[[[Sa= sha]]] I have not raised the scalability issue. My issue was limited applica= bility scope when compared to PW redundancy. E.g., the PW redundancy mechani= sms take care of dual-homed CEs in SS- and MS-PWs – something that lin= er protection of PWs cannot do.

            Also wrt scalability, there is no such thing as = 220;scales” or “doesn’t scale” – scalability i= s not a binary concept. You can say that PW protection scales worse than LSP= protection, just like you can say that LSP protection scales worse than int= erface protection. Which didn’t stop IETF from defining LSP protection= for scenarios where interface protection doesn’t do the job.

             

            Now let’s turn our attention back to whether the PW= redundancy draaft can be used to meet MPLS-TP PW protection requirements. I= can identify the following reasons why in its current form it doesn’t= :

             

            -      &nb= sp;   It explicitly (“outside the scope”) does not define protection= triggers and how to handle coexisting triggers, as requested in RFC 5654 (M= PLS-TP Requirements), reqs #75, #76 and #79

            [[[Sasha]]] So what? Definition of triggers is orthogo= nal to how coordinated protection switching happens.

            -   &nbs= p;      It does not support the ability to distinguish between diff= erent types of triggers (i.e. one end doesn’t know why the other end t= riggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77

            -   &nb= sp;      It does not define revertive/nonrevertive behavior, as r= equested in RFC 5654 (MPLS-TP Requirements), req #64

            -       =    It= does not define holdoff support, which is especially important to avoid rac= e conditions with LSP protection when it exists

            <= ![if !supportLists]>-        =   It doesn&= #8217;t support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), r= eq #65

            [[[Sasha]]] All these claims are correct – a= nd  this should not be a surprise, because MPLS-TP requirements have be= en defined much later than the PW redundancy mechanism.

            But I do not think that this just= ifies co-existence of two different mechanisms.

            -    &nb= sp;     <= /span>It’s a two-phase protocol, with the consequent impact on t= iming[[[Sasha]]] Could you please elaborate?

            -It doesn’t define retransmis= sion of protection coordination messages, so loss of a single PDU can result= in switchover not taking place, thus not supporting sub-50 ms recovery in t= his case

            [[[Sasha]]] T= he PW redundancy protocol runs either on top of LDP (which benefits from TCP= retransmissions) or on top of static PW status messages (where retransmissi= on is defined).

             

            In summary,= PW redundancy was not designed with TP requirements in mind, and as such do= es not meet the TP requirements. Of course modifications may be introduced,= but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-lin= ear-protection-06) in the standards track that supports all the above requir= ements and can be applied to MS-PW protection with minor modifications?=

            [[[Sasha]]] As I said, bec= ause the applicability scope is by far too narrow to justify a dedicated pro= tocol.

             

            Regards,<= /span>

             

            Daniel

            =  

             

            From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)Sent: Monday, June 13, 2011 4:02 PM
            To: ext Alexander Vai= nshtein; ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@ietf.org
            <= b>Subject:             Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinear= Protection Applicability to MS-PW"

             

            Hi,<= /o:p>

            I would like to second Sasha.

            End-to-end PW protection (with= diverse paths) does not scale, and put hard restrictions on the utilization= of the resources.  

            MP= LS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an= obvious way to provide protection for a PW is to protect the LSP that carri= es it. 

            If the PW is a= multi-segment PW, then LSP recovery can only protect the PW in individual s= egments.  This means that a single LSP recovery action cannot protect a= gainst a failure of a PW switching point (an S-PE).

            When protecting against an AC or T/S-PE failure by= dual connectivity, PW redundancy mechanisms provide means for the PEs to co= ordinate over which LSP the traffic of the PW is carried. =

            I also doubt why there is a need for addition= al mechanism.

            Best regards,=

            Nurit

            =

             

            From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of ext Alexander Vainshtein
            Sent: Monday, June 13, 2011 3= :43 PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@i= etf.org
            Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "M= PLS-TP LinearProtection Applicability to MS-PW"

             

            Dear Ma and all,

            Adding t= he PWE3 WG to my response.

            <= o:p> 

            The PW redundancy mech= anism supports linear protection of MS-PWs as one of many additional applica= tion use cases:

            Appendix A o= f the PW redundancy Bit draft describes 5 application u= ses cases in addition to MS-PW with single-homed CEs (which is listed there= as use case 5).

            And it is e= qually applicable to IP/MPLS and MPLS - with the help of  the Static PW Status Messages draft( if, for whatever reason, yo= u do not want  to, or cannot, use RFC 4447).

             

            H= ence I doubt the need for yet another PW redundancy  mechanism with nar= row scope of applicability.

             

            Regards,<= /span>

                 Sasha

             

            From: mpls-bounces@ietf.org [mailto:mpls-bounces= @ietf.org] On Behalf Of ma.yuxia@zte.com.cn
            Sent: Monday, J= une 13, 2011 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [mpl= s] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to= MS-PW"

            &nbs= p;

            Hi all,

            The linear protection mechanism for LSP and PW(includi= ng MS-PW) should be the same and it is valuable to describe it clearly.

            BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".

             "
              Figure 1 illu= strates such a scenario, where two MS-PWs are
              established between T-= PE A and T-PE B, over S-PEs 1-2 and 3-4
            &= nbsp; respectively. Each PW segment is established over an LSP (e.g. PW-
            &n= bsp; s12 over LSP12).
             "

            -----Original Message-----
            From: Daniel Cohn
            Sent:= Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Subject: Seeking feedback on I= -D "MPLS-TP Linear Protection
            Applicability to MS-PW"
            Import= ance: High

            Hi MPLSers,

            I uploaded "MPLS-TP Linear Protect= ion Applicability to MS-PW" I-D
            (http://tools.ietf.org/html/draft-co= hn-mpls-tp-pw-protection-00)

            The abstract goes:

            One of the requirements of the MPLS transport profile [RFC 5= 654] is
            to provide linear protection for transport paths, which include b= oth
            LSPs and PWs. The functional architecture described in [SurvivFwk]is applicable to both LSP and PWs, however [LinearProt] does not
            explici= tly describe mechanisms for PW protection in MPLS-TP.

            This document extends the applicability of the linear protect= ion
            mechanism described in [LinearProt] to MPLS-TP segmented PWs
            (MS-= PWs) as defined in [RFC 6073].

            Could you please review it and send fe= edback to the mailing list or
            directly to the author?

            Looking for= ward to your feedback,

            Daniel

            This e-= mail message is intended for the recipient only and contains information whi= ch 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 f= ax, 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_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_-- From nurit.sprecher@nsn.com Mon Jun 13 08:23: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 EA67521F84A2; Mon, 13 Jun 2011 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 oiZ9CLZ31lVI; Mon, 13 Jun 2011 08:23:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A62F621F8493; Mon, 13 Jun 2011 08:23:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5DFNS69019138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 17:23:28 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5DFNRtA028980; Mon, 13 Jun 2011 17:23:27 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 17:23:27 +0200 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_01CC29DD.D836CE89" Date: Mon, 13 Jun 2011 17:23:25 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403F64A13@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwAADpDNA= References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" , "Daniel Cohn" X-OriginalArrivalTime: 13 Jun 2011 15:23:27.0803 (UTC) FILETIME=[D829C8B0:01CC29DD] Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-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: Mon, 13 Jun 2011 15:23:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29DD.D836CE89 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable If you do it on the client service layer, you can protect also the T-PE... Why do you want to protect only against a failure of the S-PE? The PW starts at the T-PE... =20 From: ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" =20 Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens. - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surprise, because MPLS-TP requirements have been defined much later than the PW redundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechanisms. - It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate?=20 - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol. =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 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.=20 ------_=_NextPart_001_01CC29DD.D836CE89 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

            If you do it on the client service layer, you can protect also the = T-PE…

            Why do you want to protect only against a failure of the S-PE? The PW = starts at the T-PE…

             

            From:= = ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] =
            Sent: Monday, June 13, 2011 6:11 PM
            To: Daniel = Cohn
            Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - = IL/Hod HaSharon); ma.yuxia@zte.com.cn
            Subject: RE: [mpls] = [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to = MS-PW"

             

            Daniel and all,

            Please see some comments inline below.

             

            Regards,

                 Sasha

             

            From:= = Daniel Cohn [mailto:DanielC@orckit.com]
            Sent: Monday, June = 13, 2011 5:55 PM
            To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = Alexander Vainshtein; ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; = pwe3@ietf.org
            Subject: RE: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

             

            Hi,

             

            Thanks all for the feedback. I believe we all agree that PW = protection is only required in the event of S-PE failure at an MS-PW = – this  is clearly stated in the draft. Now, both Sasha and = Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW = protection requirements.

             

            First of all a word on scalability. Please note that in an MPLS-TP = environment without a control plane, the PW redundancy mechanism must = also rely on proactive connectivity check for fast failure detection to =  meet the sub-50 ms requirement. [[[Sasha]]] IMO there is = nothing specific to MPLS-TP here. Detecting S-PE failures based on the = control plane would  not fast = enough.

            Therefore any scalability considerations that apply to the PW = protection draft apply to the PW redundancy draft as = well.[[[Sasha]]] I have not raised the scalability issue. My issue = was limited applicability scope when compared to PW redundancy. E.g., = the PW redundancy mechanisms take care of dual-homed CEs in SS- and = MS-PWs – something that liner protection of PWs cannot = do.

            Also wrt scalability, there is no such thing as “scales” = or “doesn’t scale” – scalability is not a binary = concept. You can say that PW protection scales worse than LSP = protection, just like you can say that LSP protection scales worse than = interface protection. Which didn’t stop IETF from defining LSP = protection for scenarios where interface protection doesn’t do the = job.

             

            Now let’s turn our attention back to whether the PW redundancy = draaft can be used to meet MPLS-TP PW protection requirements. I can = identify the following reasons why in its current form it = doesn’t:

             

            -          = It explicitly (“outside the scope”) does not define = protection triggers and how to handle coexisting triggers, as requested = in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and = #79

            [[[Sasha]]] So what? Definition of triggers is orthogonal to how = coordinated protection switching happens.

            -          = It does not support the ability to distinguish between different = types of triggers (i.e. one end doesn’t know why the other end = triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req = #77

            -          = It does not define revertive/nonrevertive behavior, as requested in = RFC 5654 (MPLS-TP Requirements), req #64

            -          = It does not define holdoff support, which is especially important to = avoid race conditions with LSP protection when it = exists

            -          = It doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP = Requirements), req #65

            [[[Sasha]]] All these claims are correct – and  this = should not be a surprise, because MPLS-TP requirements have been defined = much later than the PW redundancy mechanism. =

            But I do not think that this justifies co-existence of two different = mechanisms.

            -          = It’s a two-phase protocol, with the consequent impact on = timing[[[Sasha]]] Could you please elaborate? =

            -          = It doesn’t define retransmission of protection coordination = messages, so loss of a single PDU can result in switchover not taking = place, thus not supporting sub-50 ms recovery in this = case

            [[[Sasha]]] The PW redundancy protocol runs either on top of LDP = (which benefits from TCP retransmissions) or on top of static PW status = messages (where retransmission is defined).

             

            In summary, PW redundancy was not designed with TP requirements in = mind, and as such does not meet the TP requirements. Of course = modifications may be introduced, but why reinvent the wheel when there = is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards = track that supports all the above requirements and can be applied to = MS-PW protection with minor modifications?

            [[[Sasha]]] As I said, because the applicability scope is by far too = narrow to justify a dedicated protocol.

             

            Regards,

             

            Daniel

             

             

            From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon)
            Sent: Monday, June = 13, 2011 4:02 PM
            To: ext Alexander Vainshtein; = ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; = pwe3@ietf.org
            Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

             

            Hi,

            I would like to second Sasha.

            End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

            MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

            If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

            When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

            I also doubt why there is a need for additional mechanism. =

            Best regards,

            Nurit

             

            From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
            Sent: Monday, June 13, 2011 3:43 = PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; = pwe3@ietf.org
            Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

             

            Dear Ma and all,

            Adding the PWE3 WG to my response.

             

            The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

            Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

            And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

             

            Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

             

            Regards,

                 Sasha

             

            From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
            Sent: Monday, June 13, 2011 3:25 = PM
            To: mpls@ietf.org
            Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

             

            Hi all,

            The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

            BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

             &qu= ot;
              = Figure 1 illustrates such a scenario, where two MS-PWs are
              = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
              = respectively. Each PW segment is established over an LSP (e.g. = PW-
              = s12 over LSP12).
             &qu= ot;

            -----Original Message-----
            From: Daniel = Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicability = to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
            The abstract goes:

            One of the requirements of the MPLS = transport profile [RFC 5654] is
            to provide linear protection for = transport paths, which include both
            LSPs and PWs. The functional = architecture described in [SurvivFwk]
            is applicable to both LSP and = PWs, however [LinearProt] does not
            explicitly describe mechanisms for = PW protection in MPLS-TP.

            This document extends the applicability = of the linear protection
            mechanism described in [LinearProt] to = MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC = 6073].

            Could you please review it and send feedback to the = mailing list or
            directly to the author?

            Looking forward to = your feedback,

            Daniel

            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. =

            ------_=_NextPart_001_01CC29DD.D836CE89-- From db3546@att.com Mon Jun 13 16:48: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 AEB511F0C5B; Mon, 13 Jun 2011 16:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3ipQDvqd9Doa; Mon, 13 Jun 2011 16:48:36 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B286F1F0C35; Mon, 13 Jun 2011 16:48:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1308008914!23976263!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 20940 invoked from network); 13 Jun 2011 23:48:34 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jun 2011 23:48:34 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5DNlRss023443; Mon, 13 Jun 2011 19:47:27 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5DNlNSv023402; Mon, 13 Jun 2011 19:47:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 19:48:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] WG last call on draft-ietf-ccamp-attribute-bnf-01.txt-completed Thread-Index: AcwcmVIl5XeruN3TSbuHZmDxQFWWbQNirdmA References: From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Cc: mpls@ietf.org Subject: Re: [mpls] [CCAMP] WG last call on draft-ietf-ccamp-attribute-bnf-01.txt-completed 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, 13 Jun 2011 23:48:36 -0000 This WG Last Call has ended. I will prepare the publication request. Thanks, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTSI) Sent: Friday, May 27, 2011 2:10 PM To: CCAMP Subject: [CCAMP] WG last call on draft-ietf-ccamp-attribute-bnf-01.txt This mail begins a WG last call on: http://www.ietf.org/id/draft-ietf-ccamp-attribute-bnf-01.txt This working group last call ends on June 10th. Please send comments to the CCAMP mailing list. Deborah (and Lou) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Mon Jun 13 17:51: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 3626821F864F; Mon, 13 Jun 2011 17:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 aG92cIdJcMqF; Mon, 13 Jun 2011 17:51:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C784E21F864B; Mon, 13 Jun 2011 17:51:35 -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.55 Message-ID: <20110614005135.27158.58510.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 17:51:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-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, 14 Jun 2011 00:51:36 -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 : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Thomas Morin Irene Grosclaude Nicolai Leymann Filename : draft-ietf-mpls-seamless-mcast-00.txt Pages : 29 Date : 2011-06-05 This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used in an IGP area then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such an inter-area service LSP may be BGP MVPN, VPLS multicast or Internet multicast over MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mcast-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-seamless-mcast-00.txt From maarten.vissers@huawei.com Tue Jun 14 04:41: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 8A83611E8097; Tue, 14 Jun 2011 04:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 v7W2Bin0ZVL1; Tue, 14 Jun 2011 04:41:26 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by ietfa.amsl.com (Postfix) with ESMTP id C8AA511E8071; Tue, 14 Jun 2011 04:41:25 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMS00A4P350BQ@lhrga04-in.huawei.com>; Tue, 14 Jun 2011 12:41:24 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMS0020D34ZIS@lhrga04-in.huawei.com>; Tue, 14 Jun 2011 12:41: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; Tue, 14 Jun 2011 12:41:17 +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; Tue, 14 Jun 2011 12:41:22 +0100 Date: Tue, 14 Jun 2011 11:41:22 +0000 From: Maarten vissers In-reply-to: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> X-Originating-IP: [10.47.154.38] To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw)" Content-language: en-US Accept-Language: en-GB, en-US Thread-topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Thread-index: AQHMKco1J8PEH1bAJECgcknBiPna2pS7RefQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-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, 14 Jun 2011 11:41:27 -0000 --Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Nurit, If I translate your proposal in terms of SDH protection, then your proposal would imply that LOVC (e.g. VC-12, VC-11 protection should not be deployed, instead only HOVC (VC-4, VC-3) protection should be deployed. We all know that the SDH network has many protected LOVC connections, and that this is scaling well. My question is therefore why protecting MS-PW connections (and Service-LSP connections) would not scale? Regards, Maarten From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 13 June 2011 15:02 To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft( if, for whatever reason, you do not want to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel 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. --Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

            Nurit,<= /p>

             <= /p>

            If I translate your propo= sal in terms of SDH protection, then your proposal would imply that LOVC (e= .g. VC-12, VC-11 protection should not be deployed, instead only HOVC (VC-4, VC-3) protection should be deployed. We all know that the= SDH network has many protected LOVC connections, and that this is scaling = well. My question is therefore why protecting MS-PW connections (and Servic= e-LSP connections) would not scale?

             <= /p>

            Regards,

            Maarten=

             <= /p>

            From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
            Sent: 13 June 2011 15:02
            To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@ietf.org
            Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Lin= earProtection Applicability to MS-PW"

             

            Hi,

            I would li= ke to second Sasha.

            End-to-end= PW protection (with diverse paths) does not scale, and put hard restrictio= ns on the utilization of the resources.  

            MPLS-TP PW= s are carried across the network inside MPLS-TP LSPs. Therefore, an obvious= way to provide protection for a PW is to protect the LSP that carries it. 

            If the PW = is a multi-segment PW, then LSP recovery can only protect the PW in individ= ual segments.  This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE).

            When prote= cting against an AC or T/S-PE failure by dual connectivity, PW redundancy m= echanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.

            I also dou= bt why there is a need for additional mechanism.

            Best regar= ds,

            Nurit=

             = ;

            From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein
            Sent: Monday, June 13, 2011 3:43 PM
            To: ma.yuxia@zte.com.cn
            Cc: mpls@ietf.org; pwe3@ietf.org
            Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Lin= earProtection Applicability to MS-PW"

             

            Dear Ma an= d all,

            Adding the= PWE3 WG to my response.

             = ;

            The PW red= undancy mechanism supports linear protection of MS-PWs as one of many addit= ional application use cases:

            Appendix A= of the PW redundancy Bit draft describes 5 application uses cases in addition = to MS-PW with single-homed CEs (which is listed there as use case 5).<= /o:p>

            And it is = equally applicable to IP/MPLS and MPLS - with the help of  the Static PW Status Messages draft( if, for whatever reason, you do not wa= nt  to, or cannot, use RFC 4= 447).

             = ;

            Hence I do= ubt the need for yet another PW redundancy  mechanism with narrow scop= e of applicability.

             = ;

            Regards,

             &nbs= p;   Sasha

             = ;

            From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn
            Sent: Monday, June 13, 2011 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Pro= tection Applicability to MS-PW"

             

            Hi all,

            The linear protection mechanism for LSP and PW(including MS-PW) sh= ould be the same and it is valuable to describe it clearly.

            BTW, there is a typo, it is "T-PE Z&q= uot; instead of "T-PE B".

             "             =
              Figure 1 illustrates such a scenario, where two MS-PWs are
              established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
              respectively. Each PW segment is established over an LSP (e.g. PW-
              s12 over LSP12).
             "

            -----Original Message---= --
            From: Daniel Cohn
            Sent: Tuesday, May 17, 2011 4:14 PM
            To: mpls
            Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
            Applicability to MS-PW"
            Importance: High

            Hi MPLSers,

            I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D=
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)

            The abstract goes:

            One of the requirements of the MPLS transport profile [RFC 5654] is
            to provide linear protection for transport paths, which include both
            LSPs and PWs. The functional architecture described in [SurvivFwk]
            is applicable to both LSP and PWs, however [LinearProt] does not
            explicitly describe mechanisms for PW protection in MPLS-TP.

            This document extends the applicability of the linear protection
            mechanism described in [LinearProt] to MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC 6073].

            Could you please review it and send feedback to the mailing list or
            directly to the author?

            Looking forward to your feedback,

            Daniel

            This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

            --Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw)-- From DanielC@orckit.com Tue Jun 14 04:44: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 2CE5111E8071; Tue, 14 Jun 2011 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] 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 HnPmCbtPBjjb; Tue, 14 Jun 2011 04:44:04 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BB11E80A8; Tue, 14 Jun 2011 04:44:03 -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_01CC2A88.93759A2A" Date: Tue, 14 Jun 2011 14:44:00 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF3552@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwpydFuQ8gnnYX6SMu1tAmQpJ1OkwAvSjPA References: From: "Daniel Cohn" To: "binny jeshan" , "Alexander Vainshtein" Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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, 14 Jun 2011 11:44:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A88.93759A2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Binny, =20 The assumption is that lower-layer protection (LSP or link protection) will take care of single-segment failures not affecting S-PEs. The hold-off mechanism defined in [LinearProt], when properly configured, prevents MS-PW switchover in this scenario. As you say, this is because lower-layer protection is more efficient so it should be used when possible. =20 Regards, =20 Daniel =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of binny jeshan Sent: Monday, June 13, 2011 3:58 PM To: Alexander Vainshtein Cc: pwe3@ietf.org; mpls@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hello authors, I have a generic question on the co-existence of PW monitoring at the MS-PW level (PSMEG) and the individual segment level (PMEG). Firstly, I believe there is no such restriction on having co-existence in monitoring these independently.. Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment MSPW fails, its quite possible that the PSMEG also detects it at the endpoints. Now, what would determine the switching priority? Wouldn't it become costlier if the PSMEG does a MS-PW level switching? Instead, one could prefer to switch to a backup path at a segment level itself. Is this addressed? Thanks, Binny. On 13 June 2011 18:13, Alexander Vainshtein wrote: Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 =20 ------_=_NextPart_001_01CC2A88.93759A2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

            Hi Binny,

             

            The assumption is that lower-layer protection (LSP or link = protection) will take care of single-segment failures not affecting = S-PEs. The hold-off mechanism defined in [LinearProt], when properly = configured, prevents MS-PW switchover in this scenario. As you say, this = is because lower-layer protection is more efficient so it should be used = when possible.

             

            Regards,

             

            Daniel

             

            From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = binny jeshan
            Sent: Monday, June 13, 2011 3:58 = PM
            To: Alexander Vainshtein
            Cc: pwe3@ietf.org; = mpls@ietf.org
            Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

             

            Hello authors,

            I have a generic = question on the co-existence of PW monitoring at the MS-PW level = (PSMEG) and the individual segment level (PMEG). Firstly, I believe = there is no such restriction on having co-existence in monitoring these = independently..

            Now lets say if a monitored mid segment (a simple = PMEG) of a 5 segment MSPW fails, its quite possible that the PSMEG also = detects it at the endpoints. Now, what would determine the switching = priority? Wouldn't it become costlier if the PSMEG does a MS-PW = level switching? Instead, one could prefer to switch to a backup path at = a segment level itself. Is this = addressed?

            Thanks,
            Binny.

            On 13 June 2011 18:13, Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com> wrote:

            Dear Ma and = all,

            Adding the PWE3 WG to my = response.

             

            The PW redundancy mechanism = supports linear protection of MS-PWs as one of many additional = application use cases:

            Appendix A of the PW redundancy Bit draft describes = 5 application uses cases in addition to MS-PW with single-homed CEs = (which is listed there as use case 5).

            And it is equally applicable to = IP/MPLS and MPLS - with the help of  the Static PW Status Messages = draft( if, for whatever reason, you do not want  to, or cannot, = use RFC 4447).

             

            Hence I doubt the need for yet = another PW redundancy  mechanism with narrow scope of = applicability.

             

            Regards,

                 = Sasha

             

            From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn
            Sent: Monday, June = 13, 2011 3:25 PM
            To: mpls@ietf.org
            Subject: Re: [mpls] = Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

             <= /o:p>

            Hi all, =

            The linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

            BTW, there is a typo, it is "T-PE = Z" instead of "T-PE B". =

             "             =
              Figure 1 illustrates such a = scenario, where two MS-PWs are
              established between T-PE A and = T-PE B, over S-PEs 1-2 and 3-4             =
              respectively. Each PW = segment is established over an LSP (e.g. PW-
              s12 over LSP12).
             "             =

            -----Original = Message-----
            From: Daniel Cohn
            Sent: Tuesday, May 17, 2011 4:14 = PM
            To: mpls
            Subject: Seeking feedback on I-D "MPLS-TP Linear = Protection
            Applicability to MS-PW"
            Importance: High

            Hi = MPLSers,

            I uploaded "MPLS-TP Linear Protection Applicability = to MS-PW" I-D
            (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protec= tion-00)

            The abstract goes:

            One of the requirements of the MPLS = transport profile [RFC 5654] is
            to provide linear protection for = transport paths, which include both
            LSPs and PWs. The functional = architecture described in [SurvivFwk]
            is applicable to both LSP and = PWs, however [LinearProt] does not
            explicitly describe mechanisms for = PW protection in MPLS-TP.

            This document extends the applicability = of the linear protection
            mechanism described in [LinearProt] to = MPLS-TP segmented PWs
            (MS-PWs) as defined in [RFC = 6073].

            Could you please review it and send feedback to the = mailing list or
            directly to the author?

            Looking forward to = your feedback,

            Daniel             =

            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

             

            ------_=_NextPart_001_01CC2A88.93759A2A-- From ice@cisco.com Tue Jun 14 06:08:55 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 401509E800A for ; Tue, 14 Jun 2011 06:08:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8wP0zSKFYoh for ; Tue, 14 Jun 2011 06:08:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9D00A9E8006 for ; Tue, 14 Jun 2011 06:08:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5ED8b5v017832; Tue, 14 Jun 2011 15:08:37 +0200 (CEST) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5ED8ZLI028815; Tue, 14 Jun 2011 15:08:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <020701cc157c$259b8960$70d29c20$@huawei.com> Date: Tue, 14 Jun 2011 15:08:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FDA2A2C-658A-48DE-BE0E-837F45FAC39A@cisco.com> References: <020701cc157c$259b8960$70d29c20$@huawei.com> To: Adrian.Farrel@huawei.com X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, draft-ietf-mpls-ldp-p2mp@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-p2mp 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, 14 Jun 2011 13:08:55 -0000 Hi Adrian, Thanks for the detailed review, see comments inline. > --- >=20 > As noted in the write-up, RFC 4664 is an unused reference. I think it = can simply > be removed unless it was intended to be added to the final paragraph = of Section > 1. Ice: ok. >=20 > --- >=20 > Abstract >=20 > Some consistency in hyphenation, please. I think you need to adopt > "point-to-multipoint" and "multipoint-to-multipoint" as in the title. Ice: Ok. >=20 > --- >=20 > Acronyms > Need to expand them on first use in the main text (Abstract doesn't = count). I > find: >=20 > (LDP is a permitted acronym - no action needed) > LSP > LSR Ice: Ok >=20 > --- >=20 > Please s/draft/document/ in the text so that when it is published as = an RFC the > text is accurate. Ice: Is this a comment on its own or related to above or below? >=20 > --- >=20 > Section 1 >=20 > Only a single copy of the packet will be sent > on any link traversed by the MP LSP (see note at end of > Section 2.4.1). >=20 > Is this strictly true in all cases. are there not fringe cases, just = as there > were in P2MP RSVP-TE, where a branch is logically made upstream of a = common link > because of limited branching capabilities at the downstream end of the = link? Ice: With mLDP this would typically not happen, but you do raise a good = point. The text is not accurate and there are examples where the same = packet may be transmitted over the the same link. For example with = running mLDP over Targeted LDP sessions, described in = draft-napierala-mpls-targeted-mldp-01. It changed 'link' into 'LDP = neighbor', that captures it more accurate. >=20 > --- >=20 > Section 1.2 >=20 > Leaf node: A Leaf node can be either an Egress or Bud LSR when > referred in the context of a P2MP LSP. In the context of a MP2MP > LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and > can also be a Bud LSR. >=20 > I think... > s/an LSR is both Ingress and Egress/a leaf is both Ingress and Egress/ Ice: Ok. >=20 > --- >=20 > Section 2.1 >=20 > The figure in this section appears to state that the S-bit must always = be set to > 1. That means that the capability cannot be withdrawn. I have no issue = with > that, but I think that if this is you intention, you must say that the = S-bit > must always be set to 1, the capability cannot be withdrawn, and the = processing > if S=3D0 is received. OTOH, if you allow withdrawal, you can leave "S" = in the > figure and refer to RFC5561 for the meaning. Ice: Good catch. There is no intention to make it non withdraw-able. = I've changed to S and pointed to RFC5561. >=20 > --- >=20 > Pedantic point I don't propose you address (unless you have more spare = than you > should have)... >=20 > The Opaque Value field is not truly opaque, since we can look into it = and find a > series of opaque elements. Ice: Ok. >=20 > --- >=20 > Section 2.2 >=20 > Can you explain to me why the working group wanted to allow the P2MP = FEC to use > any address family from IANA's "Address Family Numbers" registry to = identify the > root LSR? Ice: mLDP tree building is based on the reachability of the Root = Address. That Root address is very likely to be IPv4 or IPv6, but = nothing prevents an implementer to stick in a IPX or CLNS address and = route the LSP across the network. As long as the Root address is = reachable in each node, it will work. I don't see why we should restrict = its use. >=20 > --- >=20 > Section 2.2 >=20 > The combination of (Root Node Address, > Opaque Value) uniquely identifies a P2MP LSP within the MPLS = network. >=20 > With the current specification as shown in the figure, this is not = completely > accurate since two addresses from different families could have the = same root > node address value. >=20 > So your text should refer to the combination of {Root Node Address = type, Root > Node Address, Opaque Value). Ice: Good catch, fixed it. >=20 > --- >=20 > 2.3 >=20 > OLD > Type: The Type of the LDP MP Opaque Value Element basic type is to > be assigned by IANA. > NEW > Type: The Type of the LDP MP Opaque Value Element. IANA maintains a > registry of basic types (see Section 11). Ice: Ok. >=20 > --- >=20 > 2.3 >=20 > We don't generally define empty TLVs and objects. >=20 > Can you convince me of the need for the Extended Type? Are you = predicting a > large number of FCFS opaque values?. You are surely not expecting many = standards > track types.=20 Ice: Its always hard to predict these things, since the Type field is = only 8 bits, I think it was a good idea to reserve 255 and assigned an = extended type to it. Just in case we need it. >=20 > --- >=20 > 2.3 >=20 > OLD > Extended Type: The Extended Type of the LDP MP Opaque Value Element > extended type is to be assigned by IANA. > NEW > Extended Type: The Extended Type of the LDP MP Opaque Value = Element. > IANA maintains a registry of extended types (see Section 11). Ice: Ok. >=20 > --- >=20 > A point of pedantry, but you repeatedly refer to the "Label Map" = message and (of > course :-) it is really the "Label Mapping" message. Ice: Agreed, changed it, that reads a lot better. >=20 > --- >=20 > 2.4 >=20 > 2. P2MP Label Map : a Label Map message with a FEC TLV = with > a single P2MP FEC Element and Label TLV with label L. >=20 > Label L MUST be allocated from the per-platform label space (see > [RFC3031] section 3.14) of the LSR sending the Label Map = Message. >=20 > While you are at liberty to make this "MUST" requirement with the WGs = support, > it would be good if you gave the reason rather than "sneaking" it in. = I assume > that you want to do this to make FRR easier, but it is not immediately = clear why > P2MP is in any way different from P2P on upstream interfaces. Or maybe = it is > because you want to allow the choice of downstream interface to rest = with the > upstream LSR (per 2.4.1.2). >=20 > Can you add a short clause to say why the per-platform label space is = used? Ice: Correct, the choice of the forwarding interface rests with the = upstream LSR and FRR is easier this way. But I would not say that is the = reason we choose platform label space, it is mostly that we are just = following what is used for unicast. I don't think anything prevents mLDP = from working with per interface label space. FRR becomes harder, but = that would be the same for unicast.. So I'm sure if we need to say = anything more here. >=20 > --- >=20 > 2.4.1 >=20 > The remainder of this section specifies the procedures for > originating P2MP Label Map messages and for processing received P2MP >=20 > s/The remainder of this/This/ Ice: Ok. >=20 > --- >=20 > You have two instances (spot the block copy!) of "label map" in lower = case. Ice: Got it. >=20 > --- >=20 > 2.4.1.1 >=20 > A node Z that > wants to join a MP LSP determines the LDP peer U which is Z's > next-hop on the best path from Z to the root node X. If there is = more > than one such LDP peer, only one of them is picked. U is Z's > "Upstream LSR" for . =20 >=20 > When there are several candidate upstream LSRs, the LSR MAY select > one upstream LSR. >=20 > The "MAY" seems to be in contradiction to the previous paragraph that = appears to > say that the LSR MUST select exactly one upstream LSR. Ice: Agreed, changed to MUST. >=20 > --- >=20 > 2.4.1.1 >=20 > CRC32 is not a well-known acronym and would benefit from a reference. Ice: Done. >=20 > --- >=20 > 2.4.1 and 2.4.1.1 >=20 > It seems that it is important to be precise about what is meant by the = "opaque > value" (Y). This is particularly important in 2.4.1.1 because there is = an > interop dependency relying on the input to the hash function. You = might mean: > - the whole opaque value TLV > - the opaque value field of the opaque value TLV > (i.e., the concatenation of the whole opaque value elements) > - the value field of the opaque value element > - the concatenation of the value fields from each of the value fields > of the opaque value elements >=20 > Please add text to clarify (at least for the CRC32 case). Ice: Ok, done. Its the Opaque Value as indicated in the FEC element. = (this may or may not have multiple Opaque TLV's in it). >=20 > --- >=20 > 2.4.1.4 >=20 > Trivially... >=20 > Assuming its old forwarding state was > L'-> { ..., }, its new forwarding state > becomes L'-> { ..., , }. >=20 > Misses the case that I=3DIi for some value of i. Ice: Don't understand this comment. Can you elaborate? >=20 > --- >=20 > 2.4.2.1 >=20 > If a leaf node Z discovers (by means outside the scope of this > document) that it has no downstream neighbors in that LSP, and that > it has no need to be an egress LSR for that LSP, then it SHOULD send >=20 > Just some subtle re-wording needed. We *do* know the means by which Z = discovers > it has no downstream neighbors -- that is what this document is about! = The > parentheses apply to the second clause (that it has no need to be an = egress). Ice: Ok. >=20 > --- >=20 > 2.4.2.2. >=20 > In the light of the procedure set out in 2.4.3 and 8., should you = recommend that > propagation of Label Withdraw should be delayed to prevent full LSP = teardown > when there is a small change in the path of the trunk of an LSP? Maybe = a fringe > case we can leave to implementations? Ice: Delaying the withdraw is only useful if the change is temporarily = and likely to recover before the new path is setup. It is hard to detect = that. With the procedures in section 8 you sort of get the right = behavior for this. But if you delay the withdraw, you delay convergence = as well. Nothing in the draft prevents a withdraw to be delayed for = certain purposes, I would just leave it up to the implementation to = decide and not document in the draft. >=20 > --- >=20 > Section 3 >=20 > Many of the nits in section 2 apply here, too. Ice: Ok, I think I got them. >=20 > --- >=20 > Section 3 >=20 > While it is possible that the root of an MP2MP LSP is also a leaf and = can act as > a data source, I think that... >=20 > An MP2MP LSP is much like a P2MP LSP in that it consists of a single > root node, zero or more transit nodes and one or more leaf LSRs > acting equally as Ingress or Egress LSR.=20 >=20 > Should read "two or more leaf LSRs" since the semantic change from = P2MP is that > leaf nodes are ingresses as well as egresses, and it would make no = sense to have > only one. Ice: Well, you can have a Root node on a stick. This is typically a case = where you have a single leaf.=20 >=20 > --- >=20 > Section 3 >=20 > I can't help feeling that some figures would help understanding the = path that > packets are expected to take on an MP2MP LSP since this is key to = working out > what label state is installed. Ice: It is not that hard. Keep in mind that you build the LSP just like = a P2MP to the root. To get the MP2MP behavior you send label mappings = starting at the root down the tree following the previous installed LSP = branches. You end up with labels in both directions. With that said, the = path of the LSP is fixed now. >=20 > ---- >=20 > 5.1 >=20 > OLD > Type: The type of the LDP MP Status Value Element is to be assigned > by IANA. > NEW > Type: The type of the LDP MP Status Value Element. IANA maintains a > registry of status value types (see Section 11). >=20 >=20 > And in the figure s/Type(TBD)/Type/ Ice: Done. >=20 > --- >=20 > 5.2. LDP Messages containing LDP MP Status messages >=20 > The LDP MP status message may appear either in a label mapping > message or a LDP notification message. >=20 > I think s/status message/status TLV/ throughout. Ice: Ok. >=20 > --- >=20 > 5.2.1 >=20 > An LDP MP status TLV sent in a notification message must be > accompanied with a Status TLV. >=20 > This is a statement of fact not a piece of new protocol spec, so you = are correct > to use lower case "must". But you should include a reference at this = point. Ice: Ok. >=20 > --- >=20 > 7.1. Root node redundancy - procedures for P2MP LSPs >=20 > Since all leafs have set up P2MP LSPs to all the roots, they are > prepared to receive packets on either one of these LSPs. However, > only one of the roots should be forwarding traffic at any given = time, > for the following reasons: 1) to achieve bandwidth savings in the > network and 2) to ensure that the receiving leafs don't receive > duplicate packets (since one cannot assume that the receiving leafs = =20 > are able to discard duplicates). How the roots determine which one > is the active sender is outside the scope of this document. >=20 > The "should" seems strong since I know of deployed networks where 1+1 = style P2MP > transmission is performed and the application layer is responsible for = sorting > out duplicates that arise on failover. 1+1 is chosen in the face of = network cost > because of the high level of reliability that is wanted. Ice: In this procedure its mLDP that provides a redundancy where the = application layer does not need to be responsible in filtering the duplicates. There are = applications that don't support that behavior. This redundancy proposal is a generic Network based solution that is = hidden to the end customer. For the scenario that you described you = probably set up dedicated P2MP LSPs to achieve 1+1. This is normally not = a generic service that you apply to all the customer traffic. >=20 > --- >=20 > 8.3 >=20 > Same issue with the S-bit apparently always set meaning the capability = cannot be > withdrawn. Ice: Ok. >=20 > --- >=20 > Section 9 >=20 > This is not clear. The figure shows "Type=3DmLDP". There are two FEC = Elements > defined in the document so I think you need... >=20 > OLD >=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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Typed Wcard | Type =3D mLDP | Len =3D 2 | AFI = ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ | > +-+-+-+-+-+-+-+-+ >=20 > Type Wcard: As specified in [RFC5918] >=20 >=20 > Type: mLDP FEC Element Type as documented in this draft. >=20 > NEW >=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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Typed Wcard | Type | Len =3D 2 | AFI = ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ | > +-+-+-+-+-+-+-+-+ >=20 > Type Wcard: As specified in [RFC5918] >=20 >=20 > Type: The type of FEC Element Type. Either the P2MP FEC Element=20 > or the MP2MP FEC Element using the values defined for those > FEC Elements when carried in the FEC TLV as defined in this > document Ice: Ok. >=20 > --- >=20 > Section 10 >=20 > I am a bit disappointed by the Security Section. While it is true that = the > security relationships and techniques between LDP peers are not = changed, and the > imperatives are the same, you have introduced a new type of service = that has a > new attack vector. >=20 > In P2P LSPs, the sender has some control over the receiver, but this = is less the > case in leaf-initiated join to P2MP LSPs. I think this section should = at least > note that there is no way for a root to validate the leafs of the P2MP = tree. > Probably the only security you can offer is that; > - the leafs all form part of the same trusted network > - the opaque values could be made unguessably large > - the opaque values could be distributed in a secure way Ice: Let me think about this and discuss. >=20 > --- >=20 > Section 11 >=20 > Can you please add... >=20 > The requested code point values listed below have been allocated by > IANA through early allocation. >=20 > ...between... >=20 > The allocation policy for this space is 'Standards Action with > Early Allocation' >=20 > ...and... >=20 > This document requires allocation of three new code points from the > IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type > Name Space". The values are: Ice: Done. From internet-drafts@ietf.org Tue Jun 14 20:02: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 1760E11E80A3; Tue, 14 Jun 2011 20:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 4ZAkIhymy0pf; Tue, 14 Jun 2011 20:02:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805D111E808C; Tue, 14 Jun 2011 20:02: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.55 Message-ID: <20110615030228.7004.33343.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2011 20:02:28 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-identifiers-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: Wed, 15 Jun 2011 03:02: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 : MPLS-TP Identifiers Author(s) : Matthew Bocci George Swallow Eric Gray Filename : draft-ietf-mpls-tp-identifiers-05.txt Pages : 19 Date : 2011-06-14 This document specifies identifiers for MPLS-TP objects. Included are identifiers conformant to existing ITU conventions and identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (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-identifiers-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-identifiers-05.txt From verozheng@huawei.com Wed Jun 15 00:51: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 7BFDE11E80C5 for ; Wed, 15 Jun 2011 00:51: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=[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 smTXgf-t8cOu for ; Wed, 15 Jun 2011 00:51:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8417211E809D for ; Wed, 15 Jun 2011 00:51:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMT000VBN510J@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 15 Jun 2011 15:51:01 +0800 (CST) Received: from Z50128Z ([10.110.98.50]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMT00A2MN4UZ5@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 15 Jun 2011 15:51:01 +0800 (CST) Date: Wed, 15 Jun 2011 15:50:54 +0800 From: Vero Zheng In-reply-to: To: 'Alexander Vainshtein' , 'Mach Chen' , mpls@ietf.org, matthew.bocci@alcatel-lucent.com, swallow@cisco.com, eric.gray@ericsson.com Message-id: <016401cc2b30$f5b1da40$e1158ec0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgA= References: Cc: 'Matthew Wright' Subject: Re: [mpls] Question about ICC 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, 15 Jun 2011 07:51:47 -0000 Mach is correct on this.=20 ICC is unique within a Country. To make it globally unique, a Country = Code is needed before the ICC. Hope the authors of the identifiers draft are aware of this. Several other drafts may also be affected. Vero > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Alexander Vainshtein > Sent: Friday, June 10, 2011 9:37 PM > To: Mach Chen; mpls@ietf.org > Cc: Matthew Wright > Subject: Re: [mpls] Question about ICC >=20 > Mach, > An excellent question! >=20 > lots of thanks for picking this up! >=20 > regards, > Sasha > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach > Chen [mach.chen@huawei.com] > Sent: Friday, June 10, 2011 4:48 AM > To: mpls@ietf.org > Cc: Matthew Wright > Subject: [mpls] Question about ICC >=20 > Hi, >=20 > Are ICCs globally unique? >=20 > According to the definition of ICC in M.1400, it just says that ICCs = are unique > within a country. And there is an example shows that different = operators could > have the same ICC (e.g., Teleglobe International (UK) Ltd and = T=E9l=E9globe > Canada ULC have the ICC code:"TGB"). >=20 > So, if the ICCs are not globally unique, how to guarantee that the ICC-based > identifiers are globally unique? >=20 > Or maybe I missed something? >=20 >=20 > Best regards, > Mach > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=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 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. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Wed Jun 15 01:37:32 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 C6C4121F8599 for ; Wed, 15 Jun 2011 01:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, 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 HzcxbHaegoK9 for ; Wed, 15 Jun 2011 01:37:32 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id A42CA21F8598 for ; Wed, 15 Jun 2011 01:37:31 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 15 Jun 2011 09:37:29 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.142]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 15 Jun 2011 09:37:29 +0100 From: To: , , , , , , Date: Wed, 15 Jun 2011 09:37:25 +0100 Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAAAcZk8A== Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44058295438@EMV62-UKRD.domain1.systemhost.net> References: <016401cc2b30$f5b1da40$e1158ec0$@com> In-Reply-To: <016401cc2b30$f5b1da40$e1158ec0$@com> 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: matthew_282@virgilio.it Subject: Re: [mpls] Question about ICC 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, 15 Jun 2011 08:37:32 -0000 Folks: - We should be using source addresses in misconnectivity checking OAM CV me= ssages that relate to layer network access points. Total coupling of addre= ss *structure* to layer network topology however is not a good thing, as mi= nor changes to either require changes to the other.....total decoupling OTO= H relegates addresses to names. - We should not be using arbitrary 'text strings' to identify connections a= s was the common OPs practice when these really old ITU Recs were written. = Note that USA operators liked these and kept them in the SDH stds (path tr= ace) but other operators, and esp BT, pushed for pukka SA addresses to be u= sed. - I'm not sure country code classification is that relevant here....we are = not even dealing with a single layer network nor a TOS layer network where = peering is required (sure we can create such peering problems, but they are= technically quite unnecessary in any non-TOS layer network). What is more= relevant here is the client/server case...and this is not something any pr= evious co-ps mode layer technology has considered. Note we can have client= server netsting of several different parties in the same country. - A corollary of the client/server problem when the client and server have = the same traffic unit structure is that we can have inter-layer misconnecti= vity as well as intra-layer misconnectivity. This means that the address s= tructures we use in CV messages need to indicate at least 3 things: - the party X (globally unique) - the layer Y of party X (Y has to be unique within X) - the access point Z of layer network Y (Z has to be unique within Y). Note that the normal forwarding information in the DP traffic units only ne= ed consider the access points addresses Z (of some layer network Y). =20 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vero Zheng > Sent: 15 June 2011 08:51 > To: 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; > matthew.bocci@alcatel-lucent.com; swallow@cisco.com; > eric.gray@ericsson.com > Cc: 'Matthew Wright' > Subject: Re: [mpls] Question about ICC >=20 > Mach is correct on this. > ICC is unique within a Country. To make it globally unique, a Country > Code > is needed before the ICC. > Hope the authors of the identifiers draft are aware of this. >=20 > Several other drafts may also be affected. >=20 > Vero > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Alexander Vainshtein > > Sent: Friday, June 10, 2011 9:37 PM > > To: Mach Chen; mpls@ietf.org > > Cc: Matthew Wright > > Subject: Re: [mpls] Question about ICC > > > > Mach, > > An excellent question! > > > > lots of thanks for picking this up! > > > > regards, > > Sasha > > ________________________________________ > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach > > Chen [mach.chen@huawei.com] > > Sent: Friday, June 10, 2011 4:48 AM > > To: mpls@ietf.org > > Cc: Matthew Wright > > Subject: [mpls] Question about ICC > > > > Hi, > > > > Are ICCs globally unique? > > > > According to the definition of ICC in M.1400, it just says that ICCs > are > unique > > within a country. And there is an example shows that different > operators > could > > have the same ICC (e.g., Teleglobe International (UK) Ltd and > T=E9l=E9globe > > Canada ULC have the ICC code:"TGB"). > > > > So, if the ICCs are not globally unique, how to guarantee that the > ICC-based > > identifiers are globally unique? > > > > Or maybe I missed something? > > > > > > Best regards, > > Mach > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 loa@pi.nu Wed Jun 15 04:08: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 71BA89E800D for ; Wed, 15 Jun 2011 04:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 0sISyH8hVOOz for ; Wed, 15 Jun 2011 04:07:59 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id AAA549E800A for ; Wed, 15 Jun 2011 04:07:59 -0700 (PDT) Received: from [10.154.74.58] (unknown [192.165.126.77]) (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 7A8BD514044; Wed, 15 Jun 2011 13:07:56 +0200 (CEST) Message-ID: <4DF89286.4050103@pi.nu> Date: Wed, 15 Jun 2011 13:07:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: [mpls] verification call on draft-ietf-mpls-tp-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, 15 Jun 2011 11:08:00 -0000 Working Group, the authors of draft-ietf-mpls-tp-identifiers has updated the draft after working group last call and published version -05 of the document, that will be found at: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ A detailed list of how the wg lc comments has been addressed is found at: http://www.pi.nu/~loa/identifiers-resolution.xls This is to start a one week call to verify that the comments been correctly addressed. Please send your comments to the mpls working group mailing-list eob June 23 2011. /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 From ietf-ipr@ietf.org Wed Jun 15 08:29: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 850F511E8174; Wed, 15 Jun 2011 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 K+xhpaclEokl; Wed, 15 Jun 2011 08:29:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C85411E80BB; Wed, 15 Jun 2011 08:29:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: rajiva@cisco.com, , pmohapat@cisco.com, , X-Test-IDTracker: no Message-ID: <20110615152908.22057.55274.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 08:29:08 -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 RFC 5919 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, 15 Jun 2011 15:29:08 -0000 Dear Rajiv Asati, Emily Chen, Pradosh Mohapatra, Bob Thomas: An IPR disclosure that pertains to your RFC entitled "Signaling LDP Label Advertisement Completion" (RFC5919) was submitted to the IETF Secretariat on 2011-06-14 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1572/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to= RFC 5919.""); The IETF Secretariat From adrian@olddog.co.uk Wed Jun 15 11:16: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 C8F8611E812A for ; Wed, 15 Jun 2011 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] 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 EoZTNEGwgc9s for ; Wed, 15 Jun 2011 11:16:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id BAD4511E810E for ; Wed, 15 Jun 2011 11:16:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5FIGViV006092; Wed, 15 Jun 2011 19:16:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5FIGULp006073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2011 19:16:31 +0100 From: "Adrian Farrel" To: "'IJsbrand Wijnands'" References: <020701cc157c$259b8960$70d29c20$@huawei.com> <8FDA2A2C-658A-48DE-BE0E-837F45FAC39A@cisco.com> In-Reply-To: <8FDA2A2C-658A-48DE-BE0E-837F45FAC39A@cisco.com> Date: Wed, 15 Jun 2011 19:16:23 +0100 Message-ID: <137f01cc2b88$55f29690$01d7c3b0$@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: AQLkcg9Ce4ptjtxTf4VecJz3A1XF8QIS/Dm0kn2FEBA= Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-ldp-p2mp@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-p2mp 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: Wed, 15 Jun 2011 18:16:38 -0000 Hello Ice, Thanks for the good progress. responses in line. A > > Please s/draft/document/ in the text so that when it is published as an RFC the > > text is accurate. > > Ice: Is this a comment on its own or related to above or below? It is a standalone comment. The text you are writing will (you hope) be published as an RFC. So the text should not say (e.g.) "this draft will describe" but "this document describes" > > Section 1 > > > > Only a single copy of the packet will be sent > > on any link traversed by the MP LSP (see note at end of > > Section 2.4.1). > > > > Is this strictly true in all cases. are there not fringe cases, just as there > > were in P2MP RSVP-TE, where a branch is logically made upstream of a > > common link because of limited branching capabilities at the > > downstream end of the link? > > Ice: With mLDP this would typically not happen, but you do raise a good point. > The text is not accurate and there are examples where the same packet may be > transmitted over the the same link. For example with running mLDP over > Targeted LDP sessions, described in draft-napierala-mpls-targeted-mldp-01. It > changed 'link' into 'LDP neighbor', that captures it more accurate. I'm not going to push back any more on this. I don't think the case is as strong as it would be in a traffic engineered situation. I still think it could happen that packets are duplicated upstream of the physical branch node. > > 2.3 > > > > We don't generally define empty TLVs and objects. > > > > Can you convince me of the need for the Extended Type? Are you predicting a > > large number of FCFS opaque values?. You are surely not expecting many > > standards track types. > > Ice: Its always hard to predict these things, since the Type field is only 8 bits, I > think it was a good idea to reserve 255 and assigned an extended type to it. Just > in case we need it. Hmmm. Mutter, mutter. We can leave it and see whether the IESG complains. > > 2.4 > > > > 2. P2MP Label Map : a Label Map message with a FEC TLV with > > a single P2MP FEC Element and Label TLV with label L. > > > > Label L MUST be allocated from the per-platform label space (see > > [RFC3031] section 3.14) of the LSR sending the Label Map Message. > > > > While you are at liberty to make this "MUST" requirement with the WGs > > support, it would be good if you gave the reason rather than "sneaking" > > it in. I assume that you want to do this to make FRR easier, but it is not > > immediately clear why P2MP is in any way different from P2P on > > upstream interfaces. Or maybe it is because you want to allow the > > choice of downstream interface to rest with the upstream LSR > > (per 2.4.1.2). > > > > Can you add a short clause to say why the per-platform label space is used? > > Ice: Correct, the choice of the forwarding interface rests with the upstream LSR > and FRR is easier this way. But I would not say that is the reason we choose > platform label space, it is mostly that we are just following what is used for > unicast. I don't think anything prevents mLDP from working with per interface > label space. FRR becomes harder, but that would be the same for unicast.. So I'm > sure if we need to say anything more here. Well, you may be right in your description of most implementations. But, 5036 is quiet on the subject (implying that either label space is suitable) despite post-dating 4090. So, if you want to restrict implementations in this case (for example, suppose I don't want to support FRR, but am implementing this I-D) then you should give the reason. Or if, as you say, "I don't think anything prevents mLDP from working with per interface label space" then you need to remove this "MUST" > > 2.4.1.4 > > > > Trivially... > > > > Assuming its old forwarding state was > > L'-> { ..., }, its new forwarding state > > becomes L'-> { ..., , }. > > > > Misses the case that I=Ii for some value of i. > > Ice: Don't understand this comment. Can you elaborate? Ignore me. I'm thinking of something else! > > Section 3 > > > > While it is possible that the root of an MP2MP LSP is also a leaf and can act as > > a data source, I think that... > > > > An MP2MP LSP is much like a P2MP LSP in that it consists of a single > > root node, zero or more transit nodes and one or more leaf LSRs > > acting equally as Ingress or Egress LSR. > > > > Should read "two or more leaf LSRs" since the semantic change from P2MP > > is that leaf nodes are ingresses as well as egresses, and it would make no > > sense to have only one. > > Ice: Well, you can have a Root node on a stick. This is typically a case where you > have a single leaf. Right, so the single leaf sends data to the root. And then the root sends the data, erm, where? But, whatever... > > Section 3 > > > > I can't help feeling that some figures would help understanding the path that > > packets are expected to take on an MP2MP LSP since this is key to working out > > what label state is installed. > > Ice: It is not that hard. Keep in mind that you build the LSP just like a P2MP to the > root. To get the MP2MP behavior you send label mappings starting at the root > down the tree following the previous installed LSP branches. You end up with > labels in both directions. With that said, the path of the LSP is fixed now. Yes. I'm interested in how the data does not get back to the sender. > > Section 10 > > > > I am a bit disappointed by the Security Section. While it is true that the > > security relationships and techniques between LDP peers are not changed, > > and the imperatives are the same, you have introduced a new type of > > service that has a new attack vector. > > > > In P2P LSPs, the sender has some control over the receiver, but this is less the > > case in leaf-initiated join to P2MP LSPs. I think this section should at least > > note that there is no way for a root to validate the leafs of the P2MP tree. > > Probably the only security you can offer is that; > > - the leafs all form part of the same trusted network > > - the opaque values could be made unguessably large > > - the opaque values could be distributed in a secure way > > Ice: Let me think about this and discuss. OK. Let me know. From internet-drafts@ietf.org Wed Jun 15 13:11: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 1CC869E8024; Wed, 15 Jun 2011 13:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 v6dVLwTNlV+p; Wed, 15 Jun 2011 13:11:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1BF9E8010; Wed, 15 Jun 2011 13:11:11 -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.55 Message-ID: <20110615201111.9708.6564.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 13:11:11 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-fastreroute-mib-20.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, 15 Jun 2011 20:11:12 -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 (MPLS) Traffic Engineering= Management Information Base for Fast Reroute Author(s) : Thomas D. Nadeau Cisco Systems Riza Cetin Filename : draft-ietf-mpls-fastreroute-mib-20.txt Pages : 50 Date : 2011-06-15 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-20.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-fastreroute-mib-20.txt From swmike@swm.pp.se Wed Jun 15 22:36: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 A5E3911E80D4 for ; Wed, 15 Jun 2011 22:36:41 -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 4TSjhUi0-NnZ for ; Wed, 15 Jun 2011 22:36:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B479211E80B4 for ; Wed, 15 Jun 2011 22:36:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 158AF9C; Thu, 16 Jun 2011 07:36:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 11F599A; Thu, 16 Jun 2011 07:36:35 +0200 (CEST) Date: Thu, 16 Jun 2011 07:36:35 +0200 (CEST) From: Mikael Abrahamsson To: "Rajiv Asati (rajiva)" In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C051D2959@XMB-RCD-111.cisco.com> Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C051D2959@XMB-RCD-111.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Request for WGLC draft-ietf-mpls-ldp-ipv6-04 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, 16 Jun 2011 05:36:41 -0000 On Tue, 31 May 2011, Rajiv Asati (rajiva) wrote: > The authors believe that draft-ietf-mpls-ldp-ipv6-04 is ready for the > WGLC. Could you please advise the next step? Hi, I haven't seen any replies to this. I feel that ipv6 only control plane for MPLS is long overdue and this really needs to get done so vendors can start implementing it. Any new ISP won't be able to get more than a /22 of IPv4 addresses and would most likely have to resort to using RFC1918 addresses for infrastructure which will bring with it all kinds of badness. What else is missing from the MPLS ecosystem to get us to (from a standards point of view) feature parity between v4 and v6 for control plane? -- Mikael Abrahamsson email: swmike@swm.pp.se From loa@pi.nu Thu Jun 16 00:48: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 E0E9C228006 for ; Thu, 16 Jun 2011 00:48:52 -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 rctC3tyXqNrm for ; Thu, 16 Jun 2011 00:48:52 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4221F8440 for ; Thu, 16 Jun 2011 00:48:52 -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 968C5514044; Thu, 16 Jun 2011 09:48:50 +0200 (CEST) Message-ID: <4DF9B561.6050806@pi.nu> Date: Thu, 16 Jun 2011 09:48:49 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] working group last call on draft-ietf-mpls-tp-mib-management-overview-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: Thu, 16 Jun 2011 07:48:53 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-mib-management-overview-04.txt Please send your comments to the mpls@ietf.org mailing list. This working group last call ends on June 30th 2011. /Loa for 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 From ice@cisco.com Thu Jun 16 01:35: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 3182B11E80F0 for ; Thu, 16 Jun 2011 01:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 NtafVVhMm25Y for ; Thu, 16 Jun 2011 01:35:39 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DA6D211E807B for ; Thu, 16 Jun 2011 01:35:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5G831ZA009522; Thu, 16 Jun 2011 10:03:02 +0200 (CEST) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5G831H7027640; Thu, 16 Jun 2011 10:03:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <137f01cc2b88$55f29690$01d7c3b0$@olddog.co.uk> Date: Thu, 16 Jun 2011 10:03:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18C446C0-CEF8-41C9-879E-83E74F401F2B@cisco.com> References: <020701cc157c$259b8960$70d29c20$@huawei.com> <8FDA2A2C-658A-48DE-BE0E-837F45FAC39A@cisco.com> <137f01cc2b88$55f29690$01d7c3b0$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, draft-ietf-mpls-ldp-p2mp@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-p2mp 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, 16 Jun 2011 08:35:40 -0000 Adrian, See comments inline: >>=20 >> Ice: Correct, the choice of the forwarding interface rests with the = upstream > LSR >> and FRR is easier this way. But I would not say that is the reason we = choose >> platform label space, it is mostly that we are just following what is = used for >> unicast. I don't think anything prevents mLDP from working with per = interface >> label space. FRR becomes harder, but that would be the same for = unicast.. So > I'm >> sure if we need to say anything more here. >=20 > Well, you may be right in your description of most implementations. = But, 5036 is > quiet on the subject (implying that either label space is suitable) = despite > post-dating 4090. >=20 > So, if you want to restrict implementations in this case (for example, = suppose I > don't want to support FRR, but am implementing this I-D) then you = should give > the reason. >=20 > Or if, as you say, "I don't think anything prevents mLDP from working = with per > interface label space" then you need to remove this "MUST" Ice: Lets take the approach to claim Interface label space is out of = scope. >>=20 >> Ice: Well, you can have a Root node on a stick. This is typically a = case where > you >> have a single leaf. >=20 > Right, so the single leaf sends data to the root. And then the root = sends the > data, erm, where? Ice: This is a characteristic of MP2MP LSP. A Leaf may inject packets to = the root of the tree but has no knowledge if there would be a receiver = behind the root. The root will always receive the traffic, and drop it = if there are no receivers. Its the same in PIM Bidir trees. >>>=20 >>> I can't help feeling that some figures would help understanding the = path > that >>> packets are expected to take on an MP2MP LSP since this is key to = working > out >>> what label state is installed. >>=20 >> Ice: It is not that hard. Keep in mind that you build the LSP just = like a P2MP > to the >> root. To get the MP2MP behavior you send label mappings starting at = the root >> down the tree following the previous installed LSP branches. You end = up with >> labels in both directions. With that said, the path of the LSP is = fixed now. >=20 > Yes. I'm interested in how the data does not get back to the sender. Ice: Please see section 3.3.1.5; If it does not, it allocates a label Lu' and creates a new label swap for Lu' with Label Lu over interface Iu. Interface Iu is determined via the procedures in Section 2.4.1.2. In addition, it also adds the label swap(s) from the forwarding state downstream , omitting the swap on interface I for node D. The swap on interface I for node D is omitted to prevent packet originated by D to be forwarded back to D. Thx, Ice.= From loa@pi.nu Thu Jun 16 02:01: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 2D62111E80F0 for ; Thu, 16 Jun 2011 02:01:52 -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 27yXjpfPbOub for ; Thu, 16 Jun 2011 02:01:51 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5311E8077 for ; Thu, 16 Jun 2011 02:01:51 -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 E748A514044; Thu, 16 Jun 2011 11:01:47 +0200 (CEST) Message-ID: <4DF9C673.6070605@pi.nu> Date: Thu, 16 Jun 2011 11:01:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: statments@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, lear@cisco.com, yoichi.maeda@ttc.or.jp, ahmpls-tp@lists.itu.int, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, elisa.bellagamba@ericsson.com, ghani.abbas@ericsson.com Subject: [mpls] The IETF MPLS working group last call on "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview" (ref #055.01) 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, 16 Jun 2011 09:01:52 -0000 SG15, Q9, Q10, Q12 and Q14 For Information. The MPLS working group would like to inform you that we have started a working group last call on "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview" (draft-ietf-mpls-tp-mib-management-overview-04.txt) Please send your comments to the mpls@ietf.org mailing list before June 30th, 2011. Loa Andersson on behalf the mpls wg -- 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 eric.gray@ericsson.com Thu Jun 16 03: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 7205811E80DD for ; Thu, 16 Jun 2011 03:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 yKZV5O301Gjd for ; Thu, 16 Jun 2011 03:42:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA3811E807F for ; Thu, 16 Jun 2011 03:42:56 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5GAgt3e011037 for ; Thu, 16 Jun 2011 05:42:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 16 Jun 2011 06:42:49 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Thu, 16 Jun 2011 06:42:46 -0400 Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwABZ9x4AAd4aAEA== 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: [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-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, 16 Jun 2011 10:42:57 -0000 Forwarding in plain text... ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 13, 2011 9:54 PM To: Alexander Vainshtein; Daniel Cohn Cc: ma.yuxia@zte.com.cn; mpls@ietf.org; pwe3@ietf.org Subject: RE: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Dear All, I cannot find any reference to Inter-Chassis Communication Protocol (ICCP) = as part of MPLS-TP Control Plane. That might be our omission but as of now = Control plane solution for PW redundancy might be outside of MPLS-TP scope. =20 Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Monday, June 13, 2011 8:11 AM To: Daniel Cohn Cc: ma.yuxia@zte.com.cn; mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia= @zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is o= nly required in the event of S-PE failure at an MS-PW - this is clearly st= ated in the draft. Now, both Sasha and Nurit mention that the PW redundancy= mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environm= ent without a control plane, the PW redundancy mechanism must also rely on = proactive connectivity check for fast failure detection to meet the sub-50= ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here.= Detecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection dr= aft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised = the scalability issue. My issue was limited applicability scope when compar= ed to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-h= omed CEs in SS- and MS-PWs - something that liner protection of PWs cannot = do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale"= - scalability is not a binary concept. You can say that PW protection scal= es worse than LSP protection, just like you can say that LSP protection sca= les worse than interface protection. Which didn't stop IETF from defining L= SP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can b= e used to meet MPLS-TP PW protection requirements. I can identify the follo= wing reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection t= riggers and how to handle coexisting triggers, as requested in RFC 5654 (MP= LS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinate= d protection switching happens. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered s= witch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially importan= t to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP R= equirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surpri= se, because MPLS-TP requirements have been defined much later than the PW r= edundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechan= isms. - It's a two-phase protocol, with the consequent impact on timing[= [[Sasha]]] Could you please elaborate?=20 - It doesn't define retransmission of protection coordination mess= ages, so loss of a single PDU can result in switchover not taking place, th= us not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which ben= efits from TCP retransmissions) or on top of static PW status messages (whe= re retransmission is defined).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, an= d as such does not meet the TP requirements. Of course modifications may be= introduced, but why reinvent the wheel when there is a protocol (draft-iet= f-mpls-tp-linear-protection-06) in the standards track that supports all th= e above requirements and can be applied to MS-PW protection with minor modi= fications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard = restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, = an obvious way to provide protection for a PW is to protect the LSP that ca= rries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW = in individual segments. This means that a single LSP recovery action canno= t protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW re= dundancy mechanisms provide means for the PEs to coordinate over which LSP = the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtectio= n Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of = many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed ther= e as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the St= atic PW Status Messages draft ( if, for whatever reason, you do n= ot want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.= yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appl= icability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be t= he same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 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.=20 From eric.gray@ericsson.com Thu Jun 16 03:43:35 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 D2ADE11E813C for ; Thu, 16 Jun 2011 03:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 zI9YOtHqwlc6 for ; Thu, 16 Jun 2011 03:43:34 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4814311E8106 for ; Thu, 16 Jun 2011 03:43:34 -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 p5GAhXCP011049 for ; Thu, 16 Jun 2011 05:43:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 16 Jun 2011 06:43:27 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Thu, 16 Jun 2011 06:43:25 -0400 Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwAADpDNAAJfe4EABnKWDw 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: [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-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, 16 Jun 2011 10:43:35 -0000 =20 Forwarding in plain text... ________________________________ From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, June 14, 2011 7:31 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein Cc: mpls@ietf.org; pwe3@ietf.org; ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi Nurit, =20 The exact same argument can be made for LSP linear protection as in draft-i= etf-mpls-tp-linear-protection - it protects LSRs (transit LERs) but doesn't= protect head/tail LERs. So why not drop LSP linear protection altogether a= nd protect the client service layer instead?=20 Protection is a statistical business. Protecting S-PE will improve availabi= lity, even when T-PE is not protected - especially when you remember that t= ypically there are many more S-PEs than T-PEs in a given PW. Also as the T-= PE is typically closest to the edge, a T-PE will typically carry less PWs t= han an S-PE so S-PE protection would be more significant for the operator.= =20 AC protection (required in order to protect T-PE) using ICCP or similar, as= Greg pointed out, is not defined as part of the MPLS-TP framework. In the = most extreme case, which is gradually becoming the norm, operators deploy M= PLS to the customer edge, so the T-PE will actually be a CE in which case C= E/T-PE protection is technically an impossibility. =20 On the other hand, there is a clear MPLS-TP requirement to provide protecti= on for MPLS-TP transport paths, which includes PWs. The purpose of this dra= ft is to meet this requirement, for which there is currently no solution. I= f you have an alternative solution please share it with the list so we can = discuss it. =20 Thanks, =20 Daniel =20 =20 From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m]=20 Sent: Monday, June 13, 2011 6:23 PM To: ext Alexander Vainshtein; Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 If you do it on the client service layer, you can protect also the T-PE... Why do you want to protect only against a failure of the S-PE? The PW start= s at the T-PE... =20 From: ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia= @zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is o= nly required in the event of S-PE failure at an MS-PW - this is clearly st= ated in the draft. Now, both Sasha and Nurit mention that the PW redundancy= mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environm= ent without a control plane, the PW redundancy mechanism must also rely on = proactive connectivity check for fast failure detection to meet the sub-50= ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here.= Detecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection dr= aft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised = the scalability issue. My issue was limited applicability scope when compar= ed to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-h= omed CEs in SS- and MS-PWs - something that liner protection of PWs cannot = do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale"= - scalability is not a binary concept. You can say that PW protection scal= es worse than LSP protection, just like you can say that LSP protection sca= les worse than interface protection. Which didn't stop IETF from defining L= SP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can b= e used to meet MPLS-TP PW protection requirements. I can identify the follo= wing reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection t= riggers and how to handle coexisting triggers, as requested in RFC 5654 (MP= LS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinate= d protection switching happens. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered s= witch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially importan= t to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP R= equirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surpri= se, because MPLS-TP requirements have been defined much later than the PW r= edundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechan= isms. - It's a two-phase protocol, with the consequent impact on timing[= [[Sasha]]] Could you please elaborate?=20 - It doesn't define retransmission of protection coordination mess= ages, so loss of a single PDU can result in switchover not taking place, th= us not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which ben= efits from TCP retransmissions) or on top of static PW status messages (whe= re retransmission is defined).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, an= d as such does not meet the TP requirements. Of course modifications may be= introduced, but why reinvent the wheel when there is a protocol (draft-iet= f-mpls-tp-linear-protection-06) in the standards track that supports all th= e above requirements and can be applied to MS-PW protection with minor modi= fications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard = restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, = an obvious way to provide protection for a PW is to protect the LSP that ca= rries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW = in individual segments. This means that a single LSP recovery action canno= t protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW re= dundancy mechanisms provide means for the PEs to coordinate over which LSP = the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtectio= n Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of = many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed ther= e as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the St= atic PW Status Messages draft ( if, for whatever reason, you do n= ot want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.= yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appl= icability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be t= he same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 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.=20 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.=20 From eric.gray@ericsson.com Thu Jun 16 03:46: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 3AFF611E8077 for ; Thu, 16 Jun 2011 03:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 Q+-Ss67L0Y0a for ; Thu, 16 Jun 2011 03:45:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DF7E211E807F for ; Thu, 16 Jun 2011 03:45:58 -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 p5GAjvLd011135 for ; Thu, 16 Jun 2011 05:45:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 16 Jun 2011 06:45:52 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Thu, 16 Jun 2011 06:45:47 -0400 Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwACeE3pAAZpBUYA== 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: [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-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, 16 Jun 2011 10:46:00 -0000 Forwarded in plain text... ________________________________ From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, June 14, 2011 7:34 AM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi Sasha, thanks again and see inline with [DC]. =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia= @zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is o= nly required in the event of S-PE failure at an MS-PW - this is clearly st= ated in the draft. Now, both Sasha and Nurit mention that the PW redundancy= mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environm= ent without a control plane, the PW redundancy mechanism must also rely on = proactive connectivity check for fast failure detection to meet the sub-50= ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here.= Detecting S-PE failures based on the control plane would not fast enough. [DC] Agreed - I just pointed our that MPLS-TP has a requirement for sub-50m= s protection. Therefore any scalability considerations that apply to the PW protection dr= aft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised = the scalability issue. My issue was limited applicability scope when compar= ed to PW redundancy.=20 [DC] Correct - scalability issue was a response to Nurit's comment. E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and M= S-PWs - something that liner protection of PWs cannot do. [DC] I'm afraid I don't follow you here. Where does PW redundancy take care= of dual-homed CE? Actually PW redundancy draft explicitly states: "The met= hod for dual-homing of CE1 to PE1 and to PE3 nodes, and the protocols used,= are outside the scope of this document".=20 Also wrt scalability, there is no such thing as "scales" or "doesn't scale"= - scalability is not a binary concept. You can say that PW protection scal= es worse than LSP protection, just like you can say that LSP protection sca= les worse than interface protection. Which didn't stop IETF from defining L= SP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can b= e used to meet MPLS-TP PW protection requirements. I can identify the follo= wing reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection t= riggers and how to handle coexisting triggers, as requested in RFC 5654 (MP= LS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinate= d protection switching happens. [DC] It is. But still it needs to be defined by the recovery framework, e.g= . what should the endpoint do when one PW is in SF and the other is in SD, = or when both are in SD. Operators expect well-defined behavior in these and= other scenarios, and PW redundancy does not define them (because it was no= t in their scope).=20 - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered s= witch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially importan= t to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP R= equirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surpri= se, because MPLS-TP requirements have been defined much later than the PW r= edundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechan= isms. [DC] So how do you propose to meet the PW protection requirement?=20 - It's a two-phase protocol, with the consequent impact on timing[= [[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-pr= otection, each endpoint will immediately switch traffic to the other path u= pon identifying an SF condition in a path, without waiting for the far end = to acknowledge the switch (1-phase). In PW redundancy, an endpoint detectin= g an SF condition in a path will not switch until the far end has acknowled= ged the switch (2-phase). Needless to say, recovery is slower in a 2-phase = protocol. =20 - It doesn't define retransmission of protection coordination mess= ages, so loss of a single PDU can result in switchover not taking place, th= us not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which ben= efits from TCP retransmissions) or on top of static PW status messages (whe= re retransmission is defined).=20 [DC] True - but static PW status defines slow retransmission ("will be tran= smitted twice at an initial interval of one second") while draft-ietf-mpls-= tp-linear-protection specifies fast retransmission when required for fast r= ecovery (section 3.1.4).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, an= d as such does not meet the TP requirements. Of course modifications may be= introduced, but why reinvent the wheel when there is a protocol (draft-iet= f-mpls-tp-linear-protection-06) in the standards track that supports all th= e above requirements and can be applied to MS-PW protection with minor modi= fications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. [DC] If we were discussing designing a new protocol, I might agree with you= . But from a practical standpoint, the PW protection draft is not a dedicat= ed protocol - it's an applicability statement to an existing protocol. Both= from the implementation and the operational point of view it defines a new= use case for an existing protocol and concept. =20 =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard = restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, = an obvious way to provide protection for a PW is to protect the LSP that ca= rries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW = in individual segments. This means that a single LSP recovery action canno= t protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW re= dundancy mechanisms provide means for the PEs to coordinate over which LSP = the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtectio= n Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of = many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed ther= e as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the St= atic PW Status Messages draft ( if, for whatever reason, you do n= ot want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.= yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appl= icability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be t= he same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 [Disclaimer Elided]=20 From eric.gray@ericsson.com Thu Jun 16 03:49: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 EEBD211E813C for ; Thu, 16 Jun 2011 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 ni53rmVB91Ss for ; Thu, 16 Jun 2011 03:49:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 810E711E8077 for ; Thu, 16 Jun 2011 03:49:04 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5GAn3sg011222 for ; Thu, 16 Jun 2011 05:49:04 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 16 Jun 2011 06:48:57 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Thu, 16 Jun 2011 06:48:55 -0400 Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwACeE3pAAA/tUMABitFhg 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: [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-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, 16 Jun 2011 10:49:06 -0000 Forwarded in plain text... ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Tuesday, June 14, 2011 8:02 AM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Daniel, Please see more inline (bold purple italics). I've also stripped the portio= ns of the text that are not related to this round of comments. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, June 14, 2011 2:34 PM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi Sasha, thanks again and see inline with [DC]. From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Daniel and all, Please see some comments inline below. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia= @zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, Thanks all for the feedback. I believe we all agree that PW protection is o= nly required in the event of S-PE failure at an MS-PW - this is clearly st= ated in the draft. Now, both Sasha and Nurit mention that the PW redundancy= mechanism can meet the MPLS-TP PW protection requirements. [[[Sasha]]] ... snipped ... E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and M= S-PWs - something that liner protection of PWs cannot do. [DC] I'm afraid I don't follow you here. Where does PW redundancy take care= of dual-homed CE? Actually PW redundancy draft explicitly states: "The met= hod for dual-homing of CE1 to PE1 and to PE3 nodes, and the protocols used,= are outside the scope of this document". [[[Sasha]]] Quoting from the draft: 15.2. Multiple Multi-homed CEs with single SS-PW redundancy |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V (not shown) V V | V AC +----+ +----+ AC V +-----+ | |....|.......PW1........|....| | +-----+ | |----------| PE1|...... .........| PE3|----------| | | CE1 | +----+ \ / PW3 +----+ | CE2 | | | +----+ X +----+ | | | | | |....../ \..PW4....| | | | | |----------| PE2| | PE4|--------- | | +-----+ | |....|.....PW2..........|....| | +-----+ AC +----+ +----+ AC Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy The application in Figure 15-2 makes use of the Independent mode of operation. CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The method for dual-homing and the used protocols are outside the scope of this document. Note that the PSN tunnels are not shown in this figure for clarity. However, it can be assumed that each of the PWs shown is encapsulated in a separate PSN tunnel. Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is Standby; furthermore, assume that the AC from CE2 to PE3 is Standby and from CE2 to PE4 is Active. The method of deriving Active/Standby status of the AC is outside the scope of this document. PE1 advertises the preferential status "Active" and operational status "Pseudowire forwarding" for pseudowires PW1 and PW4 connected to PE3 and PE4. This status reflects the forwarding state of the AC attached to PE1. PE2 advertises preferential status "Standby" and operational status "Pseudowire forwarding" for pseudowires PW2 and PW3 to PE3 and PE4. PE3 advertises preferential status "Standby" and operational status "Pseudowire forwarding" for pseudowires PW1 and PW3 to PE1 and PE2. PE4 advertise the preferential status "Active" and operational status "Pseudowire forwarding" for pseudowires PW2 and PW4 to PE2 and PE1 respectively. Thus by matching the local and remote preferential forwarding status of "Active" and operational status of "Pseudowire forwarding" of pseudowires, the PE nodes determine which PW should be in the Active state. In this case it is PW4 that will be selected. On failure of the AC between CE1 and PE1, the forwarding state of the AC on PE2 is changed to Active. PE2 then announces the newly changed 'preferential forwarding' status bit of "active" to PE3 and PE4. PE1 will advertise a PW status notification message indicating that the AC between CE1 and PE1 is operationally down. PE2 and PE4 match the local and remote preferential forwarding status of "Active" and operational status "Pseudowire forwarding" and select PW2 as the new active pseudowire to send traffic to. On failure of PE1 node, PE2 will detect it and will transition the forwarding state of its AC to Active. The method by which PE2 detects that PE1 is down is outside the scope of this document. PE2 then announces the newly changed 'preferential forwarding' status bit of "Active" to PE3 and PE4. PE2 and PE4 match the local and remote preferential forwarding status of "Active" and operational status "Pseudowire forwarding" and select PW2 as the new active pseudowire to send traffic to. Note that PE3 and PE4 may have detected that the PW to PE1 went down via T-LDP Hello timeout or via other means. However, they will not be able to forward user traffic until they received the updated status bit from PE2. Because each dual-homing algorithm running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently, there is a need to signal the active status of the AC such that the PE nodes can select a common active PW for end-to-end forwarding between CE1 and CE2 as per the procedures in the independent mode. Note that any primary/secondary procedures, as defined in sections 5.1. and 5.2. , do not apply in this use case as the Active/Standby status is driven by the AC forwarding state as determined by the AC dual-homing protocol used. I believe you've taken your "out of scope" reference from this text, but IM= HO you misinterpreted it. What it means (or so I read it) is that specific dual-homing protocol is ou= t of scope as long as it meets certain assumptions. Aside: It would be good if the authors of the PW redundancy drafts could ex= plicitly specify these assumptions. [[[Sasha]]] ... snipped ... Now let's turn our attention back to whether the PW redundancy draaft can b= e used to meet MPLS-TP PW protection requirements. I can identify the follo= wing reasons why in its current form it doesn't: - It explicitly ("outside the scope") does not define protection t= riggers and how to handle coexisting triggers, as requested in RFC 5654 (MP= LS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinate= d protection switching happens. [DC] It is. But still it needs to be defined by the recovery framework, e.g= . what should the endpoint do when one PW is in SF and the other is in SD, = or when both are in SD. Operators expect well-defined behavior in these and= other scenarios, and PW redundancy does not define them (because it was no= t in their scope). [[[Sasha]]] I wonder if you have followed the discussion regarding ability = to define SD condition for LSPs and PWs on the MPLS-TP list? IMO it is not = possible to define it in a meaningful way. Hence I do not see a proposal th= at does not address a scenario that does not exist in reality as a flawed o= ne. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered s= witch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially importan= t to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP R= equirements), req #65 [[[Sasha]]] All these claims are correct - and this should not be a surpri= se, because MPLS-TP requirements have been defined much later than the PW r= edundancy mechanism. But I do not think that this justifies co-existence of two different mechan= isms. [DC] So how do you propose to meet the PW protection requirement? - It's a two-phase protocol, with the consequent impact on timing[= [[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-pr= otection, each endpoint will immediately switch traffic to the other path u= pon identifying an SF condition in a path, without waiting for the far end = to acknowledge the switch (1-phase). In PW redundancy, an endpoint detectin= g an SF condition in a path will not switch until the far end has acknowled= ged the switch (2-phase). Needless to say, recovery is slower in a 2-phase = protocol. [[[Sasha]]] To the best of my understanding, 1-phase protection is only pos= sible in 1+1 unidirectional architectures. And yes, I know that MPLS-TP req= uires a mechanism to support this; whether anybody would really do that in= the packet-switching network is not clear to me. And I acknowledge that th= e PW redundancy drafts do not support 1+1 unidirectional scheme. - It doesn't define retransmission of protection coordination mess= ages, so loss of a single PDU can result in switchover not taking place, th= us not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which ben= efits from TCP retransmissions) or on top of static PW status messages (whe= re retransmission is defined). [DC] True - but static PW status defines slow retransmission ("will be tran= smitted twice at an initial interval of one second") while draft-ietf-mpls-= tp-linear-protection specifies fast retransmission when required for fast r= ecovery (section 3.1.4). In summary, PW redundancy was not designed with TP requirements in mind, an= d as such does not meet the TP requirements. Of course modifications may be= introduced, but why reinvent the wheel when there is a protocol (draft-iet= f-mpls-tp-linear-protection-06) in the standards track that supports all th= e above requirements and can be applied to MS-PW protection with minor modi= fications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. [DC] If we were discussing designing a new protocol, I might agree with you= . But from a practical standpoint, the PW protection draft is not a dedicat= ed protocol - it's an applicability statement to an existing protocol. Both= from the implementation and the operational point of view it defines a new= use case for an existing protocol and concept. Regards, Daniel From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard = restrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, = an obvious way to provide protection for a PW is to protect the LSP that ca= rries it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW = in individual segments. This means that a single LSP recovery action canno= t protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW re= dundancy mechanisms provide means for the PEs to coordinate over which LSP = the traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtectio= n Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of = many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed ther= e as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the St= atic PW Status Messages draft ( if, for whatever reason, you do n= ot want to, or cannot, use RFC 4447 ). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.= yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appl= icability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be t= he same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel [Disclaimer Elided] From swallow@cisco.com Tue Jun 14 20:28: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 25F3B228004 for ; Tue, 14 Jun 2011 20:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 B-SMgUulHqkL for ; Tue, 14 Jun 2011 20:28:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54711E809F for ; Tue, 14 Jun 2011 20:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=42609; q=dns/txt; s=iport; t=1308108526; x=1309318126; h=date:subject:from:to:message-id:mime-version; bh=ZqqjxR/2XlIJ/9UmkRdKpMjVDh+GN8N3bkukCHcLdVc=; b=TPSlEHT5m96yDubGchE6dMg25avZiLa7mi2XkT7UtFI+xHtt1DWeY4A6 tD10yaug1MCoJAa9GDzL2xQQ6pIQffo0SdIKZyk4Y5pzzJKr8MuPN9nj2 wWC4hxvIe7Pi/pBgUfIIx86d48GiElMexV3DKi2t6rgJUdP0AzU9TwzjK Q=; X-Files: Version4_Comment_Resolution.xls : 30208 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgGAG8l+E2tJXHA/2dsb2JhbABSglGVO41jYneoMoEenkGGJgSRSYRiiyg X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="xls'32?scan'32,208,217,32";a="236395160" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2011 03:28:45 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5F3SjSg031515 for ; Wed, 15 Jun 2011 03:28:45 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, 14 Jun 2011 22:28:45 -0500 Received: from 10.98.32.172 ([10.98.32.172]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Jun 2011 03:28:45 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 14 Jun 2011 23:29:50 -0400 From: George Swallow To: Message-ID: Thread-Topic: Updated Identifiers draft version 5 Thread-Index: AcwrDHuXWYPTNZH5XkKclH9Af/peUA== Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3390938992_88638233" X-OriginalArrivalTime: 15 Jun 2011 03:28:45.0413 (UTC) FILETIME=[5517D950:01CC2B0C] X-Mailman-Approved-At: Thu, 16 Jun 2011 03:50:06 -0700 Subject: [mpls] Updated Identifiers draft version 5 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, 15 Jun 2011 03:28:48 -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_3390938992_88638233 Content-type: multipart/alternative; boundary="B_3390938992_88669736" --B_3390938992_88669736 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Attached is a spreadsheet showing the disposition of the comments on version 4. ...George --B_3390938992_88669736 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Updated Identifiers draft version 5 Attached is a spreadsheet showing the disposition of the comments on versi= on 4.

            ...George             --B_3390938992_88669736-- --B_3390938992_88638233 Content-type: application/x-msexcel; name="Version4_Comment_Resolution.xls"; x-mac-creator="5843454C"; x-mac-type="584C5338" Content-disposition: attachment; filename="Version4_Comment_Resolution.xls" Content-transfer-encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA AAAAEAAAKwAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////OQAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAD+/////v////7///8uAAAALwAAADAA AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAAP7////+//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAMLm EBkMK8wBLAAAAMABAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEEAAAA//////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAg1AAAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEA AAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0AAAB0FwAA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABgBAAAAAAAACQgQAAAGBQDpUMwHAAACAAYEAADhAAIAsATBAAIA AADiAAAAXABwAA4AAEdlb3JnZSBTd2FsbG93ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCAAIAsARhAQIAAAA9AQIAAQCcAAIAEAAZAAIAAAASAAIAAAATAAIA AACvAQIAAAC8AQIAAAA9ABIA7P/s/6R+4Ew4AAAAAAABAPQBQAACAAAAjQACAAAAIgACAAEA DgACAAEAtwECAAAA2gACAAAAMQAXAMgAAAD/f5ABAAAAAAAABwBWZXJkYW5hMQAXAMgAAQD/ f7wCAAAAAAAABwBWZXJkYW5hMQAXAMgAAgD/f5ABAAAAAAAABwBWZXJkYW5hMQAXAMgAAwD/ f7wCAAAAAAAABwBWZXJkYW5hMQAXAMgAAAD/f5ABAAAAAAAABwBWZXJkYW5hMQAXAKAAAAD/ f5ABAAAAAAAABwBWZXJkYW5hMQAXAMgABAAMAJABAAABAAAABwBWZXJkYW5hMQAXAMgABAA9 AJABAAABAAAABwBWZXJkYW5hHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMwXCkeBCEA BgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcAHQAAIiQiIywjIzAuMDBf KTtcKCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIjLCMjMC4wMF8pO1tSZWRdXCgiJCIjLCMj MC4wMFwpHgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7XygiJCIqIFwoIywjIzBcKTtfKCIkIiog Ii0iXyk7XyhAXykeBC4AKQApAABfKCogIywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSJf KTtfKEBfKR4EPwAsADoAAF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMwLjAwXCk7 XygiJCIqICItIj8/Xyk7XyhAXykeBDYAKwAxAABfKCogIywjIzAuMDBfKTtfKCogXCgjLCMj MC4wMFwpO18oKiAiLSI/P18pO18oQF8pHgQMAKQABwAAR2VuZXJhbOAAFAAAAAAA9f8gAAAA AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAA AADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAA FAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA 9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0 AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAA AADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAA FAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAAAQAgAAAAAAAAAAAAAADAIOAAFAAFACsA 9f8gAAD4AAAAAAAAAADAIOAAFAAFACkA9f8gAAD4AAAAAAAAAADAIOAAFAAFACwA9f8gAAD4 AAAAAAAAAADAIOAAFAAFACoA9f8gAAD4AAAAAAAAAADAIOAAFAAIAAAA9P8AAAD0AAAAAAAA AADAIOAAFAAHAAAA9P8AAAD0AAAAAAAAAADAIOAAFAAFAAkA9f8gAAD4AAAAAAAAAADAIOAA FAAAAAAAAQAAAAAQAAAAAAAAAADAIOAAFAAAAAAAAQABAAAQAAAAAAAAAADAIOAAFAAAAAAA AQAIAAAQAAAAAAAAAADAIOAAFAAAAAAAAQAJAAAQAAAAAAAAAADAIJMCBAAQgAP/kwIEABGA Bv+TAgQAEoAE/5MCBAATgAf/kwIEABSACf+TAgQAFYAI/5MCBAAAgAD/kwIEABaABf+SAOIA OAAAAAAA////AN0IBgAftxQAAADUAPzzBQDyCIQAAKvqAJAAAAAAZBEAAACQAJBxOgBGAKUA AICAAMDAwACAgIAAY6r+AN0tMgD/9YwATuJXAGcR/wD+p0YAhlNXAKK9kABjqv4A3S0yAP/1 jABO4lcAZxH/AP6nRgCGU1cAor2QAADM/wDM//8AzP/MAP//mQCZzP8A/5nMAMyZ/wD/zJkA M2b/ADPMzACZzAAA/8wAAP+ZAAD/ZgAAZmaZAJaWlgAAM2YAM5lmAAAzAAAzMwAAmTMAAJkz ZgAzM5kAMzMzAFwQDgADAAAAAAD///8AAAAAAGABAgAAAIUAJwARIQAAAAAfAFZlcnNpb240 X0NvbW1lbnRfUmVzb2x1dGlvbi5jc3aMAAQAAQABAMEBCADBAQAAZ/0BANYIEADWCAAAAAAA AAAAAAACAAAA/ADqFAABAACYAAAAHwAEEAAAAE1haWwgdG8gbXBscy10cCBsaXN0IDIwMTEt MDMtMTEBAAwABgA3AAAAAAAAAP9/IgAEEAAAAExpYWlzb24gU3RhdGVtZW50IExTMjk3IDIw MTEtMDMtMTcBAAwABgA3AAAAAAAAAC8CbgAEEAAAAFdlIGFudGljaXBhdGUgdGhhdCB0aGUg Y2l0ZWQgcmVzdHJpY3Rpb24gd2lsbCBzb29uIGJlIGVsaW1pbmF0ZWQgIHNvIHRoZXJlIGlz IG5vIHBvaW50IGlzIGNhbGxpbmcgaXQgb3V0IGhlcmUuAQAMAAYANwAAAAAAAAAAAHcABBAA AABUaGUgYXV0aG9ycyBkaWQgbm90IHRoaW5rIHRoZSBjb21tZW50IHdhcyBhcHByb3ByaWF0 ZSBpbiB0aGlzIGNvbnRleHQsIGhvd2V2ZXIsICB0aGUgaXNzdWUgd2FzIGFkZHJlc3NlZCBp biBjb21tZW50IE0xOAEADAAGADcAAAAAAAAAxQY2AAQQAAAAIENoYW5nZWQgdHVubmVsIG51 bWJlciB0byBUdW5uZWxfSUQsIGNsYXJpZmllZCB3b3JkaW5nAQAMAAYANwAAAAAAAABrAQkA BBAAAABlZGl0IG1hZGUBAAwABgA3AAAAAAAAAAAAXgAEEAAAAHBzZXVkb3dpcmUgbWlkcG9p bnRzIGRvIG5vdCBtZWV0IHRoZSBNSVAgZGVmaW5pdGlvbiBiZWNhdXNlIGFuIFMtUEUgY2Fu IG9yaWdpbmF0ZSBPQU0gbWVzc2FnZXMBAAwABgA3AAAAAAAAAGEEBgAEEAAAAFNvdXJjZQEA DAAGADcAAAAAAAAAAAAJAAQQAAAAQ29tbWVudCAkAQAMAAYANwAAAAAAAACSAAcABBAAAABT ZWN0aW9uAQAMAAYANwAAAAAAAAAAAAcABBAAAABDb21tZW50AQAMAAYANwAAAAAAAAAAAAYA BBAAAABVcGRhdGUBAAwABgA3AAAAAAAAAAAACwAEEAAAAERpc3Bvc2l0aW9uAQAMAAYANwAA AAAAAAAAAAgABBAAAABJVFUgU0cxNQEADAAGADcAAAAAAAAAAAADAAQQAAAAWVcxAQAMAAYA NwAAAAAAAABEAAMABBAAAABZVzIBAAwABgA3AAAAAAAAAFIAAwAEEAAAAFlXMwEADAAGADcA AAAAAAAAUgADAAQQAAAAWVc0AQAMAAYANwAAAAAAAABSAAMABBAAAABZVzUBAAwABgA3AAAA AAAAAFIAAwAEEAAAAFlXNgEADAAGADcAAAAAAAAAUgADAAQQAAAAWVc3AQAMAAYANwAAAAAA AABSAAMABBAAAABZVzgBAAwABgA3AAAAAAAAAFIAAwAEEAAAAFlXOQEADAAGADcAAAAAAAAA UgAEAAQQAAAAWVcxMAEADAAGADcAAAAAAAAAbAAEAAQQAAAAWVcxMQEADAAGADcAAAAAAAAA bAAEAAQQAAAAWVcxMgEADAAGADcAAAAAAAAAbAAqAABodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTAzNi9RAAB1c2VkIEExL1o5IGNvbnZlbnRpb24gdG8gc2hvdyB0 aGlzIGlzIGEgbWFuYWdlbWVudCBwbGFuZSBJRCBvZiBhIGRhdGFwbGFuZSBlbnRpdHkDAABN MzERAABhZGQgb3RoZXIgUFcgRkVDc6EAAEZFQzEyOCBpcyBpbXBsaWNpdGx5IHNjb3BlZCBi eSB0aGUgbm9kZS1JRHMgb2YgdGhlIExEUCBzZXNzaW9uLCBhZGRpbmcgdGhlIG5vZGUtSURz IHBsdXMgZ2xvYmFsLUlEL0lDQyBtYWtlcyB0aGlzIGVxdWl2YWxlbnQgdG8gdGhlIGN1cnJl bnQgZm9ybWF0IHNhdmUgb25lIEFDLUlEAwAATTMyBQAANy4xLjEXAAB0ZXh0IGFkZGVkIGFz IHN1Z2dlc3RlZAMAAE0zMxkAAHRleHQgZGVsZXRlZCBhcyBzdWdnZXN0ZWQDAABNMzQFAAA3 LjEuMiYAAHRleHQgYWRkZWQgdG8gZGVmaW5lIElQIFNlY3Rpb24gTUVHX0lEAwAATTM1BwAA Ny4xLjIuMQgAAGFuc3dlcmVkaQAAVGhlIExTUF9JRCBvZiBhbiBhc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgTFNQIGNvdmVycyBib3RoIHVuaWRpcmVjdGlvbmFsIExTUHMuICBTZWUgdXBk YXRlZCBzZWN0aW9uIDUuMi4yAwAATTM2BwAANy4yLjIuMUwAAGNsYXJpZmllZCBob3cgaXQg YXBwbGllcyB0byBib3RoIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IExTUHMDAABNMzcHAAA3LjIuMi4yEgAAY2xhcmlmaWNhdGlvbiBtYWRlAwAATTM4BwAANy4y LjIuMwMAAE0zOUIAAGlzIG5lZWRlZC4gYWRkZWQgLSBhdXRob3JzIGRpZCBub3QgY29uc2lk ZXJlZCBvdGhlciB3b3JkaW5nIGJldHRlcgMAAE00MC8AAGF1dGhvcnMgZGlkIG5vdCBjb25z aWRlcmVkIG90aGVyIHdvcmRpbmcgYmV0dGVyAwAATTQxAwAATTQyGQAAYWRkZWQgZXhhbXBs ZSBmb3IgcG9pbnQgQgMAAE00MxQAAEFsc28gYXBwbGllcyB0byBhIFBXCAAAUFcgYWRkZWQO AABHZW9yZ2UgU3dhbGxvdwMAAEdTMTYAAHMvYW55LXN1YiBsYXllciByZXF1aXJlcyBhL2Fu eSAoc3ViLSlsYXllciByZXF1aXJlcyBhLxQABBAAAAA1LjIuMiAoMmNkIHNlbnRlbmNlKQEA DAAGADcAAAAAAAAAAAAMAAQQAAAAbm90IGFjY2VwdGVkAQAMAAYANwAAAAAAAAAUAckABBAA AABXb3JkaW5nIHdhcyBjaGFuZ2VkIGZvciBjbGFyaWZpY2F0aW9uIHdpdGggYSByZWZlcmVu Y2UgdG8gdGhlIG1hcHBpbmcgb2YgaWRlbnRpZmllcnMgdG8gUlNWUCB3aGVyZSB3ZSBhbHJl YWR5IGhhdmUgZWxlbWVudHMgc3ByZWFkIGFjcm9zcyBvYmplY3RzLiBDaGFuZ2VkIEVhc3Qv V2VzdCB0byBBMS9aOSB0byBzaG93IGNhbm9uaWNhbCBvcmRlcmluZy4BAAwABgA3AAAAAAAA ACMRIwAAcy8oc2VlIHNlY3Rpb24gU2VjdGlvbi8oc2VlIFNlY3Rpb24DAABNMTADAABNMTEN AAA0IHBhcmFncmFwaCA5EwAAc2VlIG5ldyBwYXJhZ3JhcGggOQMAAE0xMhUAAGV4cGxpY2l0 bHkgbmFtZSBTUE1FczEAAFNQTUVzIGFyZSBMU1BzIGFuZCBuZWVkIG5vIGZ1cnRoZXIgaWRl bnRpZmljYXRpb24DAABNMTMDAABNMTREAABzL3Byb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9u IGV2ZW50cy9wcm90ZWN0aW9uIG9yIHJlc3RvcmF0aW9uIGV2ZW50cyAAAHByb3RlY3Rpb24g b3IgcmVzdG9yYXRpb24gZXZlbnRzAwAATTE1LQAAZXhwbGFpbiBkaWZmZXJlbmNlIGJldHdl ZW4gTFNQX0lEIGFuZCBMU1BfTnVtuwAATFNQX051bSBpcyB1bmlxdWUgd2l0aGluIGEgVHVu bmVsLCBMU1BfSUQgdXNlcyBMU1BfTnVtIGFzIGEgc3ViLWlkZW50aWZlciBhbmQgc3RhbmRz IHVuaXF1ZSBvbiBpdHMgb3duIC0gcmVtb3ZlZCBjb25mdXNpbmcgdGV4dCAnTFNQX0lEcyB3 aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhhdCB0dW5uZWwnIFNlZSBjb21tZW50IE0xNgMAAE0x NoIAAHMvYW5kIE1QTFMtVFAgTFNQX0lEcyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhhdCB0 dW5uZWwvYW5kIGEgTVBMUy1UUCBMU1BfSURzIHRvIGlkZW5kaWZ5IGEgTFNQIHdpdGhpbiB0 aGUgY29udGV4dCBvZiB0aGF0IHR1bm5lbC8aAABhY2NlcHRlZCB3dGloIG1vZGlmaWNhdGlv bigAAGFuZCBhbiBNUExTLVRQIExTUF9JRCB0byBpZGVuZGlmeSBhbiBMU1ADAABNMTcLAAA1 IGxhc3QgcGFyYUgAAE5vdCBjb25zaXN0ZW50IHdpdGggdGV4dCBpbiB0aGUgZmlyc3QgcGFy YWdyYXBoIG9mIHRoaXMgc2VjdGlvbi5hY2NlcHRlZAMAAE0xOEEAAGV4cGxpY2l0bHkgbmFt ZWQgdW5pZGlyZWN0aW9uYWwgTFNQcyBhbmQgaW5jb3Jwb3JhdGVkIHRoZSBjb21tZW50AwAA TTE5AwAATTIwBQAANS4yLjJTAABBZGRlZCBpZGVudGlmaWVycyBmb3IgZWFjaCB1bmlkaXJl Y3Rpb25hbCBMU1AgaW4gYWRkaXRpb24gdG8gdGhlIG92ZXJhbGwgaWRlbnRpZmllcgMAAE0y MSYAAEFkZGVkIGNsYXJpZmljYXRpb24gaW4gc2VjdGlvbiA3LjEuMi4xAwAATTIyAwAATTIz FAAAYWNjZXB0ZWQgaW4gcHJpY2lwbGVlAABDaGFuZ2VkIHRleHQgdG8ganVzdCAnUlNWUCcg YXMgdGhhdCBpcyB0aGUgcHJvdG9jb2wgYW5kIFJTVlAtVEUgYW5kIEdNUExTIGJvdGggYXJl IGV4dGVuc2lvbnMgb2YgUlNWUAMAAE0yNAMAAE0yNZEAAENoYW5nZWQgdGV4dCBvZiBuZXh0 IHBhcmFncmFwaCB0byAnRm9yIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQIHNpZ25h bGVkIGZyb20gRWFzdCB0byBXZXN0LCB0aGUgbWFwcGluZyB0byB0aGUgR01QTFMgNS10dXBs ZSBpcyBhcyBmb2xsb3dzOicDAABNMjYiAABhZGRlZCAoUlNWUCkgYXMgbW9kaWZpZXIgb2Yg TFNQX0lEAwAATTI3AwAATTI4CwAAdHlwZW8gZml4ZWQDAABNMjkDAABNMzAQAABhY2NlcHRl ZCBpbiBwYXJ0EQAAWWFhY292IFdlaW5nYXJ0ZW5NAABpZGVudGlmaWVycyB0byBiZSB1c2Vk IGluIHdpdGhpbiB0aGUgY2hvb3NlIGVpdGhlciAiaW4iIG9yICJ3aXRoaW4iIG5vdCBib3Ro LggAAGFjY2VwdGVkCQAAZWRpdCBtYWRlNAAAKGp1c3QgYmVmb3JlIHRoZSBidWxsZXRlZCBs aXN0KTogcy9mb2xsb3cvZm9sbG93aW5nLw0AAHMvYW5kIG9yL2FuZC8NAABzL0FuIFRoZS9U aGUvfgAAaXQgd291bGQgYmUgbmljZSBpZiB5b3UgY291bGQgY2xhcmlmeSB0aGF0ICJPcGVy YXRvciIgaGVyZSBpcyBhICJTZXJ2aWNlIFByb3ZpZGVyIiByYXRoZXIgdGhhbiBlLmcuIGEg bWF0aGVtYXRpY2FsIG9wZXJhdG9yID0pDAAAbm90IGFjY2VwdGVkIwAAdGVybSBpcyB3ZWxs IHVuZGVyc3Rvb2QgaW4gdGhlIElFVEZJAABzL2FuZCBmaW5hbGx5IGFuZCBhdHRhY2htZW50 IGNpcmN1aXQvYW5kLCBmaW5hbGx5LCBhbiBhdHRhY2htZW50IGNpcmN1aXQvUAAASnVzdCBh IHN1Z2dlc3Rpb24gLSBjaGFuZ2UgSXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCIgdG8gIkl0 IGlzIG5vdCByZWxhdGVkIHRvIiItAABzLyhzZWUgc2VjdGlvbiBTZWN0aW9uIDUuMS8oc2Vl IFNlY3Rpb24gNS4xKS9EAABzL3RoZSBmb3JtYXQgb2YgdGhlIGZvcm1hdCBvZiBhIFR1bm5l bF9JRC90aGUgZm9ybWF0IG9mIGEgVHVubmVsX0lELwUAADUuMi4xHgAAcy9Gb3IgYSBjby1y b3V0ZWQvQSBjby1yb3V0ZWQvEAAAcy9UaGUgZWFjaC9FYWNoLywAAHMvTGlrZXdpc2UsIHRo ZSBFYXN0L0xpa2V3aXNlLCBmb3IgdGhlIEVhc3QvDwAAU2VlIGNvbW1lbnQgTTI4AgAATTEQ AABzZWUgSVRVIGNvbW1lbnRzjwAAVGhlIHNlbnRlbmNlIGlzIGNvcnJlY3QgYXMgaXQgaXMu ICBJdCBkb2VzIG5vdCBzYXkgdGhhdCB0aGUgZG9jdW1lbnQgZGVmaW5lcyBhbGwgaWRlbnRp ZmllcnMsIG5vciBkb2VzIGl0IG1lbnRpb24gTFNQcywgdHVubmVscyBvciBjb25uZWN0aW9u cy4CAABNMngAAGFkZCAiVGhlIG9yZGVyaW5nIG9mIHRoZSBpbmZvcm1hdGlvbiBlbGVtZW50 cyBpbnZvbHZlZCBpbiBhIGNvbmNhdGVuYXRlZCBpZGVudGlmaWVyIE1VU1QgYmUgYXMgZGVm aW5lZCBpbiB0aGlzIGRvY3VtZW50LgIAAE0zCQAAZWRpdG9yaWFsFQAAYWNjZXB0ZWQgaW4g cHJpbmNpcGxlEQAAc2VlIG5ldyBzZWN0aW9uIDMCAABNNA8AADMuMSBwYXJhZ3JhcGggMhMA AHNlZSBuZXcgcGFyYWdyYXBoIDICAABNNUkAAHMvc2VydmVyIGxheWVyIE1QTFMtVFAgc2Vj dGlvbi9zZXJ2ZXIgKHN1Yi0pbGF5ZXIsIGUuZy4sIE1QTFMtVFAgc2VjdGlvbi8pAABzZXJ2 ZXIgKHN1Yi0pbGF5ZXIsIGUuZy4sIE1QTFMtVFAgc2VjdGlvbgIAAE02FwAAR2xvYmFsX0lE IC8gSUNDIHJlbGF0ZWQrAABzZWUgbWFpbGxpc3QgZGlzY3Vzc2lvbiBhbmQgY2hhaXJzIGRl Y2lzaW9uAgAATTcCAABNOAIAAE05/wCSBAgAlQcAAAwA9pQWCgAAjQIAAQQLAAB7A+8B1QsA AEwEdgBQDQAAxwV3oNENAABIBgmVwQ4AADgHdqBvDwAA5gcAAAkQAACACPaUjxEAAAYK/79d EgAA1AqhATIUAACpDHYANxUAAK4NoQGLFgAAAg+MBe8WAABmD4wFQhgAALkQMAS2GQAALRIA AjQbAACrE/aUoxsAABoUNgQAEAAghACMBShz/780+W2SAKUmBDJz/78DAAAAMnP/v2MAYQAA AAAAHwAAALvvbZIA1SUECNyIBHhy/78GtwAASOReJgrMpgSIcv+/C21MAQrMpgQOmiwBDgAA AACgJQQAzKYEAKAlBKhy/78AAIAECsymBA6aLAEOAAAA8ZehAQ4AAAAKzKYEyHL/vwtFZQAE dv+/PDqCBthy/78LbUwBPDqCBgR2/78EAAAAVo9lAArMpgQ8OoIG+HL/v7MZhQA8OoIGBHb/ vwQAAABJ5F4mBAAAAAAAAAAoc/+/gaKFAAR2/788OoIGBAAAAAAAAAAAAAAAAAAAAMh01Q8E AAAAkwIAAAR2/79Yc/+/SOJdAAR2/78EAAAAAAAAAAAAgAQCACcB4AcnAWhz/7+TAgQAJGVq JdAAAACodf+/r28OAAAQACCEAAAAaHT/v0PKbZIApSYE1AAAAAgAAAAQZWolAAAAAACgJQTY c/+/qOttkgClJgQAzKYEAAQAAJlrcJIAAAAAAGAnBAIAAAA0+W2SAKUmBAAAAAAIAgAAAKAl BAbOpgQBAAAAOHT/vyJKQQEABAAAAAQAAAh0/79XSkEBwL8xBAAEAAAQAAAAECcAAFB0/78G dv+//wEAAAoAAAAAzKYEAKAlBCh0/78AAIAEAKUmBHgUhwRWAAAABnb/v4qY2ADgmSwBSHT/ vwttTAECAP+/KjuCBlh0/78LbUwBKjuCBvR0/78OAAAAsxmFAAR2/78qO4IGeHT/vyvBbZIA AAAACAIAAKh0/79owW2SAKAlBAgCAACodP+/gaKFAPR0/78qO4IGDgAAAAAAAAB1dyKUYDya Bbh0/78Som2SCAIAAAjciATIdP+/OKJtkgCgJQQIAgAAAAAAAAAAgAQCAAAAAAAAAOh0/79u L1QBCAIAAGA8mgUAAAAAJvyJAAR2/7+BO4IGCHX/v+CoygBodf+/BHb/vxAAAADC6m2SBHb/ v2h1/78odf+/AqnKAGh1/78Edv+/EAAAAJlrcJIIBAQFiAr/HUh1/7+rY30ACNyIBAEAAAAQ AAAAAGAnBCcAAAAI3IgEqHX/vxlkfQAI3IgEBHb/v4h1/79I4l0ABHb/vxAAAACI0hkBYBQU AYUAAAABAAAAAAAAANYIEAAEdv+/mKH/v///////////1ggAABAAAADszFojAAAAAJih/78E dv+/qJf/v3w6XgAEdv+/AAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAstxtkvBbigUAAAAAAAAA AAR2/78sof+/AQAAAAisBQYAAAAACNyIBAAAAAAAAAAA7MxaI3BbigUAAQAAmAAAAB8ABBAA AABNYWlsIAoAAAAJCBAAAAYQAOlQzAcAAAIABgQAAAsCGAAAAAAAAAAAAD8AAACXOgAAcUUA APVPAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAAr AAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAAEAYEAAgDBBBQAAAAVAAAAgwACAAAAhAAC AAAATQBEGAMQPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NU WVBFIHBsaXN0IFBVQkxJQyAiLS8vQXBwbGUvL0RURCBQTElTVCAxLjAvL0VOIiAiaHR0cDov L3d3dy5hcHBsZS5jb20vRFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCI+CjxwbGlzdCB2ZXJz aW9uPSIxLjAiPgo8ZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1I b3Jpem9udGFsUmVzPC9rZXk+Cgk8ZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNr ZXQuY3JlYXRvcjwva2V5PgoJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3RyaW5n PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQk8YXJy YXk+CgkJCTxkaWN0PgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTUhv cml6b250YWxSZXM8L2tleT4KCQkJCTxyZWFsPjMwMDwvcmVhbD4KCQkJCTxrZXk+Y29tLmFw cGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCTxpbnRlZ2VyPjA8L2ludGVn ZXI+CgkJCTwvZGljdD4KCQk8L2FycmF5PgoJPC9kaWN0PgoJPGtleT5jb20uYXBwbGUucHJp bnQuUGFnZUZvcm1hdC5QTU9yaWVudGF0aW9uPC9rZXk+Cgk8ZGljdD4KCQk8a2V5PmNvbS5h cHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCTxzdHJpbmc+Y29tLmFwcGxlLmpv YnRpY2tldDwvc3RyaW5nPgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJy YXk8L2tleT4KCQk8YXJyYXk+CgkJCTxkaWN0PgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQu UGFnZUZvcm1hdC5QTU9yaWVudGF0aW9uPC9rZXk+CgkJCQk8aW50ZWdlcj4xPC9pbnRlZ2Vy PgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5PgoJCQkJ PGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJyYXk+Cgk8L2RpY3Q+Cgk8 a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNU2NhbGluZzwva2V5PgoJPGRpY3Q+ CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8c3RyaW5n PmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50 aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxrZXk+Y29t LmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1TY2FsaW5nPC9rZXk+CgkJCQk8cmVhbD4xPC9y ZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5PgoJ CQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJyYXk+Cgk8L2RpY3Q+ Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxSZXM8L2tleT4K CTxkaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJ PHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJPGtleT5jb20uYXBwbGUu cHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRpY3Q+CgkJCQk8 a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxSZXM8L2tleT4KCQkJ CTxyZWFsPjMwMDwvcmVhbD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0 ZUZsYWc8L2tleT4KCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8L2Fy cmF5PgoJPC9kaWN0PgoJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTVZlcnRp Y2FsU2NhbGluZzwva2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0 LmNyZWF0b3I8L2tleT4KCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4K CQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5 PgoJCQk8ZGljdD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1WZXJ0 aWNhbFNjYWxpbmc8L2tleT4KCQkJCTxyZWFsPjE8L3JlYWw+CgkJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2Vy PgoJCQk8L2RpY3Q+CgkJPC9hcnJheT4KCTwvZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50 LnN1YlRpY2tldC5wYXBlcl9pbmZvX3RpY2tldDwva2V5PgoJPGRpY3Q+CgkJPGtleT5QTVBQ RFBhcGVyQ29kZU5hbWU8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQu dGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9z dHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4K CQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5QTVBQRFBhcGVyQ29kZU5hbWU8L2tl eT4KCQkJCQk8c3RyaW5nPkxldHRlcjwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxlLnBy aW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJ CQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PlBNVGlvZ2FQYXBlck5h bWU8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0 b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJPGFycmF5PgoJ CQkJPGRpY3Q+CgkJCQkJPGtleT5QTVRpb2dhUGFwZXJOYW1lPC9rZXk+CgkJCQkJPHN0cmlu Zz5uYS1sZXR0ZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQu c3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJCTwvZGljdD4K CQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1h dC5QTUFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUu cHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlj a2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8 L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQu UGFnZUZvcm1hdC5QTUFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQkJCQk8YXJyYXk+CgkJCQkJ CTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQkJ CTxyZWFsPjMwNTguMzMzMzMzMzMzMzMzNTwvcmVhbD4KCQkJCQkJPHJlYWw+MjQwMDwvcmVh bD4KCQkJCQk8L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0 ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8 L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBN QWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0 PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tl eT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFn ZUZvcm1hdC5QTUFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJCQkJPGFycmF5PgoJCQkJCQk8 cmVhbD4tNzU8L3JlYWw+CgkJCQkJCTxyZWFsPi03NTwvcmVhbD4KCQkJCQkJPHJlYWw+MzIy NS4wMDAwMDAwMDAwMDA1PC9yZWFsPgoJCQkJCQk8cmVhbD4yNDc1PC9yZWFsPgoJCQkJCTwv YXJyYXk+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwva2V5 PgoJCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQk8L2RpY3Q+CgkJCTwvYXJyYXk+CgkJ PC9kaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5QTVBhcGVyTmFtZTwv a2V5PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwv a2V5PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQkJPGtleT5j b20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8 ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1QYXBlck5hbWU8 L2tleT4KCQkJCQk8c3RyaW5nPm5hLWxldHRlcjwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFw cGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRl Z2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBs ZS5wcmludC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQk8ZGljdD4K CQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmlu Zz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50 LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtl eT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLlBNVW5hZGp1c3RlZFBhZ2VSZWN0PC9rZXk+ CgkJCQkJPGFycmF5PgoJCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJCQk8aW50ZWdl cj4wPC9pbnRlZ2VyPgoJCQkJCQk8cmVhbD43MzQ8L3JlYWw+CgkJCQkJCTxyZWFsPjU3Njwv cmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5z dGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJ CQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8u UE1VbmFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxl LnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRp Y2tldDwvc3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5 PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50 LlBhcGVySW5mby5QTVVuYWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQkJCQk8YXJyYXk+CgkJ CQkJCTxyZWFsPi0xODwvcmVhbD4KCQkJCQkJPHJlYWw+LTE4PC9yZWFsPgoJCQkJCQk8cmVh bD43NzQ8L3JlYWw+CgkJCQkJCTxyZWFsPjU5NDwvcmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50 ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8 a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8ucHBkLlBNUGFwZXJOYW1lPC9rZXk+CgkJ PGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJ CTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJ CQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5wcGQuUE1QYXBlck5hbWU8L2tl eT4KCQkJCQk8c3RyaW5nPlVTIExldHRlcjwvc3RyaW5nPgoJCQkJCTxrZXk+Y29tLmFwcGxl LnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2Vy PgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5w cmludC50aWNrZXQuQVBJVmVyc2lvbjwva2V5PgoJCTxzdHJpbmc+MDAuMjA8L3N0cmluZz4K CQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQudHlwZTwva2V5PgoJCTxzdHJpbmc+Y29t LmFwcGxlLnByaW50LlBhcGVySW5mb1RpY2tldDwvc3RyaW5nPgoJPC9kaWN0PgoJPGtleT5j b20uYXBwbGUucHJpbnQudGlja2V0LkFQSVZlcnNpb248L2tleT4KCTxzdHJpbmc+MDAuMjA8 L3N0cmluZz4KCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC50eXBlPC9rZXk+Cgk8c3Ry aW5nPmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0VGlja2V0PC9zdHJpbmc+CjwvZGljdD4K PC9wbGlzdD4KTQB6AAEAAAMAAAEsASwAAAAAC/MJYP+1/7UMmgmrA2cFKAP8AAIAAABIAEgA AAAAAtgCKAABAAAAZAAAAAEAAwMDAAAAAX//AAEAAQAAAAAAAAAAAAAAAGgIABkBkAAAAAAA IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoQAiAAEAZAABAAEAAQACAPz//P8AAAAAAADg PwAAAAAAAOA/AQBVAAIACgB9AAwAAAABALYKFwAAAAIAfQAMAAIAAgBJEhgAAgACAH0ADAAD AAMAkh4ZAAIAAgB9AAwABAAEANsRGQACAAIAfQAMAAUABQAAaBkAAgACAH0ADAAGAAABtgoX AAAAAgAAAg4AAAAAAD8AAAAAAAYAAAAIAhAAAAAAAAYABAEAAAAAAAEAAAgCEAACAAAABgAI AgAAAAAAAQAACAIQAAMAAAAGAAgCAAAAAAABJQQIAhAABAAAAAYACAIAAAAAAAEAAAgCEAAF AAAABgAEAQAAAAAAAZoFCAIQAAYAAAAGAAQBAAAAAAABVwYIAhAABwAAAAYAEAQAAAAAAAGf BQgCEAAIAAAABgAMAwAAAAAAASUECAIQAAkAAAAGAAwDAAAAAAABAAAIAhAACgAAAAYACAIA AAAAAAEAAAgCEAALAAAABgAIAgAAAAAAAQAACAIQAAwAAAAGAAQBAAAAAAABAAAIAhAADQAA AAYABAEAAAAAAAEAAAgCEAAOAAAABgAIAgAAAAAAAQAACAIQABAAAAAGAAgCAAAAAAABJQQI AhAAEQAAAAYABAEAAAAAAAFXBggCEAASAAAABgAQBAAAAAAAAZsDCAIQABMAAAAGAAQBAAAA AAABAAAIAhAAFAAAAAYABAEAAAAAAAH/jwgCEAAVAAAABgAIAgAAAAAAAQAACAIQABYAAAAG AAQBAAAAAAABAAAIAhAAFwAAAAYABAEAAAAAAAEAAAgCEAAYAAAABgAEAQAAAAAAASYECAIQ ABkAAAAGAAQBAAAAAAABJQQIAhAAGgAAAAYABAEAAAAAAAEAAAgCEAAbAAAABgAEAQAAAAAA AVgGCAIQABwAAAAGAAQBAAAAAAABAAAIAhAAHQAAAAYABAEAAAAAAAElBAgCEAAeAAAABgAI AgAAAAAAAQAACAIQAB8AAAAGAAgCAAAAAAABAAD9AAoAAAAAABcABwAAAP0ACgAAAAEAFwAI AAAA/QAKAAAAAgAYAAkAAAD9AAoAAAADABkACgAAAP0ACgAAAAQAGQAMAAAA/QAKAAAABQAZ AAsAAAD9AAoAAgAAABkAcAAAAP0ACgACAAIAGgAAAAAAAQIGAAMAAAAZAP0ACgADAAEAGgAO AAAAfgIKAAMAAgAYAAAA8D/9AAoAAwADABkAcQAAAP0ACgADAAQAGQByAAAA/QAKAAMABQAZ AHMAAAD9AAoABAABABcADwAAAH4CCgAEAAIAGAAAAABA/QAKAAQAAwAZAHQAAAD9AAoABAAE ABkAcgAAAP0ACgAEAAUAGQBzAAAA/QAKAAUAAQAXABAAAAB+AgoABQACABgAAAAIQP0ACgAF AAMAGQB1AAAA/QAKAAUABAAZAHIAAAD9AAoABQAFABkAcwAAAP0ACgAGAAEAFwARAAAAfgIK AAYAAgAYAAAACED9AAoABgADABkAdgAAAP0ACgAGAAQAGQByAAAA/QAKAAYABQAZAHMAAAD9 AAoABwABABcAEgAAAH4CCgAHAAIAGAAAAAhA/QAKAAcAAwAZAHcAAAD9AAoABwAEABkAeAAA AP0ACgAHAAUAGQB5AAAA/QAKAAgAAQAXABMAAAB+AgoACAACABgAAWBzQP0ACgAIAAMAGQB6 AAAA/QAKAAgABAAZAHIAAAD9AAoACAAFABkAcwAAAP0ACgAJAAEAFwAUAAAAfgIKAAkAAgAY AAFgc0D9AAoACQADABkAewAAAP0ACgAJAAQAGQByAAAA/QAKAAkABQAZAHMAAAD9AAoACgAB ABcAFQAAAH4CCgAKAAIAGAAAABBA/QAKAAoAAwAZAHwAAAD9AAoACgAEABkAcgAAAP0ACgAK AAUAGQBzAAAA/QAKAAsAAQAXABYAAAADAg4ACwACABgAZmZmZmZmFED9AAoACwADABkAfQAA AP0ACgALAAQAGQByAAAA/QAKAAsABQAZAHMAAAD9AAoADAABABcAFwAAAP0ACgAMAAIAGAB+ AAAA/QAKAAwAAwAZAH8AAAD9AAoADAAEABkAcgAAAP0ACgAMAAUAGQBzAAAA/QAKAA0AAQAX ABgAAAD9AAoADQACABgAQAAAAP0ACgANAAMAGQCAAAAA/QAKAA0ABAAZAHIAAAD9AAoADQAF ABkAcwAAAP0ACgAOAAEAFwAZAAAAfgIKAA4AAgAYAAGQgED9AAoADgADABkAgQAAAP0ACgAO AAQAGQBBAAAA/QAKAA4ABQAZAIIAAAD9AAoAEAAAABcADQAAAP0ACgAQAAIAGgABAAAA/QAK ABAAAwAZABoAAAD9AAoAEQABABcAgwAAAH4CCgARAAIAGAAAAPA//QAKABEAAwAZAIQAAAD9 AAoAEQAEABkAQQAAAP0ACgARAAUAGQCFAAAA/QAKABIAAQAXAIYAAAB+AgoAEgACABgAAUBg QP0ACgASAAMAGQCHAAAA/QAKABIABAAZAIoAAAD9AAoAEgAFABkAQgAAAP0ACgATAAEAFwCI AAAAfgIKABMAAgAYAAAACED9AAoAEwADABkAiQAAAP0ACgATAAQAGQCKAAAA/QAKABMABQAZ AIsAAAD9AAoAFAABABcAjAAAAP0ACgAUAAIAGACNAAAA/QAKABQAAwAZAIkAAAD9AAoAFAAE ABkAigAAAP0ACgAUAAUAGQCOAAAA/QAKABUAAQAXAI8AAAB+AgoAFQACABgAAAAQQP0ACgAV AAMAGQCQAAAA/QAKABUABAAZAHIAAAD9AAoAFQAFABkAkQAAAP0ACgAWAAEAFwCSAAAAfgIK ABYAAgAYAAAAEED9AAoAFgADABkAkwAAAP0ACgAWAAQAGQB4AAAA/QAKABYABQAZAJQAAAD9 AAoAFwABABcAlQAAAH4CCgAXAAIAGAAAABBA/QAKABcAAwAZAJMAAAD9AAoAFwAEABkAeAAA AP0ACgAXAAUAGQCUAAAA/QAKABgAAQAXAJYAAAB+AgoAGAACABgAAAAQQP0ACgAYAAMAGQCT AAAA/QAKABgABAAZAHgAAAD9AAoAGAAFABkAlAAAAP0ACgAZAAEAFwCXAAAAfgIKABkAAgAY AAAAEED9AAoAGQADABkAQwAAAP0ACgAZAAQAGQByAAAA/QAKABkABQAZAHMAAAD9AAoAGgAB ABcARAAAAH4CCgAaAAIAGAAAABBA/QAKABoAAwAZAJMAAAD9AAoAGgAEABkAeAAAAP0ACgAa AAUAGQCUAAAA/QAKABsAAQAXAEUAAAD9AAoAGwACABgARgAAAP0ACgAbAAMAGQCJAAAA/QAK ABsABAAZAHIAAAD9AAoAGwAFABkARwAAAP0ACgAcAAEAFwBIAAAAfgIKABwAAgAYAAAAEED9 AAoAHAADABkASQAAAP0ACgAcAAQAGQB4AAAA/QAKABwABQAZAEoAAAD9AAoAHQABABcASwAA AH4CCgAdAAIAGAAAABRA/QAKAB0AAwAZAIQAAAD9AAoAHQAEABkAeAAAAP0ACgAdAAUAGQAD AAAA/QAKAB4AAQAXAEwAAAB+AgoAHgACABgAAAAUQP0ACgAeAAMAGQBNAAAA/QAKAB4ABAAZ AHIAAAD9AAoAHgAFABkATgAAAP0ACgAfAAEAFwBPAAAAfgIKAB8AAgAYAAAAFED9AAoAHwAD ABkAUAAAAP0ACgAfAAQAGQByAAAA/QAKAB8ABQAZAFEAAADXAEAAYgoAAEQCVAAcAFAARgBG AEYARgBGAEYARgBKAEYARgBGACoARgBGAEYARgBGAEYARgBGAEYARgBGAEYARgBGAAgCEAAg AAEABgAQBAAAAAAAAQAACAIQACEAAQAGAAgCAAAAAAABAAAIAhAAIgABAAYABAEAAAAAAAEl BAgCEAAjAAEABgAEAQAAAAAAAQAACAIQACQAAQAGAAQBAAAAAAABmgUIAhAAJQABAAYABAEA AAAAAAFXBggCEAAmAAEABgAEAQAAAAAAAZ8FCAIQACcAAQAGAAQBAAAAAAABJQQIAhAAKAAB AAYABAEAAAAAAAEAAAgCEAApAAEABgAIAgAAAAAAAQAACAIQACoAAQAGAAQBAAAAAAABAAAI AhAAKwABAAYABAEAAAAAAAEAAAgCEAAsAAEABgAEAQAAAAAAAQAACAIQAC0AAQAGAAQBAAAA AAABAAAIAhAALgABAAYABAEAAAAAAAElBAgCEAAvAAEABgAEAQAAAAAAAVcGCAIQADAAAAAG AAQBAAAAAAABmwMIAhAAMQAAAAYABAEAAAAAAAEAAAgCEAAyAAAABgAEAQAAAAAAAf+PCAIQ ADMAAAAGAAQBAAAAAAABAAAIAhAANAAAAAYABAEAAAAAAAEAAAgCEAA1AAAABgAEAQAAAAAA AQAACAIQADYAAAAGAAQBAAAAAAABJgQIAhAANwAAAAYABAEAAAAAAAElBAgCEAA4AAAABgAE AQAAAAAAAQAACAIQADkAAAAGAAQBAAAAAAABWAYIAhAAOgAAAAYABAEAAAAAAAEAAAgCEAA7 AAAABgAEAQAAAAAAASUECAIQAD4AAAAGAAgCAAAAAAABAAD9AAoAIAABABcAUgAAAH4CCgAg AAIAGAAAABRA/QAKACAAAwAZAFMAAAD9AAoAIAAEABkAVAAAAP0ACgAgAAUAGQBVAAAA/QAK ACEAAQAXAFYAAAD9AAoAIQACABgAVwAAAP0ACgAhAAMAGQBYAAAA/QAKACEABAAZAHIAAAD9 AAoAIQAFABkABAAAAP0ACgAiAAEAFwBZAAAA/QAKACIAAgAYAH4AAAD9AAoAIgADABkAhAAA AP0ACgAiAAQAGQByAAAA/QAKACIABQAZAFoAAAD9AAoAIwABABcAWwAAAP0ACgAjAAIAGAB+ AAAA/QAKACMAAwAZAJMAAAD9AAoAIwAEABkAeAAAAP0ACgAjAAUAGQCUAAAA/QAKACQAAQAX AFwAAAD9AAoAJAACABgAXQAAAP0ACgAkAAMAGQCEAAAA/QAKACQABAAZAHIAAAD9AAoAJAAF ABkAXgAAAP0ACgAlAAEAFwBfAAAA/QAKACUAAgAYAF0AAAD9AAoAJQADABkAhAAAAP0ACgAl AAQAGQByAAAA/QAKACUABQAZAGAAAAD9AAoAJgABABcAYQAAAH4CCgAmAAIAGAAAABBA/QAK ACYAAwAZAJMAAAD9AAoAJgAEABkAeAAAAP0ACgAmAAUAGQCUAAAA/QAKACcAAQAXAGIAAAB+ AgoAJwACABgAAZCAQP0ACgAnAAMAGQCEAAAA/QAKACcABAAZAGMAAAD9AAoAJwAFABkAZAAA AP0ACgAoAAEAFwBlAAAAfgIKACgAAgAYAAGQgED9AAoAKAADABkAhAAAAP0ACgAoAAQAGQB4 AAAA/QAKACgABQAZAAIAAAD9AAoAKQABABcAZgAAAH4CCgApAAIAGAABkIBA/QAKACkAAwAZ AIQAAAD9AAoAKQAEABkAYwAAAP0ACgApAAUAGQBnAAAA/QAKACoAAQAXAGgAAAB+AgoAKgAC ABgAAZCAQP0ACgAqAAMAGQCEAAAA/QAKACoABAAZAHIAAAD9AAoAKgAFABkAaQAAAP0ACgAr AAEAFwBqAAAAfgIKACsAAgAYAAGQgED9AAoAKwADABkAhAAAAP0ACgArAAQAGQByAAAA/QAK ACsABQAZAGkAAAD9AAoALAABABcAawAAAH4CCgAsAAIAGAABkIBA/QAKACwAAwAZAIQAAAD9 AAoALAAEABkAcgAAAP0ACgAsAAUAGQBsAAAA/QAKAC0AAQAXAG0AAAB+AgoALQACABgAAZCA QP0ACgAtAAMAGQCEAAAA/QAKAC0ABAAZAHIAAAD9AAoALQAFABkAaQAAAP0ACgAuAAEAFwBu AAAAfgIKAC4AAgAYAAAAGED9AAoALgADABkAhAAAAP0ACgAuAAQAGQBvAAAA/QAKAC4ABQAZ ABsAAAD9AAoALwABABcAHAAAAH4CCgAvAAIAGAAAABhA/QAKAC8AAwAXAB0AAAD9AAoALwAE ABkAeAAAAP0ACgAvAAUAFwAeAAAA/QAKADAAAQAXAB8AAAD9AAoAMAACABgAIAAAAP0ACgAw AAMAGQCEAAAA/QAKADAABAAZAHIAAAD9AAoAMAAFABkAIQAAAP0ACgAxAAEAFwAiAAAA/QAK ADEAAgAYACAAAAD9AAoAMQADABkAhAAAAP0ACgAxAAQAGQByAAAA/QAKADEABQAZACMAAAD9 AAoAMgABABcAJAAAAP0ACgAyAAIAGAAlAAAA/QAKADIAAwAZAIQAAAD9AAoAMgAEABkAcgAA AP0ACgAyAAUAGQAmAAAA/QAKADMAAQAXACcAAAD9AAoAMwACABgAKAAAAP0ACgAzAAMAGQCE AAAA/QAKADMABAAZACkAAAD9AAoAMwAFABkAKgAAAP0ACgA0AAEAFwArAAAA/QAKADQAAgAY ACwAAAD9AAoANAADABkAhAAAAP0ACgA0AAQAGQCKAAAA/QAKADQABQAZAC0AAAD9AAoANQAB ABcALgAAAP0ACgA1AAIAGAAvAAAA/QAKADUAAwAZAIQAAAD9AAoANQAEABkAcgAAAP0ACgA1 AAUAGQAwAAAA/QAKADYAAQAXADEAAAD9AAoANgACABgAMgAAAP0ACgA2AAMAGQCEAAAA/QAK ADYABAAZAHgAAAD9AAoANgAFABkABgAAAP0ACgA3AAEAFwAzAAAA/QAKADcAAgAYADIAAAD9 AAoANwADABkAhAAAAP0ACgA3AAQAGQBvAAAA/QAKADcABQAZADQAAAD9AAoAOAABABcANQAA AP0ACgA4AAIAGAAyAAAA/QAKADgAAwAZAIQAAAD9AAoAOAAEABkAeAAAAP0ACgA4AAUAGQA2 AAAA/QAKADkAAQAXADcAAAD9AAoAOQACABgAMgAAAP0ACgA5AAMAGQCTAAAA/QAKADkABAAZ AHgAAAD9AAoAOQAFABkAlAAAAP0ACgA6AAEAFwA4AAAA/QAKADoAAgAYADIAAAD9AAoAOgAD ABkAhAAAAP0ACgA6AAQAGQByAAAA/QAKADoABQAZADkAAAD9AAoAOwABABcAOgAAAH4CCgA7 AAIAGAAB0IZA/QAKADsAAwAZADsAAAD9AAoAOwAEABkAcgAAAP0ACgA7AAUAGQA8AAAA/QAK AD4AAAAZAD0AAAD9AAoAPgABABcAPgAAAH4CCgA+AAIAGAAAABBA/QAKAD4AAwAZAD8AAAD9 AAoAPgAEABkAcgAAAP0ACgA+AAUAGQAFAAAA1wA+AEAKAAAwAkYARgBGAEYARgBGAEYARgBG AEYARgBGAEYARgBGAEYARgBGAEYARgBGAEYARgBGAEYARgBGAEYAPgISALYGEQAAAEAAAAAA AAAAAAAAAMgIEQDICAAAAABAAAAAAAAIAAAAAB0ADwADEQACAAAAAQARABEAAgLvAAYABgA3 AAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAD+////BgAAAP7///////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////v8AAAMKAQAAAAAAAAAAAAAA AAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA6AAAAAkAAAABAAAAUAAAAA8AAABYAAAA FwAAAHAAAAALAAAAeAAAABAAAACAAAAAEwAAAIgAAAAWAAAAkAAAAA0AAACYAAAADAAAAMQA AAACAAAAECcAAB4AAAAQAAAAQ2lzY28gU3lzdGVtcwAAAAMAAAAAAAwACwAAAAAAAAALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAACAAAABWZXJzaW9uNF9Db21tZW50X1Jlc29s dXRpb24uY3N2AAwQAAACAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AgABAP////8gCAIAAAAAAMAA AAAAAABGFgAAAE1pY3Jvc29mdCBFeGNlbCBTaGVldAD+////OEZJQg4AAABFeGNlbC5TaGVl dC44AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AABEFwAACAAAAAEAAABIAAAABAAAAFAAAAAIAAAAaAAAABIAAACAAAAADAAAAKQAAAANAAAA sAAAABMAAAC8AAAAEQAAAMQAAAACAAAAECcAAB4AAAAQAAAAR2VvcmdlIFN3YWxsb3cAAB4A AAAQAAAAR2VvcmdlIFN3YWxsb3cAAB4AAAAcAAAATWljcm9zb2Z0IE1hY2ludG9zaCBFeGNl bAAAAEAAAACvjqc3uifMAUAAAABPG/4YDCvMAQMAAAAAAAAARwAAAHgWAAD+////UElDVBZw AAAAAABiAIAAEQL/DAD//gAAAEgAAABIAAAAAAAAAGIAgAAAAAAAHgABAAqAAYABf/9//wCa /wAAAIEAAAAAAABiAIAAAAADAAAAAABIAAAASAAAABAAEAADAAUAAAAQBIvEsAAAAAAAAAAA AGIAgAAAAAAAYgCAAAAAKQBve/ZznABnWuRznAFve2tb5HOcAWtbb3voc5wBb3tvfOlznAFn On//AEMAc5z8d70Aa3v8d70AZ1vzf/8BMa5vfPR//wF3vW989H//AmM5QjJCMvR//wFvnHOc 6X//AlbXTpVW1ul//wFnWn//AEkAc5z+d70EXxg58EIyQjJrWv53vQBnW/R//wJnOlrXSnP0 f/8Bd71vfPR//wJjOUIyTpX0f/8Bb5xznOl//wA+Eed//wFnWn//AFMMc5x3vXe9YxgpjWc5 d71Sti2Na1t3vXe9Z1v0f/8DUpVfGDoRe971f/8Bd71vfPR//wJjOU6VOfD0f/8Bb5xznOl/ /wJOdF8YZ1rpf/8BZ1p//wBNAHOc/ne9BG97RlM58E6Vc5z+d70AZ1v0f/8Dd75//3e+e971 f/8Bd71vfPR//wJ73m97d770f/8Bb5xznOh//wFre2976X//AWdaf/8AIQBnWvZjOgBnWuRz nAFve2tb5HOcAWtba3vOc5wBZzp//wBFAHOc/XveAWdaa1r8e94Dd71//297e97mf/8De95/ /297d73tf/8Ad738f/8Ee9573n//b3t73vt//wB3vdh//wF3vX//AJMAc5z9f/8BZ1pStf1/ /w973ne9TnNnOWMYa1pa1n//b3tve2taWtZrWlrWb3tWtfF//xh73lKUYxhe92taVrV3vVa1 WtZSlHe9VrVa1lKUf/9e92c5a1pSlG97Na13vX//VrVGMfx//xB73nveRjFnOWtaZzle93ve VrVWtUIQYxh3vVa1d71e91a13X//AXe9f/8AlQBznP1//wFznFK1/X//Anved71znP5Ocwpn OV73VrVSlEpSe95Oc3//Pe9WtWc58n//GHveSlJ//3//TnNznEpSXvdGMWc5WtZe90YxZzla 1kIQSlJOc3//UpRSlH//f/9WtT3v/H//EXvee95rWkpSVrU1rUpSSlJ//297YxhSlEpSf/9O c0pSWtZznN5//wF3vX//AJkAc5z9f/8CWvhKdHve/n//EHved71jGFKUVrVWtU5zd71GMUpS VrV//1KUWtZa1la1c5zyf/8Ye95jGE5zVrVWtU5zYxhnOVa1a1pjGGc5VrVrWmtaSlJa1lrW f/9a1kpSd71//1rWPe/8f/8Re9573lrWUpRe905zVrVjGFKUZzlGMVrWYxhSlGMYVrVnOXe9 3n//AXe9f/8AJwBve/dvnAFvfHOc43veAHe96nveAG97/HveAXe9d73Oe94Bc5x//wArAG97 /nOcAm+cXxhnOv1znAFvnHOc43veAHe95HveAXe9d73Oe94Bc5x//wApAHOc/X//AW97PhH9 f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AKQBznP1//wFre1K2/X//AXved73jf/8A e97kf/8Be9573s5//wF3vX//ACsAc5z+f/8Cd70xrlKV/X//AXved73jf/8Ae97kf/8Be957 3s5//wF3vX//ACEAc5z3e94Bd713veN//wB73uR//wF73nvezn//AXe9f/8AHwBnWvZnWwBv e+N3vQBznOR3vQFznHOczne9AW97f/8AWQBznPd//wR73ne9WtZ73lrW5n//AHve5H//DHve e95Oc297SlJ3vX//f/9rWla1f/9//1739n//AFa1/X//AGMY/H//BVKUa1p//3//b3t3vfV/ /wF3vX//AI0Ac5z3f/8Qe953vXOcLWtznE5zTnNa1jnOZzlGMV73QhBKUkYxa1pnOfJ//wB7 3uR//yh73nveTnNOczWta1pOc05zSlJSlH//d70ta1rWSlJSlH//YxhCEDWtOc5e90IQRjFS lEpSTnN73ne9QhBe9znOOc53vX//SlJSlFKUTnNOc0Yx9X//AXe9f/8AiwBznPd//w973ne9 f/9KUmtaQhBGMUIQNa1GMX//a1pnOU5zUpRGMfF//wB73uR//yh73nveTnNOc1a1WtZCEEYx SlJSlH//f/9KUlKUf/9KUn//Yxhve1KUWtZa1m97TnNSlGMYOc5nOU5zUpR//1KUYxhrWn// SlJSlGMYOc5WtW979X//AXe9f/8AiwBznPd//w973ne9f/9WtWtaQhBOc0IQOc5nOUYxXvdC EFKUe95CEPF//wB73uR//yh73nveUpR//173WtZCEE5zUpRWtX//f/9CEF73RjFWtX//Zzlv e1a1Xvda1kIQUpRWtVrWQhB73n//Xvda1jnOQhB//3//UpRWtV73RjFjGEYx9X//AXe9f/8A LwBznPd//wF73ne943//AHve5H//AXvee97uf/8BYxhve/l//wBSlOx//wF3vX//ACEAc5z3 f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AawBznP1//wFa90pz/X//BXved71nOXve XvdrWv5//wBve/h//wBrWvV//wB73uR//wt73nveYxhOc3veWtZWtX//VrV//3e9Yxj+f/8K UpRe92c5UpRznH//f/9nOW97f/9WteZ//wF3vX//AIkAc5z9f/8BYzlGU/1//xl73ne9VrVa 1kYxUpRa1lKUb3te90IQRjFnOVKUUpRjGEYxZzlOcz3vYxhWtU5zWtZSlFa1+3//AHve5H// GXvee95//2MYZzlKUla1d71CEH//d71Oc3//e95nOWMYTnN//1KUYxh73n//XvdjGH//QhDm f/8Bd71//wCJAHOc/H//AUZTe97+f/8Ze953vXe9MYxWtU5zPe9a1m97VrVKUlKUTnN73kpS RjE5zl73b3tSlH//Pe9a1k5ze95SlPt//wB73uR//xl73nvea1pWtX//SlJSlHveSlJ//3// TnN73lrWZzle905zf/973k5zXvdznGtaYxh//0pS5n//AXe9f/8AiwBznP1//wFa92MZ/X// GXved71//2c5d71rWm97VrVznG97a1pve3OcRjFOc173VrVznHvec5xe92taVrVve3//b3v7 f/8Ae97kf/8ae9573l73VrVve2MYXvd73la1a1pve1a1e95//3//WtZnOWc5UpR73n//f/9e 9173e95WtWta53//AXe9f/8AJwBnWvZnOgBve/d3vQFznF7373e9AHOc5He9AXOcc5zOd70B b3t//wA5AXOce974f/8Be953veN//wl73m97f/9nOXe9a1p//297f/9znO1//wN73nvef/9v e9B//wF3vX//ADcAc5z3f/8Be953veN//wl73la1TnNnOVKUNa1nOVrWXvdWte1//wN73nve c5xGMdB//wF3vX//ADcAc5z3f/8Be953veN//wl73n//Pe9//0YxWtYxjHvee95Wte1//wN7 3nvef/9Oc9B//wF3vX//ADkAc5z3f/8Be953veN//wl73n//Xvd//1rWe95SlH//YxhOc+1/ /wR73nvec5xKUne90X//AXe9f/8AIQBznPd//wF73ne943//AHve5H//AXvee97Of/8Bd71/ /wAnAHOc/H//AGc6/X//AXved73jf/8Ae97kf/8Be9573s5//wF3vX//ACkAc5z9f/8BWvdC Mv1//wF73ne943//AHve5H//AXvee97Of/8Bd71//wAtAHOc/n//A298PjI58He9/n//AXve d73jf/8Ae97kf/8Be9573s5//wF3vX//ACcAc5z8f/8AVtb9f/8Be953veN//wB73uR//wF7 3nvezn//AXe9f/8AIQBve/dvnAFvfHOc43veAHe95HveAXe9d73Oe94Bc5x//wAhAG9793Oc AW+cc5zje94Ad73ke94Bd713vc573gFznH//ADkAc5z3f/8Be953veN//wl73k5zc5xOc173 Oc573la1VrVCEO1//wR73nveYxhKUmta0X//AXe9f/8AOQBznPd//wF73ne943//CXved70x jH//TnNKUkIQb3t//0pS7X//BHvee95//1KUd73Rf/8Bd71//wA7AHOc93//AXved73jf/8K e95//0pSf/8973OcLWt//y1rUpR73u5//wR73nveSlJCEG970X//AXe9f/8AIQBznPd//wF7 3ne943//AHve5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97kf/8Be9573s5/ /wF3vX//ACkAc5z9f/8BPhFSlf1//wF73ne943//AHve5H//AXvee97Of/8Bd71//wApAHOc /X//AVa2UpX9f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AKwBznP1//wJznEIye97+ f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AKwFznHve/n//AWdac5z9f/8Be953veN/ /wB73uR//wF73nvezn//AXe9f/8AHwBnWvZnWwBve+N3vQBznOR3vQFznHOczne9AW97f/8A RwdznHvef/9//3veSnRW13ve/n//AXved73jf/8Je95jGH//WtZve1rWf/9nOVa1UpTtf/8E e9573mc5TnN3vdF//wF3vX//AEMAc5z+f/8Ca1tCMlK2/X//AXved73jf/8Je95jGD3vc5xO cznOWtZjGHe9QhDtf/8Ee9573n//TnNve9F//wF3vX//AEUAc5z+f/8Db5xOlVbWb3z+f/8B e953veN//wl73n//RjF//0IQYxgpSn//f/9KUu1//wR73nvef/9ve1rW0X//AXe9f/8AQQBz nP1//wFjOV8Y/X//AXved73jf/8Je95//2taf/9nOX//Zzl//1a1Xvftf/8Ee9573mMYVrV7 3tF//wF3vX//AB8AZ1r2ZzoAb3vjd70Ac5zkd70Bc5xznM53vQFve3//AEMBc5x73v5//wJO lUp0a3v+f/8Be953veN//wl73m97f/9nOXe9a1p//297f/9rWu1//wN73nvea1pWtdB//wF3 vX//AEEAc5z8f/8BVtZ73v5//wF73ne943//CXveUpRa1l73UpQxjG97WtZe9z3v7X//BHve e953vWc5YxjRf/8Bd71//wBBAHOc/X//AXe9Vtb9f/8Be953veN//wl73nveLWt//05zSlI9 72taTnNKUu1//wR73nvef/8973Oc0X//AXe9f/8AQwBznP1//wFKdHO9/X//AXved73jf/8K e95//0pSf/8972taKUp73lKUNa173u5//wR73nvec5xve1rW0X//AXe9f/8APQBznP1//wBj Gfx//wF73ne943//CXvef/9rWn//Zzl//2MYf/9//2ta7X//A3vee95jGEpS0H//AXe9f/8A HvZnWgFnOm9743e9AHOc5He9AXOcc5zOd70Bb3t//wAyAHOc9nveAHe943//CXvee95//3e9 f/93vX//e95znG977X///nveAG970H//AXe9f/8AOQBznPd//wF73ne943//CXveTnNjGFa1 VrUxjHOcVrU972c57X//BHvee95rWla1ZznRf/8Bd71//wA5AHOc93//AXved73jf/8Je957 3jWtf/9KUlKUOc53vV73Pe/tf/8Ee9573n//UpRnOdF//wF3vX//ADkAc5z3f/8Be953veN/ /wl73n//UpR//0pSd71CEH//UpRKUu1//wR73nveYxhOc2970X//AXe9f/8AIQBznPd//wF7 3ne943//AHve5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97kf/8Be9573s5/ /wF3vX//ACEAc5z3f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AIQBznPd//wF73ne9 43//AHve5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97kf/8Be9573s5//wF3 vX//ACEAc5z3f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AIQBznPd//wF73ne943// AHve5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97kf/8Be9573s5//wF3vX// ACEAc5z3f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AIQBznPd//wF73ne943//AHve 5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97kf/8Be9573s5//wF3vX//ACEA c5z3f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AKwBznP1//wJOlUp0e//+f/8Be953 veN//wB73uR//wF73nvezn//AXe9f/8AKQBznP1//wE+EUIy/X//AXved73jf/8Ae97kf/8B e9573s5//wF3vX//AC0Ac5z+f/8Dc71OdFK2b3v+f/8Be953veN//wB73uR//wF73nvezn// AXe9f/8AKQBznP1//wFfGF8Y/X//AXved73jf/8Ae97kf/8Be9573s5//wF3vX//AB8AZ1r2 ZzoAb3vjd70Ac5zkd70Bc5xznM53vQFve3//AD8Bc5x73vh//wF73ne943//CXveb3t//2c5 d71rWn//b3tznFrW7X//A3vee95rWla1/n//AG971H//AXe9f/8APABznPd//wF73ne943// CXveVrVOc2c5UpQ1rWc5WtY1rWc57X///nveBFrWZzl//3e9QhDUf/8Bd71//wBBAHOc93// AXved73jf/8Ke95//z3vf/9GMVrWMYx3vUIQUpRznO5//wd73nvef/9jGF73f/9//05z1H// AXe9f/8AQQBznPd//wF73ne943//CXvef/9e93//WtZ73lKUf/9WtVKU7X//CHvee95jGE5z d71a1ne9SlJznNV//wF3vX//ACEAc5z3f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8A IQBznPd//wF73ne943//AHve5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97k f/8Be9573s5//wF3vX//ACEAc5z3f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AIQBz nPd//wF73ne943//AHve5H//AXvee97Of/8Bd71//wAhAHOc93//AXved73jf/8Ae97kf/8B e9573s5//wF3vX//ACkAc5z9f/8Bc5xznP1//wF73ne943//AHve5H//AXvee97Of/8Bd71/ /wAtAHOc/n//A3e9RlNKdHe9/n//AXved73jf/8Ae97kf/8Be9573s5//wF3vX//AC0Ac5z+ f/8Dc5xGU06VZzr+f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AKwBznP1//wJjGUZT a3v+f/8Be953veN//wB73uR//wF73nvezn//AXe9f/8AKQBznP1//wFOlUIy/X//AXved73j f/8Ae97kf/8Be9573s5//wF3vX//ACkAa1v9b3wAa3v8b3wBa3tznOR73gF3vXOc5HveAXe9 d73Oe94Bc5x//wADgX//AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAUAAABUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --B_3390938992_88638233-- From eric.gray@ericsson.com Thu Jun 16 04:14: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 C216011E822C for ; Thu, 16 Jun 2011 04:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 aC11++SflvJr for ; Thu, 16 Jun 2011 04:14:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 68FCF11E80D3 for ; Thu, 16 Jun 2011 04:14:45 -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 p5GBEZNP012225; Thu, 16 Jun 2011 06:14:36 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 16 Jun 2011 07:14:30 -0400 From: Eric Gray To: "neil.2.harrison@bt.com" , "verozheng@huawei.com" , "Alexander.Vainshtein@ecitele.com" , "mach.chen@huawei.com" , "mpls@ietf.org" , "matthew.bocci@alcatel-lucent.com" , "swallow@cisco.com" Date: Thu, 16 Jun 2011 07:14:28 -0400 Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAAAcZk8AAIG+tg Message-ID: References: <016401cc2b30$f5b1da40$e1158ec0$@com> <6D3D47CB84BDE349BC23BF1C94E316E44058295438@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E44058295438@EMV62-UKRD.domain1.systemhost.net> 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 Cc: "matthew_282@virgilio.it" Subject: Re: [mpls] Question about ICC 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, 16 Jun 2011 11:14:46 -0000 Neil, The case where a difference in either X or Y might result=20 in an undetectable misconnectivity problem seems extremely unlikely. So much so, that it cannot be worth the trouble to configure both X and Y information for every OAM entity relationship, and carry it in every OAM message. Say that operator X wants to check connectivity from A to Z in layer Y. Now say that the actual connectivity is somehow between A (in X at layer Y) and Z' (in X' at layer Y') where identifier Z =3D identifier Z', and either X' !=3D X or Y' !=3D Y. It seems to me that - for this misconnectivity to remain=20 undetected - Z' would need to be configured to respond to OAM messages from A. Unless the OAM setup can occur auto- magically at Z' (based on signaling from A, perhaps), or is (for some reason) unnecessary, this seems like an extremely=20 unlikely occurrence, since it requires both misconnectivity and either a very unlikely coincidence, or an identical=20 misconfiguration of OAM. If OAM setup at Z' can occur automatically, it would - in=20 this case - require signaling that traverses either the (X, X') or (Y, Y') boundary (depending on which applies in any given case conforming to this strange scenario). That this could happen, if signaling occurs in the same channel as the misconnectivity, seems to be a flaw in techniques that depends on this mechanism for OAM setup. So, assuming that OAM MEP setup occurs using some technique that doesn't involve signaling over a potentially incorrect connection, without signaling authentication - exactly how likely is it that this scenario will actually occur in the real world? If OAM setup is unnecessary, this is a special problem (but still quite unlikely). If this is possible, it seems to me that a better safeguard against this occurrence would be to prevent OAM messages from crossing either the (X, X') or=20 (Y, Y') boundary. This is quite a bit more likely than it may seem. It is=20 quite likely that typical OAM messaging across an (X, X') boundary is blocked by default (to protect against an OAM based DoS attack, for example). And it seems to me that transferring OAM messages across a (Y, Y') boundary is not a trivial process and therefore extremely unlikely to occur accidentally. -- Eric -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Wednesday, June 15, 2011 4:37 AM To: verozheng@huawei.com; Alexander.Vainshtein@ecitele.com; mach.chen@huawe= i.com; mpls@ietf.org; matthew.bocci@alcatel-lucent.com; swallow@cisco.com; = Eric Gray Cc: matthew_282@virgilio.it Subject: RE: [mpls] Question about ICC Importance: High Folks: - We should be using source addresses in misconnectivity checking OAM CV me= ssages that relate to layer network access points. Total coupling of addre= ss *structure* to layer network topology however is not a good thing, as mi= nor changes to either require changes to the other.....total decoupling OTO= H relegates addresses to names. - We should not be using arbitrary 'text strings' to identify connections a= s was the common OPs practice when these really old ITU Recs were written. = Note that USA operators liked these and kept them in the SDH stds (path tr= ace) but other operators, and esp BT, pushed for pukka SA addresses to be u= sed. - I'm not sure country code classification is that relevant here....we are = not even dealing with a single layer network nor a TOS layer network where = peering is required (sure we can create such peering problems, but they are= technically quite unnecessary in any non-TOS layer network). What is more= relevant here is the client/server case...and this is not something any pr= evious co-ps mode layer technology has considered. Note we can have client= server netsting of several different parties in the same country. - A corollary of the client/server problem when the client and server have = the same traffic unit structure is that we can have inter-layer misconnecti= vity as well as intra-layer misconnectivity. This means that the address s= tructures we use in CV messages need to indicate at least 3 things: - the party X (globally unique) - the layer Y of party X (Y has to be unique within X) - the access point Z of layer network Y (Z has to be unique within Y). Note that the normal forwarding information in the DP traffic units only ne= ed consider the access points addresses Z (of some layer network Y). =20 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vero Zheng > Sent: 15 June 2011 08:51 > To: 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; > matthew.bocci@alcatel-lucent.com; swallow@cisco.com; > eric.gray@ericsson.com > Cc: 'Matthew Wright' > Subject: Re: [mpls] Question about ICC >=20 > Mach is correct on this. > ICC is unique within a Country. To make it globally unique, a Country > Code > is needed before the ICC. > Hope the authors of the identifiers draft are aware of this. >=20 > Several other drafts may also be affected. >=20 > Vero > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Alexander Vainshtein > > Sent: Friday, June 10, 2011 9:37 PM > > To: Mach Chen; mpls@ietf.org > > Cc: Matthew Wright > > Subject: Re: [mpls] Question about ICC > > > > Mach, > > An excellent question! > > > > lots of thanks for picking this up! > > > > regards, > > Sasha > > ________________________________________ > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach > > Chen [mach.chen@huawei.com] > > Sent: Friday, June 10, 2011 4:48 AM > > To: mpls@ietf.org > > Cc: Matthew Wright > > Subject: [mpls] Question about ICC > > > > Hi, > > > > Are ICCs globally unique? > > > > According to the definition of ICC in M.1400, it just says that ICCs > are > unique > > within a country. And there is an example shows that different > operators > could > > have the same ICC (e.g., Teleglobe International (UK) Ltd and > T=E9l=E9globe > > Canada ULC have the ICC code:"TGB"). > > > > So, if the ICCs are not globally unique, how to guarantee that the > ICC-based > > identifiers are globally unique? > > > > Or maybe I missed something? > > > > > > Best regards, > > Mach > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 neil.2.harrison@bt.com Thu Jun 16 04:58:25 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 4DB9E1F0C34 for ; Thu, 16 Jun 2011 04:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, 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 JQ2BVhGzNxmt for ; Thu, 16 Jun 2011 04:58:24 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id ED15D1F0C35 for ; Thu, 16 Jun 2011 04:58:23 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 16 Jun 2011 12:58:22 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.142]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 16 Jun 2011 12:58:22 +0100 From: To: , , , , , , Date: Thu, 16 Jun 2011 12:58:17 +0100 Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAAAcZk8AAIG+tgADCpdsA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44058295F3C@EMV62-UKRD.domain1.systemhost.net> References: <016401cc2b30$f5b1da40$e1158ec0$@com> <6D3D47CB84BDE349BC23BF1C94E316E44058295438@EMV62-UKRD.domain1.systemhost.net> 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: matthew_282@virgilio.it Subject: Re: [mpls] Question about ICC 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, 16 Jun 2011 11:58:25 -0000 Eric...please see in-line: Eric Gray [mailto:eric.gray@ericsson.com]b wrote 16 June 2011 12:14 >=20 > Neil, >=20 > The case where a difference in either X or Y might result > in an undetectable misconnectivity problem seems extremely > unlikely.=20 NH=3D> I recall someone (I won't say who) saying many years ago at an IETF = mtg that if we had misconnectivity problems in MPLS then we should buy our = equipment form a reputable supplier and not add OAM...things seems to have = changed a bit since then.... > So much so, that it cannot be worth the trouble > to configure both X and Y information for every OAM entity > relationship, and carry it in every OAM message. NH=3D> Well, that is a judgement call one has to make. But given that the a= bility to provide a transparent client/server relationship is the critical = service a transport network must provide then one should at least consider = the implications of this within the OAM framework. =20 The inter-layer misconnectivity problem does not arise in any co-cs mode la= yer transport network where the traffic unit (frame) is of a fixed size....= this is a property of the regular time-slicing of resource that creates the= co-cs network mode. So here we only have intra-layer misconnectivity to d= eal with. It also was not a problem with past co-ps mode technologies because we neve= r self-nested them AFAIK...indeed for any co-ps mode technology based on a = fixed traffic unit size (similar to the co-cs case above) this would not be= possible anyway, eg ATM. The problem of misconnectivity between different LSP levels already exists = in MPLS wrt sublayering of LSPs. But here we are only dealing with a singl= e layer network belonging to one party. However, in a proper transport network such sublayering is not required. W= e do however require layering. And in MPLS-TP we have both sublayering and= layering. So one can either aim for completeness in one's approach to OAM across both= nested sublayers and layers or not. That is a judgement call one can make= . >=20 > Say that operator X wants to check connectivity from A to Z > in layer Y. Now say that the actual connectivity is somehow > between A (in X at layer Y) and Z' (in X' at layer Y') where > identifier Z =3D identifier Z', and either X' !=3D X or Y' !=3D Y. >=20 > It seems to me that - for this misconnectivity to remain > undetected - Z' would need to be configured to respond to > OAM messages from A.=20 NH=3D> We should never use OAM that is of a request/response type to detect= defects in either co-cs or co-ps mode layer networks as it is not reliable= . This is not like the cl-ps mode where request/response OAM is the right = approach. And the reason is that in the co-cs or co-ps mode we create conn= ections which are constraining constructs for their child traffic units and= OAM....this is also why one can take short-cuts of the labelling of the ch= ild traffic units as I have explained in previous mails. However, one can = have traffic leak unidirectionally from a connection, ie there is no return= path. So request/response OAM should never be used to try and detect or t= race out misconnectivity defects in such networks. > Unless the OAM setup can occur auto- > magically at Z' (based on signaling from A, perhaps), or is > (for some reason) unnecessary, this seems like an extremely > unlikely occurrence, since it requires both misconnectivity > and either a very unlikely coincidence, or an identical > misconfiguration of OAM. >=20 > If OAM setup at Z' can occur automatically, it would - in > this case - require signaling that traverses either the > (X, X') or (Y, Y') boundary (depending on which applies in > any given case conforming to this strange scenario). That > this could happen, if signaling occurs in the same channel > as the misconnectivity, seems to be a flaw in techniques > that depends on this mechanism for OAM setup. >=20 > So, assuming that OAM MEP setup occurs using some technique > that doesn't involve signaling over a potentially incorrect > connection, without signaling authentication - exactly how > likely is it that this scenario will actually occur in the > real world? >=20 > If OAM setup is unnecessary, this is a special problem (but > still quite unlikely). If this is possible, it seems to me > that a better safeguard against this occurrence would be to > prevent OAM messages from crossing either the (X, X') or > (Y, Y') boundary. NH=3D> Hmm...not sure this is valid. One should be passing client traffic = and its OAM transparently in the server in a client/server relationship. S= omething could happen in a server layer to incorrectly strip off the server= header and expose the client traffic units and OAM to forwarding in the se= rver layer. This is the type of defect I had in mind....same thing can hap= pen in MPLS today but here only wrt sublayering in the same layer network. 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 >=20 > This is quite a bit more likely than it may seem. It is > quite likely that typical OAM messaging across an (X, X') > boundary is blocked by default (to protect against an OAM > based DoS attack, for example). And it seems to me that > transferring OAM messages across a (Y, Y') boundary is not > a trivial process and therefore extremely unlikely to occur > accidentally. >=20 > -- > Eric >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Wednesday, June 15, 2011 4:37 AM > To: verozheng@huawei.com; Alexander.Vainshtein@ecitele.com; > mach.chen@huawei.com; mpls@ietf.org; matthew.bocci@alcatel-lucent.com; > swallow@cisco.com; Eric Gray > Cc: matthew_282@virgilio.it > Subject: RE: [mpls] Question about ICC > Importance: High >=20 > Folks: >=20 > - We should be using source addresses in misconnectivity checking > OAM CV messages that relate to layer network access points. Total > coupling of address *structure* to layer network topology however is > not a good thing, as minor changes to either require changes to the > other.....total decoupling OTOH relegates addresses to names. >=20 > - We should not be using arbitrary 'text strings' to identify > connections as was the common OPs practice when these really old ITU > Recs were written. Note that USA operators liked these and kept them > in the SDH stds (path trace) but other operators, and esp BT, pushed > for pukka SA addresses to be used. >=20 > - I'm not sure country code classification is that relevant > here....we are not even dealing with a single layer network nor a TOS > layer network where peering is required (sure we can create such > peering problems, but they are technically quite unnecessary in any > non-TOS layer network). What is more relevant here is the > client/server case...and this is not something any previous co-ps mode > layer technology has considered. Note we can have client server > netsting of several different parties in the same country. >=20 > - A corollary of the client/server problem when the client and > server have the same traffic unit structure is that we can have inter- > layer misconnectivity as well as intra-layer misconnectivity. This > means that the address structures we use in CV messages need to > indicate at least 3 things: > - the party X (globally unique) > - the layer Y of party X (Y has to be unique within X) > - the access point Z of layer network Y (Z has to be unique within > Y). >=20 > Note that the normal forwarding information in the DP traffic units > only need consider the access points addresses Z (of some layer network > Y). >=20 > regards, Neil >=20 > 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 > information > is prohibited. If you've received this email in error, please let me > know immediately > 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 >=20 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Vero Zheng > > Sent: 15 June 2011 08:51 > > To: 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; > > matthew.bocci@alcatel-lucent.com; swallow@cisco.com; > > eric.gray@ericsson.com > > Cc: 'Matthew Wright' > > Subject: Re: [mpls] Question about ICC > > > > Mach is correct on this. > > ICC is unique within a Country. To make it globally unique, a Country > > Code > > is needed before the ICC. > > Hope the authors of the identifiers draft are aware of this. > > > > Several other drafts may also be affected. > > > > Vero > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Alexander Vainshtein > > > Sent: Friday, June 10, 2011 9:37 PM > > > To: Mach Chen; mpls@ietf.org > > > Cc: Matthew Wright > > > Subject: Re: [mpls] Question about ICC > > > > > > Mach, > > > An excellent question! > > > > > > lots of thanks for picking this up! > > > > > > regards, > > > Sasha > > > ________________________________________ > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Mach > > > Chen [mach.chen@huawei.com] > > > Sent: Friday, June 10, 2011 4:48 AM > > > To: mpls@ietf.org > > > Cc: Matthew Wright > > > Subject: [mpls] Question about ICC > > > > > > Hi, > > > > > > Are ICCs globally unique? > > > > > > According to the definition of ICC in M.1400, it just says that > ICCs > > are > > unique > > > within a country. And there is an example shows that different > > operators > > could > > > have the same ICC (e.g., Teleglobe International (UK) Ltd and > > T=E9l=E9globe > > > Canada ULC have the ICC code:"TGB"). > > > > > > So, if the ICCs are not globally unique, how to guarantee that the > > ICC-based > > > identifiers are globally unique? > > > > > > Or maybe I missed something? > > > > > > > > > Best regards, > > > Mach > > > _______________________________________________ > > > 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. > > > > > > _______________________________________________ > > > 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 Greg.Jones@itu.int Thu Jun 16 07:40: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 60E4E11E80E0 for ; Thu, 16 Jun 2011 07:40:09 -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 2AbdC5u-SEam for ; Thu, 16 Jun 2011 07:40:08 -0700 (PDT) Received: from mail8.itu.ch (mail8.itu.ch [156.106.192.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8464011E80FD for ; Thu, 16 Jun 2011 07:40:08 -0700 (PDT) Received: from PROTINT1.blue.itu.ch (protint1.itu.ch [156.106.128.47]) by mail8.itu.ch (8.13.8/8.14.4) with ESMTP id p5GEe6H2010319 for ; Thu, 16 Jun 2011 16:40:07 +0200 Received: from mailbox3.blue.itu.ch ([156.106.134.231]) by PROTINT1.blue.itu.ch with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 16:40:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 16 Jun 2011 16:39:15 +0200 Message-ID: In-Reply-To: <20110616085711.1916.86933.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-tsb-mpls-tp-ach-ptn-01.txt Thread-Index: AQICi3YuEmzFVKmZsthl/TlK3AkM85RTTzPw References: <20110616085711.1916.86933.idtracker@ietfa.amsl.com> From: To: X-OriginalArrivalTime: 16 Jun 2011 14:40:06.0842 (UTC) FILETIME=[491BE1A0:01CC2C33] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (mail8.itu.ch [156.106.192.38]); Thu, 16 Jun 2011 16:40:07 +0200 (CEST) Cc: tsbsg15@itu.int Subject: [mpls] FW: New Version Notification for draft-tsb-mpls-tp-ach-ptn-01.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, 16 Jun 2011 14:40:09 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgMTYg SnVuZSAyMDExIDEwOjU3DQpUbzogSm9uZXMsIEdyZWcNCkNjOiBKb25lcywgR3JlZw0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10c2ItbXBscy10cC1hY2gtcHRu LTAxLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdHNiLW1wbHMtdHAtYWNoLXB0 bi0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHcmVnIEpvbmVzIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC10c2It bXBscy10cC1hY2gtcHRuDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBBc3NpZ25tZW50IG9mIGFu IEFzc29jaWF0ZWQgQ2hhbm5lbCBUeXBlIGZvciBQYWNrZXQgVHJhbnNwb3J0IE5ldHdvcmsgQXBw bGljYXRpb25zDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0wNi0xNQ0KV0cgSUQ6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDExDQoNCkFic3RyYWN0Og0KICAgVGhlIFRy YW5zcG9ydCBQcm9maWxlIG9mIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUy0N CiAgIFRQKSBpcyBhIHBhY2tldC1iYXNlZCB0cmFuc3BvcnQgdGVjaG5vbG9neSBiYXNlZCBvbiB0 aGUgTVBMUw0KICAgVHJhZmZpYyBFbmdpbmVlcmluZyAoTVBMUy1URSkgYW5kIFBzZXVkb3dpcmUg KFBXKSBkYXRhIHBsYW5lDQogICBhcmNoaXRlY3R1cmVzIGFwcGxpY2FibGUgaW4gdmFyaW91cyBk ZXBsb3ltZW50IGVudmlyb25tZW50cy4NCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhl IGFsbG9jYXRpb24gb2YgYW4gQXNzb2NpYXRlZCBDaGFubmVsDQogICBUeXBlIHRvIHN1cHBvcnQg SVRVLVQgZGVmaW5lZCBmdW5jdGlvbnMgZm9yIHBhY2tldCB0cmFuc3BvcnQNCiAgIG5ldHdvcmsg KFBUTikgYXBwbGljYXRpb25zLCBzdWNoIGFzIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uDQog ICBhbmQgTWFpbnRlbmFuY2UgKE9BTSksIGFuZCBhcHBsaWNhYmxlIHRvIE1QTFMtVFAgUHNldWRv d2lyZXMNCiAgIChQV3MpLCBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcyksIFN1Yi1wYXRoIE1h aW50ZW5hbmNlDQogICBFbGVtZW50cyAoU1BNRXMpIGFuZCBTZWN0aW9ucy4NCg0KICAgVGhpcyBk b2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZWNvbWUgYSBwcm9kdWN0IG9mIGEgam9pbnQNCiAgIElu dGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpIC8gSW50ZXJuYXRpb25hbA0KICAg VGVsZWNvbW11bmljYXRpb25zIFVuaW9uIFRlbGVjb21tdW5pY2F0aW9uIFN0YW5kYXJkaXphdGlv bg0KICAgU2VjdG9yIChJVFUtVCkgZWZmb3J0IHRvIGluY2x1ZGUgYW4gTVBMUyBUcmFuc3BvcnQg UHJvZmlsZQ0KICAgd2l0aGluIHRoZSBJRVRGIE1QTFMgYW5kIFBXRTMgYXJjaGl0ZWN0dXJlcyB0 byBzdXBwb3J0IHRoZQ0KICAgY2FwYWJpbGl0aWVzIGFuZCBmdW5jdGlvbmFsaXRpZXMgb2YgYSBw YWNrZXQgdHJhbnNwb3J0IG5ldHdvcmsNCiAgIGFzIGRlZmluZWQgYnkgdGhlIElUVS1ULg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From internet-drafts@ietf.org Thu Jun 16 09:14:51 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 0E37A9E806A; Thu, 16 Jun 2011 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Qyonhafw8Fhr; Thu, 16 Jun 2011 09:14:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2069E805B; Thu, 16 Jun 2011 09:14:50 -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.55 Message-ID: <20110616161450.4852.70429.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 09:14:50 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-on-demand-cv-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: Thu, 16 Jun 2011 16:14:51 -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-04.txt Pages : 20 Date : 2011-06-16 LSP-Ping is an existing and widely deployed OAM mechanism for MPLS LSPs. This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS-TP LSPs. 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 a registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-04.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-04.txt From eric.gray@ericsson.com Thu Jun 16 09:19: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 D5A859E807E for ; Thu, 16 Jun 2011 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 X0xyUGYTRisw for ; Thu, 16 Jun 2011 09:19:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5F9E8071 for ; Thu, 16 Jun 2011 09:19:22 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5GGJK4T027838 for ; Thu, 16 Jun 2011 11:19:21 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 16 Jun 2011 12:19:16 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Thu, 16 Jun 2011 12:19:15 -0400 Thread-Topic: New version of draft-ietf-mpls-tp-on-demand-cv Thread-Index: AcwsQSKLYmse2/foRaij+FDcOVwXtw== 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_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_" MIME-Version: 1.0 Subject: [mpls] New version of draft-ietf-mpls-tp-on-demand-cv 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, 16 Jun 2011 16:19:24 -0000 --_004_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_ Content-Type: multipart/alternative; boundary="_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_" --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is now available at: http://tools.ietf.org/id/draft-ietf-mpls-tp-on-demand-= cv-04.txt and at http://tools.ietf.org/html/draft-ietf-mpls-tp-on-demand-cv To see what has been changed directly, go to http://tools.ietf.org/rfcdiff = and do a diff of http://tools.ietf.org/id/draft-ietf-mpls-tp-on-demand-cv-03.txt and= the new text link above, or view the diff provided via the HTML link at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-on-demand-cv-04.txt= . A comment spread-sheet is attached to this mail that lists comments receive= d during last call that either resulted in changes to the draft, or were not = previously discussed at length and resolved on the mailing list. -- Eric --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
            Is now av= ailable at:=20 ht= tp://tools.ietf.org/id/draft-ietf-mpls-tp-on-demand-cv-04.txt
            and at http://= tools.ietf.org/html/draft-ietf-mpls-tp-on-demand-cv=20
             
            To see wh= at has been=20 changed directly, go to http://tools.ietf.org/rfcdiff&nb= sp;and=20 do a
            diff of <= A=20 href=3D"http://tools.ietf.org/id/draft-ietf-mpls-tp-on-demand-cv-03.txt">ht= tp://tools.ietf.org/id/draft-ietf-mpls-tp-on-demand-cv-03.txt=20 and the new text
            link abov= e, or view=20 the diff provided via the HTML link at:
             
            http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-on-demand= -cv-04.txt.
             
            A comment= =20 spread-sheet is attached to this mail that lists comments=20 received
            during la= st call=20 that either resulted in changes to the draft, or were not=20 previously
            discussed= at length=20 and resolved on the mailing list.
             
            --
            Eric
            --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_-- --_004_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_ Content-Type: application/octet-stream; name="comments-on-03.csv" Content-Description: comments-on-03.csv Content-Disposition: attachment; filename="comments-on-03.csv"; size=12107; creation-date="Thu, 16 Jun 2011 13:56:28 GMT"; modification-date="Thu, 16 Jun 2011 13:56:41 GMT" Content-Transfer-Encoding: base64 U2VjdGlvbixQYWdlLENvbW1lbnQsUmVzb2x1dGlvbg0KMCwwLCJUaGlzIGRyYWZ0IHNob3VsZCBu b3QgYmUgcmVmZXJyZWQgdG8gYXMgIiJvbi1kZW1hbmQgQ1YiIiwgYmVjYXVzZSBpdCBpcyBub3Qg YSB2YXJpYXRpb24gb2YgQ0MvQ1YgZnVuY3Rpb25zLCBidXQgYW4gZXh0ZW5zaW9uIG9mIExTUC1Q aW5nLiIsIlJlamVjdGVkLiBMU1AtUGluZyBpcyB0aGUgZGVmaW5lZCBtZWNoYW5zaW0gZm9yIGRv aW5nIG9uLWRlbWFuZCBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLCBhbmQgaGFzIGJlZW4gc28g Zm9yIHNvbWUgdGltZS4gUHJvYWN0aXZlIENDL0NWIGhhcyBkaWZmZXJlbnQgc2NhbGFiaWxpdHkg Y29uc2lkZXJhdGlvbnMsIGhlbmNlIHVzZXMgYSBkaWZmZXJlbnQgYXBwcm9hY2guIg0KMCwwLEl0 IHNlZW1zIHRoYXQgdGhpcyBkcmFmdCAodmVyc2lvbiAwMykgaGFzIGRldGVybWluZWQgbm90IHRv IHVzZSBBQ0gtVExWIGFzIGRlZmluZWQgaW4gUkZDNTU4NiBzaW5jZSB0aGUgZHJhZnQgYWNoLXRs diBpcyByZW1vdmVkLiBUaGUgcmF0aW9uYWwgaXMgdGhhdCBSRkM0Mzc5IGFsc28gaGFzIFRMViBp biBpdHMgcGF5bG9hZCBzbyB0aGF0IHVzZXJzIG1heSBiZSBjb25mdXNlZCB3aGV0aGVyIHRoZSBu ZXcgVExWcyBpbiB0aGlzIGRyYWZ0IGFyZSBhcHBsaWVkIGFjY29yZGluZyB0byBhY2gtdGx2IG9y IFJGQzQzNzkgVExWLiAsUmVqZWN0ZWQuIFRoZSBBQ0gtVExWIGRyYWZ0IGhhcyBiZWVuIHJlbW92 ZWQgYmVjYXVzZSB0aGUgZGVjaXNpb24gd2FzIG1hZGUgdG8gZGlzY29udGludWUgd29yayBvbiB0 aGF0IGRyYWZ0LiAgUmVsZXZhbnQgdGV4dCBhbmQgb2JqZWN0cyBmcm9tIHRoYXQgZHJhZnQgaGF2 ZSBiZWVuIGV4cGxpY2l0bHkgaW5jbHVkZWQgaW4gdGhpcyBkcmFmdC4gIEl0IGlzIG5ldmVyIGNs ZWFyIChvciBldmVuIGEgZ29vZCBpZGVhKSBob3cgdG8gY2xhcmlmeSB0aGF0IHNvbWV0aGluZyB0 aGF0IGlzIG5vIGxvbmdlciBiZWluZyBkZWZpbmVkIGlzIG5vdCB1c2VkLg0KMCwwLEl0IGlzIHVu Y2xlYXIgd2hldGhlciB0aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDQzNzkgYW5kIFJGQyA1MDg1 LiwiUmVqZWN0ZWQuIFRoZSBkb2N1bWVudCBpcyB2ZXJ5IGNsZWFyIGFib3V0IGV4YWN0bHkgd2hh dCBpdCB1cGRhdGVzIGluIFJGQyA0Mzc5LiBUaGUgdXBkYXRlZCBpbmZvcm1hdGlvbiBpcyBleHBs aWNpdGx5IGluY2x1ZGVkIGluIHNlY3Rpb24gMy4zLCBhbmQgdGhlIGV4dGVudCBvZiB0aGUgdXBk YXRlcyBpcyBjbGVhcmx5IHN0YXRlZCBpbiBJQU5BIENvbnNpZGVyYXRpb25zLiINCjEuMiw0LEl0 IGlzIG5vdCBjbGVhciB3aHkgdGhpcyBkcmFmdCBtZW50aW9ucyBCRkQgYW5kIFJGQzU4ODQgKEJG RCBmb3IgTVBMUyBMU1BzKS4sUmVqZWN0ZWQuIFNlY3Rpb24gMS4yIGRvZXMgbm90IGNvbnRhaW4g YW55IHJlZmVyZW5jZSB0byBCRkQuDQoxLjMsNSxJdCBpcyBub3QgY2xlYXIgd2h5IHRoaXMgZHJh ZnQgbWVudGlvbnMgQkZEIGFuZCBSRkM1ODg0IChCRkQgZm9yIE1QTFMgTFNQcykuLCJSZWplY3Rl ZC4gVGhlIHRleHQgdGhhdCBpbmNsdWRlcyBCRkQgaXMgYSBmYWN0dWFsIHN0YXRlbWVudCBhYm91 dCB3aGF0IGlzIHRoZSBjYXNlIGlmIElQIGFkZHJlc3NpbmcgaXMgbm90IGF2YWlsYWJsZSBmb3Ig dXNlIGluIE9BTSBnZW5lcmFsbHkuICBJZiB0aGUgc3RhdGVtZW50IHdhcyBhcmd1YWJseSB1bnRy dWUgdW5kZXIgdGhvc2UgY2lyY3Vtc3RhbmNlcywgd2Ugd291bGQgcmVtb3ZlIGl0LiAgVGhpcyBp cyBub3QgdGhlIGNhc2UuIg0KMiw1LEl0IGlzIG5vdCBjbGVhciBob3cgdGhlIGFkZHJlc3MgVExW cyBhcmUgdXNlZCBmb3IgTUVQLXRvLU1FUCBhbmQgTUVQLXRvLU1JUCBjb21tdW5pY2F0aW9uLiBB bmQgaXQgaXMgYWxzbyBub3QgY2xlYXIgaG93IHRoZXkgYXJlIHVzZWQgaW4gY2FzZSBvZiBub2Rl IE1FUC9NSVAgYW5kL29yIHBlciBpbnRlcmZhY2UgTUVQL01JUC4sIlJlamVjdGVkLiAgVGhlIGlu dGVuZGVkIGNvbW11bmljYXRpb24gZm9yIHRoZXNlIG1lc3NhZ2VzIGlzIHRvIHZlcmlmeSB0aGF0 IGNvcnJlY3QgKGkuZS4gLSBleHBlY3RlZCkgY29ubmVjdGl2aXR5IGV4aXN0cy4gIFNvbWUgIGZv bGtzIGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhlc2Ugb2JqZWN0cyBtYXkgYmUgaGVscGZ1bCwgYW5k IHRoZWlyIHVzZSBpcyBub3QgbWFuZGF0b3J5LCBzbyBhbnlvbmUgd2hvIGZlZWxzIHRoZXkgYXJl bid0IHVzZWZ1bCwgbmVlZCBub3QgdXNlIHRoZW0uICBGb3IgZXhhbXBsZSwgRFNNQVAvRERNQVAg VExWcyBtYXkgYmUgdXNlZCB0byBpbmRpY2F0ZSBhIHRhcmdldCBpbnRlcmZhY2UgZm9yIHBlci1p bnRlcmZhY2UgY29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbi4iDQoyLjEsNSwiU29tZSBjbGVhbi11 cCBpcyBuZWVkZWQgd2l0aCByZXNwZWN0IHRvIHVzZSBvZiBEU01BUCBhbmQgRERNQVAuIE9uZSBv ZiB0aGVzZSAgdGVybXMgaXMgbm90IGRlZmluZWQgaW4gUkZDIDQzNzksIGFuZCB0aGVzZSB0ZXJt cyBuZWVkIHRvIGJlIGV4cGxpY2l0bHkgZXhwYW5kZWQgZm9yIGF0IGxlYXN0IHRoZSBmaXJzdCBv Y2N1cnJlbmNlLiIsIkFkZGVkIHJlcXVpcmVkIHJlZmVyZW5jZSB0byBlbmhhbmNlZCBEU01BUCwg ZXhwYW5kZWQgdGhlIGFjcm9ueW1zIGFzIHN1Z2dlc3RlZCwgYW5kIGNsZWFuZWQgdXAgdGhlIHRl eHQgcmVsYXRlZCB0byB1c2Ugb2YgYWRkcmVzcyBpbmZvcm1hdGlvbiBpbiB0aGVzZSBUTFZzLiIN CjIuMSw1LFRleHQgaW4gdGhpcyBzZWN0aW9uIHNlZW1zIHRvIGltcGx5IHRoYXQgaWRlbnRpZmll ciBpbmZvcm1hdGlvbiB3b3VsZCBiZSBpZ25vcmVkLixDbGFyaWZpZWQgdGhhdCBpZGVudGlmaWVy IHZlcmlmaWNhdGlvbiBpcyBwYXJ0IG9mIHRoZSBjb25zaXN0ZW5jeSBjaGVja3MgcGVyZm9ybWVk IG9uIHRoZSBjb250cm9sL2RhdGEgcGxhbmUuDQoyLjEuMSw1LFRoZSB0ZXh0IG9uIGluY2x1ZGlu ZyBEU01BUC9ERE1BUCBpbmZvcm1hdGlvbiBpbiB0aGlzIHNlY3Rpb24gc2VlbXMgdG8gYmUgaW5j b25zaXN0ZW50IHdpdGggdGhlIGludGVudGlvbiB0aGF0IHRoZXNlIFRMVnMgYXJlIG9wdGlvbmFs LiwiQ2xhcmlmaWVkIHRoZSB0ZXh0IGJ5IGFkZGluZyAiIklmIHRoZSBEU01BUCAob3IgRERNUCkg VExWIGlzIGluY2x1ZGVkIIUiIiINCjIuMS4xLDUsIlNvbWUgY2xlYW4tdXAgaXMgbmVlZGVkIHdp dGggcmVzcGVjdCB0byB1c2Ugb2YgRFNNQVAgYW5kIERETUFQIC0gaW4gcGFydGljdWxhciB3aXRo IHJlc3BlY3QgdG8gdGhlIHVzZSBvZiBhZGRyZXNzIFRMVi4gVGhlc2Ugb2JqZWN0cyBpbmNsdWRl IGFuIGFkZHJlc3MgaW5mb3JtYXRpb24gZmllbGQgZm9yIHdoaWNoIHRoZSBpbnRlbnQgc2VlbXMg dG8gYmUgdG8gZGVmaW5lIGEgbmV3IGFkZHJlc3MgdHlwZSwgZm9yIHVzaW5nIHRoaXMgZmllbGQg d2l0aG91dCBhbiBhZGRyZXNzLiIsQ2xlYW5lZCB1cCB0aGUgdGV4dCByZWxhdGVkIHRvIHVzZSBv ZiBhZGRyZXNzIGluZm9ybWF0aW9uIGluIHRoZXNlIFRMVnMuDQoyLjIsNiwiVGhpcyBzZWN0aW9u IHRhbGtzIGFib3V0IFNvdXJjZSBhbmQgRGVzdGluYXRpb24gIiJBZGRyZXNzIiIgVExWcyAtIHdo ZXJlIHRoZXNlIHNob3VsZCBiZSBpZGVudGlmaWVycy4iLENvcnJlY3RlZCB1c2FnZSB0byByZWZs ZWN0IHRoZSBmYWN0IHRoYXQgdGhlc2UgYXJlIGlkZW50aWZpZXJzLg0KMi4yLjEsNixUaGUgcmVm ZXJlbmNlIHRvIGRyYWZ0LWlldGYtbXBscy10cC1pZGVudGlmaWVycyBpcyBub3JtYXRpdmUgYW5k IG5vdCBpbmZvcm1hdGl2ZSBhcyByZXBvcnRlZCBpbiBzZWN0aW9uIDkuMixNb3ZlZCB0aGUgcmVm ZXJlbmNlIHRvIHNlY3Rpb24gOS4xIChOb3JtYXRpdmUgUmVmZXJlbmNlcykNCjIuMyw3LCJPQU0g bWVjaGFuaXNtcyBzaG91bGQgd29yayB3aXRoIE1FRywgTUVQIGFuZCBNSVAgaWRlbnRpZmllcnMu IFRoZXNlIGlkZW50aWZpZXJzIHNob3VsZCBub3QgYmUgZGVwZW5kZW50IG9uIGhvdyB0aGUgTFNQ IG9yIFBXIGhhcyBiZWVuIHNldHVwIChlLmcuLCBzdGF0aWNhbGx5IG9yIHZpYSBhIGR5bmFtaWMg Y29udHJvbCBwbGFuZSkuIiwiUmVqZWN0ZWQuIFN1cGVyZmljaWFsbHksIHRoaXMgY29tbWVudCBh cHBlYXJzIHRvIG1ha2Ugc2Vuc2UuICBIb3dldmVyLCBmdXJ0aGVyIGFuYWx5c2lzIGJyaW5ncyBv dXQgYSBmZXcgZmxhd3MgaW4gdGhlIHRoaW5raW5nIHRoYXQgbWFrZXMgaXQgYXBwZWFyIHRoYXQg d2F5LiAgRm9yIG9uZSB0aGluZywgY2VydGFpbiBhYmlsaXRlcyAoc3VjaCBhcyB0aGUgYWJpbGl0 eSB0byBpZGVudGlmeSBzaWduYWxpbmcgZW50aXRpZXMpIHJlcXVpcmUgdGhhdCBwYXJ0aWNpcGF0 aW5nIG5vZGVzIGhhdmUgY2VydGFpbiBpbmZvcm1hdGlvbiBhYm91dCBlYWNoIG90aGVyIHRoYXQg bWFrZXMgZXhwbGljaXQgaW5jbHVzaW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBpbiBhbiBPQU0gbWVz c2FnZSBhIHJlZHVuZGFudCAodGh1cyB3YXN0ZWZ1bCkgZXhlcmNpc2UuICBJbiBzZWN0aW9uIDIu MyB3ZSBkZWZpbmUgaG93IHRvIGlkZW50aWZ5IGFuIE9BTSBlbmQtcG9pbnQgd2hlbiB0aGUgaW5m b3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHNpZ25hbGluZyBpcyBub3QgcHJlc2VudC4gIFRvICBy ZXF1aXJlIGEgY29tbW9uIGlkZW50aWZpZXIgdG8gYmUgdXNlZCBpbiBib3RoIHRoZSBzaWduYWxl ZCBhbmQgbm9uLXNpZ25hbGVkIGNhc2VzIHdvdWxkIGVmZmVjdGl2ZWx5IGJ1cmRlbiBzaWduYWxp bmcgaW1wbGVtZW50YXRpb25zIHdpdGggYWRkaXRpb25hbCBiYWdnYWdlLiAgQmVjYXVzZSBzaWdu YWxpbmcgaXMgY3VycmVudGx5IHRoZSBjb21tb24gbW9kZSBvZiBvcGVyYXRpb24gaW4gTVBMUyBu ZXR3b3JrcywgbWFraW5nIHRoZSBjb21tb24gY2FzZSBzdWItb3B0aW1hbCB3b3VsZCBiZSBhIHZl cnkgYmFkIGlkZWEuICBOb3RlIHRoYXQgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgdGV4dCB0byBw cmV2ZW50IGFuIG9wZXJhdG9yIGZyb20gdXNpbmcgdGhlICIic3RhdGljIGlkZW50aWZpZXJzIiIg Zm9yIGFsbCBPQU0sIGlmIHRoYXQgaXMgd2hhdCB0aGV5IHdhbnQgdG8gZG8uIg0KMi4yLjIsNywi TFNQIFBpbmcgaXMgZXh0ZW5kZWQgdG8gYmUgdXNlZCBpbiBub24tSVAgbmV0d29ya3MgYnkgZGVm aW5pbmc6IERTTUFQL0RETUFQIEJhc2VkIE5vbi1JUCBBZGRyZXNzIFRMViwgU291cmNlL0Rlc3Rp bmF0aW9uIEFkZHJlc3MgVExWLiBIb3dldmVyLCBJbiB0cmFuc3BvcnQgbmV0d29ya3MsIGluLWJh bmQgT0FNIGZ1bmN0aW9ucyBkbyBub3QgbmVlZCBhZGRyZXNzZXMsIGp1c3QgaWRlbnRpZmllcnMu IiwiU291cmNlIGFuZCBEZXN0aW5hdGlvbiBhZGRyZXNzZXMgYXJlIGNoYW5nZWQgdG8gc291cmNl IGFuZCBkZXN0aW5hdGlvbiBpZGVudGlmaWVycy4gRFNNQVAgYW5kIERETUFQIFRMVnMgbm93IGlu Y2x1ZGUgYW4gIiJhZGRyZXNzIHR5cGUiIiB0aGF0IGlzICIibm8gYWRkcmVzcyIiIg0KMi4yLjMs NywiTFNQIFBpbmcgaXMgZXh0ZW5kZWQgdG8gYmUgdXNlZCBpbiBub24tSVAgbmV0d29ya3MgYnkg ZGVmaW5pbmc6IERTTUFQL0RETUFQIEJhc2VkIE5vbi1JUCBBZGRyZXNzIFRMViwgU291cmNlL0Rl c3RpbmF0aW9uIEFkZHJlc3MgVExWLiBIb3dldmVyLCBJbiB0cmFuc3BvcnQgbmV0d29ya3MsIGlu LWJhbmQgT0FNIGZ1bmN0aW9ucyBkbyBub3QgbmVlZCBhZGRyZXNzZXMsIGp1c3QgaWRlbnRpZmll cnMuIiwiU291cmNlIGFuZCBEZXN0aW5hdGlvbiBhZGRyZXNzZXMgYXJlIGNoYW5nZWQgdG8gc291 cmNlIGFuZCBkZXN0aW5hdGlvbiBpZGVudGlmaWVycy4gRFNNQVAgYW5kIERETUFQIFRMVnMgbm93 IGluY2x1ZGUgYW4gIiJhZGRyZXNzIHR5cGUiIiB0aGF0IGlzICIibm8gYWRkcmVzcyIiIg0KMi4z LjIsOCxUaGUgZm9ybWF0IHNwZWNpZmllZCBmb3IgdGhlIFN0YXRpYyBQc2V1ZG93aXJlIFRMViBp cyBub3QgY29uc2lzdGVudCB3aXRoIHRoZSBjb3JyZXNwb25kaW5nIGlkZW50aWZpZXIgZGVmaW5l ZCBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMuLEFkZGVkIHRoZSBBR0kgYXMgYSBu ZXcgZmllbGQgaW4gdGhlIGZvcm1hdA0KMyw5LFNob3VsZCBzZWN0aW9uIDMgaW5jbHVkZSBpbmZv cm1hdGlvbiBhYm91dCB1c2Ugb2YgdGhlIFBhZCBUTFY/LEFkZGVkIGEgbmV3IHBhcmFncmFwaCBh dCB0aGUgZW5kIG9mIHNlY3Rpb24gMyB0byBtYWtlIGEgZ2VuZXJhbCByZWZlcmVuY2UgdG8gdXNp bmcgbWVzc2FnZSBhbmQgVExWIGNvbnN0cnVjdGlvbiBwcm9jZWR1cmVzIHNwZWNpZmllZCBpbiBS RkMgNDM3OS4NCjMuMywxMCxIb3cgY2FuIGEgbm9kZSByZWNlaXZlIGFuIGVjaG8gcmVxdWVzdCB3 aXRoIHJlcGx5IG1vZGUgZGlmZmVyZW50IHRoYW4gNCBpZiB0aGUgZWNobyByZXF1ZXN0cyBNVVNU IGJlIHNlbnQgd2l0aCBhIHJlcGx5IG1vZGUgZXF1YWwgdG8gND8sTVVTVCBoYXMgYmVlbiBjaGFu Z2VkIHRvIFNIT1VMRC4NCjMuMywxMCwiVGhlIHdvcmRpbmcgY2hvaWNlIGZvciBkZXNjcmliaW5n IHRoZSB1c2FnZSBpbiBzZWN0aW9uIDMuMyBpcyBhIGJpdCBjb25mdXNpbmcsIGFwcGVhcmluZyBh cyBpdCBkb2VzIGFmdGVyIDMuMi4gIDMuMiBzYXlzIHRoYXQgeW91IGNhbiB1c2UgSVAgZW5jYXBz dWxhdGlvbiB3aXRoIEFDSCwgYW5kIHRoYXQgeW91IHVzZSB0aGUgSVAgQUNIIHR5cGUuICBTZWN0 aW9uIDMuMyB0aGVuIHJlZmVycyB0byAiInVzaW5nIE9uLWRlbWFuZCBDViB2aWEgTFNQLVBpbmcg d2l0aCB0aGUgQUNIIGhlYWRlciIiIHdoZW4gcmVmZXJyaW5nIHRvIG1lc3NhZ2VzIHRoYXQgd2ls bCBub3QgaGF2ZSBJUCBoZWFkZXJzLiAgQnV0IHRoZSB0ZXh0IGp1c3QgZmluaXNoZWQgdGVsbGlu ZyBtZSB0aGF0IEkgbWlnaHQgaGF2ZSBhbiBBQ0ggaGVhZGVyIGFuZCBhbiBJUCBoZWFkZXIuICBT b21lIG90aGVyIHdheSBvZiBpZGVudGlmeWluZyB0aGUgdHdvIGNhc2VzIHdvdWxkIGJlIGhlbHBm dWwuCiIsIlRoaXMgYWxzbyBpcyBhIGNhc2Ugb2YgcHJlc3VtZWQgY29udGV4dCB0aGF0IGNsZWFy bHkgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLiBBZGRlZCB0aGUgcXVhbGlmaWVyIHRvIHRoZSBhbWJp Z3VvdXMgc3RhdGVtZW50ICIiSW4gdGhlIG5vbi1JUCBjYXNlIIUiIiINCjMuMywxMCxUaGUgcHJv Y2VkdXJlcyBpbiBzZWN0aW9uIDMuMyBhc3N1bWUgdGhlIGV4aXN0ZW5jZSBvZiBhbiBpbi1iYW5k IHJldHVybiBwYXRoLiBIb3cgY2FuIHRoZXkgYmUgdXNlZCB3aXRoIHAybXAgTFNQcyB0aGF0IGRv IG5vdCBoYXZlIGFuIGluLWJhbmQgcmV0dXJuIHBhdGg/LCJUaGlzIGlzIG5vdCB0aGUgY2FzZS4g IFNlY3Rpb24gMy41IHJlZmVycyB0byBlYXJsaWVyIHNlY3Rpb25zIGluIFNlY3Rpb24gMyAoaW5j bHVkaW5nIHNlY3Rpb24gMy4zIGV4cGxpY2l0bHkgZm9yIHRoZSBub24tSVAgY2FzZSksIHdoZXJl IHRoZSBzZXQgb2YgYXNzdW1wdGlvbnMgYXJlOgoKICAgIGEpIHRoZXJlIGlzIGEgcmV2ZXJzZSBw YXRoIExTUCBvciBQVy4KICAgIGIpIHRoZXJlIGV4aXN0cyBhIHJldHVybiBwYXRoIG9mIHNvbWUg dW5zcGVjaWZpZWQgdHlwZS4KICAgIGMpIHRoZXJlIGlzIG5vIGtub3duIHJldmVyc2UgcGF0aC4K ClRoaXMgY292ZXJzIHRoZSByYW5nZSBvZiBwb3NzaWJpbGl0aWVzLiAgU2VjdGlvbiAzLjMgaXMg YSBiaXQgbW9yZSBsaW1pdGluZywgYnV0IG9ubHkgc3BlY2lmaWVzIHRoYXQgZWNobyByZXF1ZXN0 IHBhY2tldHMgU0hPVUxEIGJlIGRyb3BwZWQgaWYgdGhlcmUgaXMgbm8gTVBMUyBMU1AgcGF0aCBv biB3aGljaCB0byByZXR1cm4gYSByZXBseS4gIEluIE5vcm1hdGl2ZSBsYW5ndWFnZSB1c2FnZSAt IHNwZWNpZmllZCBpbiBSRkMgMjExOSAtIFNIT1VMRCBhbGxvd3MgZm9yIGV4Y2VwdGlvbnMgaWYg IiJ2YWxpZCByZWFzb25zIiIgZXhpc3QgIiJpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMiIjsg Y2xlYXJseSBpdCBpcyBwb3NzaWJsZSB0aGF0IHNvbWUgb3V0LW9mLWJhbmQgcmV0dXJuIHBhdGgg bWF5IGV4aXN0LCBhbmQgdGhpcyB3b3VsZCBjbGVhcmx5IGZpdCB0aGUgYmlsbCBmb3IgIiJwYXJ0 aWN1bGFyIGNpcmN1bXN0YW5jZXMuIiIgIFdlIGRvIG5vdCBpbnRlbmQgdG8gc3BlY2lmeSB0aGF0 IGFueSBzdWNoIG91dC1vZi1iYW5kIGNoYW5uZWwgTVVTVCBleGlzdCwgaG93ZXZlciwgc28gd2Ug ZGlkIG5vdCByZWZlciB0byBhbnkgc3VjaCBjaGFubmVsLiAgV2UgdXNlIFNIT1VMRCB3aGVyZSB3 ZSBtaWdodCB1c2UgTUFZLCBiZWNhdXNlIGl0IGlzIGFjdHVhbGx5IGEgZ3JlYXQgZGVhbCBtb3Jl IGxpa2VseSB0aGF0IGltcGxlbWVudGF0aW9ucyB3aWxsIGRyb3AgdGhlc2UgcmVxdWVzdHMuICAK CldlICBoYXZlIG1hZGUgdGhlIGxhbmd1YWdlIGxlc3MgcmVzdHJpY3RpdmUgYnkgYWxsb3dpbmcg dGhhdCBzb21lIG90aGVyIG1ldGhvZCBvZiByZXR1cm5pbmcgdGhlIHJlc3BvbnNlIE1BWSBiZSB1 c2VkIGlmIGF2YWlsYWJsZS4iDQozLjQuMSwxMSwiQXJlICIicmV2ZXJzZSBwYXRoIEZFQyBpbmZv cm1hdGlvbiIiIGluIDMuNC4xICh0aGF0IHJlZmVycyB0byAzLjQuMikgYW5kICIiUmV2ZXJzZS1w YXRoIHRhcmdldCBGRUMgc3RhY2sgVExWIiIgaW4gMy40LjIgdGhlIHNhbWU/ICBUaGUgZm9ybWVy IGlzIGRlc2NyaWJlZCB0byAiIihTSE9VTEQpIHJldHVybiIiIHdoaWxlIHRoZSBsYXR0ZXIgaXMg ZGVzY3JpYmVkIHRvICIiKE1BWSkgYXR0YWNoIiIiLCJSZWplY3RlZC4gIFRoZXkgY2xlYXJseSBh cmUgdGhlIHNhbWUsIGdpdmVuIHRoYXQgdGhlICIiaW4tY29udGV4dCIiIHRleHQgaW4gc2VjdGlv biAzLjQuMSBzdGF0ZXM6CgoiIldoZW4gW3RoZSBWYWxpZGF0ZSBSZXZlcnNlIFBhdGggKFIpXSBm bGFnIGlzIHNldCBpbiB0aGUgZWNobyByZXF1ZXN0LCB0aGUgTFNQLWVncmVzcyBTSE9VTEQgcmV0 dXJuIHJldmVyc2UgcGF0aCBGRUMgaW5mb3JtYXRpb24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDMuNC4yLiIiCgpGcm9tIHRoaXMgdGV4dCwgYW5kIHRoZSB0ZXh0IGFjdHVhbGx5IGluIHNlY3Rp b24gMy40LjIsIGl0IHNob3VsZCBiZSBvYnZpb3VzIHRoYXQgLSB3aGlsZSB0aGlzIGluZm9ybWF0 aW9uIE1BWSBiZSBhdHRhY2hlZCB0byBhbnkgcmVzcG9uc2UsIGl0IFNIT1VMRCBiZSBhdHRhY2hl ZCB3aGVuIGV4cGxpY2l0bHkgcmVxdWVzdGVkLiINCjMuNC4yLDExLCJUaGVyZSBzZWVtcyB0byBi ZSBhbiBpbmNvbnNpc3RlbmN5IGJldHdlZW4gc2VjdGlvbnMgMy40LjEgYW5kIDMuNC4yLiBTZWN0 aW9uIDMuNC4xIHNheXMgdGhhdCBpZiB0aGUgUiBmbGFnIGlzIHNldCwgdGhlIGVncmVzcyBMU1Ig IiJTSE9VTEQiIiByZXR1cm4gcmV2ZXJzZSBwYXRoIEZFQyBpbmZvcm1hdGlvbi4gIFNlY3Rpb24g My40LjIgc2F5cyB0aGF0IGlmIHRoZSBSIGZsYWcgaXMgc2V0LCB0aGUgZWdyZXNzIExTUiAiIk1B WSIiIHJldHVybiB0aGUgaW5mb3JtYXRpb24uICBXaGljaCBpcyBpdD8KIixJdCBTSE9VTEQgYmUg U0hPVUxEIGluIGJvdGggY2FzZXMuIFRoaXMgaGFzIGJlZW4gY29ycmVjdGVkLg0KMy41LDEyLFRo ZSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1wMm1wLWxzcC1waW5nIGlzIG5vcm1hdGl2ZSBhbmQg bm90IGluZm9ybWF0aXZlIGFzIHJlcG9ydGVkIGluIHNlY3Rpb24gOS4yLE1vdmVkIHRoZSByZWZl cmVuY2UgdG8gc2VjdGlvbiA5LjEgKE5vcm1hdGl2ZSBSZWZlcmVuY2VzKQ0KMy40LjIsMTIsRmln dXJlIDggaXMgdW5jbGVhciByZWdhcmRpbmcgdGhlIHRleHQgaW4gMy4yIFRhcmdldCBGRUMgU3Rh Y2sgaW4gUkZDNDM3OSBzaW5jZSB0aGUgbGVuZ3RoIGFuZCB2YWx1ZSBmaWVsZHMgKHByZWZpeCkg YXJlIG1pc3NpbmcuLFJlamVjdGVkLiBXZSBwb2ludCB0byBSRkMgNDM3OSBmb3IgYm90aCB0aGUg VExWIGZvcm1hdCBhbmQgcnVsZXMgZm9yIFRMViBjb25zdHJ1Y3Rpb24uIFRoZSBkZXNjcmlwdGlv biBvZiBob3cgdG8gZ2VuZXJhdGUgdGhlIFRMViBhcmUgbm90IGFtYmlndW91cy4NCjMuNC4zLDEy LCIzLjQuMyBzYXlzICIiMi4gSWYgdGhlIFJldmVyc2UtUGF0aCB0YXJnZXQgRkVDIHN0YWNrIHN0 YWNrIFRMViBpcyBwcmVzZW50Li4uIiIgKEJlc2lkZXMgZHVwbGljYXRlZCAiInN0YWNrIiIgKHR5 cG8pKS4gSG93IGRvZXMgdGhlIEluZ3Jlc3MgKHJlcXVlc3RpbmcpIG5vZGUgYWNrbm93bGVkZ2Uv ZXhwZWN0IHRoYXQgdGhpcyBUTFYgYXMgYXR0YWNoZWQgaW4gcmVwbHlpbmcgaXMgaW5jbHVkZWQ/ ICIsIk5vIGNoYW5nZSBpcyByZXF1ZXN0ZWQgaW4gdGhpcyBjb21tZW50LiBUaGUgdHlwbyBoYXMg YmVlbiBjb3JyZWN0ZWQuIFBpbmctYmFzZWQgb24tZGVtYW5kIGNvbm5lY3Rpdml0eSB2ZXJpZmlj YXRpb24gaXMgc3RhdGVmdWwuIEltcGxlbWVudGF0aW9ucyBzZW5kaW5nIGEgIiJQaW5nIiIgc3Rv cmUgc3RhdGUgaW5mb3JtYXRpb24gcmVsYXRpdmUgdG8gZWFjaCAiIlBpbmciIiBpbiB0cmFuc2l0 LiAgSW5jbHVkZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uIFNIT1VMRCBiZSBpbmRpY2F0aW9ucyBv ZiB3aGF0IHRoZSByZXF1ZXN0ZXIgZXhwZWN0cyB0byBzZWUgaW4gYSByZXNwb25zZS4gIE5vdGU6 IHRoaXMgaXMgbm90IGFsd2F5cyByZXF1aXJlZCBhcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXkgYWx3 YXlzIHJlcXVlc3QgY2VydGFpbiB0aGluZ3MgaW4gZWFjaCByZXF1ZXN0IGl0IHNlbmRzIC0gaGVu Y2UgaXQgbWF5IG5vdCBiZSBuZWNlc3NhcnkgdG8gZXhwbGljaXRseSBzdG9yZSB0aGlzIGluZm9y bWF0aW9uIHdpdGggZWFjaCBwZW5kaW5nIHJlcXVlc3QuICBJdCBpcyBhbHNvIHBvc3NpYmxlIHRo YXQgdGhlIHJlc3BvbmRlciBtYXkgbm90IGluY2x1ZGUgYWxsIG9mIHRoZSBpbmZvcm1hdGlvbiBy ZXF1ZXN0ZWQgLSBoZW5jZSBhbnkgaW1wbGVtZW50YXRpb24gbmVlZHMgdG8gYmUgcHJlcGFyZWQg Zm9yIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHJlcXVlc3RlZCBpbmZvcm1hdGlvbiBtYXkgbm90IGJl IGluY2x1ZGVkLiAgRXhwbGljaXQgQWNrbm93bGVkZ2VtZW50IGlzIG5ldmVyIHJlcXVpcmVkLiIN CjMuNC4zLDEyLCJJbmdyZXNzL0VncmVzcyAobm9kZSkgc2hvdWxkIGJlIGFsaWduZWQgd2l0aCBy ZXF1ZXN0aW5nL3JlcGx5aW5nIG5vZGUuIEl0IHNlZW1zICIiSW5ncmVzcyIiIGlzICIicmVxdWVz dGluZyIiLCBidXQgd2UgaGF2ZSAyIExTUHMgZm9yIHRoaXMgZnVuY3Rpb24gKFRoZXJlZm9yZSBt YXkgYmUgY29uZnVzZWQpIiwiQ2hhbmdlZCBhcHByb3ByaWF0ZSBpbnN0YW5jZXMgb2YgIiJpbmdy ZXNzIiIgdG8gIiJSZXF1ZXN0ZXIiIiBhbmQgIiJlZ3Jlc3MiIiB0byAiIlJlc3BvbmRlciIiIGFu ZCBhZGRlZCB0ZXh0IHRvIHRoZSBjb252ZW50aW9ucyBzZWN0aW9uIHRvIGV4cGxhaW4gdGhpcy4g Ig0KMy40LjMsMTIsIlJlZ2FyZGluZyBjaGVjayAjMSBpbiAzLjQuMzogaXMgaXQgdGhlIHNhbWUg YXMgMy42IGluIFJGQzQzNzkgd2hlcmUgk1RoZSBJbnRlcmZhY2UgYW5kIExhYmVsIFN0YWNrIFRM ViBNQVkgYmUgdmFsaWRhdGVklC4gCihPciBkb2VzIHRoZSBJbnRlcmZhY2UgaW4gdGhpcyBkcmFm dCByZWZlciB0byB0aGUgcGh5c2ljYWwgSUYgb3IgdGhlIHNlcnZlciBsYXllcj8pICIsIlllcywg dmVyaWZpY2F0aW9uIHN0ZXAgMSBpbiBzZWN0aW9uIDMuNC4zIHJlZmVycyB0byB0aGUgYW5hbG9n b3VzIHZlcmlmaWNhdGlvbiBkZXNjcmliZWQgaW4gUkZDIDQzNzksIHNlY3Rpb24gMy42LgoKV2Ug aGF2ZSBtYWRlIGFuIGFwcHJvcHJpYXRlIGNsYXJpZmljYXRpb24gaW4gdGhpcyBzZWN0aW9uIHRv IGluZGljYXRlIHRoYXQgdGhlIHZlcmlmaWNhdGlvbiBzdGVwcyBhcmUgcGVyZm9ybWVkIGJhc2Vk IG9uIHByb2NlZHVyZXMgaW4gUkZDIDQzNzkuIg0KNC4zLDE0LFRoZSByZWZlcmVuY2UgdG8gZHJh ZnQtaWV0Zi1wMm1wLWxzcC1waW5nIGlzIG5vcm1hdGl2ZSBhbmQgbm90IGluZm9ybWF0aXZlIGFz IHJlcG9ydGVkIGluIHNlY3Rpb24gOS4yLE1vdmVkIHRoZSByZWZlcmVuY2UgdG8gc2VjdGlvbiA5 LjEgKE5vcm1hdGl2ZSBSZWZlcmVuY2VzKQ0KLCwsDQosLCwNCiwsLA0KLCwsDQosLCwNCiwsLA0K LCwsDQosLCwNCiwsLA0KLCwsDQosLCwNCiwsLA0KLCwsDQosLCwNCiwsLA0KLCwsDQosLCwNCiws LA0KLCwsDQosLCwNCiwsLA0KLCwsDQo= --_004_C0AC8FAB6849AB4FADACCC70A949E2F10B0784813DEUSAACMS0701e_-- From internet-drafts@ietf.org Thu Jun 16 10:55: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 741F911E8131; Thu, 16 Jun 2011 10:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 ENNNX-LD45Cs; Thu, 16 Jun 2011 10:55:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D729611E8090; Thu, 16 Jun 2011 10:55:36 -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.55 Message-ID: <20110616175536.4843.16008.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 10:55:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-p2mp-14.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, 16 Jun 2011 17:55:37 -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-14.txt Pages : 39 Date : 2011-06-16 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-14.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-14.txt From loa@pi.nu Thu Jun 16 13:00: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 61B9211E8238 for ; Thu, 16 Jun 2011 13:00:39 -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 yuq++mQhRizn for ; Thu, 16 Jun 2011 13:00:37 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2530E11E8176 for ; Thu, 16 Jun 2011 13:00:36 -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 A061C514044; Thu, 16 Jun 2011 22:00:35 +0200 (CEST) Message-ID: <4DFA60E3.90807@pi.nu> Date: Thu, 16 Jun 2011 22:00:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" , Ross Callon , George Swallow , MPLS-TP ad hoc team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 16 Jun 2011 20:00:39 -0000 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 From swallow@cisco.com Thu Jun 16 14: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 6BB7611E82E3 for ; Thu, 16 Jun 2011 14:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 8qiNNbfWG82c for ; Thu, 16 Jun 2011 14:03:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92B11E8268 for ; Thu, 16 Jun 2011 14:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=3208; q=dns/txt; s=iport; t=1308258236; x=1309467836; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=amE+Xbtx+xEMfEf4CGvsdVNSnQqEN2tnNTJImXe6dSg=; b=GVg1/tXeRIU0pVlvhg+EAEdZc8WxLPDi7AmqieWn8xulDYHUMAabqDQD 3PdeH+1JgYEQjBt7nOX+u+u0SQBsj4A4z4nf3BnW3u3g2lUOuxYgC3MRU 2i6x/4aaKxx5aqcON98iAfMigetNrCuA5bbO8KqhCIcRjFIZPrT0e5qHI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAHBu+k2tJXHB/2dsb2JhbABEDpdgjiVjd4hzoimOfI8SgxqDDQSRWYRliy0 X-IronPort-AV: E=Sophos;i="4.65,377,1304294400"; d="scan'208";a="237114370" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2011 21:03:55 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5GL3thO017284; Thu, 16 Jun 2011 21:03:55 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); Thu, 16 Jun 2011 16:03:54 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Jun 2011 21:03:54 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 16 Jun 2011 17:03:52 -0400 From: George Swallow To: Vero Zheng , "'Alexander Vainshtein'" , "'Mach Chen'" , , BOCCI Matthew , Eric Gray Message-ID: Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAATuwUUw== In-Reply-To: <016401cc2b30$f5b1da40$e1158ec0$@com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Jun 2011 21:03:54.0907 (UTC) FILETIME=[E6E7BEB0:01CC2C68] Cc: 'Matthew Wright' Subject: Re: [mpls] Question about ICC 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, 16 Jun 2011 21:03:57 -0000 Vero - Carrier codes are done on a national basis. But I believe that ICCs are unique. My basis for this belief is the following on the ITU Web page. "A centralized List of ITU Carrier Codes (ICCs) has been created with the ITU/TSB as the repository. All domestic and international carriers are expected to register with ITU/TSB for a carrier code. Instead of individual operators sending their ICCs to the TSB for registration, the national regulatory authorities are requested to provide the validated codes and related information of domestic network operators directly to the TSB. This list may be used to identify the operators while completing layer 2 records= , related information, as explained in paragraph 8.3, 13.3 and 20.3 of ITU-T Recommendation M.1400." 8.3 has an example using unqualified (no country code) ICCs used to designate an international circuit. The odd thing is that I cannot find a pointer to the "centralized List of ITU Carrier Codes (ICCs)". ...George On 6/15/11 3:50 AM, "Vero Zheng" wrote: > Mach is correct on this. > ICC is unique within a Country. To make it globally unique, a Country Cod= e > is needed before the ICC. > Hope the authors of the identifiers draft are aware of this. >=20 > Several other drafts may also be affected. >=20 > Vero >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Alexander Vainshtein >> Sent: Friday, June 10, 2011 9:37 PM >> To: Mach Chen; mpls@ietf.org >> Cc: Matthew Wright >> Subject: Re: [mpls] Question about ICC >>=20 >> Mach, >> An excellent question! >>=20 >> lots of thanks for picking this up! >>=20 >> regards, >> Sasha >> ________________________________________ >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach >> Chen [mach.chen@huawei.com] >> Sent: Friday, June 10, 2011 4:48 AM >> To: mpls@ietf.org >> Cc: Matthew Wright >> Subject: [mpls] Question about ICC >>=20 >> Hi, >>=20 >> Are ICCs globally unique? >>=20 >> According to the definition of ICC in M.1400, it just says that ICCs are > unique >> within a country. And there is an example shows that different operators > could >> have the same ICC (e.g., Teleglobe International (UK) Ltd and T=E9l=E9globe >> Canada ULC have the ICC code:"TGB"). >>=20 >> So, if the ICCs are not globally unique, how to guarantee that the > ICC-based >> identifiers are globally unique? >>=20 >> Or maybe I missed something? >>=20 >>=20 >> Best regards, >> Mach >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=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 Telecom. If yo= u >> have received this transmission in error, please inform us by e-mail, > phone or >> fax, and then delete the original and all copies thereof. >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From nurit.sprecher@nsn.com Thu Jun 16 14:24:50 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 23CA111E8315 for ; Thu, 16 Jun 2011 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 cgEegbSJvU0g for ; Thu, 16 Jun 2011 14:24:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05E11E8316 for ; Thu, 16 Jun 2011 14:24:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5GLOOvs020416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 23:24:24 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5GLOKdo022985; Thu, 16 Jun 2011 23:24:23 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 23:24:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2011 23:19:41 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264040013BD@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAATuwUUwAAVi+Q References: <016401cc2b30$f5b1da40$e1158ec0$@com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext George Swallow" , "Vero Zheng" , "Alexander Vainshtein" , "Mach Chen" , , "BOCCI Matthew" , "Eric Gray" X-OriginalArrivalTime: 16 Jun 2011 21:24:20.0340 (UTC) FILETIME=[C151FB40:01CC2C6B] Cc: Matthew Wright Subject: Re: [mpls] Question about ICC 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, 16 Jun 2011 21:24:50 -0000 George, The codes are unique within a country.=20 As specified in M.1400, the national authority in each country is = requested to ensure that the Carrier Codes are unique within that = country.=20 That means that in order to have unique global identification you must = include the country code (which identifies the country in which the town = is located. Format: ISO 3166 three alpha-code). Best regards, Nurit P.S. note that where M.1400 refers to a transmission station in which = the circuit is terminating, they include the following elements: town = name, transmission station detail, operator ID (ICC) and country code.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext George Swallow Sent: Friday, June 17, 2011 12:04 AM To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; = BOCCI Matthew; Eric Gray Cc: 'Matthew Wright' Subject: Re: [mpls] Question about ICC Vero - Carrier codes are done on a national basis. But I believe that ICCs = are unique. My basis for this belief is the following on the ITU Web page. "A centralized List of ITU Carrier Codes (ICCs) has been created with = the ITU/TSB as the repository. All domestic and international carriers are expected to register with ITU/TSB for a carrier code. Instead of = individual operators sending their ICCs to the TSB for registration, the national regulatory authorities are requested to provide the validated codes and related information of domestic network operators directly to the TSB. = This list may be used to identify the operators while completing layer 2 = records, related information, as explained in paragraph 8.3, 13.3 and 20.3 of = ITU-T Recommendation M.1400." 8.3 has an example using unqualified (no country code) ICCs used to designate an international circuit. The odd thing is that I cannot find a pointer to the "centralized List = of ITU Carrier Codes (ICCs)". ...George On 6/15/11 3:50 AM, "Vero Zheng" wrote: > Mach is correct on this. > ICC is unique within a Country. To make it globally unique, a Country = Code > is needed before the ICC. > Hope the authors of the identifiers draft are aware of this. >=20 > Several other drafts may also be affected. >=20 > Vero >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >> Alexander Vainshtein >> Sent: Friday, June 10, 2011 9:37 PM >> To: Mach Chen; mpls@ietf.org >> Cc: Matthew Wright >> Subject: Re: [mpls] Question about ICC >>=20 >> Mach, >> An excellent question! >>=20 >> lots of thanks for picking this up! >>=20 >> regards, >> Sasha >> ________________________________________ >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach >> Chen [mach.chen@huawei.com] >> Sent: Friday, June 10, 2011 4:48 AM >> To: mpls@ietf.org >> Cc: Matthew Wright >> Subject: [mpls] Question about ICC >>=20 >> Hi, >>=20 >> Are ICCs globally unique? >>=20 >> According to the definition of ICC in M.1400, it just says that ICCs = are > unique >> within a country. And there is an example shows that different = operators > could >> have the same ICC (e.g., Teleglobe International (UK) Ltd and = T=E9l=E9globe >> Canada ULC have the ICC code:"TGB"). >>=20 >> So, if the ICCs are not globally unique, how to guarantee that the > ICC-based >> identifiers are globally unique? >>=20 >> Or maybe I missed something? >>=20 >>=20 >> Best regards, >> Mach >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=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 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. >>=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 From nurit.sprecher@nsn.com Thu Jun 16 14:26: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 59E9F11E8319 for ; Thu, 16 Jun 2011 14:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 poukpgulUHXb for ; Thu, 16 Jun 2011 14:26:15 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D7BD911E82F9 for ; Thu, 16 Jun 2011 14:26:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5GLQ1Tx003140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 23:26:01 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5GLQ1tP026946; Thu, 16 Jun 2011 23:26:01 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 23:26:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2011 23:25:58 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264040013BF@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAATuwUUwAAVi+QAABgsnA= References: <016401cc2b30$f5b1da40$e1158ec0$@com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext George Swallow" , "Vero Zheng" , "Alexander Vainshtein" , "Mach Chen" , , "BOCCI Matthew" , "Eric Gray" X-OriginalArrivalTime: 16 Jun 2011 21:26:00.0965 (UTC) FILETIME=[FD4C2350:01CC2C6B] Cc: Matthew Wright Subject: Re: [mpls] Question about ICC 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, 16 Jun 2011 21:26:16 -0000 I had a typo :-( See correction below .=20 -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 Sent: Friday, June 17, 2011 12:20 AM To: 'ext George Swallow'; Vero Zheng; 'Alexander Vainshtein'; 'Mach = Chen'; mpls@ietf.org; BOCCI Matthew; Eric Gray Cc: 'Matthew Wright' Subject: RE: [mpls] Question about ICC George, The codes are unique within a country.=20 As specified in M.1400, the national authority in each country is = requested to ensure that the Carrier Codes are unique within that = country.=20 That means that in order to have unique global identification you must = include the country code (which identifies the country in which the town = is located. Format: ISO 3166 three alpha-code). that means that in order to have a unique global identification you = must include the country code (which identifies the country of the = domestic network operator. Format: ISO 3166 three alpha-code). Best regards, Nurit P.S. note that where M.1400 refers to a transmission station in which = the circuit is terminating, they include the following elements: town = name, transmission station detail, operator ID (ICC) and country code.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext George Swallow Sent: Friday, June 17, 2011 12:04 AM To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; = BOCCI Matthew; Eric Gray Cc: 'Matthew Wright' Subject: Re: [mpls] Question about ICC Vero - Carrier codes are done on a national basis. But I believe that ICCs = are unique. My basis for this belief is the following on the ITU Web page. "A centralized List of ITU Carrier Codes (ICCs) has been created with = the ITU/TSB as the repository. All domestic and international carriers are expected to register with ITU/TSB for a carrier code. Instead of = individual operators sending their ICCs to the TSB for registration, the national regulatory authorities are requested to provide the validated codes and related information of domestic network operators directly to the TSB. = This list may be used to identify the operators while completing layer 2 = records, related information, as explained in paragraph 8.3, 13.3 and 20.3 of = ITU-T Recommendation M.1400." 8.3 has an example using unqualified (no country code) ICCs used to designate an international circuit. The odd thing is that I cannot find a pointer to the "centralized List = of ITU Carrier Codes (ICCs)". ...George On 6/15/11 3:50 AM, "Vero Zheng" wrote: > Mach is correct on this. > ICC is unique within a Country. To make it globally unique, a Country = Code > is needed before the ICC. > Hope the authors of the identifiers draft are aware of this. >=20 > Several other drafts may also be affected. >=20 > Vero >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >> Alexander Vainshtein >> Sent: Friday, June 10, 2011 9:37 PM >> To: Mach Chen; mpls@ietf.org >> Cc: Matthew Wright >> Subject: Re: [mpls] Question about ICC >>=20 >> Mach, >> An excellent question! >>=20 >> lots of thanks for picking this up! >>=20 >> regards, >> Sasha >> ________________________________________ >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach >> Chen [mach.chen@huawei.com] >> Sent: Friday, June 10, 2011 4:48 AM >> To: mpls@ietf.org >> Cc: Matthew Wright >> Subject: [mpls] Question about ICC >>=20 >> Hi, >>=20 >> Are ICCs globally unique? >>=20 >> According to the definition of ICC in M.1400, it just says that ICCs = are > unique >> within a country. And there is an example shows that different = operators > could >> have the same ICC (e.g., Teleglobe International (UK) Ltd and = T=E9l=E9globe >> Canada ULC have the ICC code:"TGB"). >>=20 >> So, if the ICCs are not globally unique, how to guarantee that the > ICC-based >> identifiers are globally unique? >>=20 >> Or maybe I missed something? >>=20 >>=20 >> Best regards, >> Mach >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=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 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. >>=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 From chenying220@huawei.com Thu Jun 16 18:50: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 2C8D211E812C for ; Thu, 16 Jun 2011 18:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+a-EISZl3Z4 for ; Thu, 16 Jun 2011 18:50:45 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1611E810C for ; Thu, 16 Jun 2011 18:50:45 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMW00ENNVSIGY@szxga03-in.huawei.com> for mpls@ietf.org; Fri, 17 Jun 2011 09:50:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMW00MPDVSIVQ@szxga03-in.huawei.com> for mpls@ietf.org; Fri, 17 Jun 2011 09:50:42 +0800 (CST) Received: from c59992d ([10.112.114.157]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMW003S3VSF0M@szxml04-in.huawei.com> for mpls@ietf.org; Fri, 17 Jun 2011 09:50:42 +0800 (CST) Date: Fri, 17 Jun 2011 09:50:39 +0800 From: Emily Chen To: rajiva@cisco.com, pmohapat@cisco.com, bobthomas@alum.mit.edu Message-id: <88046B003D4B4A8396BC624B66F6CEDD@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110615152908.22057.55274.idtracker@ietfa.amsl.com> Cc: mpls@ietf.org, stbryant@cisco.com Subject: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5919 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, 17 Jun 2011 01:50:46 -0000 Dear all, AD queried me yesterday for the IPR claim, actually I was also surprised by the claim when getting the email notification from IETF Secretariat. I was not aware of existing of such patent, sorry for that! After I got the notification email, I queried IPR department within my company. They said they were having an IPR review group (virtual group with members from various functions) to do such patent review against published or in-development standards. Once they found one, they would claim asap according to corporate procedure. That is all what I know about it. Sorry for the confusion caused. As one of the author of RFC 5919, I am looking forward to widely adoption and deployment of the technology, hope the fact of existing IPR not prevent the using of the RFC. Best regards, Emily ----- Original Message ----- From: "IETF Secretariat" To: ; Cc: ; ; ; ; Sent: Wednesday, June 15, 2011 11:29 PM Subject: [mpls] IPR Disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 5919 > > Dear Rajiv Asati, Emily Chen, Pradosh Mohapatra, Bob Thomas: > > An IPR disclosure that pertains to your RFC entitled "Signaling LDP Label > Advertisement Completion" (RFC5919) was submitted to the IETF Secretariat on > 2011-06-14 and has been posted on the "IETF Page of Intellectual Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1572/). The title of the IPR > disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC > 5919.""); > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From binnyjeshan@gmail.com Thu Jun 16 23:04:32 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 370DC1F0C4F for ; Thu, 16 Jun 2011 23:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 odLa6-lg7ftS for ; Thu, 16 Jun 2011 23:04:31 -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 1D22F1F0C3B for ; Thu, 16 Jun 2011 23:04:30 -0700 (PDT) Received: by ywp31 with SMTP id 31so1590337ywp.31 for ; Thu, 16 Jun 2011 23:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EHoknlJlQT4ZpphrA0fwK3E5JMrzviu9I5xi5ritwPI=; b=YbGDlECMXNoxTnbbqDOExFv/4ZApckSpLlSyOWc+VwlVnZFrVapflzr7A0i4bs1g/g dbPftFhWEwkzLMBGFVF74pBUSemklp7pY3fWFkV0SJ1d7CHSTo4fHfS7yLu3TmLZ04cJ LvX+unArTfURtJBM/XVzbN0N3PTNXiTMawYOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xJMhUnV2KsoYXItCTN+tgzQise5XLShsHpNypgKHRnbvTEuebqn7hZXHYL5Jx0u+VE 2Vp0Fq24Thdpmj2/9kY/nMFd7+Jf0cR1wxLUaQzaf1W98zzaQF2uyUrbr/SdmwolfsSx VcUaVPGLJ4+Ei+U6gmgNqZtXOZ9Kof8CWrbK8= MIME-Version: 1.0 Received: by 10.90.62.4 with SMTP id k4mr2130930aga.53.1308290668733; Thu, 16 Jun 2011 23:04:28 -0700 (PDT) Received: by 10.90.87.7 with HTTP; Thu, 16 Jun 2011 23:04:28 -0700 (PDT) In-Reply-To: <4DFA60E3.90807@pi.nu> References: <4DFA60E3.90807@pi.nu> Date: Fri, 17 Jun 2011 11:34:28 +0530 Message-ID: From: binny jeshan To: Loa Andersson Content-Type: multipart/alternative; boundary=0016364edaa892a63f04a5e22892 Cc: Ross Callon , "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 17 Jun 2011 06:04:32 -0000 --0016364edaa892a63f04a5e22892 Content-Type: text/plain; charset=ISO-8859-1 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 > --0016364edaa892a63f04a5e22892 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 als= o be included in the FEC TLV structure?

            Also, wouldn't it be cle= ar if the usage of EXP bits in (PHB consideration) is also explicitly defin= ed somewhere around the responder procedures?

            Thanks,
            Binny.

            On 17 June 2011 01:= 30, Loa Andersson <loa@pi= .nu> 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:
            ht= tp://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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
            Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
            Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
            =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
            _______________________________________________
            mpls mailing list
            mpls@ietf.org
            ht= tps://www.ietf.org/mailman/listinfo/mpls

            --0016364edaa892a63f04a5e22892-- From loa@pi.nu Fri Jun 17 01:28: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 D117122800D for ; Fri, 17 Jun 2011 01:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, 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 zKEtGhBNXSvJ for ; Fri, 17 Jun 2011 01:28:14 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF7228005 for ; Fri, 17 Jun 2011 01:28:14 -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 C6CDC514044; Fri, 17 Jun 2011 10:28:12 +0200 (CEST) Message-ID: <4DFB101E.2070907@pi.nu> Date: Fri, 17 Jun 2011 10:28:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mpls@ietf.org References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> In-Reply-To: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: [mpls] This poll has ended: Re: poll on draft-vkst-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: Fri, 17 Jun 2011 08:28:14 -0000 Working Group, Some time ago we polled draft-vkst-mpls-tp-te-mib-00.txt to see if it could be adapted as a working group document. Wew had good support for adopting the draft as a working group document. However as part of the poll we alos asked folks with MIB-doctor background to review the document, they came up with comments that the working group chairs wanted to have addressed before accepting the document. These comments has now been addressed (in version -02) and the working group chairs has decided to adopt the document as a new mpls working group document. COuld the authors please publish the new working group document as draft-ietf-mpls-tp-te-mib-00.txt without any other changes than file name and dates. /Loa On 2011-05-03 19:47, loa@pi.nu wrote: > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends 2011-05-18. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- 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 loa@pi.nu Fri Jun 17 03:11: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 7720111E8078 for ; Fri, 17 Jun 2011 03:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 hmWT9H5a9yTo for ; Fri, 17 Jun 2011 03:11:39 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id C3B999E800D for ; Fri, 17 Jun 2011 03:11:38 -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 207E9514044; Fri, 17 Jun 2011 12:11:36 +0200 (CEST) Message-ID: <4DFB285A.4020303@pi.nu> Date: Fri, 17 Jun 2011 12:11:38 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-raza-mpls-ldp-ip-pw-capability@tools.ietf.org References: <4DE795A3.5050106@pi.nu> In-Reply-To: <4DE795A3.5050106@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon Subject: Re: [mpls] poll on draft-raza-mpls-ldp-ip-pw-capability-01 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, 17 Jun 2011 10:11:39 -0000 Working Group, this Call For Adaption (aka "poll") has ended. We have a new working group document! Could the authors please republish the draft as draft-ietf-mpls-ldp-ip-pw-capability-00.txt without any othr change than dates and file name. /Loa for the mpls wg co-chairs On 2011-06-02 15:52, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-raza-mpls-ldp-ip-pw-capability-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends 2011-06-16. > > /Loa > > -- 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 wnattras@telcordia.com Fri Jun 17 06:12: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 E83001F0C3F for ; Fri, 17 Jun 2011 06:12:09 -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 Xi8ty1KGo8w6 for ; Fri, 17 Jun 2011 06:12:08 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietfa.amsl.com (Postfix) with ESMTP id B08A71F0C48 for ; Fri, 17 Jun 2011 06:12:08 -0700 (PDT) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id p5HDBnYU015185; Fri, 17 Jun 2011 09:11:50 -0400 (EDT) X-AuditID: 80602530-b7c10ae000000a2b-94-4dfb528ec8c4 Received: from rrc-dte-exhb1.dte.telcordia.com (rrc-dte-exhb1.cc.telcordia.com [128.96.20.12]) by pya-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id 95.93.02603.E825BFD4; Fri, 17 Jun 2011 09:11:42 -0400 (EDT) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Fri, 17 Jun 2011 09:11:49 -0400 From: "Nattrass, William W" To: "'George Swallow'" , "'Vero Zheng'" , "'Alexander Vainshtein'" , "'Mach Chen'" , "'mpls@ietf.org'" , "'BOCCI Matthew'" , "'Eric Gray'" Date: Fri, 17 Jun 2011 09:11:49 -0400 Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAATuwUUwAhL27g Message-ID: <5CFF94AC6128EA478EB1B82775E1B6A726580F363C@rrc-dte-exmb1.dte.telcordia.com> References: <016401cc2b30$f5b1da40$e1158ec0$@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'Matthew Wright' Subject: Re: [mpls] Question about ICC 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, 17 Jun 2011 13:12:10 -0000 Who maintains the list? =20 Is it being said that the ITU is a maintenance agency to maintain a listing= ? If so, how does ITU receive remuneration for the work? Bill -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Thursday, June 16, 2011 5:04 PM To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; BOCCI M= atthew; Eric Gray Cc: 'Matthew Wright' Subject: Re: [mpls] Question about ICC Vero - Carrier codes are done on a national basis. But I believe that ICCs are unique. My basis for this belief is the following on the ITU Web page. "A centralized List of ITU Carrier Codes (ICCs) has been created with the ITU/TSB as the repository. All domestic and international carriers are expected to register with ITU/TSB for a carrier code. Instead of individual operators sending their ICCs to the TSB for registration, the national regulatory authorities are requested to provide the validated codes and related information of domestic network operators directly to the TSB. This list may be used to identify the operators while completing layer 2 records= , related information, as explained in paragraph 8.3, 13.3 and 20.3 of ITU-T Recommendation M.1400." 8.3 has an example using unqualified (no country code) ICCs used to designate an international circuit. The odd thing is that I cannot find a pointer to the "centralized List of ITU Carrier Codes (ICCs)". ...George On 6/15/11 3:50 AM, "Vero Zheng" wrote: > Mach is correct on this. > ICC is unique within a Country. To make it globally unique, a Country Cod= e > is needed before the ICC. > Hope the authors of the identifiers draft are aware of this. >=20 > Several other drafts may also be affected. >=20 > Vero >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Alexander Vainshtein >> Sent: Friday, June 10, 2011 9:37 PM >> To: Mach Chen; mpls@ietf.org >> Cc: Matthew Wright >> Subject: Re: [mpls] Question about ICC >>=20 >> Mach, >> An excellent question! >>=20 >> lots of thanks for picking this up! >>=20 >> regards, >> Sasha >> ________________________________________ >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach >> Chen [mach.chen@huawei.com] >> Sent: Friday, June 10, 2011 4:48 AM >> To: mpls@ietf.org >> Cc: Matthew Wright >> Subject: [mpls] Question about ICC >>=20 >> Hi, >>=20 >> Are ICCs globally unique? >>=20 >> According to the definition of ICC in M.1400, it just says that ICCs are > unique >> within a country. And there is an example shows that different operators > could >> have the same ICC (e.g., Teleglobe International (UK) Ltd and T=E9l=E9gl= obe >> Canada ULC have the ICC code:"TGB"). >>=20 >> So, if the ICCs are not globally unique, how to guarantee that the > ICC-based >> identifiers are globally unique? >>=20 >> Or maybe I missed something? >>=20 >>=20 >> Best regards, >> Mach >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=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 Telecom. If yo= u >> have received this transmission in error, please inform us by e-mail, > phone or >> fax, and then delete the original and all copies thereof. >>=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 From swallow@cisco.com Fri Jun 17 06:12: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 3A01911E8088 for ; Fri, 17 Jun 2011 06:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 egwP0Aj1bLQv for ; Fri, 17 Jun 2011 06:12:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4093F11E8070 for ; Fri, 17 Jun 2011 06:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=5284; q=dns/txt; s=iport; t=1308316359; x=1309525959; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ZuX8VKUYgKWhowgvX41BGnTlynKIskCza3+GOJNW7nQ=; b=ctmT144iBMzti7pVhtxF1FnttrdseCH2qKx3qCcgKB/3tReK9sWbIALM Hz3AqvWfsUJtVjgVeEB187+JT1ac53th9NNZpTN3ZFY+dvsrkNgdRhbOs RJq50b9KyEkG1vpje1lArQu6FC6WPRDZUMi2J6izX6Ofq7w6UtqGBA+sL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAAJS+02tJV2b/2dsb2JhbABEDpdljiVkd4hzoGWOfo8fgxqDDQSRXoRoizE X-IronPort-AV: E=Sophos;i="4.65,381,1304294400"; d="scan'208";a="379032581" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2011 13:12:38 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5HDCcS9031418; Fri, 17 Jun 2011 13:12:38 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 08:12:37 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jun 2011 13:12:36 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 17 Jun 2011 09:12:35 -0400 From: George Swallow To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , Vero Zheng , Alexander Vainshtein , Mach Chen , , BOCCI Matthew , Eric Gray Message-ID: Thread-Topic: [mpls] Question about ICC Thread-Index: AcwnEHMBwgfP9jvnQ2GGwIqNu7e28AAYxWjIAO5rDgAATuwUUwAAVi+QAABgsnAAIR4gRQ== In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264040013BF@DEMUEXC014.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Jun 2011 13:12:37.0919 (UTC) FILETIME=[3AEB8AF0:01CC2CF0] Cc: Matthew Wright Subject: Re: [mpls] Question about ICC 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, 17 Jun 2011 13:12:40 -0000 Thanks Nurit. Guess Y.1731 has a problem here as well! ...George On 6/16/11 5:25 PM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" wrote: > I had a typo :-( > See correction below . >=20 > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: Friday, June 17, 2011 12:20 AM > To: 'ext George Swallow'; Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'= ; > mpls@ietf.org; BOCCI Matthew; Eric Gray > Cc: 'Matthew Wright' > Subject: RE: [mpls] Question about ICC >=20 > George, > The codes are unique within a country. > As specified in M.1400, the national authority in each country is request= ed to > ensure that the Carrier Codes are unique within that country. > That means that in order to have unique global identification you must in= clude > the country code (which identifies the country in which the town is locat= ed. > Format: ISO 3166 three alpha-code). >=20 > that means that in order to have a unique global identification you = must > include the country code (which identifies the country of the domestic ne= twork > operator. Format: ISO 3166 three alpha-code). >=20 > Best regards, > Nurit >=20 > P.S. note that where M.1400 refers to a transmission station in which the > circuit is terminating, they include the following elements: town name, > transmission station detail, operator ID (ICC) and country code. >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of e= xt > George Swallow > Sent: Friday, June 17, 2011 12:04 AM > To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; mpls@ietf.org; BOCCI > Matthew; Eric Gray > Cc: 'Matthew Wright' > Subject: Re: [mpls] Question about ICC >=20 > Vero - >=20 > Carrier codes are done on a national basis. But I believe that ICCs are > unique. My basis for this belief is the following on the ITU Web page. >=20 > "A centralized List of ITU Carrier Codes (ICCs) has been created with the > ITU/TSB as the repository. All domestic and international carriers are > expected to register with ITU/TSB for a carrier code. Instead of individu= al > operators sending their ICCs to the TSB for registration, the national > regulatory authorities are requested to provide the validated codes and > related information of domestic network operators directly to the TSB. Th= is > list may be used to identify the operators while completing layer 2 recor= ds, > related information, as explained in paragraph 8.3, 13.3 and 20.3 of ITU-= T > Recommendation M.1400." >=20 > 8.3 has an example using unqualified (no country code) ICCs used to > designate an international circuit. >=20 > The odd thing is that I cannot find a pointer to the "centralized List of > ITU Carrier Codes (ICCs)". >=20 > ...George >=20 >=20 > On 6/15/11 3:50 AM, "Vero Zheng" wrote: >=20 >> Mach is correct on this. >> ICC is unique within a Country. To make it globally unique, a Country Co= de >> is needed before the ICC. >> Hope the authors of the identifiers draft are aware of this. >>=20 >> Several other drafts may also be affected. >>=20 >> Vero >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Alexander Vainshtein >>> Sent: Friday, June 10, 2011 9:37 PM >>> To: Mach Chen; mpls@ietf.org >>> Cc: Matthew Wright >>> Subject: Re: [mpls] Question about ICC >>>=20 >>> Mach, >>> An excellent question! >>>=20 >>> lots of thanks for picking this up! >>>=20 >>> regards, >>> Sasha >>> ________________________________________ >>> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Mach >>> Chen [mach.chen@huawei.com] >>> Sent: Friday, June 10, 2011 4:48 AM >>> To: mpls@ietf.org >>> Cc: Matthew Wright >>> Subject: [mpls] Question about ICC >>>=20 >>> Hi, >>>=20 >>> Are ICCs globally unique? >>>=20 >>> According to the definition of ICC in M.1400, it just says that ICCs ar= e >> unique >>> within a country. And there is an example shows that different operator= s >> could >>> have the same ICC (e.g., Teleglobe International (UK) Ltd and T=E9l=E9globe >>> Canada ULC have the ICC code:"TGB"). >>>=20 >>> So, if the ICCs are not globally unique, how to guarantee that the >> ICC-based >>> identifiers are globally unique? >>>=20 >>> Or maybe I missed something? >>>=20 >>>=20 >>> Best regards, >>> Mach >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=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 Telecom. If y= ou >>> have received this transmission in error, please inform us by e-mail, >> phone or >>> fax, and then delete the original and all copies thereof. >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From swallow@cisco.com Fri Jun 17 06:19: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 956DD11E8088 for ; Fri, 17 Jun 2011 06:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 Sc-XMF8v43si for ; Fri, 17 Jun 2011 06:19:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id CE82D11E8070 for ; Fri, 17 Jun 2011 06:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=864; q=dns/txt; s=iport; t=1308316743; x=1309526343; h=date:subject:from:to:cc:message-id:mime-version; bh=TTZtMGHg/kOFa3joNqJEt4fYnIvWGf25f6Rj9Ky3/h4=; b=RVSCx0kEOQ9P57kC3PUD4lwnp+Db374qS7ugVhp1cOIA50gK2/FWl0zK 1+4YOIS4LYYXMA6sy2FGGk0+BlZabq28RCSD1NN+YchKfCjaBMTyl1iet v1gJRezxhL2Bn8US6sip/p+wopNQxND4S49+IMXvZ3SXpdLNMRB7+H75M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGpT+02tJXHB/2dsb2JhbABSglGjOWR3qVqeHYYnBJFehGiLMQ X-IronPort-AV: E=Sophos;i="4.65,381,1304294400"; d="scan'208,217";a="287563182" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2011 13:19:03 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5HDJ3Pr030265; Fri, 17 Jun 2011 13:19:03 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); Fri, 17 Jun 2011 08:19:02 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jun 2011 13:19:02 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 17 Jun 2011 09:19:01 -0400 From: George Swallow To: "BUSI, ITALO (ITALO)" , "Malcolm.BETTS@zte.com.cn" , Huub van Helvoort Message-ID: Thread-Topic: ICC and CC Thread-Index: Acws8R9BP4vhbe21L0mJVMv//H110w== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3391147141_40274444" X-OriginalArrivalTime: 17 Jun 2011 13:19:02.0765 (UTC) FILETIME=[204E61D0:01CC2CF1] Cc: mpls@ietf.org Subject: [mpls] ICC and CC 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, 17 Jun 2011 13:19:04 -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_3391147141_40274444 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Huub, Italo, Malcolm, I look to you guys as the authority on this. Should I prefix the ICC with a CC? Thanks, ...George --B_3391147141_40274444 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable ICC and CC Huub, I= talo, Malcolm,

            I look to you guys as the authority on this.  Should I prefix the ICC = with a CC?

            Thanks,

            ...George             --B_3391147141_40274444-- From ietf-ipr@ietf.org Fri Jun 17 07:17: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 64DD911E8193; Fri, 17 Jun 2011 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 1i6FmMcAB3KW; Fri, 17 Jun 2011 07:17:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14B011E80C8; Fri, 17 Jun 2011 07:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: , stbryant@cisco.com, X-Test-IDTracker: no Message-ID: <20110617141700.3225.45725.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 07:17:00 -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-loss-delay-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: Fri, 17 Jun 2011 14:17:04 -0000 Dear Dan Frost, Stewart Bryant: An IPR disclosure that pertains to your Internet-Draft entitled "Packet Lo= ss and Delay Measurement for MPLS Networks" (draft-ietf-mpls-loss-delay) was submitted to the IETF Secretariat on 2011-06-17 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1574/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mp= ls- loss-delay-03.""); The IETF Secretariat From internet-drafts@ietf.org Fri Jun 17 07:24: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 7B3F311E818F; Fri, 17 Jun 2011 07:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 TdeuohN4pOIc; Fri, 17 Jun 2011 07:24:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7549111E81A3; Fri, 17 Jun 2011 07:24:45 -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.55 Message-ID: <20110617142445.3310.42928.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 07:24:45 -0700 Cc: mpls@ietf.org Subject: [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: Fri, 17 Jun 2011 14:24:46 -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 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 From rajiva@cisco.com Fri Jun 17 07:48: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 6836511E8129 for ; Fri, 17 Jun 2011 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pSTQ2SYlURKB for ; Fri, 17 Jun 2011 07:48:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id C369B11E807F for ; Fri, 17 Jun 2011 07:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2567; q=dns/txt; s=iport; t=1308322109; x=1309531709; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Gkd+WZB7f65XsitE5urt3uRJTDYMZ/uXrTC/BiPMt1c=; b=HUnAYpqqlQRftT+4NQ4kjQQmDVF549g6wLjzcnPq8ePbpbKo9K17dLB+ LkJbsoMUsfH5NTqrHb8332fft/bTCIeEbg+iWy9qBzhc+88hSo20u+Tvr DvQGDXakZk6JigejeSjCeRGG3QR8EKPp/iJpRvYJvUOpE6lp48rFkzVUA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAIpo+02tJXHA/2dsb2JhbABSEJdVjwl3qWWeEoYnBIcgjyaKX1Q X-IronPort-AV: E=Sophos;i="4.65,381,1304294400"; d="scan'208";a="358652699" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-5.cisco.com with ESMTP; 17 Jun 2011 14:48:28 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5HEmSb7018271; Fri, 17 Jun 2011 14:48:28 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 09:48:27 -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, 17 Jun 2011 09:48:26 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C053FB2B1@XMB-RCD-111.cisco.com> In-Reply-To: <88046B003D4B4A8396BC624B66F6CEDD@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5919 Thread-Index: AcwskPup9nKh1IfbRkSoYR5B/dtmvwAbHV9Q References: <20110615152908.22057.55274.idtracker@ietfa.amsl.com> <88046B003D4B4A8396BC624B66F6CEDD@china.huawei.com> From: "Rajiv Asati (rajiva)" To: "Emily Chen" , "Pradosh Mohapatra (pmohapat)" , X-OriginalArrivalTime: 17 Jun 2011 14:48:27.0967 (UTC) FILETIME=[9E373CF0:01CC2CFD] Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5919 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, 17 Jun 2011 14:48:30 -0000 Emily, I was surprised as well. Do you have a pointer to the patent? https://datatracker.ietf.org/ipr/1572/ doesn't give much info, nor does google. Cheers, Rajiv > -----Original Message----- > From: Emily Chen [mailto:chenying220@huawei.com] > Sent: Thursday, June 16, 2011 9:51 PM > To: Rajiv Asati (rajiva); Pradosh Mohapatra (pmohapat); bobthomas@alum.mit.edu > Cc: Adrian Farrel; Stewart Bryant (stbryant); mpls@ietf.org > Subject: Re: [mpls] IPR Disclosure: Huawei Technologies Co.,Ltd's Statement > about IPR related to RFC 5919 >=20 > Dear all, >=20 > AD queried me yesterday for the IPR claim, actually I was also surprised by > the claim when getting the email notification from IETF Secretariat. I was not > aware of existing of such patent, sorry for that! >=20 > After I got the notification email, I queried IPR department within my > company. They said they were having an IPR review group (virtual group with > members from various functions) to do such patent review against published or > in-development standards. Once they found one, they would claim asap according > to corporate procedure. That is all what I know about it. >=20 > Sorry for the confusion caused. As one of the author of RFC 5919, I am looking > forward to widely adoption and deployment of the technology, hope the fact of > existing IPR not prevent the using of the RFC. >=20 >=20 > Best regards, > Emily >=20 > ----- Original Message ----- > From: "IETF Secretariat" > To: ; > Cc: ; ; ; > ; > Sent: Wednesday, June 15, 2011 11:29 PM > Subject: [mpls] IPR Disclosure: Huawei Technologies Co.,Ltd's Statement about > IPR related to RFC 5919 >=20 >=20 > > > > Dear Rajiv Asati, Emily Chen, Pradosh Mohapatra, Bob Thomas: > > > > An IPR disclosure that pertains to your RFC entitled "Signaling LDP Label > > Advertisement Completion" (RFC5919) was submitted to the IETF Secretariat on > > 2011-06-14 and has been posted on the "IETF Page of Intellectual Property > Rights > > Disclosures" (https://datatracker.ietf.org/ipr/1572/). The title of the IPR > > disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to > RFC > > 5919.""); > > > > The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From internet-drafts@ietf.org Fri Jun 17 08:12:25 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 ACEAB11E81AD; Fri, 17 Jun 2011 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 CRJjVImM5jak; Fri, 17 Jun 2011 08:12:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3604911E809C; Fri, 17 Jun 2011 08:12:25 -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.55 Message-ID: <20110617151225.5292.65749.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 08:12:25 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-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: Fri, 17 Jun 2011 15:12:25 -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 : LDP IP and PW Capability Author(s) : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-00.txt Pages : 11 Date : 2011-06-17 Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN/PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces its "incapability" = or disability or non-support for IP label switching or L2VPN/PW application, hence disabling corresponding application state exchange over the established LDP session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ip-pw-capability-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-ldp-ip-pw-capability-00.= txt From swallow@cisco.com Fri Jun 17 08:32: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 7A73B11E8179 for ; Fri, 17 Jun 2011 08:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 VIye8hRyPJfK for ; Fri, 17 Jun 2011 08:32:45 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 89AC611E8122 for ; Fri, 17 Jun 2011 08:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=2106; q=dns/txt; s=iport; t=1308324765; x=1309534365; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=DUErbtIFeZC+f09Qd0Vv/MaZO8rO6Zr1mN64iWyHLe8=; b=XT/UpAhqA0MYRQryrbIWvKfO7cKShjN9wEKAEH+q7UIUCs0nePnVsSgK 2bUP1Obhuwlc+V19/ambGX/s/qOom/JgDHhJ6fno0z5Zr0XsV4ZjC29FK RYh5UaWU4uQvV3dKvMyXPbgeWeQNSgsiDS7/JyMZD20N4V2zYgg9VW6Ho I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA5z+02tJV2d/2dsb2JhbABSglGjRmR3iHOhPZ4ThicEkV6EaIsx X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208,217";a="287574946" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2011 15:32:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5HFWhkD002371; Fri, 17 Jun 2011 15:32:44 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 10:32:43 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jun 2011 15:32:43 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 17 Jun 2011 11:32:41 -0400 From: George Swallow To: George Swallow , "BUSI, ITALO (ITALO)" , "Malcolm.BETTS@zte.com.cn" , Huub van Helvoort Message-ID: Thread-Topic: [mpls] ICC and CC Thread-Index: Acws8R9BP4vhbe21L0mJVMv//H110wAEqxJq In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3391155162_40753296" X-OriginalArrivalTime: 17 Jun 2011 15:32:43.0800 (UTC) FILETIME=[CD373180:01CC2D03] Cc: mpls@ietf.org Subject: Re: [mpls] ICC and CC 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, 17 Jun 2011 15:32:46 -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_3391155162_40753296 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit And if so, do you have a suggestion for the combined fields? I thought ICC stood for International Carrier Code. M.1600 does not expand the acronym. ...George On 6/17/11 9:19 AM, "George Swallow" wrote: > Huub, Italo, Malcolm, > > I look to you guys as the authority on this. Should I prefix the ICC with a > CC? > > Thanks, > > ...George > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --B_3391155162_40753296 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls] ICC and CC And if = so, do you have a suggestion for the combined fields?

            I thought ICC stood for International Carrier Code.   M.16= 00 does not expand the acronym.  

            ...George

            On 6/17/11 9:19 AM, "George Swallow" <swallow@cisco.com> wrote:

            Huub, Italo, Malcolm,

            I look to you guys as the authority on this.  Should I prefix the ICC = with a CC?

            Thanks,

            ...George
            _____________________________________= __________
            mpls mailing list
            mpls@ietf.org
            https://www.ietf.org/m= ailman/listinfo/mpls
            --B_3391155162_40753296-- From adrian@olddog.co.uk Fri Jun 17 09:37: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 5661611E815A for ; Fri, 17 Jun 2011 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 YCI57YIg5jiV for ; Fri, 17 Jun 2011 09:37:03 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 13AF811E80E2 for ; Fri, 17 Jun 2011 09:37:02 -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 p5HGaqAo003735; Fri, 17 Jun 2011 17:36:52 +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 p5HGaosP003726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2011 17:36:51 +0100 From: "Adrian Farrel" To: "'Rajiv Asati \(rajiva\)'" , "'Emily Chen'" , "'Pradosh Mohapatra \(pmohapat\)'" , References: <20110615152908.22057.55274.idtracker@ietfa.amsl.com> <88046B003D4B4A8396BC624B66F6CEDD@china.huawei.com> <067E6CE33034954AAC05C9EC85E2577C053FB2B1@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C053FB2B1@XMB-RCD-111.cisco.com> Date: Fri, 17 Jun 2011 17:36:44 +0100 Message-ID: <17bb01cc2d0c$befcfc90$3cf6f5b0$@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: AQJd8c0VPXELmFW7+02QNKcoMjeM/AJQF75IAZS/nOSTfw5K0A== Content-Language: en-gb Cc: mpls@ietf.org, "'Stewart Bryant \(stbryant\)'" Subject: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5919 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: Fri, 17 Jun 2011 16:37:04 -0000 Hi, https://data.epo.org/publication-server/getpdf.jsp?pn=2222037&ki=A1&cc=EP seems to be the European version of the same. A > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: 17 June 2011 15:48 > To: Emily Chen; Pradosh Mohapatra (pmohapat); bobthomas@alum.mit.edu > Cc: Adrian Farrel; Stewart Bryant (stbryant); mpls@ietf.org > Subject: RE: [mpls] IPR Disclosure: Huawei Technologies Co.,Ltd's Statement > about IPR related to RFC 5919 > > Emily, > > I was surprised as well. > > Do you have a pointer to the patent? > > https://datatracker.ietf.org/ipr/1572/ doesn't give much info, nor does > google. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: Emily Chen [mailto:chenying220@huawei.com] > > Sent: Thursday, June 16, 2011 9:51 PM > > To: Rajiv Asati (rajiva); Pradosh Mohapatra (pmohapat); > bobthomas@alum.mit.edu > > Cc: Adrian Farrel; Stewart Bryant (stbryant); mpls@ietf.org > > Subject: Re: [mpls] IPR Disclosure: Huawei Technologies Co.,Ltd's > Statement > > about IPR related to RFC 5919 > > > > Dear all, > > > > AD queried me yesterday for the IPR claim, actually I was also > surprised by > > the claim when getting the email notification from IETF Secretariat. I > was not > > aware of existing of such patent, sorry for that! > > > > After I got the notification email, I queried IPR department within my > > company. They said they were having an IPR review group (virtual group > with > > members from various functions) to do such patent review against > published or > > in-development standards. Once they found one, they would claim asap > according > > to corporate procedure. That is all what I know about it. > > > > Sorry for the confusion caused. As one of the author of RFC 5919, I am > looking > > forward to widely adoption and deployment of the technology, hope the > fact of > > existing IPR not prevent the using of the RFC. > > > > > > Best regards, > > Emily > > > > ----- Original Message ----- > > From: "IETF Secretariat" > > To: ; > > Cc: ; ; ; > > ; > > Sent: Wednesday, June 15, 2011 11:29 PM > > Subject: [mpls] IPR Disclosure: Huawei Technologies Co.,Ltd's > Statement about > > IPR related to RFC 5919 > > > > > > > > > > Dear Rajiv Asati, Emily Chen, Pradosh Mohapatra, Bob Thomas: > > > > > > An IPR disclosure that pertains to your RFC entitled "Signaling LDP > Label > > > Advertisement Completion" (RFC5919) was submitted to the IETF > Secretariat on > > > 2011-06-14 and has been posted on the "IETF Page of Intellectual > Property > > Rights > > > Disclosures" (https://datatracker.ietf.org/ipr/1572/). The title of > the IPR > > > disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR > related to > > RFC > > > 5919.""); > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > From adrian@olddog.co.uk Fri Jun 17 09:52: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 ECF7511E81DD for ; Fri, 17 Jun 2011 09:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 zGaOZHuJlM8g for ; Fri, 17 Jun 2011 09:52:13 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id B6A7A11E81C7 for ; Fri, 17 Jun 2011 09:52:12 -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 p5HGqAK8011250 for ; Fri, 17 Jun 2011 17:52:10 +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 p5HGq9Js011244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 17 Jun 2011 17:52:10 +0100 From: "Adrian Farrel" To: Date: Fri, 17 Jun 2011 17:52:03 +0100 Message-ID: <17c101cc2d0e$e2917f80$a7b47e80$@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: AcwtDm6U/ZK77BO2TryklFqk3bo/Fw== Content-Language: en-gb Subject: [mpls] Second IETF last call on draft-ietf-mpls-loss-delay 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: Fri, 17 Jun 2011 16:52:14 -0000 Hi MPLS working group, I very much regret to inform you that it is necessary to hold a second IETF last call on draft-ietf-mpls-loss-delay. This document had completed a previous IETF last call and was on the agenda for IESG evaluation on Thursday 23rd. Unfortunately, a very late IPR disclosure was received from Huawei Technologies. While I appreciate this disclosure being made before the document was published as an RFC, I find it disappointing that the disclosure was made so late through the process. This is a disruption to the normal functioning of the working group and causes unnecessary delay to your work. May I ask the working group to take the opportunity of the second IETF last call to consider the IPR disclosure and raise any concerns on the MPLS list or on the IETF list. If the WG decides to revisit the draft in the light of the IPR disclosure, could the chairs please let me know so that I can refer the draft back to the WG. Can I take this opportunity to remind everyone in the WG (i.e. everyone subscribed to the MPLS list) of their duties under IETF IPR Policy (http://www.ietf.org/about/note-well.html), and let me specifically remind document authors of their responsibilities. Thanks, Adrian From iesg-secretary@ietf.org Fri Jun 17 11:16: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 450DC9E8024; Fri, 17 Jun 2011 11:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 ZM-lHdz3pZPR; Fri, 17 Jun 2011 11:16:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14179E8004; Fri, 17 Jun 2011 11:16:29 -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.55 Message-ID: <20110617181629.10414.74124.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 11:16:29 -0700 Cc: mpls@ietf.org Subject: [mpls] Second Last Call: (Packet Loss and Delay Measurement for MPLS Networks) 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: Fri, 17 Jun 2011 18:16:30 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Packet Loss and Delay Measurement for MPLS Networks' as a Proposed Standard This is a second last call. The last call is only necessary because of a late-received IPR disclosure. 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-07-01. 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 Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1574/ From eric.gray@ericsson.com Fri Jun 17 16:10: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 9ADD011E809E for ; Fri, 17 Jun 2011 16:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 az-3QHmONw2m for ; Fri, 17 Jun 2011 16:10:39 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 660AD11E807F for ; Fri, 17 Jun 2011 16:10:39 -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 p5HNAPAH026979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jun 2011 18:10:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 17 Jun 2011 19:10:25 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 17 Jun 2011 19:10:22 -0400 Thread-Topic: poll on draft-vkst-mpls-tp-te-mib-00.txt Thread-Index: AcwsSU6lqUmagjEuRMiI/REKgcJf9gA+kgMQ 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: poll on draft-vkst-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: Fri, 17 Jun 2011 23:10:44 -0000 Forwarding in plain text... ________________________________ From: Joan Cucchiara [mailto:jcucchiara@mindspring.com]=20 Sent: Thursday, June 16, 2011 1:17 PM To: adrian@olddog.co.uk; 'venkatesan mahalingam'; 'mpls' Cc: loa@pi.nu; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-t= e-mib@tools.ietf.org Subject: Re: poll on draft-vkst-mpls-tp-te-mib-00.txt =20 Hello, =20 Yes, I think the MIB is ready to be accepted as a working group=20 document. =20 As a comment (for a working group draft revision) would like to=20 see an explanation of how to configure index values with a populated mplsTunnelTable. =20 Thanks, -Joan =20 =20 ----- Original Message -----=20 From: Adrian Farrel =20 To: 'venkatesan mahalingam' ; jcucchiara@mi= ndspring.com ; 'mpls' =20 Cc: loa@pi.nu ; swallow@cisco.com ; rcallon@juniper.net ; draft-vkst-mpls-= tp-te-mib@tools.ietf.org=20 Sent: Saturday, June 04, 2011 5:05 PM Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt Thanks Venkat, =20 [Recalling that I am speaking as an individual contributor and not as AD] =20 This revision is much improved and I think the I-D would form a good basis= for further WG work. =20 Adrian =20 From: venkatesan mahalingam [mailto:venkatflex@gmail.com]=20 Sent: 04 June 2011 20:20 To: Adrian Farrel; jcucchiara@mindspring.com; mpls Cc: loa@pi.nu; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-= te-mib@tools.ietf.org Subject: Fwd: poll on draft-vkst-mpls-tp-te-mib-00.txt =20 Dear Adrian and Joan, =20 We have addressed the 3 major comments identified by you during WG adoptio= n poll. Apologies for the delayed response as we wanted to address each ite= m carefully and get consensus among authors of this document. =20 1. MPLS-TE-STD-MIB is extended by MPLS-TP-TE-STD-MIB mib module The 'extends' relationship is a sparse augmentation so that the entry = in the mplsTpTunnelTable has the same index values. Redefining of the index d= efinitions is now removed and the table is referenced with the same indices as in mplsTunnelTable. =20 2. Separate mib module for textual conventions created for MPLS-TP mib mod= ules. This is part of the present MIB,=20 which will be published separately, later. =20 3. Separate mib modules for MPLS-TP-TC-STD-MIB, MPLS-TP-ID-STD-MIB, MPLS-T= P-LSR-STD-MIB and=20 MPLS-TP-TE-STD-MIB have been created. These are presently part of this= MIB, so as overcome the mib compilation issues. These mibs will be published as separate drafts, after the adoption. =20 Apart from the above we have taken care of minor issues as well. We think,= the issues raised were addressed, and the document is ready to be adopted = as WG doc. Any changes, if needed, we will address in the subsequent revisi= ons. Kindly let us know if you have any questions. =20 New version can be accessed through this below URL, http://tools.ietf.org/html/draft-vkst-mpls-tp-te-mib-01 =20 Thanks, Venkat. =20 ---------- Forwarded message ---------- From: venkatesan mahalingam Date: Mon, May 9, 2011 at 5:29 PM Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt To: adrian@olddog.co.uk, loa@pi.nu, mpls Cc: swallow@cisco.com, rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tool= s.ietf.org =09 =09 Hi Adrian and all, Please find the responses inlined with the tag <> =20 Thanks, TP-MIB-Authors. ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Saturday, May 07, 2011 3:40 AM To: loa@pi.nu; mpls@ietf.org Cc: swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tool= s.ietf.org Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt =20 >[speaking as an individual WG participant] =20 >I support the idea of constructing a MIB module for MPLS-TP LSPs and for = other >elements of MPLS-TP, but I have significant reservations about adopting t= his >document in its current form. I recognise that once adopted, the WG will = be able >to enforce changes in content, but I am concerned that this document does= not >correctly reflect the relationship with other MIB modules, and that takin= g this >as a starting point will encourage us to go down the wrong path resulting= in a >starting direction that will be hard to change. =20 >I would be happy to see the authors spend a little more time on this and = then >adopt it into the WG. =20 >In overview my concerns are as follows: =20 > mplsGlobalId, mplsIcc and mplsNodeId are node properties that will turn = out > to > be equally applicable for PWs. They should appear in a MIB module dedica= ted > to > the LSR not just to the MPLS-TP LSPs. Given that these three objects and > mplsNodeConfigTable and mplsNodeIpMapTable are all related to MPLS-TP > identifiers, why not have a separate module for them all? =20 =20 <> We agree that mplsGlobalId, mplsIcc and mplsNodeId can = be kept in a common mib module. mplsNodeConfigTable is created specifically to map the [Global-id_Node-id] and Icc-id into Local-Num. This Local-Num will be used as the tunnel sourc= e/destination identifier. =20 This idea has been followed to retain the MPLS tunnel table for MPLS-TP TE= extensions also. We think that mplsNodeConfigTable/mplsNodeIpMapTable is not applicable for= PWs. The reason is that we already have the 129 FEC PWs with variable length of= SAII & TAII. And the SAII & TAII already includes the Global-Id and Node-Id (or ICC Id) Since the MPLS-TP PWs are always FEC129 Type2 based PWs, the flexibility i= n SAII & TAII=20 can be used to configure Global-id/Node-id or ICC id. =20 =20 > A number of objects related to Global IDs and Node IDs appear to be of t= he > wrong > max value compared to draft-ietf-mpls-tp-identifiers. You could usefully > define > TCs for them and for the ICC ID. What will zero Global IDs and Node IDs > mean? =20 =20 <> Yes, the Max value of Global-Id and Node-id are wrong. = Max value should be max of 4 bytes value. We will correct them. =20 Yes, we can keep the TCs for Global-id/Node-id and ICC-id in a seperate mi= b module. 1) A Global_ID of zero means that no Global_ID is present. 2) A Node_ID of zero is the default value that indicates the Node_ID is invalid. =20 =20 > I see the value of the ICC entries in mplsNodeConfigTable and the use of > mplsNodeIccMapTable to generate a unique index to use in defining entrie= s in > the > various pre-existing tables. (But see my comment on the use of > mplsNodeConfigLocalNum in mplsTunnelExtEntry, below). I do not see the v= alue > of > the Global entries in mplsNodeConfigTable and the use of mplsNodeIpMapEn= try > since you say in the preamble to mplsTunnelExtEntry that Source-Tunnel_N= um > is > mapped with mplsTunnelIndex. Quite possibly there is descriptive text > missing. =20 <> mplsNodeConfigTable is the configuration table that is = used to configure Global-id/Node-id and/or ICC-id with the local map number. i.e. This table is used to configure the global-id/N= ode-id and/or ICC-id for the given local map number. =20 The other two tables mplsNodeIpMapEntry and mplsNodeIccMapTable are just R= EAD-ONLY tables. These read only tables are meant for users who want to view the reverse ma= pping of Global-id/Node-id=20 or ICC-id to the LocalNum. =20 > There seems to be some ambiguity about whether the objects in this docum= ent > refer to MPLS-TP or to extensions to MPLS-TE. it would be really nice to > sort > this out. =20 <> This document is created to address the requirements of= TE extensions for MPLS-TP and this will also be applicable for MPLS TE and hence the mib= modules are named generically. Since we are augmenting the TE mib, we named it as TE e= xtension. If many others prefer to name this as TP extension, we can change the name= s accordingly. =20 =20 > mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm guessin= g > you > actually want a sparse augmentation since in a "mixed" environment you w= ill > not > want to have all these objects present but unused. So you need to change= the > way > you define this. =20 <> Yes, we actually meant sparse augmentation. This mplsTu= nnelExtEntry=20 will have entries only when required. For example, this table will have entries for the MPLS-TP tunnels, but not= for MPLS tunnels. Does it answer your question? Do you expect few more description to be added to this table? Also, do you foresee any issue of augmentation? Is it possible to explain = the same? =20 > In mplsTunnelExtTable you do not state what DstTunnelNum is mapped with. > This is > key and could completely break your augmentation unless you get it right= ! =20 <> There are two ways to look at this problem. One way is = to force the DstTunnelNum as key.=20 Other way is NOT to force it as key. Let us take an example to demonstrate= this. Let us say that we have a forward LSP with SrcTunnel_100, Instance_1, Sour= ce_R1, Destination_R5, DstTunnel_200. Option1: Force DstTunnelNum as key: If we mandate DstTunnelNum as key, then the following combination is theor= etically valid. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 LSP2: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300.= Even though the LSP2 is theoretically valid, it is not correct to have same indices for the forward LSP. i.e Treating t= he LSP2 as separate=20 independent LSP is not looking correct. Hence, the Option1 is dropped. =20 Option2: Do not force DstTunnelNum as key: This is the option that we choose. i.e User can configure DstTunnelNum as = read-write column,=20 but it is not part of indices to mplsTunnelTable. If we try to include tha= t as key, even the existing MPLS based mplsTunnelTable will have problems in interpr= etation.=20 Also, we do not see a real need to force that as index/key. According to t= his option, the LSP1 is a valid combination. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 If user wants to use a different reverse LSP, they can modify the DstTunne= l value as 300. But, it will still be called as LSP1. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300 = (modified). If required, we can discuss with mpls-tp-identifiers authors to confirm wh= ether this approach is fine. =20 =20 > For mplsTunnelExtEntry you have... > Source Global identifier/ICC and Destination > Global identifier/ICC are maintained in the > mplsNodeConfigTable and mplsNodeConfigLocalNum is used to > create an entry in mplsTunnelTable. > This is possibly too vague to be actually practical. =20 <> We created a word document to explain the various optio= ns that were considered before taking this option. We will share the same with you.=20 In principle, the idea is to reuse the mplsTunnelTable without disturbing = its existing meaning for MPLS based tunnels.=20 Even though we can think of alternate designs based on separate new table = for MPLS_TP tunnels, we thought that reusing the existing table is a better option since MPLS_T= P is just an extension of existing MPLS. You can go through our document and provide your comments. =20 =20 > How will mplsTunnelExtDestTnlIndex actually be used? > - What value will it have for unidirecitonal tunnels? > (Or for bidriectional associated tunnels where the reverse > direction is not present on this LSR) =20 <> A zero value will be held by this (mplsTunnelExtDestTnl= Index) object when the unidirectional tunnel is desired. This object contains the source tunnel index value incase of co-routed bidirectional tunnel and for associated bidirectional tunnel this object contains the reverse direction tunnel index and reverse lsp index object will be added in the next version of this draft. =20 =20 > - Is this actually meant to be the object that gives us the > DstTunnelNum? If so, what has this to do with the reverse > direction? =20 <> Yes, this helps to associate the forward/reverse direct= ion tunnels for associated bi-directional tunnel. For co-routed bidirectional case, SrcTunnelNum =3D DstTunnelNum and SrcTunnelLspNum =3D DstTunnelLspNum, this is because we use same tunnel entry with two different XC entries for both forward and reverse direction LSPs. =20 > It is completely unclear to me what mplsTunnelExtTnlApp is for! =20 <> This object provides the information on whether the tun= nel entry is MPLS tunnel or the MPLS-TP tunnel (tunnel application is either MPLS or MPLS-TP). =20 =20 > It certainly makes a nonsense of mplsTpTunnelsConfigured and > mplsTpTunnelsActive =20 <> This is to keep the tunnel count for MPLS-TP specific t= unnels which are configured as mplsTp in mplsTunnelExtTnlApp object. If the object is not g= oing to be useful for users, this can be removed. =20 =20 >Cheers, >Adrian =20 =20 > -----Original Message----- > From: loa@pi.nu [mailto:loa@pi.nu] > Sent: 03 May 2011 18:48 > To: mpls@ietf.org > Cc: Adrian Farrel; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mp= ls-tp- > te-mib@tools.ietf.org > Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-vkst-mpls-tp-te-mib-00.txt >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document > please respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. >=20 > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. >=20 > The poll ends 2011-05-18. >=20 > /Loa =20 =20 From eric.gray@ericsson.com Fri Jun 17 16:11: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 0104511E80DF for ; Fri, 17 Jun 2011 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 clxWtYX2mgrw for ; Fri, 17 Jun 2011 16:11:34 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16711E80CE for ; Fri, 17 Jun 2011 16:11:34 -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 p5HNBXjr027021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jun 2011 18:11:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 17 Jun 2011 19:11:32 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 17 Jun 2011 19:11:32 -0400 Thread-Topic: poll on draft-vkst-mpls-tp-te-mib-00.txt Thread-Index: AcwsSXCV40cmozeWs0iweNJFgbsyJgA+mR3Q 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: poll on draft-vkst-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: Fri, 17 Jun 2011 23:11:42 -0000 Forwarding in plain text... ________________________________ From: Thomas D. Nadeau [mailto:thomas.nadeau@ca.com] Sent: Thursday, June 16, 2011 1:19 PM To: Joan Cucchiara; adrian@olddog.co.uk; 'venkatesan mahalingam'; 'mpls' Cc: loa@pi.nu; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-t= e-mib@tools.ietf.org Subject: Re: poll on draft-vkst-mpls-tp-te-mib-00.txt Joan Cucchiara On 6/16/11 1:17 PM, "Joan Cucchiara" wrote: Hello, Yes, I think the MIB is ready to be accepted as a working group document. As a comment (for a working group draft revision) would like to see an explanation of how to configure index values with a populated mplsTunnelTable. TOM: Cool. We will add that to the document in the next revision. --Tom Thanks, -Joan ----- Original Message ----- From: Adrian Farrel To: 'venkatesan mahalingam' = ; jcucchiara@mindspring.com ; 'mpls' Cc: loa@pi.nu ; swallow@cisco.com ; rcallon@juniper.net ; d= raft-vkst-mpls-tp-te-mib@tools.ietf.org Sent: Saturday, June 04, 2011 5:05 PM Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt Thanks Venkat, [Recalling that I am speaking as an individual contributor= and not as AD] This revision is much improved and I think the I-D would f= orm a good basis for further WG work. Adrian From: venkatesan mahalingam [mailto:venkatflex@gmail.com] Sent: 04 June 2011 20:20 To: Adrian Farrel; jcucchiara@mindspring.com; mpls Cc: loa@pi.nu; swallow@cisco.com; rcallon@juniper.net; draf= t-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Fwd: poll on draft-vkst-mpls-tp-te-mib-00.txt Dear Adrian and Joan, We have addressed the 3 major comments identified by you d= uring WG adoption poll. Apologies for the delayed response as we wanted to = address each item carefully and get consensus among authors of this docum= ent. 1. MPLS-TE-STD-MIB is extended by MPLS-TP-TE-STD-MIB mib m= odule The 'extends' relationship is a sparse augmentation so = that the entry in the mplsTpTunnelTable has the same index values. Redefining= of the index definitions is now removed and the table is referenced with the same indices as in mplsTunnelTable. 2. Separate mib module for textual conventions created for = MPLS-TP mib modules. This is part of the present MIB, which will be published separately, later. 3. Separate mib modules for MPLS-TP-TC-STD-MIB, MPLS-TP-ID= -STD-MIB, MPLS-TP-LSR-STD-MIB and MPLS-TP-TE-STD-MIB have been created. These are present= ly part of this MIB, so as overcome the mib compilation issues. These mibs will be published as separate drafts, after = the adoption. Apart from the above we have taken care of minor issues as = well. We think, the issues raised were addressed, and the document is read= y to be adopted as WG doc. Any changes, if needed, we will address in the = subsequent revisions. Kindly let us know if you have any questions. New version can be accessed through this below URL, http://tools.ietf.org/html/draft-vkst-mpls-tp-te-mib-01 Thanks, Venkat. ---------- Forwarded message ---------- From: venkatesan mahalingam Date: Mon, May 9, 2011 at 5:29 PM Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt To: adrian@olddog.co.uk, loa@pi.nu, mpls Cc: swallow@cisco.com, rcallon@juniper.net, draft-vkst-mpls= -tp-te-mib@tools.ietf.org Hi Adrian and all, Please find the responses inlined with the tag <> Thanks, TP-MIB-Authors. ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Saturday, May 07, 2011 3:40 AM To: loa@pi.nu; mpls@ietf.org Cc: swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls= -tp-te-mib@tools.ietf.org Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt >[speaking as an individual WG participant] >I support the idea of constructing a MIB module for MPLS-= TP LSPs and for other >elements of MPLS-TP, but I have significant reservations = about adopting this >document in its current form. I recognise that once adopt= ed, the WG will be able >to enforce changes in content, but I am concerned that th= is document does not >correctly reflect the relationship with other MIB modules= , and that taking this >as a starting point will encourage us to go down the wron= g path resulting in a >starting direction that will be hard to change. >I would be happy to see the authors spend a little more t= ime on this and then >adopt it into the WG. >In overview my concerns are as follows: > mplsGlobalId, mplsIcc and mplsNodeId are node properties= that will turn out > to > be equally applicable for PWs. They should appear in a M= IB module dedicated > to > the LSR not just to the MPLS-TP LSPs. Given that these t= hree objects and > mplsNodeConfigTable and mplsNodeIpMapTable are all relat= ed to MPLS-TP > identifiers, why not have a separate module for them all= ? <> We agree that mplsGlobalId, mplsIcc and= mplsNodeId can be kept in a common mib module. mplsNodeConfigTable is created specifically to map the [Gl= obal-id_Node-id] and Icc-id into Local-Num. This Local-Num will be used as = the tunnel source/destination identifier. This idea has been followed to retain the MPLS tunnel table= for MPLS-TP TE extensions also. We think that mplsNodeConfigTable/mplsNodeIpMapTable is not= applicable for PWs. The reason is that we already have the 129 FEC PWs with va= riable length of SAII & TAII. And the SAII & TAII already includes the Global-Id and Nod= e-Id (or ICC Id) Since the MPLS-TP PWs are always FEC129 Type2 based PWs, t= he flexibility in SAII & TAII can be used to configure Global-id/Node-id or ICC id. > A number of objects related to Global IDs and Node IDs a= ppear to be of the > wrong > max value compared to draft-ietf-mpls-tp-identifiers. Yo= u could usefully > define > TCs for them and for the ICC ID. What will zero Global = IDs and Node IDs > mean? <> Yes, the Max value of Global-Id and Nod= e-id are wrong. Max value should be max of 4 bytes value. We will correct them. Yes, we can keep the TCs for Global-id/Node-id and ICC-id = in a seperate mib module. 1) A Global_ID of zero means that no Global_ID is present. 2) A Node_ID of zero is the default value that indicates t= he Node_ID is invalid. > I see the value of the ICC entries in mplsNodeConfigTabl= e and the use of > mplsNodeIccMapTable to generate a unique index to use in= defining entries in > the > various pre-existing tables. (But see my comment on the = use of > mplsNodeConfigLocalNum in mplsTunnelExtEntry, below). I = do not see the value > of > the Global entries in mplsNodeConfigTable and the use of= mplsNodeIpMapEntry > since you say in the preamble to mplsTunnelExtEntry that= Source-Tunnel_Num > is > mapped with mplsTunnelIndex. Quite possibly there is des= criptive text > missing. <> mplsNodeConfigTable is the configuratio= n table that is used to configure Global-id/Node-id and/or ICC-id with the local map number. i.e. This table is used to configure = the global-id/Node-id and/or ICC-id for the given local map number. The other two tables mplsNodeIpMapEntry and mplsNodeIccMap= Table are just READ-ONLY tables. These read only tables are meant for users who want to view= the reverse mapping of Global-id/Node-id or ICC-id to the LocalNum. > There seems to be some ambiguity about whether the objec= ts in this document > refer to MPLS-TP or to extensions to MPLS-TE. it would b= e really nice to > sort > this out. <> This document is created to address the= requirements of TE extensions for MPLS-TP and this will also be applicable for MPLS TE a= nd hence the mib modules are named generically. Since we are augmenting the TE mib, we = named it as TE extension. If many others prefer to name this as TP extension, we can = change the names accordingly. > mplsTunnelExtEntry is defined as augmenting mplsTunnelEn= try. I'm guessing > you > actually want a sparse augmentation since in a "mixed" e= nvironment you will > not > want to have all these objects present but unused. So yo= u need to change the > way > you define this. <> Yes, we actually meant sparse augmentat= ion. This mplsTunnelExtEntry will have entries only when required. For example, this table will have entries for the MPLS-TP = tunnels, but not for MPLS tunnels. Does it answer your question? Do you expect few more description to be added to this tab= le? Also, do you foresee any issue of augmentation? Is it poss= ible to explain the same? > In mplsTunnelExtTable you do not state what DstTunnelNum= is mapped with. > This is > key and could completely break your augmentation unless = you get it right! <> There are two ways to look at this prob= lem. One way is to force the DstTunnelNum as key. Other way is NOT to force it as key. Let us take an example= to demonstrate this. Let us say that we have a forward LSP with SrcTunnel_100, = Instance_1, Source_R1, Destination_R5, DstTunnel_200. Option1: Force DstTunnelNum as key: If we mandate DstTunnelNum as key, then the following comb= ination is theoretically valid. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,= DstTunnel_200 LSP2: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,= DstTunnel_300. Even though the LSP2 is theoretically valid, it is not correct to have same indices for the forward LSP.= i.e Treating the LSP2 as separate independent LSP is not looking correct. Hence, the Option1 = is dropped. Option2: Do not force DstTunnelNum as key: This is the option that we choose. i.e User can configure = DstTunnelNum as read-write column, but it is not part of indices to mplsTunnelTable. If we try= to include that as key, even the existing MPLS based mplsTunnelTable will have pro= blems in interpretation. Also, we do not see a real need to force that as index/key.= According to this option, the LSP1 is a valid combination. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,= DstTunnel_200 If user wants to use a different reverse LSP, they can mod= ify the DstTunnel value as 300. But, it will still be called as LSP1. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,= DstTunnel_300 (modified). If required, we can discuss with mpls-tp-identifiers autho= rs to confirm whether this approach is fine. > For mplsTunnelExtEntry you have... > Source Global identifier/ICC and Destination > Global identifier/ICC are maintained in the > mplsNodeConfigTable and mplsNodeConfigLocalN= um is used to > create an entry in mplsTunnelTable. > This is possibly too vague to be actually practical. <> We created a word document to explain t= he various options that were considered before taking this option. We will share the same with you= . In principle, the idea is to reuse the mplsTunnelTable wit= hout disturbing its existing meaning for MPLS based tunnels. Even though we can think of alternate designs based on sep= arate new table for MPLS_TP tunnels, we thought that reusing the existing table is a better opt= ion since MPLS_TP is just an extension of existing MPLS. You can go through our document and provide your comments. > How will mplsTunnelExtDestTnlIndex actually be used? > - What value will it have for unidirecitonal tunnels? > (Or for bidriectional associated tunnels where the rev= erse > direction is not present on this LSR) <> A zero value will be held by this (mpls= TunnelExtDestTnlIndex) object when the unidirectional tunnel is desired. This object contains the source tunnel index value incase = of co-routed bidirectional tunnel and for associated bidirectional tunnel this object contains the reverse direction tunnel i= ndex and reverse lsp index object will be added in the next version = of this draft. > - Is this actually meant to be the object that gives us = the > DstTunnelNum? If so, what has this to do with the rev= erse > direction? <> Yes, this helps to associate the forwar= d/reverse direction tunnels for associated bi-directional tunnel. For co-routed bidirectional case, SrcTunnelNum =3D DstTunn= elNum and SrcTunnelLspNum =3D DstTunnelLspNum, this is because we use same tunnel entry with two different= XC entries for both forward and reverse direction LSPs. > It is completely unclear to me what mplsTunnelExtTnlApp = is for! <> This object provides the information on= whether the tunnel entry is MPLS tunnel or the MPLS-TP tunnel (tunnel application is e= ither MPLS or MPLS-TP). > It certainly makes a nonsense of mplsTpTunnelsConfigured= and > mplsTpTunnelsActive <> This is to keep the tunnel count for MP= LS-TP specific tunnels which are configured as mplsTp in mplsTunnelExtTnlApp object. If the = object is not going to be useful for users, this can be removed. >Cheers, >Adrian > -----Original Message----- > From: loa@pi.nu [mailto:loa@pi.nu] > Sent: 03 May 2011 18:48 > To: mpls@ietf.org > Cc: Adrian Farrel; swallow@cisco.com; rcallon@juniper.net= ; draft-vkst-mpls-tp- > te-mib@tools.ietf.org > Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt > > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > an mpls working group document. > > If you support the document becoming a working group doc= ument > please respond to this poll with "yes/support" > > If you do not support the document becoming a working gr= oup > document please respond to this poll with "no/do not sup= port" > and at the same time give the technical reasons why you = are > not supporting the document. > > If you have technical comments or in any other way want = to > discuss the document, please send these comments to the = mpls > working group mailing list, but with another subject tha= n what > is on this mail. > > The poll ends 2011-05-18. > > /Loa From adrian@olddog.co.uk Sat Jun 18 04:38: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 2ADD411E8096 for ; Sat, 18 Jun 2011 04:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[AWL=-0.158, 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 kK+MRe-Hp0z4 for ; Sat, 18 Jun 2011 04:38:57 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFA111E8082 for ; Sat, 18 Jun 2011 04:38:56 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5IBc8Qj018125 for ; Sat, 18 Jun 2011 12:38:09 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5IBc7qG018112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 18 Jun 2011 12:38:08 +0100 From: "Adrian Farrel" To: Date: Sat, 18 Jun 2011 12:38:47 +0100 Message-ID: <189401cc2dac$49d62ea0$dd828be0$@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: AcwtrEUfh6hQzNmhQu6v43wqwyK1uQ== Content-Language: en-gb Subject: [mpls] FW: [OPSAWG] BCP 161, RFC 6291 on Guidelines for the Use of the "OAM" Acronym in the IETF 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, 18 Jun 2011 11:38:58 -0000 FYI > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of rfc-editor@rfc-editor.org > Sent: 17 June 2011 17:53 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: opsawg@ietf.org; rfc-editor@rfc-editor.org > Subject: [OPSAWG] BCP 161, RFC 6291 on Guidelines for the Use of the "OAM" > Acronym in the IETF > > A new Request for Comments is now available in online RFC libraries. > > BCP 161 > RFC 6291 > > Title: Guidelines for the Use of > the "OAM" Acronym in the IETF > Author: L. Andersson, H. van Helvoort, > R. Bonica, D. Romascanu, > S. Mansfield > Status: Best Current Practice > Stream: IETF > Date: June 2011 > Mailbox: loa.andersson@ericsson.com, > huub.van.helvoort@huawei.com, > rbonica@juniper.net, dromasca@avaya.com, > scott.mansfield@ericsson.com > Pages: 9 > Characters: 16696 > See Also: BCP0161 > > I-D Tag: draft-ietf-opsawg-mpls-tp-oam-def-10.txt > > URL: http://www.rfc-editor.org/rfc/rfc6291.txt > > At first glance, the acronym "OAM" seems to be well-known and > well-understood. Looking at the acronym a bit more closely reveals a > set of recurring problems that are revisited time and again. > > This document provides a definition of the acronym "OAM" (Operations, > Administration, and Maintenance) for use in all future IETF documents > that refer to OAM. There are other definitions and acronyms that > will be discussed while exploring the definition of the constituent > parts of the "OAM" term. This memo documents an Internet Best Current > Practice. > > This document is a product of the Operations and Management Area Working > Group Working Group of the IETF. > > > BCP: This document specifies an Internet Best Current Practices for the > Internet Community, and requests discussion and suggestions for > improvements. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC From Alexander.Vainshtein@ecitele.com Sat Jun 18 08:42: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 7E4F211E818A; Sat, 18 Jun 2011 08:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396] 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 HZ2B9CVtCQmB; Sat, 18 Jun 2011 08:42:51 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id CDEA811E816C; Sat, 18 Jun 2011 08:42:50 -0700 (PDT) X-AuditID: 93eaf2e7-b7c2dae0000028e9-9d-4dfcc7711943 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 0D.B5.10473.177CCFD4; Sat, 18 Jun 2011 18:42:41 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 18 Jun 2011 18:42:48 +0300 From: Alexander Vainshtein To: "yaacov.weingarten@nsn.com" , "annamaria.fulignoli@ericsson.com" Date: Sat, 18 Jun 2011 18:42:46 +0300 Thread-Topic: 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: AQHMLc5fhdiAGpqKu0G7uB0M08zc9w== 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_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTa0gUURTHuTvj7rg5MW5r3kRiu72g2s3FgrFaiSTQSCwqe5KOu7fdqdnZ bWcL1w9l2QM07OEqJZI9trDMRBNKK6qNXgb2IKHUSiiL7PEhilqrtRmHTIjup//5n98953C5 hyIMlbokihf92CdyAtLqyYr+z1/Mm+/8zE7Z25bKnu97o2F31lwAbNepMzFs98uLOrb8cwvJ dvTVALbp8hHtfF1m8EdTTObA105tZigU0WRGGjt1S8g1xWAeJ4oeP+fHJgeW7Da0xMdv5ewB ZOIdNmRFJq/A2bEbi34b4rxeLDpQut70z5knY7xowqLd4+BFpw1lLcsxs+zsNLMVpU+ZaE2d q1/u4iUTNrs5XjC5sSRxTmySnfwWwhVuK/BGFhZWBC8RxeDWnFIQS0FmFuz4dAWoeix8+KJR Wwr0lIFpBTB6/Z5ODYIAHnrWTiqUlrHB5vrnQ5SR2QVga8cFjRIQzD4SVtXfIhSKZCbDUEP9 UN0xzFJYMliqVbSRyYWRtyd1qrbAaNdJ2acomsmBJ/pWKzaQx/jWfk6jaIJJhF2vazXqeAwM XXlAqDoBvnsVjVH5BNiztxGovAfuKSsb8mkmHt478ppU+XHwRt1T8gAwVo8oWz3iSvWIK6pv gU8rg1pVT4enj78nVG2Gh6NhcqR/DOjOggRe8PoL3M4UqwXbeT8WsMXucTcD9R+9vQQGaieF AUMBFEfnl/zINsRwW6WAOwzGURqUQNfe/pltGF3gcQRcnOTK820RsBQGkCKQkZ5QI+doBxco wj7Pn9RC+ZEPEkmj7B75x4r+vNSUlP8HKJHus3/INjBO+QtuwtiLfX/qJFMUgnSP0j7eh524 cAMv+P+mNVSsMkacPMYKhaElL+eWeKeabwdm6kTDuzAwkKJHxEmJdJYCMQrk2iIO11G2afvg 4GA/SJQfYAxdrVBx8q4NV+qXm2jkJtGBAaWJvCrDqaRigDLKd/xq2N+2w1jVfTTrqhisuFlW uc5xeNHjort1ya29Tz5lpNvur390Xj9+/tpmy+qIq3PWpJbRG+PnCItnzsgITP0Qdy43Oe1Z bGlayfebebPT0lt7mkP524pcGwo/wpfXJuRsq2pahV7xd2p6heuXF5zdvXE8CK0s7/76eOXi wO1eREouzjqN8Encb6nSqMEoBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: [mpls] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? 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, 18 Jun 2011 15:42:52 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, I would highly appreciate some clarification on the following issue: Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP d= ata plane? We have been recently reminded by Daniel Cohn that 1+1 protection has been d= eclared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more,= Req. #65-B states that it MUST be supported in the unidirectional mode for= P2P connectivity. The problematic use case from my point of view is PW traffic carried within= a 1+1-protected LSP between a pair of PEs. To the best of my understanding, unidirectional 1+1 linear protection, in it= s absolutely minimal form, would imply that: 1. Some form of proactive connectivity check (CC) would be applied to both Wor= king (W) and Protection (P) LSPs. It is my understanding that the GAL/G-ACH= mechanism would be used as the encapsulation for the CC packets 2. Based on the results of CC, one of the incoming LSPs would be selected as Ac= tive 3. When in comes to PW client traffic in these LSPs: * In the Tx direction: * Each PW packet would be replicated and forwarded thru both W and P LSPs * Replication would leave the PW label (and everything after this label) the= same for both copies, so that only Tunnel labels and accompanying linke lay= er encapsulations would be different * In the Rx direction: * Both W and P LSPs would be terminated, i.e., their labels would be popped an= d, if the resulting packets are still labeled, the next label looked up * PW packets received from the Active LSP would be forwarded to the= appropriate PW Forwarder, and PW packets received from the inactive LSP wou= ld be silently discarded If this understanding is correct, this would mean that treatment of the rece= ived PW labels would depend on the specific terminated LSP from which the pa= ckets labeled with those have been received. In principle, this would be pos= sible if we would treat these LSPs and interfaces and allocate PW labels fro= m the per-interface space(even this would be non-trivial, because there is n= o way to guarantee that the same label value has simiilar meaning in differe= nt label spaces). But, as per RFC 4447, PW labels MUST be allocated from th= e per-platform label space. And of course, simply discarding all the packets received from the inactive= LSP would not do because this would affect CC operation. Did I miss something substantial in my analysis? Please note also that 1:1 protection could rely on the remote Tx endpoint on= ly sending packets to the (common) Active LSP making life simpler (no real n= eed for selection on the Rx side). I understand that draft-ietf-mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never... 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_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
            Hi all,
            I would highly appreciate so= me clarification on the following issue:
            Is 1+1 linear protection= architecture for LSPs compatible with the MPLS-TP data plane?
            We have been recently remind= ed by Daniel Cohn that 1+1 protection has been declared as MUST to suppo= rt for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states that i= t MUST be supported in the unidirectional mode for P2P connectivity.
             
            The problematic use case fro= m my point of view is PW traffic carried within a 1+1-protected LSP betw= een a pair of PEs.
             
            To the best of my understand= ing, unidirectional 1+1 linear protection, in its absolutely m= inimal form, would imply that:
            1. Some form of proactive connectivity chec= k (CC) would be applied to both  Working (W) and Protection= (P) LSPs. It is my understanding that= the GAL/G-ACH mechanism would be used as the encapsulation for the CC packets
            2. Based on the results of CC, one of the i= ncoming LSPs would be selected as Active
            3. When in comes to PW client traffic<= a> in these LSPs:
              • In the Tx direction:<= /font>
                • Each PW packet would be replicated and f= orwarded thru both W and P LSPs
                •  Replication would leave the PW lab= el (and everything after this label) the same for both copies, so that only= Tunnel labels and accompanying linke layer encapsulation= s would be different
              • In the Rx direction:
                • Both W an= d P LSPs would be terminated, i.e., their labels would be popped and,= if the resulting packets are still labeled, the next label looked up=
                • PW packets received from the Active= LSP would be forwarded to the appropriate PW Forwarder, and PW packe= ts received from the inactive LSP would be silently discarded<= /li>

            If this understanding is correct, this wou= ld mean that treatment of the received PW labels would depend on the specifi= c terminated LSP from which the packets labeled with those have been receive= d. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW labels= from the per-interface space(even this would be non-triv= ial, because there is no way to guarantee that the same label value has = ;simiilar meaning in different label spaces).  But, as per RFC 4447, PW labels MUST be allocated from the p= er-platform label space.

            And of course, simply discarding all the p= ackets received from the inactive LSP would not do because this would affect= CC operation.

             

            Did I miss something substantial in my ana= lysis?

             

            Please note also that 1:1 protection could= rely on the remote Tx endpoint only sending packets to the (common)= Active LSP making life simpler (no real need for selection on the Rx side).=

             

            I understand that draft-ietf= -mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never...

             

            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_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_-- From gregimirsky@gmail.com Sat Jun 18 09:17: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 E7B6411E81C4; Sat, 18 Jun 2011 09:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, 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 k-y9L6AFqsZC; Sat, 18 Jun 2011 09:17:02 -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 7D0F511E81A2; Sat, 18 Jun 2011 09:17:02 -0700 (PDT) Received: by vws12 with SMTP id 12so3259936vws.31 for ; Sat, 18 Jun 2011 09:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q4HRkwglnOtEjiNSVwsXD94WSp3uddTg86UtmKJa9pQ=; b=PCwY6hpVZ9BX+m68kr0mQL7iEVs6ZXZo0VOqhDbCSyeTY0hHCs3cdWcN8zNEa+7eZC AtesZhNSrJqq3VsyA84PtOM9Gv8FvPCgW7sSZgZCnd/4i9gkK+sUa6HVNButmH1XHzdK 5XnDpLQ7EtrKYrhD1zoJOoiP2M3UutZdDp8tU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p8JUOZxwFYmpAlxZIP7IAxredeJiDwdmCB9BOSoH/+nrMewuiz9ocvUdfwtK4FmYvl AtLbe6ks8EsMqTPB17lYrx9eNcXj3iT8er9PDrGSPVDiH4jOiZ2vrX7ZLB/rfx6ADZkS qXC8lNbkynf63kvpVloRO6B6xaSaMEsCOKKlk= MIME-Version: 1.0 Received: by 10.52.162.72 with SMTP id xy8mr4871685vdb.87.1308413821755; Sat, 18 Jun 2011 09:17:01 -0700 (PDT) Received: by 10.52.160.67 with HTTP; Sat, 18 Jun 2011 09:17:01 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Jun 2011 09:17:01 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=bcaec53f95dd10a42304a5fed5ec Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? 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, 18 Jun 2011 16:17:04 -0000 --bcaec53f95dd10a42304a5fed5ec Content-Type: text/plain; charset=ISO-8859-1 Dear Sasha, I think that there is one assumption in line of your logic that changes the result. When we consider 1+1 LSP protection sink discards traffic from one source on LSP level. As result there should not be issue with Rx on PW client traffic since sink receives PW packets only from Active LSP and PW packets from Inactive LSP would never be seen. If we consider 1:1 PW protection, then, as I imagine, we have redundant PW and thus PW labels are different. Then the sink selects one of PWs as active but there should be no issue with PW labels. Please let me know if understood scenarios correctly. Kind regards, Greg On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Hi all, > I would highly appreciate some clarification on the following issue: > > Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP > data plane? > > We have been recently reminded by Daniel Cohn that 1+1 protection has been > declared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more, > Req. #65-B states that it MUST be supported in the unidirectional mode for > P2P connectivity. > > The problematic use case from my point of view is PW traffic carried within > a 1+1-protected LSP between a pair of PEs. > > To the best of my understanding, unidirectional 1+1 linear protection, in > its absolutely minimal form, would imply that: > > 1. Some form of proactive connectivity check (CC) would be applied > to both Working (W) and Protection (P) LSPs. It is my understanding > that the GAL/G-ACH mechanism would be used as the encapsulation for the > CC packets > 2. Based on the results of CC, one of the incoming LSPs would be > selected as Active > 3. When in comes to PW client traffic in these LSPs: > - In the Tx direction: > - Each PW packet would be replicated and forwarded thru both W and > P LSPs > - Replication would leave the PW label (and everything after > this label) the same for both copies, so that only Tunnel labels and > accompanying linke layer encapsulations would be different > - In the Rx direction: > - Both W and P LSPs would be terminated, i.e., their labels would > be popped and, if the resulting packets are still labeled, the next label > looked up > - PW packets received from the Active LSP would be forwarded to > the appropriate PW Forwarder, and PW packets received from the > inactive LSP would be silently discarded > > If this understanding is correct, this would mean that treatment of the > received PW labels would depend on the specific terminated LSP from which > the packets labeled with those have been received. In principle, this would > be possible if we would treat these LSPs and interfaces and allocate PW > labels from the per-interface space(even this would be non-trivial, > because there is no way to guarantee that the same label value has simiilarmeaning in different label spaces). But, as per RFC 4447, PW labels MUST be > allocated from the per-platform label space. > > And of course, simply discarding all the packets received from the inactive > LSP would not do because this would affect CC operation. > > > > Did I miss something substantial in my analysis? > > > > Please note also that 1:1 protection could rely on the remote Tx endpoint > only sending packets to the (common) Active LSP making life simpler (no real > need for selection on the Rx side). > > > > I understand that draft-ietf-mpls-tp-linear-protection is in the final > stages of the WG discussion, and apologize for raising this question so > late. But late is (sometimes) better than never... > > > > 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. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --bcaec53f95dd10a42304a5fed5ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sasha,
            I think that there is one assumption in line of your logic t= hat changes the result.
            When we consider 1+1 LSP protection sink discard= s traffic from one source on LSP level. As result there should not be issue= with Rx on PW client traffic since sink receives PW packets only from Acti= ve LSP and PW packets from Inactive LSP would never be seen.
            If we consider 1:1 PW protection, then, as I imagine, we have redundant PW = and thus PW labels are different. Then the sink selects one of PWs as activ= e but there should be no issue with PW labels.

            Please let me know if= understood scenarios correctly.

            Kind regards,
            Greg

            On Sat, Jun 18,= 2011 at 8:42 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&= gt; wrote:
            Hi all,
            I would highly appreciate s= ome clarification on the following issue:
            Is 1+1 linear protection ar= chitecture for LSPs compatible with the MPLS-TP data plane?
            We have been recently remin= ded by Daniel Cohn that 1+1 protection has been declared as MUST to support= for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states tha= t it MUST be supported in=A0the unidirectional mode for P2P connectivity.
            =A0
            The problematic use case fr= om my point of view is PW traffic carried within a 1+1-protected LSP betwee= n a=A0pair of PEs.
            =A0
            To the best of my understan= ding, unidirectional=A01+1 linear protection,=A0in its absolutely minimal f= orm,=A0would imply that:
            1. Some form of proactive connectivity che= ck (CC) would be applied to=A0both=A0 Working (W) and Protection (P)= LSPs. It is my understanding that th= e GAL/G-ACH mechanism would=A0be used=A0as the encapsulation for the CC packets
            2. Based on the results of CC, one of the = incoming LSPs would be selected as Active
            3. When in comes to PW client=A0traffic= in these LSPs:
              • In the=A0Tx direction:
                • Each PW packet would be replicated and = forwarded thru both W and P LSPs
                • =A0Replication would leave the PW label= (and everything after this label) the same for both copies, so that only T= unnel labels and accompanying=A0linke layer encapsulations wo= uld be different
              • In the Rx direction:
                • Both W a= nd P LSPs would be terminated, i.e., their labels would be popped an= d, if the resulting packets are still labeled, the next label looked up
                • PW packets received from the Active= LSP would be forwarded to the appropriate PW Forwarder, and PW pack= ets received from the inactive LSP would be silently discarded

            If this understanding is correct, this wo= uld mean that treatment of the received PW labels would depend on the speci= fic terminated LSP from which the packets labeled with those have been rece= ived. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW label= s from=A0the per-interface space(even this would be non-trivi= al, because there is no way to guarantee that the same label value has=A0si= miilar meaning in different label spaces). =A0But, as per RFC 4447, PW labels MUST be allocated from the per= -platform label space.

            And of course, simply discarding all the = packets received from the inactive LSP would not do because this would affe= ct CC operation.

            =A0

            Did I miss something substantial in my an= alysis?

            =A0

            Please note also that 1:1 protection coul= d rely on the remote Tx endpoint only sending packets to the (common= ) Active LSP making life simpler (no real need for selection on the Rx side= ).

            =A0

            I understand that draft-ietf-mpls-tp-linear-protection is in the final sta= ges of the WG discussion, and apologize for raising this question so late. = But late is (sometimes) better than never...

            =A0

            Regards,

            =A0=A0=A0=A0 Sasha

            =A0

            =A0

            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


            --bcaec53f95dd10a42304a5fed5ec-- From Alexander.Vainshtein@ecitele.com Sat Jun 18 12:02: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 6412511E81FC; Sat, 18 Jun 2011 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396] 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 nljVXDvZ88+C; Sat, 18 Jun 2011 12:02:26 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3487411E81FB; Sat, 18 Jun 2011 12:02:24 -0700 (PDT) X-AuditID: 93eaf2e7-b7c2dae0000028e9-2c-4dfcf63853d3 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id B6.F6.10473.836FCFD4; Sat, 18 Jun 2011 22:02:16 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 18 Jun 2011 22:02:22 +0300 From: Alexander Vainshtein To: Greg Mirsky Date: Sat, 18 Jun 2011 21:58:41 +0300 Thread-Topic: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt0ynNZ3JEDsDySsWhgBj3eR20rgAFpOiu 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_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLsWRmVeSWpSXmKPExsUy+dWnL7oW3/74GvzaIWux7ukzJoumOZsZ Lb5Ne8pqcWvpSlaLvk9bWCzOPZ3DaLFx90w2B3aPKb83snr8+nqVzWPnrLvsHkuW/GTy+Ln+ KnsAa1QDo01iXl5+SWJJqkJKanGyrVJAUWZZYnKlkkJmiq2SoZJCQU5icmpual6JrVJiQUFq XoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLJTUzY0tuYKycgsVkjVzU3MzFHI TS0uTkxPVQCKJGxhzjhzwrPgdFHFq65vzA2M0xO6GDk5JARMJGZcOcsIYYtJXLi3nq2LkYtD SGA3o0T73+1MEM40Rom599awglSxCdhKbFp9lw3EFhFQl+jcdpwdpIhZ4DaLxKzHt9lBEiwC qhLfd5wE6ubgEBaIkXjeJAdRHysx+1UHI4RtJHH1xkKwmbwC/hJ3nn+G2tzCKPF+xVOwIk4B R4nTc/aygNiMQOd9P7WGCcRmFhCXuPVkPhPE2QISS/acZ4awRSVePv7HClEvKnGnfT0jRH2+ xMOLU6CWCUqcnPmEBaJeUuLgihssExjFZiEZOwtJyywkLRBxPYkbU6ewQdjaEssWvmaGsHUl Zvw7xIIsvoCRfRWjaGZOQUlSbrqBoV5qcmZJak6qXnJ+7iZGSCJ7voPx13yVQ4wCHIxKPLwJ zb99hVgTy4orcw8xSnIwKYnyTvz6x1eILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/iHKAcb0pi ZVVqUT5MyhUY+hOZpbiT84HJOa8k3tjAADdHSZz3afIbXyGBdGDSzE5NLUgtgpkjw8GhJME7 AWS9YFFqempFWmZOCUKaiYMT5AweoDM4QGp4iwsSc4sz0yHypxiNORatfXmIkWPZ7DeHGIVY 8vLzUqXEeXVBSgVASjNK8+CmgTJc/f///18xigODQZi3EaSKB5gd4ea9AlrFBLTq369fIKuA GQkuJdXAOOnVHDbbx/y6kSdSOTYcOPjg8N/Loryndi43WDbd/dgxQ/5NESsPO6/4eUWv/c/f iIuy+i8+2T03Fn/fEF349tayt2Yfnp2t+fhPqtml5+7xYE+/iLidKzx59Fs3Gx7zL5mqe+rC 6rzUv5Ea0l8WNy8IEFSTEZ13zF2I4VtLlNLWYF57ya8LnZVYijMSDbWYi4oTAUaOe95LBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? 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, 18 Jun 2011 19:02:27 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. However, I disagree with your conclusion: if you discard the traffic at the= LSP level (i.e. based on the incoming tunnel label), you would also discard= CC and PSC traffic: at this level they are undistinguishable from the PW tr= affic. The situation with the PW protection will be indeed different because Workin= g and Protection PWs would use different PW labels. Hopefully this clarifies my point. Regards, Sasha ________________________________ From: Greg Mirsky [gregimirsky@gmail.com] Sent: Saturday, June 18, 2011 7:17 PM To: Alexander Vainshtein Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; mpls@ietf.o= rg; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pw= e3; Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant (st= bryant@cisco.com) Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are th= ey compatible? Dear Sasha, I think that there is one assumption in line of your logic that changes the= result. When we consider 1+1 LSP protection sink discards traffic from one source on= LSP level. As result there should not be issue with Rx on PW client traffic= since sink receives PW packets only from Active LSP and PW packets from Ina= ctive LSP would never be seen. If we consider 1:1 PW protection, then, as I imagine, we have redundant PW a= nd thus PW labels are different. Then the sink selects one of PWs as active= but there should be no issue with PW labels. Please let me know if understood scenarios correctly. Kind regards, Greg On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein > wrote: Hi all, I would highly appreciate some clarification on the following issue: Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP d= ata plane? We have been recently reminded by Daniel Cohn that 1+1 protection has been d= eclared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more,= Req. #65-B states that it MUST be supported in the unidirectional mode for= P2P connectivity. The problematic use case from my point of view is PW traffic carried within= a 1+1-protected LSP between a pair of PEs. To the best of my understanding, unidirectional 1+1 linear protection, in it= s absolutely minimal form, would imply that: 1. Some form of proactive connectivity check (CC) would be applied to both Wor= king (W) and Protection (P) LSPs. It is my understanding that the GAL/G-ACH= mechanism would be used as the encapsulation for the CC packets 2. Based on the results of CC, one of the incoming LSPs would be selected as Ac= tive 3. When in comes to PW client traffic in these LSPs: * In the Tx direction: * Each PW packet would be replicated and forwarded thru both W and P LSPs * Replication would leave the PW label (and everything after this label) the= same for both copies, so that only Tunnel labels and accompanying linke lay= er encapsulations would be different * In the Rx direction: * Both W and P LSPs would be terminated, i.e., their labels would be popped an= d, if the resulting packets are still labeled, the next label looked up * PW packets received from the Active LSP would be forwarded to the= appropriate PW Forwarder, and PW packets received from the inactive LSP wou= ld be silently discarded If this understanding is correct, this would mean that treatment of the rece= ived PW labels would depend on the specific terminated LSP from which the pa= ckets labeled with those have been received. In principle, this would be pos= sible if we would treat these LSPs and interfaces and allocate PW labels fro= m the per-interface space(even this would be non-trivial, because there is n= o way to guarantee that the same label value has simiilar meaning in differe= nt label spaces). But, as per RFC 4447, PW labels MUST be allocated from th= e per-platform label space. And of course, simply discarding all the packets received from the inactive= LSP would not do because this would affect CC operation. Did I miss something substantial in my analysis? Please note also that 1:1 protection could rely on the remote Tx endpoint on= ly sending packets to the (common) Active LSP making life simpler (no real n= eed for selection on the Rx side). I understand that draft-ietf-mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never... 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. _______________________________________________ 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_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
            Dear Greg,
            Lots of thanks for a prompt response.
             
            However, I disagree with your conclusion= : if you discard the traffic at the LSP level (i.e. based on the incoming tu= nnel label), you would also discard CC and PSC traffic: at this level they a= re undistinguishable from the PW traffic.
            The situation with the PW protection will be indeed different because W= orking and Protection PWs would use different PW labels.
             
            Hopefully this clarifies my point.
            Regards,
                 Sasha
            From: Greg Mirsky= [gregimirsky@gmail.com]
            Sent: Saturday, June 18, 2011 7:17 PM
            To: Alexander Vainshtein
            Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; mpls= @ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; Mishael Wex= ler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bry= ant (stbryant@cisco.com)
            Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data pl= ane: are they compatible?

            Dear Sasha,
            I think that there is one assumption in line of your logic that changes the= result.
            When we consider 1+1 LSP protection sink discards traffic from one sourc= e on LSP level. As result there should not be issue with Rx on PW client tra= ffic since sink receives PW packets only from Active LSP and PW packets from= Inactive LSP would never be seen.
            If we consider 1:1 PW protection, then, as I imagine, we have redundant PW a= nd thus PW labels are different. Then the sink selects one of PWs as active= but there should be no issue with PW labels.

            Please let me know if understood scenarios correctly.

            Kind regards,
            Greg

            On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainsh= tein <Alexander.Vainshtein= @ecitele.com> wrote:
            Hi all,
            I would highly appreciate so= me clarification on the following issue:
            Is 1+1 linear protection= architecture for LSPs compatible with the MPLS-TP data plane?
            We have been recently remind= ed by Daniel Cohn that 1+1 protection has been declared as MUST to suppo= rt for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states that i= t MUST be supported in the unidirectional mode for P2P connectivity.
             
            The problematic use case fro= m my point of view is PW traffic carried within a 1+1-protected LSP betw= een a pair of PEs.
             
            To the best of my understand= ing, unidirectional 1+1 linear protection, in its absolutely m= inimal form, would imply that:
            1. Some form of proactive connectivity chec= k (CC) would be applied to both  Working (W) and Protection= (P) LSPs. It is my understanding that= the GAL/G-ACH mechanism would be used as the encapsulation for the CC packets
            2. Based on the results of CC, one of the i= ncoming LSPs would be selected as Active
            3. When in comes to PW client traffic<= a> in these LSPs:
              • In the Tx direction:<= /font>
                • Each PW packet would be replicated and f= orwarded thru both W and P LSPs
                •  Replication would leave the PW lab= el (and everything after this label) the same for both copies, so that only= Tunnel labels and accompanying linke layer encapsulation= s would be different
              • In the Rx direction:
                • Both W an= d P LSPs would be terminated, i.e., their labels would be popped and,= if the resulting packets are still labeled, the next label looked up=
                • PW packets received from the Active= LSP would be forwarded to the appropriate PW Forwarder, and PW packe= ts received from the inactive LSP would be silently discarded

            If this understanding is correct, this wou= ld mean that treatment of the received PW labels would depend on the specifi= c terminated LSP from which the packets labeled with those have been receive= d. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW labels= from the per-interface space(even this would be non-triv= ial, because there is no way to guarantee that the same label value has = ;simiilar meaning in different label spaces).  But, as per RFC 4447, PW labels MUST be allocated from the p= er-platform label space.

            And of course, simply discarding all the p= ackets received from the inactive LSP would not do because this would affect= CC operation.

             

            Did I miss something substantial in my ana= lysis?

             

            Please note also that 1:1 protection could= rely on the remote Tx endpoint only sending packets to the (common)= Active LSP making life simpler (no real need for selection on the Rx side).=

             

            I understand that draft-ietf= -mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never...

             

            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.


            _______________________________________________
            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_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_-- From davarish@yahoo.com Sat Jun 18 13:43: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 B094321F85E2 for ; Sat, 18 Jun 2011 13:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, UNPARSEABLE_RELAY=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 3YRqUL5O5V9q for ; Sat, 18 Jun 2011 13:43:31 -0700 (PDT) Received: from smtp108-mob.biz.mail.gq1.yahoo.com (smtp108-mob.biz.mail.gq1.yahoo.com [98.136.185.199]) by ietfa.amsl.com (Postfix) with SMTP id 7B2D321F85E1 for ; Sat, 18 Jun 2011 13:43:31 -0700 (PDT) Received: (qmail 11300 invoked from network); 18 Jun 2011 20:43:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:Cc:From:Date:Content-Type:MIME-Version; b=qlDhpurPR/97BMNMREEYkqYpnI4xhEiWpK75HFvcyXU5P3lYLyJAhzpmNClj8cJ028CwBfePdC02z7zlcu96vrzEMlXg6GN7k6WYNl7sc2bSqXn+tYwj6rwHtXT3pid5OB/16486yA9xfIQAA+calFwYrEvxGsyYm+8YehHLgC4= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308429807; bh=FNW2hzhUrGk3VCubm2OyMzjvSeQ/PyWd99JMw67MU+A=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:Cc:From:Date:Content-Type:MIME-Version; b=KvYnaZFslfSJ+dCcjhCc7yx89h364uEmrD2ojAPv9g1ttyJjMg5Dx6zY9Ifm95wlKWlEYEcy3pziUm0WQik1MbO7O7h9rYFpcdJFz8tzLk4/FaqlXNaovf7knSRFtAvDPAJwTTIvY58n8b1+fTqzT3lwy5qCtewRLrXXPyVAVtE= Received: from b15.c27.bise6.blackberry (davarish@74.82.86.201 with xymcookie) by smtp108-mob.biz.mail.gq1.yahoo.com with SMTP; 18 Jun 2011 13:43:26 -0700 PDT X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-YMail-OSG: 3c0T3lcVM1k0I263SuqJMGafKQexPnfdKxcPudqKk2SglfE wywmlrAmrTNmh_.UqnJoIAgOJFW80OURxlEJYkn2BLSSXiSkMe289HYELxNt G8vNZrfHPlsnK2TVO3avmriU0yZSvwktf0_R4obj9bjp7z7eBV9ahmuBecH4 tjqZ4k74DbfAcwqr6vIRBVC0FJ9Moow2kgJat.4A4eha7fCWe9CiGm6otxqF RDVpUnxDMgTS8uZ9_wUcUOdFIe2ItziaYMuPoQhpah7u.oRf5LZCuymaTWro Ns2SvwyRh7P0EcMJtC0fhmL1Seo2Nf6ipp9rZ2orSOTlNJzIgah4vBmvuQBb a_mNgoBYSbfiVIV.G_3_U52ONCGaL03fxoktr7anC X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 1398490709 Message-ID: <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> Content-Transfer-Encoding: quoted-printable X-Priority: Normal References: , In-Reply-To: Sensitivity: Normal Importance: Normal To: "Alexander Vainshtein" , mpls-bounces@ietf.org, "Greg Mirsky" From: davarish@yahoo.com Date: Sat, 18 Jun 2011 20:43:38 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: davarish@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 20:43:31 -0000 Sasha All=20traffic=20except=20LSP=20OAM=20traffic=20from=20protection=20LSP=20mu= st=20be=20discarded=20in=20Rx.=20So=20what=20is=20the=20issue? Thx Shahram Sent=20via=20BlackBerry=20by=20AT&T -----Original=20Message----- From:=20Alexander=20Vainshtein=20 Sender:=20mpls-bounces@ietf.org Date:=20Sat,=2018=20Jun=202011=2021:58:41=20 To:=20Greg=20Mirsky Cc:=20mpls@ietf.org;=20Vladimir=20Kleiner;=20Mishael=20Wexler;=20pwe3;=20Oren=20Gal;=20John=20Shirron;=20Stewart=20Bryant=20\(stbryant@cisco.com\);=20Rotem=20Cohen Subject:=20Re:=20[mpls]=20[PWE3]=201+1=20linear=20LSP=20protection=20and=20= MPLS-TP=20data=20plane: =20are=20they=20compatible? _______________________________________________ mpls=20mailing=20list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sat Jun 18 21:04:50 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 6F22211E80BD; Sat, 18 Jun 2011 21:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396] 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 L-5grqlbhmcK; Sat, 18 Jun 2011 21:04:50 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id EEB8E11E80B6; Sat, 18 Jun 2011 21:04:48 -0700 (PDT) X-AuditID: 93eaf2e7-b7c82ae0000020ff-c6-4dfd7557b9bc Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id A1.D0.08447.7557DFD4; Sun, 19 Jun 2011 07:04:39 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 19 Jun 2011 07:04:46 +0300 From: Alexander Vainshtein To: "davarish@yahoo.com" , "mpls-bounces@ietf.org" , Greg Mirsky Date: Sun, 19 Jun 2011 07:04:45 +0300 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qM Message-ID: References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> In-Reply-To: <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> 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: H4sIAAAAAAAAA2VTW0wTWRjOmZm2Q2XWoVp7IKjNCCS7aw31Ou5a18f6QMCIl/ggDtNjO7Gd Np1BrT5ICGgWE7O7GrLb9VqrUVEJRI0CkbRe4jYqJhAgoEYCDYK3WI0XFHCmE1mM5+k7//d9 5zvn5P9J3FRjyCEFUUZBkfMyeiNxcCT11raxYqyosD+Cs7GhKsC+q0vq2Ja2TgPbe+qsjj2Q ukSw95OHwSq989CnRp3zWviRwRmNfsSc4fANrITYVAlWcKLolzkZWV1I4h1MSVDYzvEhxiq4 HIydsQa8HI98SJQdDBcIINHFrDRav1srFJkgWpHI+12C6HYwq9cW21h2yXKbnVlZMM++6Fdj qUeQrMjm4wSv1YckiXMjq1LZcgn3NHYdMQSGpu98s69DXwmOULUgg4T0YtjdfgZoeBZ88LhB XwuMpIluAfBqrBvTNnUAXu5tTqv0tAM21T/Sq3gmXQPg/uosVYTTdzGYetdnUAmCzof9LyOY imfQ5fDiqSpMM/Cwq3JCp+GFMHnlZFpP0cXwzvh+Qkurx+Dz5r60IYMOwIGeG+lkoNzvfeJ8 uo7TFtg7eAzT7k3DaGs7rmEzHB4Y12l6M3y4rwFo+vnweEtKr+Gf4ekTz3AtOAv+988goXmz YexMD/EHsISnRISn2MNT7OEp9uOAOAfMgjcgl/vchfYFiBdk5EULeL+vCWhNNHQVjB7LiwOa BEwm9bRgrMik47ZLIV8cZJMYY6ZqZaX0Q7nfFfJwkqcsWOFFUhxAEmdmUqG1Cke5uNAuFPR/ pVjlm//Ec6bxfqVdRblsUWHhNxvGQiX550Um2q303TaEAij41ZpLkgykGtTErCByo51bBa/8 P42RGWpyppJ8QtVQUoDzSYJb4xPARkYuDMeBiRD9IsqxUDWqiFZFngpx8hx1evZMTEyMAIvy 5hmUW1VlKrM1edKIEoIpIeOjo2qIMh+TVE4lWC83J8YGS49iu2KONX1P7m05eLP01qey6mXJ V9HOPXUbPh9+kX/PYlv3Ovdfb+bWvPntZcup+Et3m7k1tKZ+6aZQTXHL75HfTjrn7C6WE4n2 vz4c2Fx1Le+Xyx3039Hq97M9Jav3+lI/yjFjdast+3bHwN3I8I650/ML+s9dfzvalmtnCMnD 2X/CgxL3BQxKDzEYBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? 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, 19 Jun 2011 04:04:50 -0000 Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only differenti= ate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW p= ackets received from both active and inactive LSPs look exactly the same wit= h the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms of= RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Sh= irron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:= are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren= Gal; John Shirron; Stewart= Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? _______________________________________________ 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 Alexander.Vainshtein@ecitele.com Sun Jun 19 11:13: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 DD8C011E80AB; Sun, 19 Jun 2011 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396] 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 L18CKZ5+u1jB; Sun, 19 Jun 2011 11:13:59 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3163911E80D2; Sun, 19 Jun 2011 11:13:57 -0700 (PDT) X-AuditID: 93eaf2e7-b7c82ae0000020ff-1d-4dfe3c5da4bd Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id D2.B3.08447.D5C3EFD4; Sun, 19 Jun 2011 21:13:49 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sun, 19 Jun 2011 21:13:55 +0300 From: Alexander Vainshtein To: "davarish@yahoo.com" , "mpls-bounces@ietf.org" , Greg Mirsky Date: Sun, 19 Jun 2011 21:13:55 +0300 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMAB2hhpo= Message-ID: References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry>, 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: H4sIAAAAAAAAA2VTf0wTVxzfu7u2R+XcUcA+ycwuNzBBV0eji6dQZrJkYVlAIpIlywy7Xh/t be216R0ETIxNh5KgYRqIy25b6GYxys9ANAGd2ayLATLdJvsVxBmjlQDGTWJYKALeccowvr8+ 730+n+/nvZfvl8RtDZYcUpQUFJZ4P2u2Ei1TM48c+4oWSwuSXZu4SxNRwM2eSJq4C9//ZuHG 2s+YuOaZswR3LfkV2GUuaZ3vM5UMqjctJfH4HFaiqpexcuKDCCjiJSmo8ApiPEgWXGx5WKzl hXqWET0u1skyIT8voACSFBfLh0JI8rDFVuaFVaTJRIlBkhD0iJLXxb5bsdvBcW/ucDjZ4o2v ObcWWvf6RJlBjgAv+pkAkmXeixjt5KOzuK+7519z6EtYd+72ZRABn2Y1gTQS0ttga/wHzMDr 4C9/95qbgJW00YMANvX/jhmbVgDPT5wz6Soz7YL9nTfNOs6iDwF4pCFDF+H0Txicmb1h0QmC zoMdCw8JHWfSbtjTHsUMgwD/iCyZDLwTDjVe1wqRJEXvhqM3HEbYPxhMnZ5fDkijy2H8645l DLTr/TfStVwHp+1w7G7b02vTMP7dz7iBs+HknUWToc+G4429wNC/DmMXZswG3gxPfTO9rKfo DDj8xV3C8K6Hl07/RRwDdnVVhLrKrq6yq6vsMUB0gGzRH1LcAW+BcwsSRAX50RYhGOgHRg9N DIBUW24C0CRg0ymfY7HUZuJr5fpAAqwnMTabKt+pHa11Bz31Pl72VYVr/EhOAEjibBa1kK9x lIev34/CwWcUp/3ycTxnjRDUulVSqrYWFDy3Ye1UUrhfaqO9Wtt9glAIhZ9ZXyFJFlJ9hVrV jDDyorpq0a/8T2Nkmp6criXbdQ0lh/iALHoNfgQ4yG+7JxPARkhBCeXYqWZdROsiX420Ukcf noNLS0tTwK69OZOSdFW6Nlorlaa0EEwLWUyl9BBtPFaonAi4V7cu+s6O1gUm7+iQ58dOt9JV bS/ero50mdtiVJybtn3+8nA0v+zh4TuWNc63XqoeU+8/qBj6+NU3Tg6knancFSt7r2X0s/ff zv3wwPza8ck527Ge1HH84obmmG/6UUMClSXbq0Yfj+dXKTX3+q5eSe+INKl5j2d/rfwzemsP 2XI9yBKyj3duwsMy/wSCHEv3FwQAAA== Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? 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, 19 Jun 2011 18:14:00 -0000 Shahram, Greg and all, After some thought: One way to model selection in 1+1 linear protection architecture could be to= define a "special" internal interface in the box and to define the ILM acti= on on the tunnel label of an inactive LSP as "Pop and forward to special int= erface". The special interface then would then forward resulting labeled packets with= a reserved top label to control and discard all the rest. This behavior wou= ld not be part of "normal" MPLS data plane hence no contradictions with its= architecture. I assume that this is roughly the formal model for what Shahram and Greg hav= e said. Regards, Sasha ________________________________________ From: Alexander Vainshtein Sent: Sunday, June 19, 2011 7:04 AM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Sh= irron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:= are they compatible? Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only differenti= ate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW p= ackets received from both active and inactive LSPs look exactly the same wit= h the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms of= RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Sh= irron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:= are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren= Gal; John Shirron; Stewart= Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? _______________________________________________ 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 davari@broadcom.com Sun Jun 19 22: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 3756811E8093; Sun, 19 Jun 2011 22:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 m3lfvWF45hEW; Sun, 19 Jun 2011 22:22:51 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9550211E807B; Sun, 19 Jun 2011 22:22:51 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 19 Jun 2011 22:27:01 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 19 Jun 2011 22:22:37 -0700 From: "Shahram Davari" To: "Alexander Vainshtein" , "davarish@yahoo.com" , "mpls-bounces@ietf.org" , "Greg Mirsky" Date: Sun, 19 Jun 2011 22:22:32 -0700 Thread-Topic: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMADVBtzA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93138B358@SJEXCHCCR02.corp.ad.broadcom.com> References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> 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: 61E005AF62O11202431-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? 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, 20 Jun 2011 05:22:52 -0000 Hi Sasha, That is correct. But the behavior is what I call Leaky drop. Meaning that a= ll the Protection LSP packets must be dropped (including the PW traffic) ex= cept the LSP OAM packets. Thanks Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Saturday, June 18, 2011 9:05 PM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only different= iate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW = packets received from both active and inactive LSPs look exactly the same w= ith the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms o= f RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Ore= n Gal; John Shirron; Stewar= t Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= : are they compatible? _______________________________________________ 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 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 From davari@broadcom.com Sun Jun 19 22:41: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 70A3D11E80E5; Sun, 19 Jun 2011 22:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 EUBOSuDWVTiJ; Sun, 19 Jun 2011 22:41:52 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id B38EF11E80E6; Sun, 19 Jun 2011 22:41:52 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 19 Jun 2011 22:46:21 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 19 Jun 2011 22:41:40 -0700 From: "Shahram Davari" To: "Alexander Vainshtein" , "davarish@yahoo.com" , "mpls-bounces@ietf.org" , "Greg Mirsky" Date: Sun, 19 Jun 2011 22:41:16 -0700 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMAB2hhpoAGDsEAA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93138B372@SJEXCHCCR02.corp.ad.broadcom.com> References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry>, 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: 61E001273B46064640-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? 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, 20 Jun 2011 05:41:53 -0000 Hi Sahsa, Actually what you can do is to define 2 special interfaces, one for working= and one for protection LSP. Then for working interface, set the behavior a= s pop and forward as normal, and for protection interface pop and forward t= o control plane only reserved labels. In case of failure the behavior of th= e two interfaces must be changed. IS that correct? Thx Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Sunday, June 19, 2011 11:14 AM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Shahram, Greg and all, After some thought: One way to model selection in 1+1 linear protection architecture could be t= o define a "special" internal interface in the box and to define the ILM ac= tion on the tunnel label of an inactive LSP as "Pop and forward to special = interface". The special interface then would then forward resulting labeled packets wit= h a reserved top label to control and discard all the rest. This behavior w= ould not be part of "normal" MPLS data plane hence no contradictions with i= ts architecture. I assume that this is roughly the formal model for what Shahram and Greg ha= ve said. Regards, Sasha ________________________________________ From: Alexander Vainshtein Sent: Sunday, June 19, 2011 7:04 AM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only different= iate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW = packets received from both active and inactive LSPs look exactly the same w= ith the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms o= f RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Ore= n Gal; John Shirron; Stewar= t Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= : are they compatible? _______________________________________________ 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 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. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From sboutros@cisco.com Sun Jun 19 23:19: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 BA53421F8471 for ; Sun, 19 Jun 2011 23:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ZHRsg91jaJEY for ; Sun, 19 Jun 2011 23:19:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC321F846E for ; Sun, 19 Jun 2011 23:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=13983; q=dns/txt; s=iport; t=1308550783; x=1309760383; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=yOzY2k0izuXXS3b/f/6/x0DQDfceAB2NpoSkkZaKBt4=; b=dahz5IaQU2nIcz5WF46oXVMsp2F3qjFtZY1nKXuHDkF+65f6IrXz5LqD 5JxpLBj0wxlkpx0upK/fNH/41tfeqC8rFVf1UXevDTcnbMgpx1L6fS9QE 473H72LTGqlUkFb2hv8deBR8n+N1jmRjupJDM+WFYDRYca7dRmU7iGFzt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAIrl/k2rRDoI/2dsb2JhbABHDIdcj3WPCneIc6AknSyDIIMKBIcgjyeLOA X-IronPort-AV: E=Sophos;i="4.65,391,1304294400"; d="scan'208,217";a="717021305" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 06:19:31 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5K6JVqj018750; Mon, 20 Jun 2011 06:19:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Jun 2011 23:19:30 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.166.155]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Jun 2011 23:19:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 19 Jun 2011 23:19:26 -0700 To: Gregory Mirsky , "Siva Sivabalan(msiva)" , Rahul Aggarwal , "martin.vigoureux@alcatel-lucent.com" , "dai.xuehui@zte.com.cn" , "swallow@cisco.com" , David Ward , "stbryant@cisco.com" , "cpignata@cisco.com" , "Bitar, Nabil N" , BUSI ITALO , "LEVRAU, LIEVEN (LIEVEN)" , "laurent.ciavaglia@alcatel-lucent.com" , "wu.bo@zte.com.cn" , "yang_jian@zte.com.cn" , "mpls@ietf.org" From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_35203921==.ALT" Message-ID: X-OriginalArrivalTime: 20 Jun 2011 06:19:29.0903 (UTC) FILETIME=[0359B7F0:01CC2F12] Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 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, 20 Jun 2011 06:19:44 -0000 --=====================_35203921==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Greg, At 04:52 PM 6/7/2011, Gregory Mirsky wrote: >Hi Sami, >thank you for your response. Please find my notes below and in-lined >with tag GIM>>: >second paragraph of Introduction refers to use of LSP-Ping "either >over GACh or using native IP addressing". I think that this is in >reference to different encapsulations of LSP-Ping and the text might >benefit from the clarification and note that with either type of >encapsulation an LSP-Ping is always transported in-band over MPLS-TP >network. Considering that characterizing G-ACh encapsulation as >exclusively "in-band option" for LI-LB transport might be >misleading. Perhaps it can be referred as "G-ACh option". Sami: Agreed, will clarify the text to align more with the on-demand-cv draft that allows LSP Ping to be G-ACH encaped with or without IP address. >Section 3.3 What is application of Informational Return Code? Sami: No application so far. >Section 3.5 Which Operation and Return Code values should be used >when negotiating CHAP Authentication? Sami: We will use Request and Response messages with the same operation being authenticated, return codes will reflect authentication success/failures in case we get one. >section 3.6.2 states that "only LI-LB response TLV might be present >in LSP Ping Echo request message". I think it is a typo and this >clarification is in regard to LSP Ping Echo reply message, not request. Sami: Will address. > * In 6.3.g it might be "back to MEP-A' in place of "back to A" > to be consistent with terminology used. Sami: Will address. >I find draft-ietf-mpls-tp-ach-tlv-02 expired and IANA's ACH TLV >Registry is empty. The document doesn't request IANA allocation of >ACH TLV types for Source MEP-ID, Destination MEP-ID, Destination >MIP-ID, and Authentication. How these ACH TLV types will be defined? Sami: Will get rid of the MEP-IDs and use source/tgt identifiers defined in the on-demand-cv draft. >Reference 9 is missing mention of RFC 1334. Sami: Will add. Thanks, Sami > Regards, > Greg > > >---------- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >Of Sami Boutros >Sent: Monday, June 06, 2011 10:16 PM >To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; >martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >swallow@cisco.com; David Ward; stbryant@cisco.com; >cpignata@cisco.com; Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN >(LIEVEN); laurent.ciavaglia@alcatel-lucent.com; wu.bo@zte.com.cn; >yang_jian@zte.com.cn; mpls@ietf.org >Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 > >Hi Greg, > >Here are responses to your comments please let us know if you are OK >with the Responses. > >> * section 3.2 I think that there are mandatory TLVs for LI-LB >> and optional. Mandatory TLV for LI might be Source MEP-ID, >> Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. >> Optional, e.g. Authentication TLV. > >Response-1: Correct. > GIM>> I don't find Source and Destination MEP-ID, MIP-ID TLVs > being discussed or referenced even though section 6.3 refers to > validation of Source and Destination/target MEP-IDs. >> * section 3.3.5 describes Return Code in Return TLV for >> LSP-ping option of LI-LB signaling. For in-band option Return Code >> has different values and values listed in this section are for >> field Cause Code. I think it would be beneficial to have some >> uniformity across LI-LB signalling options and in Return TLV have >> both Return Code and Cause Code fields with values identical for >> in-band and LSP-Ping options. > >Response-2: Addressed in latest version -02 where we made this >section shared by both in-Band and LSP-Ping, we as well limited the ># of TLVs used by LSP Ping. > GIM>> Great >> * section 3.3.6 defines Authentication TLV for LSP-Ping option. >> Authentication of LB request but in-band option doesn't have >> provision to indicate that Authentication is in use. I propose to >> allocate MSB of Reserved field as Authentication flag. > >Response-3: Addressed in latest version -02 by making authentication >TLV common to both in-band and LSP Ping. > GIM>> Agree >> * section 6.3 mentions that Authentication may be used both in >> Lock request and Lock response. I think that if Authentication was >> present in Lock request and accepted by remote MEP, then Lock >> response must have Authentication. Similar is applicable to use of >> Authentication in Unlock request/response, and Setting/Removing LB . > >Response-4: We described authentication procedures in more details >in section 3.5 of latest draft version, please have a look to see if >it addresses your concern. >GIM>> I was thinking of allocating an Authnetication (A) flag from >Reserved field to indicate whether Authentication is in use for >given LB and LI. Note, that setting of A flag on LI Lock request or >LB Set request defines use of Authentication not only in >corresponding replies but in Unlock/Unset as well. >> * section 6.5.b I think that there's no guarantee that sender >> of LI request will not generate false positive after remote MEP >> locks the LSP. Perhaps, if proactive OAM is enabled, the remote >> MEP should send LI reply but it might stop sending OAM messages >> after 3*TxPeriod interval. > >Response-5: Addressed in section 6.3 last paragraph > >MEP-D will lock the LSP, resulting in that all traffic from D to A, >including all OAM traffic, stops. > >a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv >and cc packets, but since it has been informed that the LSP will be >locked it will take no action(s). >b. When MEP-A receives the LI ACK, MEP-A discontinues sending other >OAM traffic, e.g. cv and cc packets. MEP-D will detect this, but >since it is in Locked state it will take no action. >GIM>> Thank you. > >Thanks, > >Sami --=====================_35203921==.ALT Content-Type: text/html; charset="us-ascii" Hi Greg,

            At 04:52 PM 6/7/2011, Gregory Mirsky wrote:
            Hi Sami,
            thank you for your response. Please find my notes below and in-lined with tag GIM>>:
              second paragraph of Introduction refers to use of LSP-Ping "either over GACh or using native IP addressing". I think that this is in reference to different encapsulations of LSP-Ping and the text might benefit from the clarification and note that with either type of encapsulation an LSP-Ping is always transported in-band over MPLS-TP network. Considering that characterizing G-ACh encapsulation as exclusively "in-band option" for LI-LB transport might be misleading. Perhaps it can be referred as "G-ACh option".

            Sami: Agreed, will clarify the text to align more with the on-demand-cv draft that allows LSP Ping to be G-ACH encaped with or without IP address.

              Section 3.3 What is application of Informational Return Code?

            Sami: No application so far.

              Section 3.5 Which Operation and Return Code values should be used when negotiating CHAP Authentication?

            Sami: We will use Request and Response messages with the same operation being authenticated, return codes will reflect authentication success/failures in case we get one.

              section 3.6.2 states that "only LI-LB response TLV might be present in LSP Ping Echo request message". I think it is a typo and this clarification is in regard to LSP Ping Echo reply message, not request.

            Sami: Will address.

            • In 6.3.g it might be "back to MEP-A' in place of "back to A" to be consistent with terminology used.

            Sami: Will address.

              I find draft-ietf-mpls-tp-ach-tlv-02 expired and IANA's ACH TLV Registry is empty. The document doesn't request IANA allocation of ACH TLV types for Source MEP-ID, Destination MEP-ID, Destination MIP-ID, and Authentication. How these ACH TLV types will be defined?

            Sami: Will get rid of the MEP-IDs and use source/tgt identifiers defined in the on-demand-cv draft.

              Reference 9 is missing mention of RFC 1334.

            Sami: Will add.

            Thanks,

            Sami

                Regards,
                    Greg

            From: mpls-bounces@ietf.org [ mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros
            Sent: Monday, June 06, 2011 10:16 PM
            To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; swallow@cisco.com; David Ward; stbryant@cisco.com; cpignata@cisco.com; Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN (LIEVEN); laurent.ciavaglia@alcatel-lucent.com; wu.bo@zte.com.cn; yang_jian@zte.com.cn; mpls@ietf.org
            Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01

            Hi Greg,

            Here are responses to your comments please let us know if you are OK with the Responses.

            • section 3.2 I think that there are mandatory TLVs for LI-LB and optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication TLV.

            Response-1: Correct.
             GIM>> I don't find Source and Destination MEP-ID, MIP-ID TLVs being discussed or referenced even though section 6.3 refers to validation of Source and Destination/target MEP-IDs.
            • section 3.3.5 describes Return Code in Return TLV for LSP-ping option of LI-LB signaling. For in-band option Return Code has different values and values listed in this section are for field Cause Code. I think it would be beneficial to have some uniformity across LI-LB signalling options and in Return TLV have both Return Code and Cause Code fields with values identical for in-band and LSP-Ping options.

            Response-2: Addressed in latest version -02 where we made this section shared by both in-Band and LSP-Ping, we as well limited the # of TLVs used by LSP Ping.
             GIM>> Great
            • section 3.3.6 defines Authentication TLV for LSP-Ping option. Authentication of LB request but in-band option doesn't have provision to indicate that Authentication is in use. I propose to allocate MSB of Reserved field as Authentication flag.

            Response-3: Addressed in latest version -02 by making authentication TLV common to both in-band and LSP Ping.
             GIM>> Agree
            • section 6.3 mentions that Authentication may be used both in Lock request and Lock response. I think that if Authentication was present in Lock request and accepted by remote MEP, then Lock response must have Authentication. Similar is applicable to use of Authentication in Unlock request/response, and Setting/Removing LB .

            Response-4: We described authentication procedures in more details in section 3.5 of latest draft version, please have a look to see if it addresses your concern.
            GIM>> I was thinking of allocating an Authnetication (A) flag from Reserved field to indicate whether Authentication is in use for given LB and LI. Note, that setting of A flag on LI Lock request or LB Set request defines use of Authentication not only in corresponding replies but in Unlock/Unset as well.
            • section 6.5.b I think that there's no guarantee that sender of LI request will not generate false positive after remote MEP locks the LSP. Perhaps, if proactive OAM is enabled, the remote MEP should send LI reply but it might stop sending OAM messages after 3*TxPeriod interval.

            Response-5:  Addressed in section 6.3 last paragraph

            MEP-D will lock the LSP, resulting in that all traffic from D to A, including all OAM traffic, stops.

            a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc packets, but since it has been informed that the LSP will be locked it will take no action(s).
            b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM traffic, e.g. cv and cc packets. MEP-D will detect this, but since it is in Locked state it will take no action.
            GIM>> Thank you.

            Thanks,

            Sami

            --=====================_35203921==.ALT-- From Alexander.Vainshtein@ecitele.com Sun Jun 19 23:51: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 10ECD21F8598; Sun, 19 Jun 2011 23:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396] 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 XTPWOZrFQdbS; Sun, 19 Jun 2011 23:51:11 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC421F8595; Sun, 19 Jun 2011 23:51:09 -0700 (PDT) X-AuditID: 93eaf2e7-b7b6cae000001c92-ab-4dfeedd2b4cc Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 24.F5.07314.2DDEEFD4; Mon, 20 Jun 2011 09:50:59 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 20 Jun 2011 09:51:05 +0300 From: Alexander Vainshtein To: Shahram Davari , "davarish@yahoo.com" , "mpls-bounces@ietf.org" , Greg Mirsky Date: Mon, 20 Jun 2011 09:51:01 +0300 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMAB2hhpoAGDsEAAACc5zg Message-ID: References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry>, <2C2F1EBA8050E74EA81502D5740B4BD6A93138B372@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93138B372@SJEXCHCCR02.corp.ad.broadcom.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: H4sIAAAAAAAAA2WTa0wTWRTH985M2wEZMxSwV+JjHN+PknbR7Gy0RhOzW2KIxkeMxgSG6bWd 2E4nnWKs+0H0i5GNqJH4qKygAR/4IKIfimiUGj/UJ4oYbVQiQnia7BKCi5p2ZzorYpxP/3PP /5zfvZNzSNxcacolRSmIAhLvZY3pxJH+oWFr24dEoa28xcQ1HCjgWnr2Am7kaLeBa7793MTF 6y4YuIqh6wT3uLsKrDA5wx2PjM7Kz1cNzqbwG5OztnYUc4bDd7G1hi1lYBkvSf4gH0SMCymC g10bEHfwQohlRJeDtbOM7OUF5ENS0MHysowkF7s8nfnhW6baRIlBkuB3iZLbwRasX2PluCW/ Wu3s8jkz7flL0zd4RIVBVh8vehkfUhTejRj1pPg67rm674FJPrVwZ7Lqi6kMRGaWgzQS0ovh 0+ZRQteTYOvbBmM5SCfNdDOAxweaCD04CmBf05+45jLSDth48U3KlU1fBnD/w+OpAKcfYrDi 74tGzUXQs+G5RCKls2gBvmivNmg6m3bBuninUde/wT2nXpk0TdFr4P4rBzEdV0HAuwd7VTZJ ptFbYOwjpnmAer+P9y+lNE5bYLyrGtPvTcPam09wXefAvvcJg+7Pga/3NQDdvwjWNA8Zdb0Q nj09gOvcTBg70fX/+yfDlvMviUPAEh6HCI8rD48rD48rrwFEPcgRvXKwxOe22fOQIAaRF+UJ fl8j0KepJwI+Vc+KApoEbAblsSYKzQZ+hxLyRcFkEmNzqM5B9Whiid8V8vCKpyhQ6kVKFEAS Z7OpovdqjnLxoV0o4P+a4tS/fBjPnSD41bmVgkX5Ntt3AWuhuoXBQjPtVuduO0IyCnwtnUKS LKRWq+NtzgwgN9q5TfQGv6UxMk0jZ6jk/C6NrMi8TxHdev4+yCfPXO6LAvLsycEoMBOSX0K5 FqpEa0drVk+pNNZNW6bdyWSyH1jUl2dRvObKUFdtrF+/isJUVLI/hVK3ZCyVWwZWnh7ZW7ch 9s/USJu8imTi/94bKZhWdW3dg9KBa00RhZkR+n1uZbLmWGZhny0299Gczs+W6fKdtvqs+t52 7NnmTa03hisy5mdvrHy+Mr60wz36S0/L7Pbe4rwO342GxIRhi2HriGf9XxMbMeGPtLe1t8oj P53Iixb/7HzXOmv7ppJ5MZZQPLx9AR5Q+P8AN0qvkycEAAA= Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? 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, 20 Jun 2011 06:51:12 -0000 Shahram, Lots of thanks for a prompt response. I doubt the value of two special interfaces: IMHO at least one of the LSPs (= Active) should be terminated (i.e. the ILM for its action would look "Pop an= d look up the next label"). But the "leaky drop" interface seems to be the right thing to do. The name i= s nice. I wonder if adding a clarification would benefit the linear protection draft= ? Regards, Sasha > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 20, 2011 8:41 AM > To: Alexander Vainshtein; davarish@yahoo.com; mpls-bounces@ietf.org; > Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) > Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Hi Sahsa, > > Actually what you can do is to define 2 special interfaces, one for > working and one for protection LSP. Then for working interface, set the > behavior as pop and forward as normal, and for protection interface pop > and forward to control plane only reserved labels. In case of failure > the behavior of the two interfaces must be changed. > > IS that correct? > > Thx > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Sunday, June 19, 2011 11:14 AM > To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) > Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Shahram, Greg and all, > After some thought: > One way to model selection in 1+1 linear protection architecture could > be to define a "special" internal interface in the box and to define > the ILM action on the tunnel label of an inactive LSP as "Pop and > forward to special interface". > > The special interface then would then forward resulting labeled packets > with a reserved top label to control and discard all the rest. This > behavior would not be part of "normal" MPLS data plane hence no > contradictions with its architecture. > > I assume that this is roughly the formal model for what Shahram and > Greg have said. > > Regards, > Sasha > > > > > > ________________________________________ > From: Alexander Vainshtein > Sent: Sunday, June 19, 2011 7:04 AM > To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen > Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Shahram, > The problem IMHO is in the combination of two points : > > - At the LSP level both LSP OAM and PW traffic look exactly the same > (after popping the Tunnel label a labeled packet remains). You can only > differentiate between them when you look up the next label in the stack > > - When you look at the next label after having popped the tunnel label, > PW packets received from both active and inactive LSPs look exactly the > same with the same label from the per-platform label space. > > IMO this means that you cannot describe the desired behavior in the > terms of RFC 3031 and 3032. > > Hopefully this clarifies my question. > > Regards, > Sasha > > > > ________________________________________ > From: davarish@yahoo.com [davarish@yahoo.com] > Sent: Saturday, June 18, 2011 11:43 PM > To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen > Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Sasha > > All traffic except LSP OAM traffic from protection LSP must be > discarded in Rx. So what is the issue? > > Thx > Shahram > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Alexander Vainshtein > Sender: mpls-bounces@ietf.org > Date: Sat, 18 Jun 2011 21:58:41 > To: Greg Mirsky > Cc: mpls@ietf.org; Vladimir > Kleiner; Mishael > Wexler; pwe3; Oren > Gal; John Shirron; > Stewart Bryant \(stbryant@cisco.com\); Rotem > Cohen > Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane: > are they compatible? > > _______________________________________________ > 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. > > _______________________________________________ > 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 iesg-secretary@ietf.org Mon Jun 20 08:08: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 6802221F8555; Mon, 20 Jun 2011 08:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 klfKbEYt6ZQA; Mon, 20 Jun 2011 08:08:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F0821F850E; Mon, 20 Jun 2011 08:08:19 -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.55 Message-ID: <20110620150819.14593.8675.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 08:08:19 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths) 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: Mon, 20 Jun 2011 15:08:20 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths' 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-07-04. 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 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-p2mp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-p2mp/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1064/ http://datatracker.ietf.org/ipr/1285/ http://datatracker.ietf.org/ipr/1086/ http://datatracker.ietf.org/ipr/1454/ From eosborne@cisco.com Mon Jun 20 15:19:55 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 651C411E80C1; Mon, 20 Jun 2011 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] 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 6RQzWIGGMGK8; Mon, 20 Jun 2011 15:19:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3551711E80D1; Mon, 20 Jun 2011 15:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=6926; q=dns/txt; s=iport; t=1308608394; x=1309817994; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vaeQkCXKbXMRBvIhzv4UszCTReylKNjWo1SWSnQvSkg=; b=QuMSDPTKCWOQzpv01fbLPWBVL5KIwpUZw3v2pgQ9a6H50/dTTqfZ6aei Bf2YSbxULXkWZbQSg4E/JxXu/AqnXX8X18FrShzZ22ldiCTTIbziXbyI7 X4YhkPKGAoTBgxTIc2PqO2HuIQEhPkuZfgwTxNSHW/UIBM8wqBt5CTLpi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAADnG/02tJV2d/2dsb2JhbABTl1uPDHeqQZ4ehioEhyCPJ4Q8hno X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="237518248" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2011 22:19:52 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5KMJqub024844; Mon, 20 Jun 2011 22:19:52 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 17:19:52 -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: Mon, 20 Jun 2011 17:19:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt0ynNZ3JEDsDySsWhgBj3eR20rgAFpOiuAGuJVeA= References: , From: "Eric Osborne (eosborne)" To: "Alexander Vainshtein" , "Greg Mirsky" X-OriginalArrivalTime: 20 Jun 2011 22:19:52.0515 (UTC) FILETIME=[2D1A8930:01CC2F98] Cc: mpls@ietf.org, Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? 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, 20 Jun 2011 22:19:55 -0000 Hi Sasha, Greg- If I understand correctly, the point that's being raised is that an implementation must distinguish Rx'd P-LSP packets it needs to discard (e.g. user traffic) vs. those that it must not (managmentm such as CC and PSC). If this is the point, I agree with it. But I don't see that it's any cause for concern. An implementation ought to be able to examine all traffic in an LSP and decide what it wants to keep; for CC and PSC (and for everything, as far as I can see), all traffic we want to keep will be in the GACH. eric > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Saturday, June 18, 2011 2:59 PM > To: Greg Mirsky > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > mpls@ietf.org; Eric Osborne (eosborne); Vladimir Kleiner; Andrew Sergeev; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > Rennison; Stewart Bryant (stbryant) > Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are > they compatible? >=20 > Dear Greg, > Lots of thanks for a prompt response. >=20 > However, I disagree with your conclusion: if you discard the traffic at > the LSP level (i.e. based on the incoming tunnel label), you would also > discard CC and PSC traffic: at this level they are undistinguishable from > the PW traffic. > The situation with the PW protection will be indeed different because > Working and Protection PWs would use different PW labels. >=20 > Hopefully this clarifies my point. > Regards, > Sasha > ________________________________ >=20 > From: Greg Mirsky [gregimirsky@gmail.com] > Sent: Saturday, June 18, 2011 7:17 PM > To: Alexander Vainshtein > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > mpls@ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > Rennison; Stewart Bryant (stbryant@cisco.com) > Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are > they compatible? >=20 >=20 > Dear Sasha, > I think that there is one assumption in line of your logic that changes > the result. > When we consider 1+1 LSP protection sink discards traffic from one source > on LSP level. As result there should not be issue with Rx on PW client > traffic since sink receives PW packets only from Active LSP and PW packets > from Inactive LSP would never be seen. > If we consider 1:1 PW protection, then, as I imagine, we have redundant PW > and thus PW labels are different. Then the sink selects one of PWs as > active but there should be no issue with PW labels. >=20 > Please let me know if understood scenarios correctly. >=20 > Kind regards, > Greg >=20 >=20 > On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein > wrote: >=20 >=20 > Hi all, > I would highly appreciate some clarification on the following issue: >=20 > Is 1+1 linear protection architecture for LSPs compatible with > the MPLS-TP data plane? >=20 > We have been recently reminded by Daniel Cohn that 1+1 protection > has been declared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). > What's more, Req. #65-B states that it MUST be supported in the > unidirectional mode for P2P connectivity. >=20 > The problematic use case from my point of view is PW traffic carried > within a 1+1-protected LSP between a pair of PEs. >=20 > To the best of my understanding, unidirectional 1+1 linear > protection, in its absolutely minimal form, would imply that: >=20 > 1. > Some form of proactive connectivity check (CC) would be > applied to both Working (W) and Protection (P) LSPs. It is my > understanding that the GAL/G-ACH mechanism would be used as the > encapsulation for the CC packets > 2. > Based on the results of CC, one of the incoming LSPs would be > selected as Active > 3. > When in comes to PW client traffic in these LSPs: >=20 > * > In the Tx direction: >=20 > * > Each PW packet would be replicated and forwarded > thru both W and P LSPs > * > Replication would leave the PW label (and > everything after this label) the same for both copies, so that only Tunnel > labels and accompanying linke layer encapsulations would be different >=20 > * > In the Rx direction: >=20 > * > Both W and P LSPs would be terminated, i.e., their > labels would be popped and, if the resulting packets are still labeled, > the next label looked up > * PW packets received from the Active LSP would be > forwarded to the appropriate PW Forwarder, and PW packets received from > the inactive LSP would be silently discarded >=20 > If this understanding is correct, this would mean that treatment of > the received PW labels would depend on the specific terminated LSP from > which the packets labeled with those have been received. In principle, > this would be possible if we would treat these LSPs and interfaces and > allocate PW labels from the per-interface space(even this would be non- > trivial, because there is no way to guarantee that the same label value > has simiilar meaning in different label spaces). But, as per RFC 4447, PW > labels MUST be allocated from the per-platform label space. >=20 > And of course, simply discarding all the packets received from the > inactive LSP would not do because this would affect CC operation. >=20 >=20 >=20 > Did I miss something substantial in my analysis? >=20 >=20 >=20 > Please note also that 1:1 protection could rely on the remote Tx > endpoint only sending packets to the (common) Active LSP making life > simpler (no real need for selection on the Rx side). >=20 >=20 >=20 > I understand that draft-ietf-mpls-tp-linear-protection is in the > final stages of the WG discussion, and apologize for raising this question > so late. But late is (sometimes) better than never... >=20 >=20 >=20 > Regards, >=20 > Sasha >=20 >=20 >=20 >=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 > 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. >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=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 > 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. From internet-drafts@ietf.org Mon Jun 20 20:40: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 BA67311E81D7; Mon, 20 Jun 2011 20:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 nzHPxSIJnBSq; Mon, 20 Jun 2011 20:40:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE10D11E81D6; Mon, 20 Jun 2011 20:40:40 -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.55 Message-ID: <20110621034040.9408.14138.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 20:40:40 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-p2mp-lsp-ping-17.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, 21 Jun 2011 03:40:42 -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 : Detecting Data Plane Failures in Point-to-Multipoint Mul= tiprotocol Label Switching (MPLS) - Extensions to LSP Ping Author(s) : Shaleen Saxena George Swallow Zafar Ali Adrian Farrel Seisho Yasukawa Thomas D. Nadeau Filename : draft-ietf-mpls-p2mp-lsp-ping-17.txt Pages : 27 Date : 2011-06-20 This document updates RFC 4379. Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping&quo= t;. The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-17.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-p2mp-lsp-ping-17.txt From yaakov_s@rad.com Tue Jun 21 01:45:55 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 9DA8111E8084 for ; Tue, 21 Jun 2011 01:45:55 -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 805raZUC35tB for ; Tue, 21 Jun 2011 01:45:54 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8611E807B for ; Tue, 21 Jun 2011 01:45:51 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 21 Jun 2011 11:45:49 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 21 Jun 2011 11:45:49 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Tue, 21 Jun 2011 11:45:49 +0300 From: Yaakov Stein To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] Second IETF last call on draft-ietf-mpls-loss-delay Thread-Index: AcwtDm6U/ZK77BO2TryklFqk3bo/FwC4D9Fw Date: Tue, 21 Jun 2011 08:45:48 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E5BAC3@EXRAD5.ad.rad.co.il> References: <17c101cc2d0e$e2917f80$a7b47e80$@olddog.co.uk> In-Reply-To: <17c101cc2d0e$e2917f80$a7b47e80$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Second IETF last call on draft-ietf-mpls-loss-delay 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, 21 Jun 2011 08:45:55 -0000 The IPR disclosure refers to PCT filing CN2009/073659, which (except for a short abstract) is only available in Chinese. Is there a translation available so that non-Chinese speakers=20 can evaluate the relevance and impact of this disclosure ? Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: Friday, June 17, 2011 19:52 To: mpls@ietf.org Subject: [mpls] Second IETF last call on draft-ietf-mpls-loss-delay Hi MPLS working group,=20 I very much regret to inform you that it is necessary to hold a second IETF= last call on draft-ietf-mpls-loss-delay. This document had completed a previous IETF last call and was on the agenda= for IESG evaluation on Thursday 23rd.=20 Unfortunately, a very late IPR disclosure was received from Huawei Technolo= gies. While I appreciate this disclosure being made before the document was publi= shed as an RFC, I find it disappointing that the disclosure was made so late thr= ough the process. This is a disruption to the normal functioning of the working group and cau= ses unnecessary delay to your work. May I ask the working group to take the opportunity of the second IETF last= call to consider the IPR disclosure and raise any concerns on the MPLS list or o= n the IETF list. If the WG decides to revisit the draft in the light of the IPR disclosure, could the chairs please let me know so that I can refer the dra= ft back to the WG. Can I take this opportunity to remind everyone in the WG (i.e. everyone subscribed to the MPLS list) of their duties under IETF IPR Policy (http://www.ietf.org/about/note-well.html), and let me specifically remind document authors of their responsibilities. Thanks, Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Jun 21 01:47: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 2086B11E807B; Tue, 21 Jun 2011 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396] 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 f4mhyWRXHJ9y; Tue, 21 Jun 2011 01:47:45 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAAD11E80B1; Tue, 21 Jun 2011 01:47:44 -0700 (PDT) X-AuditID: 93eaf2e7-b7ce9ae0000066df-dd-4e005aa6b5ec Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 67.4C.26335.6AA500E4; Tue, 21 Jun 2011 11:47:35 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 21 Jun 2011 11:47:41 +0300 From: Alexander Vainshtein To: "Eric Osborne (eosborne)" Date: Tue, 21 Jun 2011 11:47:38 +0300 Thread-Topic: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt0ynNZ3JEDsDySsWhgBj3eR20rgAFpOiuAGuJVeAAFJBKwA== 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: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTXWzTVhjttZ3EKTUyaUIvFUKW+ZEYTdXAkIxo2I94CEih5ecBwjowzl3i LXFCbBDtwyho2iYElEKF1FCpBUoLpTQKZWurriAiIVYq0U0baK0ADWgGhPISGONHIlzPUIrw g3Xud86557P1fTRpa7QU07KioZgihnhzPnUok33ibPflrSq72kkLXel/CGF3UzcQnh5Om4TR E6dMwv7sOUq4mm4CQrK/0fypxdPwMmnyvPj3mtnTF79p8bS2Pic8zxPXLJUmXy0oFxUlooka 4vxIldx8ZUzeLkrVPCf73byL56IhUUJhpGhuXoxGkeLnl+VzHzzlWCYrHFKkiF9WAm5+xdoK pyAsXuJ08cvmzXYtWpq/LiirHHKGRTnEhZGqigHE4crmc2SwJ/HQFD2/fMftJ92gFsQX7wFW GrIfw66OSxYDT4e/3UqY94B82sb2AZhtug2MQwOAQ9luk64ys2549vRNs47t7EJY13OB0EUk O0TB75+9BDpBsXPhif5hLKLpQvYLeG/3LENfBY9kfgR62c5+Dn+6G9TLDFsBkwdH3mTtI2D6 1u+ETlhZLxyrf0TpGODu/rvS+X+dZIvg6FgzYXTNwtZfhkkDO+CDu69Mht4Bb/yQAIa+BLb0 Z80GXgDbjj4kjeBpcLBxjDK8M+DFk39RB0BRfFJEfJI9Psken2RvAVQHcMihqLYlHChzlSJJ 1lAIlUqR8FlgDNO9XvCieU4KsDTgC5i8hpzXZhK3q9XhFJhBE7yDcW3IW2WbuiXirw6KanBT bFsIqSkAaZK3M3XrMcf4xeoaFIu8pQT8k+vJ4ilSBI+tom1aVFb23oEvYtLSuNfGBvDUfYNQ FMXeWmfSNA+ZEjzdtmkxFEA7vpJD2juaoK16cgFO3qt3xahRMazKAYO/ApbQPS0PUoA+dkZ/ tx0ZTwEbpUQUVIwjdQOrG4LblIk79Y3amcvlMqAIf38h49CjC/C+TdyawYEEDsxlXnlxIN6U Caq4FvSyU+zzG7Xr7X7gHFq50efq6/n7szklNcSNztGAz97MjR24811pSD1TWTO1lr8/0u4Z tTZ7OpaPnPpj/M63a+CC1amqDcODM+/Tl/eigY2Prf25X0dmtQ12+Z2bHw301k0flpLup197 L1ddp5JfLvyzuzDxScXxnwfKLVvrlw7s8vGUGhRdH5ExVXwNKfBebCwEAAA= Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant\)" , Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? 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, 21 Jun 2011 08:47:46 -0000 Eric, I believe the issue has been successfully resolved with help from Shahram an= d Greg. The way to resolve it, from my point of view, was to say that the inactive L= SP would not be terminated in the tail-end in the normal way LSPs are termin= ated i.e., the ILM-defined action on its label would not be "Pop and look up= the next label (if it exists)". Rather, this action would be "Pop and forwa= rd to a "leaky drop" interface". Thus the problem has been effectively remov= ed from the scope of MPLS data plane architecture (as defined in RFC 3031 an= d 3032): it would be the responsibility of the "leaky drop" interface to "le= ak" GACH packets to control while dropping all the rest (user traffic). Acco= rdingly, implementation could be partitioned into two components: - implementation of the "leaky drop" interface (one such per box would suffi= ce) - manipulation of the ILM entries referring to the labels of the two LSPs. Hopefully these notes will be useful. Regards, Sasha > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Tuesday, June 21, 2011 1:20 AM > To: Alexander Vainshtein; Greg Mirsky > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > mpls@ietf.org; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pwe3; > Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant > (stbryant) > Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: > are they compatible? > > Hi Sasha, Greg- > > If I understand correctly, the point that's being raised is that an > implementation must distinguish Rx'd P-LSP packets it needs to discard > (e.g. user traffic) vs. those that it must not (managmentm such as CC > and PSC). > > If this is the point, I agree with it. But I don't see that it's any > cause for concern. An implementation ought to be able to examine all > traffic in an LSP and decide what it wants to keep; for CC and PSC (and > for everything, as far as I can see), all traffic we want to keep will > be in the GACH. > > > > eric > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Saturday, June 18, 2011 2:59 PM > > To: Greg Mirsky > > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > > mpls@ietf.org; Eric Osborne (eosborne); Vladimir Kleiner; Andrew > Sergeev; > > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > > Rennison; Stewart Bryant (stbryant) > > Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: > are > > they compatible? > > > > Dear Greg, > > Lots of thanks for a prompt response. > > > > However, I disagree with your conclusion: if you discard the traffic > at > > the LSP level (i.e. based on the incoming tunnel label), you would > also > > discard CC and PSC traffic: at this level they are undistinguishable > from > > the PW traffic. > > The situation with the PW protection will be indeed different because > > Working and Protection PWs would use different PW labels. > > > > Hopefully this clarifies my point. > > Regards, > > Sasha > > ________________________________ > > > > From: Greg Mirsky [gregimirsky@gmail.com] > > Sent: Saturday, June 18, 2011 7:17 PM > > To: Alexander Vainshtein > > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > > mpls@ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; > > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > > Rennison; Stewart Bryant (stbryant@cisco.com) > > Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: > are > > they compatible? > > > > > > Dear Sasha, > > I think that there is one assumption in line of your logic that > changes > > the result. > > When we consider 1+1 LSP protection sink discards traffic from one > source > > on LSP level. As result there should not be issue with Rx on PW > client > > traffic since sink receives PW packets only from Active LSP and PW > packets > > from Inactive LSP would never be seen. > > If we consider 1:1 PW protection, then, as I imagine, we have > redundant PW > > and thus PW labels are different. Then the sink selects one of PWs as > > active but there should be no issue with PW labels. > > > > Please let me know if understood scenarios correctly. > > > > Kind regards, > > Greg > > > > > > On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein > > wrote: > > > > > > Hi all, > > I would highly appreciate some clarification on the following > issue: > > > > Is 1+1 linear protection architecture for LSPs > compatible with > > the MPLS-TP data plane? > > > > We have been recently reminded by Daniel Cohn that 1+1 > protection > > has been declared as MUST to support for MPLS-TP in RFC 5654 (Req. > #65). > > What's more, Req. #65-B states that it MUST be supported in the > > unidirectional mode for P2P connectivity. > > > > The problematic use case from my point of view is PW traffic > carried > > within a 1+1-protected LSP between a pair of PEs. > > > > To the best of my understanding, unidirectional 1+1 linear > > protection, in its absolutely minimal form, would imply that: > > > > 1. > > Some form of proactive connectivity check (CC) would be > > applied to both Working (W) and Protection (P) LSPs. It is my > > understanding that the GAL/G-ACH mechanism would be used as the > > encapsulation for the CC packets > > 2. > > Based on the results of CC, one of the incoming LSPs > would be > > selected as Active > > 3. > > When in comes to PW client traffic in these LSPs: > > > > * > > In the Tx direction: > > > > * > > Each PW packet would be replicated and > forwarded > > thru both W and P LSPs > > * > > Replication would leave the PW label > (and > > everything after this label) the same for both copies, so that only > Tunnel > > labels and accompanying linke layer encapsulations would be different > > > > * > > In the Rx direction: > > > > * > > Both W and P LSPs would be terminated, > i.e., their > > labels would be popped and, if the resulting packets are still > labeled, > > the next label looked up > > * PW packets received from the Active LSP > would be > > forwarded to the appropriate PW Forwarder, and PW packets received > from > > the inactive LSP would be silently discarded > > > > If this understanding is correct, this would mean that treatment > of > > the received PW labels would depend on the specific terminated LSP > from > > which the packets labeled with those have been received. In > principle, > > this would be possible if we would treat these LSPs and interfaces > and > > allocate PW labels from the per-interface space(even this would be > non- > > trivial, because there is no way to guarantee that the same label > value > > has simiilar meaning in different label spaces). But, as per RFC > 4447, PW > > labels MUST be allocated from the per-platform label space. > > > > And of course, simply discarding all the packets received from > the > > inactive LSP would not do because this would affect CC operation. > > > > > > > > Did I miss something substantial in my analysis? > > > > > > > > Please note also that 1:1 protection could rely on the remote Tx > > endpoint only sending packets to the (common) Active LSP making life > > simpler (no real need for selection on the Rx side). > > > > > > > > I understand that draft-ietf-mpls-tp-linear-protection is in the > > final stages of the WG discussion, and apologize for raising this > question > > so late. But late is (sometimes) better than never... > > > > > > > > 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. > > > > > > _______________________________________________ > > 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. 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 stbryant@cisco.com Tue Jun 21 05:35: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 2E4B411E80DC for ; Tue, 21 Jun 2011 05:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 it19tqIlavL9 for ; Tue, 21 Jun 2011 05:35:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0011E80C2 for ; Tue, 21 Jun 2011 05:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2659; q=dns/txt; s=iport; t=1308659744; x=1309869344; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hYXBHAafi3kShsVEvd9deBNMU2QtLz1IM000keNf/wM=; b=mRaLd/MTQviUFZfl2P4b1uc/yxFV22+XXfBLnyGwiEv8GDW+/P+0/PmF 2/xLzwZp7g1OJPv/UCGZwGgXPdtFI19qiAnbiShPjVbLOa/7RnCrnqw0Q dhow11OGQW+zYrNnzxrUeQpIoPuz1DVAeeGa8uFcTHM98yik2gRhr5ior 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BANePAE6Q/khR/2dsb2JhbABUl1uPE3eqSYMQDwGbJIYqBJFmkAc X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="95425808" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2011 12:35:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5LCZeiW030004; Tue, 21 Jun 2011 12:35:43 GMT Received: from dhcp-gpk02-vlan300-64-103-65-107.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p5LCZbOK014177; Tue, 21 Jun 2011 13:35:38 +0100 (BST) Message-ID: <4E00904A.5010508@cisco.com> Date: Tue, 21 Jun 2011 13:36:26 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yaakov Stein References: <17c101cc2d0e$e2917f80$a7b47e80$@olddog.co.uk> <07F7D7DED63154409F13298786A2ADC903E5BAC3@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903E5BAC3@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Second IETF last call on draft-ietf-mpls-loss-delay X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 12:35:46 -0000 Yaakov This claims to be a translation http://www.wipo.int/patentscope/search/en/WO2011026264 http://www.wipo.int/patentscope/search/en/detail.jsf?docId=WO2011026264&recNum=1&maxRec=&office=&prevFilter=&sortOption=&queryString=&tab=PCTDescription It's basically a Google translation from the Chinese which gives you a choice of languages, English, Hebrew etc Stewart On 21/06/2011 09:45, Yaakov Stein wrote: > The IPR disclosure refers to PCT filing CN2009/073659, > which (except for a short abstract) is only available in Chinese. > > Is there a translation available so that non-Chinese speakers > can evaluate the relevance and impact of this disclosure ? > > Y(J)S > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, June 17, 2011 19:52 > To: mpls@ietf.org > Subject: [mpls] Second IETF last call on draft-ietf-mpls-loss-delay > > Hi MPLS working group, > > I very much regret to inform you that it is necessary to hold a second IETF last > call on draft-ietf-mpls-loss-delay. > > This document had completed a previous IETF last call and was on the agenda for > IESG evaluation on Thursday 23rd. > > Unfortunately, a very late IPR disclosure was received from Huawei Technologies. > While I appreciate this disclosure being made before the document was published > as an RFC, I find it disappointing that the disclosure was made so late through > the process. > > This is a disruption to the normal functioning of the working group and causes > unnecessary delay to your work. > > May I ask the working group to take the opportunity of the second IETF last call > to consider the IPR disclosure and raise any concerns on the MPLS list or on the > IETF list. If the WG decides to revisit the draft in the light of the IPR > disclosure, could the chairs please let me know so that I can refer the draft > back to the WG. > > Can I take this opportunity to remind everyone in the WG (i.e. everyone > subscribed to the MPLS list) of their duties under IETF IPR Policy > (http://www.ietf.org/about/note-well.html), and let me specifically remind > document authors of their responsibilities. > > Thanks, > Adrian > > _______________________________________________ > 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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From iesg-secretary@ietf.org Tue Jun 21 07:07: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 01C3711E8167; Tue, 21 Jun 2011 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 CyM84Xf2c1ci; Tue, 21 Jun 2011 07:07:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2BA11E814F; Tue, 21 Jun 2011 07:07:03 -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.55 Message-ID: <20110621140703.30243.75939.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 07:07:03 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS-TP Linear Protection) 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: Tue, 21 Jun 2011 14:07:04 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Linear Protection' 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-07-05. 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 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/ No IPR declarations have been submitted directly on this I-D. From eric.gray@ericsson.com Tue Jun 21 07:48:55 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 53C5111E815A for ; Tue, 21 Jun 2011 07:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 BWBNo39vYpdR for ; Tue, 21 Jun 2011 07:48:54 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C633211E8154 for ; Tue, 21 Jun 2011 07:48:53 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5LEmq3m031106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jun 2011 09:48:53 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 21 Jun 2011 10:48:52 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 21 Jun 2011 10:48:50 -0400 Thread-Topic: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 Thread-Index: AQI12X/8bGAt9w/aSv3piPWpQrmG1JP0TZwQgABD6aA= 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: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 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, 21 Jun 2011 14:48:55 -0000 Forwarding in plain text... ________________________________ From: Daniel King [mailto:daniel@olddog.co.uk] Sent: Tuesday, June 21, 2011 6:50 AM To: Eric Gray Cc: mpls@ietf.org; draft-ietf-mpls-tp-mib-management-overview@tools.ietf.or= g Subject: RE: Last Call review of draft-ietf-mpls-tp-mib-management-overview= -04 Hi Eric, Thanks for taking the time to review the draft thoroughly. As usual, a grea= t review. We will issue a new version of the draft at the end of the LC per= iod to address your, and any other, comments. We will then follow-up up wit= h you to make sure your points have been addressed. Br, Dan. From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: 20 June 2011 19:12 To: draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org Cc: mpls@ietf.org Subject: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 This is my comments on this version for WG Last Call. This is generally a very useful piece of work. Most of my comments are rel= ated to front matter (prior to section 4 where most of the "meat" of the draft s= tarts), or in other text which has probably not received recent review. This review is for the draft located at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-04 Comments/Questions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract: Why use "would be required" to describe additional MIB modules? Are they required, or does the requirement hinge on some other dependency? Introduction: Second paragraph: s/responsibility of the modules/responsibility for the mo= dules/ Third paragraph: Why do you explicitly refer to the GMPLS control plane, wh= en it is clearly the case that a transport path may be PW-based and PW signaling = is based on LDP? And, once the signaling context is expanded to include any f= orm of MPLS signaling, why limit the context of this paragraph to MPLS-TP? Any= LSP or PW can be statically provisioned. Fourth paragraph: instead of "architecture for MPLS-TP" we should say "arch= itecture for MPLS, as extended for MPLS-TP" - because there is not (AFAIK) intended = to be any restriction in the applicability of this management architecture to jus= t MPLS-TP. Also in the fourth paragraph, please break the first sentence into two part= s. And, we again say "would be required", implying in this specific context "if anyone= , anywhere, ever even thinks they might use SNMP for the management interface." Does i= t seem likely that this will not be the case? Section 1.1: First paragraph: There is a problem with the two phrases "the MPLS-TP netw= orks" and "its client networks" (this can happen when using too many such phrases= in a sentence). As I understand the sentence (based on how it is now written), = it means to say: "MPLS-TP network management is inseparable from client network management s= o that the same management approach can be used regardless of the client." Once I think I have teased out the meaning of this sentence, I find that it= is wrong. Instead of being "inseparable", it should be "separable" or "independent" (= since the intent appears to be to allow MPLS-TP network to be managed independent of = the way that client networks are managed). Also in the first paragraph, "management functions ... includes" should be = either "management functions ... include", or "management function ... includes" (= given the opening of the next paragraph, I suspect the latter choice is more appr= opriate). Second paragraph: the first sentence in this paragraph needs work. Is the = purpose of the management function to provide control, monitoring and procedures (w= here control and monitoring applies to protocol mechanisms, and procedures appli= es to building blocks for ...) or is it to provide control and monitoring of both= protocol mechanisms and procedures? Also, assuming that a "profile" is supposed to = be a subset, why do we need "building blocks" for a transport profile of MPLS? Again, this is the problem with viewing MPLS-TP as separate from MPLS. We'= ve defined extensions to MPLS, such that we can define a transport profile. B= uilding blocks in this case are these extensions and apply to MPLS generally, even = though added to MPLS to allow definition of a transport profile. Section 2: PW terminology references are conspicuously missing from this se= ction. Minimally, the PWE3 architecture (RFC 3985) should be included here. Section 4.2.3: This section provides a doubtful description of a Label Edge= Router. Unfortunately, I am not aware of any RFC or other draft that defines this c= oncept. It is certainly not explicitly defined in any of the RFCs listed in section= 2 (where a list of RFCs is provided for terminology sources) - though it is used in = at least one of them. I suggest that you provide a definition "for the purposes of this document"= in the Terminology section. From a management perspective, your description is ve= ry convenient. In general, however, an LER typically provides either ingress = to, or egress from, an LSP. Since LSPs may be hierarchical, it is not even clear = that an LER will necessarily be mapping a network layer header (directly) to an = FTN (the mapping may be implied by any of a set of labels that each map to a su= bset of the intended FEC). >From a management perspective, the simple description you use is sufficient= , if not necessarily complete. It should be clear, however, that you are not de= fining the term LER to generally mean what you have in this section, since that wo= uld likely provoke some person - at some later time - to ask "well, what do we = call a device that is an egress to LSPs?" Section 4.2.5: This section provides a doubtful (if intuitive) description = of an Label Switched Path. Part of the problem is that "MPLS domain" is a bit nebulous= . An LSP begins where a set of one or more labels is prepended to a previously e= xisting network layer or MPLS label header (thus forming, or adding to, a label sta= ck). The LSP continues through an arbitrary number of 0 or more LSRs where a top-of-= stack label is swapped for the appropriate corresponding downstream label. Final= ly, the LSP ends at the LSP egress (which will either be where the last label in th= e set is removed, or at the next LSR after this last label is removed - if PHP is us= ed and the LSR removing the label is the penultimate hop). At any LSR along the LSP, = the local view of an LSP comprises eitehr an FTN or an ILM (which - for managem= ent purposes is represented by in-segment and out-segment mappings). The issue with the description you provide is that 1) it is more than just = the path taken (many LSPs may follow the same path) and 2) any LSP may be carried in another LSP, which itself may not traverse the entire MPLS domain. Label Switched Path is defined in very explicit and precise detail in RFC 3= 031. Section 4.2.6: In the first paragraph, why is there a line break between "layered" and "mo= dular"? Section 4.2.8: First paragraph - This sentence/paragraph needs work. Possibly it should st= art "The purpose of MPLS resiliency is ..." Also, "no interruption" seems hard= ly to be likely - perhaps "minimal interruption"? Section 4.2.10: There are problems with the dependency chart in this section. First, it is= not too obvious how to resolve dependencies where lines intersect. After some trou= ble, I realized that your use of arrows going into the intersection seems to mean = that a dependency is one way. So - for example - that means - MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-GENERIC-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB etc. - but not the other way around (nor is there - for example - a direct depende= ncy between MPLS-FTN-STD-MIB and MPLS-LDP-GENERIC-STD-MIB). This notation is broken when it comes to the relationship between the follo= wing: MPLS-TE-STD-MIB and ... GMPLS-LSR-STD-MIB and ... GMPLS-TE-STD-MIB and ... PW-MPLS-STD-MIB and ... These look like they may all be dependent on both MPLS-LSR-STD-MIB and MPLS-FTN-STD-MIB - probably because of a missing arrow on the left side (pointing right) of an intersection where these all come together (although= you might argue that the absence of an arrow pointing left on the dashed-line g= oing left from this intersection means that the dependency doesn't go that way). I wonder if this chart might not be simplified somewhat by taking out indir= ect (or implicit) dependencies. For example (if I am reading this right), MPLS-LDP-GENERIC-STD-MIB ---> MPLS-LDP-STD-MIB, MPLS-FTN-STD-MIB ---> MPLS-TE-STD-MIB and MPLS-LDP-STD-MIB ---> MPLS-LSR-STD-MIB, MPLS-TE-STD-MIB ---> MPLS-LSR-STD-MIB and MPLS-LSR-STD-MIB ---> MPLS-TC-STD-MIB, means you could remove the dependencies: MPLS-FTN-STD-MIB ---> MPLS-LDP-STD-MIB (eliminating the above issue) MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-GENERIC-STD-MIB --> MPLS-TC-STD-MIB MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB These dependencies are implied by the dependencies above. Section 5: First paragraph, "sub sections" should probably be hyphenated. Also, there= 's something not-quite right about the sentence. Reading the section, it's th= e sub-sections of this section that focus on gaps in the current set of MPLS = MIB modules. Also, if "its" subsitutes for MPLS MIB modules, "its use" should b= e "their use." Lastly, restating an earlier comment, MPLS-TP is not an exten= sion of MPLS, it's a profile of MPLS as extended. I suggest re-wording the sent= ence as follows: "The below sub-sections of this section focus on possible gaps in existing = MPLS MIB modules in order to determine extensions or additional MIB modules that= are required to support MPLS-TP in MPLS networks." Second paragraph, why is there a line-break between "of" and "equipment"? Third paragraph, why is there a line-break between "for" and "MPLS-TP"? Fifth paragraph, either "Operations" should be "the Operations", or "functi= on" should be "functions" in the first sentence. Sixth paragraph, "seperate ..." should be "separate ..." section 5.1.1: The first sentence is actually two separate sentences joined by a comma. I= t should just be two separate sentences. Also, why is there a line-break bef= ore "for" in the second line of the first paragraph? The first sub-bullets under each of the two major bullets in this section s= hould include a reference to the identifiers draft (for Global_ID, Node_ID and t= unnel LSR identifier). I believe the intention is that "tunnel LSR identifier" s= hould be "Tunnel_ID"; if that is not correct, what does it mean? section 5.1.2: It is not obvious how the recommendations in this section address the issue of all missing identifiers mentioned in the preceding section. Which bulle= t is intended to address the missing tunnel identfier based on ICC? Section 5.2.1: Again there is a mssing reference to the identifiers draft. Rather than add= (or repeat) these references, perhaps it would be better if a general statement about identifiers was made in the lead-in text for section 5, along with cu= rrent references to various MIB documents, management and OAM requirements and framework documents, etc. Note that the first mention of the identifiers draft does not occur in this= section until sub-section 5.6.1 (even though material from this draft is needed ear= lier). Section 5.4.1: MIB-based management of exclusively on-demand OAM functions does not make as much sense as for other OAM functions. In particualr, Route Tracing does not seem to be an OAM function for which MIB-based management will make any sense. Some reasons why: 1) most MIBs today are essentially read-only. Thus it is unlikely that a R= oute trace would be invokable via a MIB . 2) the results of a route-trace would be difficult to represent in a MIB. 3) a Route-Trace is very unlikely to be an ongoing activity that would need= to be monitored over any significant period of time. As near as I can tell, this is the only listed OAM function which is extrem= ely unlikely to be used in proactive OAM and - therefore - does not make sense as a MIB function. Section 6: Second paragraph - "must be suppor in" should be "must be supported in" Also, same paragraph - "need tbe conformed to" should be "need to be complied with" Section 6: Either there is a convention being employed here that I am not aware of, or the phrase "New X" is being used in some way that is not transparent. At several points in this section phrases like "new textual convention mib module" and "New Identifiers" are used as if they are names of existing documents, that already accomplish some goal described in susequent text. If the intention is to refer to a task that is as yet to be accomplished by= a new document, then the status of the task in question is not that it has been done already, and the phrase should be prefixed with "a" (or "A" if it occurs at the beginning of the sentence). If these are names of a set of documents, then these are very unfortunate names. Section 6.1.2: First paragraph - should "mib module" be "MIB module"? Second paragraph - is there already a "new textual convention mib [SIC] module" or are we getting ahead of ourselves in saying that a "textual convention representing the MEP identifier is defined in new textual convention mib [SIC] module"? Same paragraph - "... identify maintenance ... should be "... identify a maintenance ..." Section 6.1.3: I cannot be certain what this section says without understanding what the convention ("New X") means, if anything. Minimally, either the sentence should start "A New identifier identifies a new managed ...", "New identifiers identify new managed ...", or "New Identifiers describes managed ..." Section 6.1.4: Second paragraph - "corouted" should be "co-routed"... Section 6.1.5: Second paragraph - "much similar" should be "very similar", or just "simila= r"; Also, is this MIB (MPLS-TE-STD-MIB) already extended (as the text implies), or does it need to be extended? Same paragraph - "could be" should be "are either" (they MUST be one or the other, which is not what "could be X or Y" means). Section 7 (Management Options): Second paragraph - "refer" should be "refer to"... Section 9 (IANA Considerations): This is inconsistent with text earlier in the draft. For example, in secti= on 6.1.1, 6.2.1, 6.3.1 and 6.4.1, there is the statement that OIDs for MIB modules ar= e yet to be assigned and managed by IANA. I think this is intended as a general statement, as it does not seem that t= his document actually specifies any particular OIDs that would need to be assig= ned by IANA (or, if it does, I did not pick up on it). However, this document = seems to be making the point - possibly as a reminder - that the MIBs recommended by this draft will require OID assignments from IANA. I suggest saying something to this effect in the IANA considerations sectio= n and adding that there is no IANA action required specifically by this document.= You might easily modify the first two paragraphs in section 8 (Security Conside= rations) for this purpose in Section 9. You must do something to remove the current ambiguity, as it is not clear t= hat you are not requesting specific OIDs for the - as yet to be specified - new= objects in the OID trees in sections 6.1.1, 6.2.1, 6.3.1 and 6.4.1. From eric.gray@ericsson.com Tue Jun 21 07:49:34 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 BEE7B11E81A9 for ; Tue, 21 Jun 2011 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 EreKr1riWzDF for ; Tue, 21 Jun 2011 07:49:33 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6530811E819D for ; Tue, 21 Jun 2011 07:49:31 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5LEnS90031146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jun 2011 09:49:30 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 21 Jun 2011 10:49:28 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 21 Jun 2011 10:49:27 -0400 Thread-Topic: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 Thread-Index: AcwvdYGUChkX3Ok/QyaJ75csgltLngArNv4g 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: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 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, 21 Jun 2011 14:49:34 -0000 Forwarding in plain text... ________________________________ From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Monday, June 20, 2011 2:12 PM To: draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org Cc: mpls@ietf.org Subject: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 This is my comments on this version for WG Last Call. This is generally a very useful piece of work. Most of my comments are rel= ated to front matter (prior to section 4 where most of the "meat" of the draft s= tarts), or in other text which has probably not received recent review. This review is for the draft located at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-04 Comments/Questions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract: Why use "would be required" to describe additional MIB modules? Are they required, or does the requirement hinge on some other dependency? Introduction: Second paragraph: s/responsibility of the modules/responsibility for the mo= dules/ Third paragraph: Why do you explicitly refer to the GMPLS control plane, wh= en it is clearly the case that a transport path may be PW-based and PW signaling = is based on LDP? And, once the signaling context is expanded to include any f= orm of MPLS signaling, why limit the context of this paragraph to MPLS-TP? Any= LSP or PW can be statically provisioned. Fourth paragraph: instead of "architecture for MPLS-TP" we should say "arch= itecture for MPLS, as extended for MPLS-TP" - because there is not (AFAIK) intended = to be any restriction in the applicability of this management architecture to jus= t MPLS-TP. Also in the fourth paragraph, please break the first sentence into two part= s. And, we again say "would be required", implying in this specific context "if anyone= , anywhere, ever even thinks they might use SNMP for the management interface." Does i= t seem likely that this will not be the case? Section 1.1: First paragraph: There is a problem with the two phrases "the MPLS-TP netw= orks" and "its client networks" (this can happen when using too many such phrases= in a sentence). As I understand the sentence (based on how it is now written), = it means to say: "MPLS-TP network management is inseparable from client network management s= o that the same management approach can be used regardless of the client." Once I think I have teased out the meaning of this sentence, I find that it= is wrong. Instead of being "inseparable", it should be "separable" or "independent" (= since the intent appears to be to allow MPLS-TP network to be managed independent of = the way that client networks are managed). Also in the first paragraph, "management functions ... includes" should be = either "management functions ... include", or "management function ... includes" (= given the opening of the next paragraph, I suspect the latter choice is more appr= opriate). Second paragraph: the first sentence in this paragraph needs work. Is the = purpose of the management function to provide control, monitoring and procedures (w= here control and monitoring applies to protocol mechanisms, and procedures appli= es to building blocks for ...) or is it to provide control and monitoring of both= protocol mechanisms and procedures? Also, assuming that a "profile" is supposed to = be a subset, why do we need "building blocks" for a transport profile of MPLS? Again, this is the problem with viewing MPLS-TP as separate from MPLS. We'= ve defined extensions to MPLS, such that we can define a transport profile. B= uilding blocks in this case are these extensions and apply to MPLS generally, even = though added to MPLS to allow definition of a transport profile. Section 2: PW terminology references are conspicuously missing from this se= ction. Minimally, the PWE3 architecture (RFC 3985) should be included here. Section 4.2.3: This section provides a doubtful description of a Label Edge= Router. Unfortunately, I am not aware of any RFC or other draft that defines this c= oncept. It is certainly not explicitly defined in any of the RFCs listed in section= 2 (where a list of RFCs is provided for terminology sources) - though it is used in = at least one of them. I suggest that you provide a definition "for the purposes of this document"= in the Terminology section. From a management perspective, your description is ve= ry convenient. In general, however, an LER typically provides either ingress = to, or egress from, an LSP. Since LSPs may be hierarchical, it is not even clear = that an LER will necessarily be mapping a network layer header (directly) to an = FTN (the mapping may be implied by any of a set of labels that each map to a su= bset of the intended FEC). >From a management perspective, the simple description you use is sufficient= , if not necessarily complete. It should be clear, however, that you are not de= fining the term LER to generally mean what you have in this section, since that wo= uld likely provoke some person - at some later time - to ask "well, what do we = call a device that is an egress to LSPs?" Section 4.2.5: This section provides a doubtful (if intuitive) description = of an Label Switched Path. Part of the problem is that "MPLS domain" is a bit nebulous= . An LSP begins where a set of one or more labels is prepended to a previously e= xisting network layer or MPLS label header (thus forming, or adding to, a label sta= ck). The LSP continues through an arbitrary number of 0 or more LSRs where a top-of-= stack label is swapped for the appropriate corresponding downstream label. Final= ly, the LSP ends at the LSP egress (which will either be where the last label in th= e set is removed, or at the next LSR after this last label is removed - if PHP is us= ed and the LSR removing the label is the penultimate hop). At any LSR along the LSP, = the local view of an LSP comprises eitehr an FTN or an ILM (which - for managem= ent purposes is represented by in-segment and out-segment mappings). The issue with the description you provide is that 1) it is more than just = the path taken (many LSPs may follow the same path) and 2) any LSP may be carried in another LSP, which itself may not traverse the entire MPLS domain. Label Switched Path is defined in very explicit and precise detail in RFC 3= 031. Section 4.2.6: In the first paragraph, why is there a line break between "layered" and "mo= dular"? Section 4.2.8: First paragraph - This sentence/paragraph needs work. Possibly it should st= art "The purpose of MPLS resiliency is ..." Also, "no interruption" seems hard= ly to be likely - perhaps "minimal interruption"? Section 4.2.10: There are problems with the dependency chart in this section. First, it is= not too obvious how to resolve dependencies where lines intersect. After some trou= ble, I realized that your use of arrows going into the intersection seems to mean = that a dependency is one way. So - for example - that means - MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-GENERIC-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB etc. - but not the other way around (nor is there - for example - a direct depende= ncy between MPLS-FTN-STD-MIB and MPLS-LDP-GENERIC-STD-MIB). This notation is broken when it comes to the relationship between the follo= wing: MPLS-TE-STD-MIB and ... GMPLS-LSR-STD-MIB and ... GMPLS-TE-STD-MIB and ... PW-MPLS-STD-MIB and ... These look like they may all be dependent on both MPLS-LSR-STD-MIB and MPLS-FTN-STD-MIB - probably because of a missing arrow on the left side (pointing right) of an intersection where these all come together (although= you might argue that the absence of an arrow pointing left on the dashed-line g= oing left from this intersection means that the dependency doesn't go that way). I wonder if this chart might not be simplified somewhat by taking out indir= ect (or implicit) dependencies. For example (if I am reading this right), MPLS-LDP-GENERIC-STD-MIB ---> MPLS-LDP-STD-MIB, MPLS-FTN-STD-MIB ---> MPLS-TE-STD-MIB and MPLS-LDP-STD-MIB ---> MPLS-LSR-STD-MIB, MPLS-TE-STD-MIB ---> MPLS-LSR-STD-MIB and MPLS-LSR-STD-MIB ---> MPLS-TC-STD-MIB, means you could remove the dependencies: MPLS-FTN-STD-MIB ---> MPLS-LDP-STD-MIB (eliminating the above issue) MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-GENERIC-STD-MIB --> MPLS-TC-STD-MIB MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB These dependencies are implied by the dependencies above. Section 5: First paragraph, "sub sections" should probably be hyphenated. Also, there= 's something not-quite right about the sentence. Reading the section, it's th= e sub-sections of this section that focus on gaps in the current set of MPLS = MIB modules. Also, if "its" subsitutes for MPLS MIB modules, "its use" should b= e "their use." Lastly, restating an earlier comment, MPLS-TP is not an exten= sion of MPLS, it's a profile of MPLS as extended. I suggest re-wording the sent= ence as follows: "The below sub-sections of this section focus on possible gaps in existing = MPLS MIB modules in order to determine extensions or additional MIB modules that= are required to support MPLS-TP in MPLS networks." Second paragraph, why is there a line-break between "of" and "equipment"? Third paragraph, why is there a line-break between "for" and "MPLS-TP"? Fifth paragraph, either "Operations" should be "the Operations", or "functi= on" should be "functions" in the first sentence. Sixth paragraph, "seperate ..." should be "separate ..." section 5.1.1: The first sentence is actually two separate sentences joined by a comma. I= t should just be two separate sentences. Also, why is there a line-break bef= ore "for" in the second line of the first paragraph? The first sub-bullets under each of the two major bullets in this section s= hould include a reference to the identifiers draft (for Global_ID, Node_ID and t= unnel LSR identifier). I believe the intention is that "tunnel LSR identifier" s= hould be "Tunnel_ID"; if that is not correct, what does it mean? section 5.1.2: It is not obvious how the recommendations in this section address the issue of all missing identifiers mentioned in the preceding section. Which bulle= t is intended to address the missing tunnel identfier based on ICC? Section 5.2.1: Again there is a mssing reference to the identifiers draft. Rather than add= (or repeat) these references, perhaps it would be better if a general statement about identifiers was made in the lead-in text for section 5, along with cu= rrent references to various MIB documents, management and OAM requirements and framework documents, etc. Note that the first mention of the identifiers draft does not occur in this= section until sub-section 5.6.1 (even though material from this draft is needed ear= lier). Section 5.4.1: MIB-based management of exclusively on-demand OAM functions does not make as much sense as for other OAM functions. In particualr, Route Tracing does not seem to be an OAM function for which MIB-based management will make any sense. Some reasons why: 1) most MIBs today are essentially read-only. Thus it is unlikely that a R= oute trace would be invokable via a MIB . 2) the results of a route-trace would be difficult to represent in a MIB. 3) a Route-Trace is very unlikely to be an ongoing activity that would need= to be monitored over any significant period of time. As near as I can tell, this is the only listed OAM function which is extrem= ely unlikely to be used in proactive OAM and - therefore - does not make sense as a MIB function. Section 6: Second paragraph - "must be suppor in" should be "must be supported in" Also, same paragraph - "need tbe conformed to" should be "need to be complied with" Section 6: Either there is a convention being employed here that I am not aware of, or the phrase "New X" is being used in some way that is not transparent. At several points in this section phrases like "new textual convention mib module" and "New Identifiers" are used as if they are names of existing documents, that already accomplish some goal described in susequent text. If the intention is to refer to a task that is as yet to be accomplished by= a new document, then the status of the task in question is not that it has been done already, and the phrase should be prefixed with "a" (or "A" if it occurs at the beginning of the sentence). If these are names of a set of documents, then these are very unfortunate names. Section 6.1.2: First paragraph - should "mib module" be "MIB module"? Second paragraph - is there already a "new textual convention mib [SIC] module" or are we getting ahead of ourselves in saying that a "textual convention representing the MEP identifier is defined in new textual convention mib [SIC] module"? Same paragraph - "... identify maintenance ... should be "... identify a maintenance ..." Section 6.1.3: I cannot be certain what this section says without understanding what the convention ("New X") means, if anything. Minimally, either the sentence should start "A New identifier identifies a new managed ...", "New identifiers identify new managed ...", or "New Identifiers describes managed ..." Section 6.1.4: Second paragraph - "corouted" should be "co-routed"... Section 6.1.5: Second paragraph - "much similar" should be "very similar", or just "simila= r"; Also, is this MIB (MPLS-TE-STD-MIB) already extended (as the text implies), or does it need to be extended? Same paragraph - "could be" should be "are either" (they MUST be one or the other, which is not what "could be X or Y" means). Section 7 (Management Options): Second paragraph - "refer" should be "refer to"... Section 9 (IANA Considerations): This is inconsistent with text earlier in the draft. For example, in secti= on 6.1.1, 6.2.1, 6.3.1 and 6.4.1, there is the statement that OIDs for MIB modules ar= e yet to be assigned and managed by IANA. I think this is intended as a general statement, as it does not seem that t= his document actually specifies any particular OIDs that would need to be assig= ned by IANA (or, if it does, I did not pick up on it). However, this document = seems to be making the point - possibly as a reminder - that the MIBs recommended by this draft will require OID assignments from IANA. I suggest saying something to this effect in the IANA considerations sectio= n and adding that there is no IANA action required specifically by this document.= You might easily modify the first two paragraphs in section 8 (Security Conside= rations) for this purpose in Section 9. You must do something to remove the current ambiguity, as it is not clear t= hat you are not requesting specific OIDs for the - as yet to be specified - new= objects in the OID trees in sections 6.1.1, 6.2.1, 6.3.1 and 6.4.1. From eric.gray@ericsson.com Tue Jun 21 07:51: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 7CB5511E81A7 for ; Tue, 21 Jun 2011 07:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.066 X-Spam-Level: X-Spam-Status: No, score=-4.066 tagged_above=-999 required=5 tests=[AWL=-2.270, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 aX4-2Vv6efoh for ; Tue, 21 Jun 2011 07:51:07 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C986511E8197 for ; Tue, 21 Jun 2011 07:50:24 -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 p5LEo7h2031228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jun 2011 09:50:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 21 Jun 2011 10:50:12 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 21 Jun 2011 10:50:10 -0400 Thread-Topic: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvgAAI39/AAPNmNoA== 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] FW: RE: [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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, 21 Jun 2011 14:51:08 -0000 Rm9yd2FyZGluZyBpbiBwbGFpbiB0ZXh0Li4uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21d DQpTZW50OiBNb25kYXksIEp1bmUgMjAsIDIwMTEgNTo1MSBBTQ0KVG86IEFsZXhhbmRlciBWYWlu c2h0ZWluOyBtYS55dXhpYUB6dGUuY29tLmNuDQpDYzogbXBsc0BpZXRmLm9yZzsgU3ByZWNoZXIs IE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiBS RTogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFAgTGlu ZWFyIFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KDQoNClNhc2hhLA0KDQoN Cg0KSSB0aGluayB0aGUgbWFpbiBxdWVzdGlvbiBoZXJlIGlzIHdoeSBjYWxsIFBXIGxpbmVhciBw cm90ZWN0aW9uIGFuIGFkLWhvYyBtZWNoYW5pc20gd2hlbiBpdKGvcyBzaW1wbHkgYW4gZXh0ZW5z aW9uIG9mIExTUCBsaW5lYXIgcHJvdGVjdGlvbi4gRnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwb2lu dCBvZiB2aWV3LCB0aGUgZGlmZmVyZW5jZXMgYXJlIG1pbmltYWwgqEMgeW91IGNvdWxkIGV2ZW4g c2F5IHNlbWFudGljLiBJIHRoaW5rIHRoaXMgaXMgd2hhdCBNYSBtZWFucyBieSBzaW1wbGljaXR5 IGFuZCBJIHdob2xseSBhZ3JlZSB3aXRoIGhlciCoQyB5b3UgaGF2ZSBhIHNpbmdsZSBtZWNoYW5p c20gdG8gcHJvdGVjdCBhbGwgdHJhbnNwb3J0IHBhdGhzIKhDIGJlIHRoZW0gTFNQIG9yIFBXLg0K DQoNCg0KTXkgdHdvIGNlbnRzLA0KDQoNCg0KREMNCg0KDQoNCkZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQpTZW50OiBN b25kYXksIEp1bmUgMjAsIDIwMTEgMTE6NTAgQU0NClRvOiBtYS55dXhpYUB6dGUuY29tLmNuDQpD YzogRGFuaWVsIENvaG47IG1wbHNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwv SG9kIEhhU2hhcm9uKTsgcHdlM0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFJFOiBbbXBsc10gW1BX RTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQIExpbmVhciBQcm90ZWN0aW9uIEFw cGxpY2FiaWxpdHkgdG8gTVMtUFciDQoNCg0KDQpEZWFyIE1hLA0KDQpMb3RzIG9mIHRoYW5rcyBm b3Igb3VyIHJlc3BvbnNlLiBQbGVhc2Ugc2VlIHNvbWUgY29tbWVudHMvYW5zd2VycyBpbmxpbmUg YmVsb3cuDQoNCg0KDQpSZWdhcmRzLA0KDQogICAgIFNhc2hhDQoNCg0KDQpGcm9tOiBtYS55dXhp YUB6dGUuY29tLmNuIFttYWlsdG86bWEueXV4aWFAenRlLmNvbS5jbl0NClNlbnQ6IE1vbmRheSwg SnVuZSAyMCwgMjAxMSAxMTozMSBBTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpDYzogRGFu aWVsIENvaG47IG1wbHNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhh U2hhcm9uKTsgcHdlM0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogUkU6IFttcGxzXSBbUFdFM10g U2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFBMaW5lYXJQcm90ZWN0aW9uQXBwbGljYWJp bGl0eSB0byBNUy1QVyINCg0KDQoNCg0KSGkgU2FzaGEsDQoNCiJMaW5lYXIgcHJvdGVjdGlvbiIg aXMgZGlmZmVyZW50IGZyb20gIk11bHRpLWhvbWVkIENFIHJlZHVuZGFuY3kiIGFuZCBoYXMgbm8g cmVmZXJlbmNlIHdpdGggQUMuDQoNCltbW1Nhc2hhXV1dIEFic29sdXRlbHkuDQoNCg0KV29ya2lu ZyBwYXRoKHMpIGFuZCBwcm90ZWN0aW9uIHBhdGgocykgaGF2ZSBzYW1lIHNvdXJjZSBhbmQgc2lu ayBlbmRwb2ludHMgaW4gbGluZWFyIHByb3RlY3Rpb24gdHlwZS4NCg0KW1tbU2FzaGFdXV0gT2Yg Y291cnNlLg0KDQoNCg0KSU1ITywgV2hlbiBTLVBFIGZhaWxzLCBpdCBpcyBtb3JlIHNpbXBsZSB0 byB1c2UgIkxpbmVhciBwcm90ZWN0aW9uIiB0byBwcm90ZWN0IGl0Lg0KDQpbW1tTYXNoYV1dXSBX ZWxsLCBzaW1wbGljaXR5ICwgbGlrZSBiZWF1dHksIGlzIGluIHRoZSBleWUgb2YgdGhlIGJlaG9s ZGVySi4NCg0KQnV0IElNSE8gIGludHJvZHVjaW5nIG11bHRpcGxlIHNpbXBsZSBhZCBob2Mgc29s dXRpb25zIChlYWNoIGZvciBpdHMgc3BlY2lmaWMgY2FzZSkgYW5kIG1haW50YWluaW5nIHRoZW0g IGV2ZW50dWFsbHkgbWFrZSB5b3VyIGxpZmUgbW9yZSAgY29tcGxpY2F0ZWQgd2hlbiBjb21wYXJl ZCB3aXRoIG9uZSBnZW5lcmljIG1lY2hhbmlzbaGtDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQpNYQ0K DQoNCkFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4g0LTT2iAyMDExLTA2LTE0IDIwOjAyOjEwOg0KDQo+IERhbmllbCwNCj4gUGxlYXNlIHNlZSBt b3JlIGlubGluZSAoYm9sZCBwdXJwbGUgaXRhbGljcykuIEmhr3ZlIGFsc28gc3RyaXBwZWQgdGhl DQo+IHBvcnRpb25zIG9mIHRoZSB0ZXh0IHRoYXQgYXJlIG5vdCByZWxhdGVkIHRvIHRoaXMgcm91 bmQgb2YgY29tbWVudHMuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgICAgU2FzaGENCj4NCj4gRnJvbTog RGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXks IEp1bmUgMTQsIDIwMTEgMjozNCBQTQ0KPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gQ2M6 IG1wbHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwv SG9kDQo+IEhhU2hhcm9uKTsgbWEueXV4aWFAenRlLmNvbS5jbg0KPiBTdWJqZWN0OiBSRTogW21w bHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90 ZWN0aW9uQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gSGkgU2FzaGEsIHRoYW5rcyBhZ2Fp biBhbmQgc2VlIGlubGluZSB3aXRoIFtEQ10uDQo+DQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0 ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+IFNlbnQ6IE1v bmRheSwgSnVuZSAxMywgMjAxMSA2OjExIFBNDQo+IFRvOiBEYW5pZWwgQ29obg0KPiBDYzogbXBs c0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZzsgU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QN Cj4gSGFTaGFyb24pOyBtYS55dXhpYUB6dGUuY29tLmNuDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10g W1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rp b25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBEYW5pZWwgYW5kIGFsbCwNCj4gUGxlYXNl IHNlZSBzb21lIGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCj4NCj4gUmVnYXJkcywNCj4gICAgICBT YXNoYQ0KPg0KPiBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV0N Cj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDU6NTUgUE0NCj4gVG86IFNwcmVjaGVyLCBO dXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgQWxleGFuZGVyIFZhaW5zaHRlaW47DQo+IG1h Lnl1eGlhQHp0ZS5jb20uY24NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMt DQo+IFRQTGluZWFyUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBIaSwN Cj4NCj4gVGhhbmtzIGFsbCBmb3IgdGhlIGZlZWRiYWNrLiBJIGJlbGlldmUgd2UgYWxsIGFncmVl IHRoYXQgUFcNCj4gcHJvdGVjdGlvbiBpcyBvbmx5IHJlcXVpcmVkIGluIHRoZSBldmVudCBvZiBT LVBFIGZhaWx1cmUgYXQgYW4gTVMtUFcNCj4gqEMgdGhpcyAgaXMgY2xlYXJseSBzdGF0ZWQgaW4g dGhlIGRyYWZ0LiBOb3csIGJvdGggU2FzaGEgYW5kIE51cml0DQo+IG1lbnRpb24gdGhhdCB0aGUg UFcgcmVkdW5kYW5jeSBtZWNoYW5pc20gY2FuIG1lZXQgdGhlIE1QTFMtVFAgUFcNCj4gcHJvdGVj dGlvbiByZXF1aXJlbWVudHMuDQo+IFtbW1Nhc2hhXV1dIKGtIHNuaXBwZWQgoa0NCj4gRS5nLiwg dGhlIFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtcyB0YWtlIGNhcmUgb2YgZHVhbC1ob21lZCBDRXMg aW4NCj4gU1MtIGFuZCBNUy1QV3MgqEMgc29tZXRoaW5nIHRoYXQgbGluZXIgcHJvdGVjdGlvbiBv ZiBQV3MgY2Fubm90IGRvLg0KPiBbRENdIEmhr20gYWZyYWlkIEkgZG9uoa90IGZvbGxvdyB5b3Ug aGVyZS4gV2hlcmUgZG9lcyBQVyByZWR1bmRhbmN5DQo+IHRha2UgY2FyZSBvZiBkdWFsLWhvbWVk IENFPyBBY3R1YWxseSBQVyByZWR1bmRhbmN5IGRyYWZ0IGV4cGxpY2l0bHkNCj4gc3RhdGVzOiCh sFRoZSBtZXRob2QgZm9yIGR1YWwtaG9taW5nIG9mIENFMSB0byBQRTEgYW5kIHRvIFBFMyBub2Rl cywNCj4gYW5kIHRoZSBwcm90b2NvbHMgdXNlZCwgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnShsS4NCj4gW1tbU2FzaGFdXV0gUXVvdGluZyBmcm9tIHRoZSBkcmFmdDoNCj4g MTUuMi4gTXVsdGlwbGUgTXVsdGktaG9tZWQgQ0VzIHdpdGggc2luZ2xlIFNTLVBXIHJlZHVuZGFu Y3kNCj4NCj4gICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gRW11bGF0ZWQgU2VydmljZSAt LS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAg fDwtLS0tLS0tIFBzZXVkbyBXaXJlIC0tLS0tLT58ICAgICAgICAgIHwNCj4gICAgICAgICAgICAg IHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwNCj4g ICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICB8PC0tIFBTTiBUdW5uZWxzLS0+fCAgICB8ICAg ICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAgViAgICBWICAgIChub3Qgc2hvd24p ICAgViAgICBWICAgICAgICAgIHwNCj4gICAgICAgICAgICAgIFYgICAgQUMgICAgKy0tLS0rICAg ICAgICAgICAgICAgICAgKy0tLS0rICAgICBBQyAgIFYNCj4gICAgICAgICstLS0tLSsgICAgfCAg ICAgfC4uLi58Li4uLi4uLlBXMS4uLi4uLi4ufC4uLi58ICAgICB8ICAgICstLS0tLSsNCj4gICAg ICAgIHwgICAgIHwtLS0tLS0tLS0tfCBQRTF8Li4uLi4uICAgLi4uLi4uLi4ufCBQRTN8LS0tLS0t LS0tLXwgICAgIHwNCj4gICAgICAgIHwgQ0UxIHwgICAgICAgICAgKy0tLS0rICAgICAgXCAvICBQ VzMgICAgKy0tLS0rICAgICAgICAgIHwgQ0UyIHwNCj4gICAgICAgIHwgICAgIHwgICAgICAgICAg Ky0tLS0rICAgICAgIFggICAgICAgICAgKy0tLS0rICAgICAgICAgIHwgICAgIHwNCj4gICAgICAg IHwgICAgIHwgICAgICAgICAgfCAgICB8Li4uLi4uLyBcLi5QVzQuLi4ufCAgICB8ICAgICAgICAg IHwgICAgIHwNCj4gICAgICAgIHwgICAgIHwtLS0tLS0tLS0tfCBQRTJ8ICAgICAgICAgICAgICAg ICAgfCBQRTR8LS0tLS0tLS0tIHwgICAgIHwNCj4gICAgICAgICstLS0tLSsgICAgfCAgICAgfC4u Li58Li4uLi5QVzIuLi4uLi4uLi4ufC4uLi58ICAgICB8ICAgICstLS0tLSsNCj4gICAgICAgICAg ICAgICAgICAgQUMgICAgKy0tLS0rICAgICAgICAgICAgICAgICAgKy0tLS0rICAgIEFDDQo+DQo+ DQo+ICAgICAgRmlndXJlIDE1LTIgTXVsdGlwbGUgTXVsdGktaG9tZWQgQ0VzIHdpdGggc2luZ2xl IFNTLVBXIHJlZHVuZGFuY3kNCj4NCj4gICAgVGhlIGFwcGxpY2F0aW9uIGluIEZpZ3VyZSAxNS0y IG1ha2VzIHVzZSBvZiB0aGUgSW5kZXBlbmRlbnQgbW9kZSBvZg0KPiAgICBvcGVyYXRpb24uDQo+ DQo+ICAgIENFMSBpcyBkdWFsLWhvbWVkIHRvIFBFMSBhbmQgUEUyLiBDRTIgaXMgZHVhbC1ob21l ZCBQRTMgYW5kIFBFNC4gVGhlDQo+ICAgIG1ldGhvZCBmb3IgZHVhbC1ob21pbmcgYW5kIHRoZSB1 c2VkIHByb3RvY29scyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUNCj4gICAgb2YgdGhpcyBkb2N1bWVu dC4gIE5vdGUgdGhhdCB0aGUgUFNOIHR1bm5lbHMgYXJlIG5vdCBzaG93biBpbiB0aGlzDQo+ICAg IGZpZ3VyZSBmb3IgY2xhcml0eS4gSG93ZXZlciwgaXQgY2FuIGJlIGFzc3VtZWQgdGhhdCBlYWNo IG9mIHRoZSBQV3MNCj4gICAgc2hvd24gaXMgZW5jYXBzdWxhdGVkIGluIGEgc2VwYXJhdGUgUFNO IHR1bm5lbC4NCj4NCj4gICAgQXNzdW1lIHRoYXQgdGhlIEFDIGZyb20gQ0UxIHRvIFBFMSBpcyBB Y3RpdmUsIGZyb20gQ0UxIHRvIFBFMiBpcw0KPiAgICBTdGFuZGJ5OyBmdXJ0aGVybW9yZSwgYXNz dW1lIHRoYXQgdGhlIEFDIGZyb20gQ0UyIHRvIFBFMyBpcyBTdGFuZGJ5DQo+ICAgIGFuZCBmcm9t IENFMiB0byBQRTQgaXMgQWN0aXZlLiBUaGUgbWV0aG9kIG9mIGRlcml2aW5nIEFjdGl2ZS9TdGFu ZGJ5DQo+ICAgIHN0YXR1cyBvZiB0aGUgQUMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC4NCj4NCj4gICAgUEUxIGFkdmVydGlzZXMgdGhlIHByZWZlcmVudGlhbCBzdGF0dXMg IkFjdGl2ZSIgYW5kIG9wZXJhdGlvbmFsDQo+ICAgIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJk aW5nIiBmb3IgcHNldWRvd2lyZXMgUFcxIGFuZCBQVzQgY29ubmVjdGVkDQo+ICAgIHRvIFBFMyBh bmQgUEU0LiBUaGlzIHN0YXR1cyByZWZsZWN0cyB0aGUgZm9yd2FyZGluZyBzdGF0ZSBvZiB0aGUg QUMNCj4gICAgYXR0YWNoZWQgdG8gUEUxLiBQRTIgYWR2ZXJ0aXNlcyBwcmVmZXJlbnRpYWwgc3Rh dHVzICJTdGFuZGJ5IiBhbmQNCj4gICAgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZv cndhcmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzIgYW5kDQo+ICAgIFBXMyB0byBQRTMgYW5kIFBF NC4gUEUzIGFkdmVydGlzZXMgcHJlZmVyZW50aWFsIHN0YXR1cyAiU3RhbmRieSIgYW5kDQo+ICAg IG9wZXJhdGlvbmFsIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2ly ZXMgUFcxIGFuZA0KPiAgICBQVzMgdG8gUEUxIGFuZCBQRTIuIFBFNCBhZHZlcnRpc2UgdGhlIHBy ZWZlcmVudGlhbCBzdGF0dXMgIkFjdGl2ZSINCj4gICAgYW5kIG9wZXJhdGlvbmFsIHN0YXR1cyAi UHNldWRvd2lyZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMgUFcyDQo+ICAgIGFuZCBQVzQg dG8gUEUyIGFuZCBQRTEgcmVzcGVjdGl2ZWx5LiBUaHVzIGJ5IG1hdGNoaW5nIHRoZSBsb2NhbCBh bmQNCj4gICAgcmVtb3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0aXZl IiBhbmQgb3BlcmF0aW9uYWwNCj4gICAgc3RhdHVzIG9mICJQc2V1ZG93aXJlIGZvcndhcmRpbmci IG9mIHBzZXVkb3dpcmVzLCB0aGUgUEUgbm9kZXMNCj4gICAgZGV0ZXJtaW5lIHdoaWNoIFBXIHNo b3VsZCBiZSBpbiB0aGUgQWN0aXZlIHN0YXRlLiBJbiB0aGlzIGNhc2UgaXQgaXMNCj4gICAgUFc0 IHRoYXQgd2lsbCBiZSBzZWxlY3RlZC4NCj4NCj4gICAgT24gZmFpbHVyZSBvZiB0aGUgQUMgYmV0 d2VlbiBDRTEgYW5kIFBFMSwgdGhlIGZvcndhcmRpbmcgc3RhdGUgb2YNCj4gICAgdGhlIEFDIG9u IFBFMiBpcyBjaGFuZ2VkIHRvIEFjdGl2ZS4gUEUyIHRoZW4gYW5ub3VuY2VzIHRoZSBuZXdseQ0K PiAgICBjaGFuZ2VkICdwcmVmZXJlbnRpYWwgZm9yd2FyZGluZycgc3RhdHVzIGJpdCBvZiAiYWN0 aXZlIiB0byBQRTMgYW5kDQo+ICAgIFBFNC4gUEUxIHdpbGwgYWR2ZXJ0aXNlIGEgUFcgc3RhdHVz IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGluZGljYXRpbmcNCj4gICAgdGhhdCB0aGUgQUMgYmV0d2Vl biBDRTEgYW5kIFBFMSBpcyBvcGVyYXRpb25hbGx5IGRvd24uIFBFMiBhbmQgUEU0DQo+ICAgIG1h dGNoIHRoZSBsb2NhbCBhbmQgcmVtb3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBv Zg0KPiAgICAiQWN0aXZlIiBhbmQgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndh cmRpbmciIGFuZCBzZWxlY3QNCj4gICAgUFcyIGFzIHRoZSBuZXcgYWN0aXZlIHBzZXVkb3dpcmUg dG8gc2VuZCB0cmFmZmljIHRvLg0KPg0KPiAgICBPbiBmYWlsdXJlIG9mIFBFMSBub2RlLCBQRTIg d2lsbCBkZXRlY3QgaXQgYW5kIHdpbGwgdHJhbnNpdGlvbiB0aGUNCj4gICAgZm9yd2FyZGluZyBz dGF0ZSBvZiBpdHMgQUMgdG8gQWN0aXZlLiBUaGUgbWV0aG9kIGJ5IHdoaWNoIFBFMg0KPiAgICBk ZXRlY3RzIHRoYXQgUEUxIGlzIGRvd24gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4gUEUyDQo+ICAgIHRoZW4gYW5ub3VuY2VzIHRoZSBuZXdseSBjaGFuZ2VkICdwcmVmZXJl bnRpYWwgZm9yd2FyZGluZycgc3RhdHVzDQo+ICAgIGJpdCBvZiAiQWN0aXZlIiB0byBQRTMgYW5k IFBFNC4gUEUyIGFuZCBQRTQgbWF0Y2ggdGhlIGxvY2FsIGFuZA0KPiAgICByZW1vdGUgcHJlZmVy ZW50aWFsIGZvcndhcmRpbmcgc3RhdHVzIG9mICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAg ICBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgYW5kIHNlbGVjdCBQVzIgYXMgdGhlIG5l dyBhY3RpdmUNCj4gICAgcHNldWRvd2lyZSB0byBzZW5kIHRyYWZmaWMgdG8uIE5vdGUgdGhhdCBQ RTMgYW5kIFBFNCBtYXkgaGF2ZQ0KPiAgICBkZXRlY3RlZCB0aGF0IHRoZSBQVyB0byBQRTEgd2Vu dCBkb3duIHZpYSBULUxEUCBIZWxsbyB0aW1lb3V0IG9yIHZpYQ0KPiAgICBvdGhlciBtZWFucy4g SG93ZXZlciwgdGhleSB3aWxsIG5vdCBiZSBhYmxlIHRvIGZvcndhcmQgdXNlciB0cmFmZmljDQo+ ICAgIHVudGlsIHRoZXkgcmVjZWl2ZWQgdGhlIHVwZGF0ZWQgc3RhdHVzIGJpdCBmcm9tIFBFMi4N Cj4NCj4gICAgQmVjYXVzZSBlYWNoIGR1YWwtaG9taW5nIGFsZ29yaXRobSBydW5uaW5nIG9uIHRo ZSB0d28gbm9kZSBzZXRzLA0KPiAgICBpLmUuLCB7Q0UxLCBQRTEsIFBFMn0gYW5kIHtDRTIsIFBF MywgUEU0fSwgc2VsZWN0cyB0aGUgYWN0aXZlIEFDDQo+ICAgIGluZGVwZW5kZW50bHksIHRoZXJl IGlzIGEgbmVlZCB0byBzaWduYWwgdGhlIGFjdGl2ZSBzdGF0dXMgb2YgdGhlIEFDDQo+ICAgIHN1 Y2ggdGhhdCB0aGUgUEUgbm9kZXMgY2FuIHNlbGVjdCBhIGNvbW1vbiBhY3RpdmUgUFcgZm9yIGVu ZC10by1lbmQNCj4gICAgZm9yd2FyZGluZyBiZXR3ZWVuIENFMSBhbmQgQ0UyIGFzIHBlciB0aGUg cHJvY2VkdXJlcyBpbiB0aGUNCj4gICAgaW5kZXBlbmRlbnQgbW9kZS4NCj4NCj4gICAgTm90ZSB0 aGF0IGFueSBwcmltYXJ5L3NlY29uZGFyeSBwcm9jZWR1cmVzLCBhcyBkZWZpbmVkIGluIHNlY3Rp b25zDQo+ICAgIDUuMS4gIGFuZCA1LjIuICwgZG8gbm90IGFwcGx5IGluIHRoaXMgdXNlIGNhc2Ug YXMgdGhlIEFjdGl2ZS9TdGFuZGJ5DQo+ICAgIHN0YXR1cyBpcyBkcml2ZW4gYnkgdGhlIEFDIGZv cndhcmRpbmcgc3RhdGUgYXMgZGV0ZXJtaW5lZCBieSB0aGUgQUMNCj4gICAgZHVhbC1ob21pbmcg cHJvdG9jb2wgdXNlZC4NCj4NCj4NCj4gSSBiZWxpZXZlIHlvdaGvdmUgdGFrZW4geW91ciChsG91 dCBvZiBzY29wZaGxIHJlZmVyZW5jZSBmcm9tIHRoaXMgdGV4dCwNCj4gYnV0IElNSE8geW91IG1p c2ludGVycHJldGVkIGl0Lg0KPiBXaGF0IGl0IG1lYW5zIChvciBzbyBJIHJlYWQgaXQpIGlzIHRo YXQgc3BlY2lmaWMgZHVhbC1ob21pbmcNCj4gcHJvdG9jb2wgaXMgb3V0IG9mIHNjb3BlIGFzIGxv bmcgYXMgaXQgbWVldHMgY2VydGFpbiBhc3N1bXB0aW9ucy4NCj4gQXNpZGU6IEl0IHdvdWxkIGJl IGdvb2QgaWYgdGhlIGF1dGhvcnMgb2YgdGhlIFBXIHJlZHVuZGFuY3kgZHJhZnRzDQo+IGNvdWxk IGV4cGxpY2l0bHkgc3BlY2lmeSB0aGVzZSBhc3N1bXB0aW9ucy4NCj4NCj4gW1tbU2FzaGFdXV0g oa0gc25pcHBlZCChrQ0KPg0KPiBOb3cgbGV0oa9zIHR1cm4gb3VyIGF0dGVudGlvbiBiYWNrIHRv IHdoZXRoZXIgdGhlIFBXIHJlZHVuZGFuY3kNCj4gZHJhYWZ0IGNhbiBiZSB1c2VkIHRvIG1lZXQg TVBMUy1UUCBQVyBwcm90ZWN0aW9uIHJlcXVpcmVtZW50cy4gSSBjYW4NCj4gaWRlbnRpZnkgdGhl IGZvbGxvd2luZyByZWFzb25zIHdoeSBpbiBpdHMgY3VycmVudCBmb3JtIGl0IGRvZXNuoa90Og0K Pg0KPiAtICAgICAgICAgIEl0IGV4cGxpY2l0bHkgKKGwb3V0c2lkZSB0aGUgc2NvcGWhsSkgZG9l cyBub3QgZGVmaW5lDQo+IHByb3RlY3Rpb24gdHJpZ2dlcnMgYW5kIGhvdyB0byBoYW5kbGUgY29l eGlzdGluZyB0cmlnZ2VycywgYXMNCj4gcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQIFJl cXVpcmVtZW50cyksIHJlcXMgIzc1LCAjNzYgYW5kICM3OQ0KPiBbW1tTYXNoYV1dXSBTbyB3aGF0 PyBEZWZpbml0aW9uIG9mIHRyaWdnZXJzIGlzIG9ydGhvZ29uYWwgdG8gaG93DQo+IGNvb3JkaW5h dGVkIHByb3RlY3Rpb24gc3dpdGNoaW5nIGhhcHBlbnMuDQo+IFtEQ10gSXQgaXMuIEJ1dCBzdGls bCBpdCBuZWVkcyB0byBiZSBkZWZpbmVkIGJ5IHRoZSByZWNvdmVyeQ0KPiBmcmFtZXdvcmssIGUu Zy4gd2hhdCBzaG91bGQgdGhlIGVuZHBvaW50IGRvIHdoZW4gb25lIFBXIGlzIGluIFNGIGFuZA0K PiB0aGUgb3RoZXIgaXMgaW4gU0QsIG9yIHdoZW4gYm90aCBhcmUgaW4gU0QuIE9wZXJhdG9ycyBl eHBlY3Qgd2VsbC0NCj4gZGVmaW5lZCBiZWhhdmlvciBpbiB0aGVzZSBhbmQgb3RoZXIgc2NlbmFy aW9zLCBhbmQgUFcgcmVkdW5kYW5jeQ0KPiBkb2VzIG5vdCBkZWZpbmUgdGhlbSAoYmVjYXVzZSBp dCB3YXMgbm90IGluIHRoZWlyIHNjb3BlKS4NCj4gW1tbU2FzaGFdXV0gSSB3b25kZXIgaWYgeW91 IGhhdmUgZm9sbG93ZWQgdGhlIGRpc2N1c3Npb24gcmVnYXJkaW5nDQo+IGFiaWxpdHkgdG8gZGVm aW5lIFNEIGNvbmRpdGlvbiBmb3IgTFNQcyBhbmQgUFdzIG9uIHRoZSBNUExTLVRQIGxpc3Q/DQo+ IElNTyBpdCBpcyBub3QgcG9zc2libGUgdG8gZGVmaW5lIGl0IGluIGEgbWVhbmluZ2Z1bCB3YXku IEhlbmNlIEkgZG8NCj4gbm90IHNlZSBhIHByb3Bvc2FsIHRoYXQgZG9lcyBub3QgYWRkcmVzcyBh IHNjZW5hcmlvIHRoYXQgZG9lcyBub3QNCj4gZXhpc3QgaW4gcmVhbGl0eSBhcyBhIGZsYXdlZCBv bmUuDQo+DQo+IC0gICAgICAgICAgSXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBk aXN0aW5ndWlzaCBiZXR3ZWVuDQo+IGRpZmZlcmVudCB0eXBlcyBvZiB0cmlnZ2VycyAoaS5lLiBv bmUgZW5kIGRvZXNuoa90IGtub3cgd2h5IHRoZSBvdGhlcg0KPiBlbmQgdHJpZ2dlcmVkIHN3aXRj aCksIGFzIHJlcXVlc3RlZCBpbiBSRkMgNTY1NCAoTVBMUy1UUA0KPiBSZXF1aXJlbWVudHMpLCBy ZXEgIzc3DQo+IC0gICAgICAgICAgSXQgZG9lcyBub3QgZGVmaW5lIHJldmVydGl2ZS9ub25yZXZl cnRpdmUgYmVoYXZpb3IsIGFzDQo+IHJlcXVlc3RlZCBpbiBSRkMgNTY1NCAoTVBMUy1UUCBSZXF1 aXJlbWVudHMpLCByZXEgIzY0DQo+IC0gICAgICAgICAgSXQgZG9lcyBub3QgZGVmaW5lIGhvbGRv ZmYgc3VwcG9ydCwgd2hpY2ggaXMgZXNwZWNpYWxseQ0KPiBpbXBvcnRhbnQgdG8gYXZvaWQgcmFj ZSBjb25kaXRpb25zIHdpdGggTFNQIHByb3RlY3Rpb24gd2hlbiBpdCBleGlzdHMNCj4gLSAgICAg ICAgICBJdCBkb2VzbqGvdCBzdXBwb3J0IDErMSBtb2RlLCBhcyByZXF1ZXN0ZWQgaW4gUkZDIDU2 NTQNCj4gKE1QTFMtVFAgUmVxdWlyZW1lbnRzKSwgcmVxICM2NQ0KPiBbW1tTYXNoYV1dXSBBbGwg dGhlc2UgY2xhaW1zIGFyZSBjb3JyZWN0IKhDIGFuZCAgdGhpcyBzaG91bGQgbm90IGJlIGENCj4g c3VycHJpc2UsIGJlY2F1c2UgTVBMUy1UUCByZXF1aXJlbWVudHMgaGF2ZSBiZWVuIGRlZmluZWQg bXVjaCBsYXRlcg0KPiB0aGFuIHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbS4NCj4gQnV0IEkg ZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBqdXN0aWZpZXMgY28tZXhpc3RlbmNlIG9mIHR3byBkaWZm ZXJlbnQNCj4gbWVjaGFuaXNtcy4NCj4gW0RDXSBTbyBob3cgZG8geW91IHByb3Bvc2UgdG8gbWVl dCB0aGUgUFcgcHJvdGVjdGlvbiByZXF1aXJlbWVudD8NCj4gLSAgICAgICAgICBJdKGvcyBhIHR3 by1waGFzZSBwcm90b2NvbCwgd2l0aCB0aGUgY29uc2VxdWVudCBpbXBhY3Qgb24gdGltaW5nDQo+ IFtbW1Nhc2hhXV1dIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlPyBbRENdIEluIGRyYWZ0LWll dGYtbXBscy10cC0NCj4gbGluZWFyLXByb3RlY3Rpb24sIGVhY2ggZW5kcG9pbnQgd2lsbCBpbW1l ZGlhdGVseSBzd2l0Y2ggdHJhZmZpYyB0bw0KPiB0aGUgb3RoZXIgcGF0aCB1cG9uIGlkZW50aWZ5 aW5nIGFuIFNGIGNvbmRpdGlvbiBpbiBhIHBhdGgsIHdpdGhvdXQNCj4gd2FpdGluZyBmb3IgdGhl IGZhciBlbmQgdG8gYWNrbm93bGVkZ2UgdGhlIHN3aXRjaCAoMS1waGFzZSkuIEluIFBXDQo+IHJl ZHVuZGFuY3ksIGFuIGVuZHBvaW50IGRldGVjdGluZyBhbiBTRiBjb25kaXRpb24gaW4gYSBwYXRo IHdpbGwgbm90DQo+IHN3aXRjaCB1bnRpbCB0aGUgZmFyIGVuZCBoYXMgYWNrbm93bGVkZ2VkIHRo ZSBzd2l0Y2ggKDItcGhhc2UpLg0KPiBOZWVkbGVzcyB0byBzYXksIHJlY292ZXJ5IGlzIHNsb3dl ciBpbiBhIDItcGhhc2UgcHJvdG9jb2wuDQo+IFtbW1Nhc2hhXV1dIFRvIHRoZSBiZXN0IG9mIG15 IHVuZGVyc3RhbmRpbmcsIDEtcGhhc2UgcHJvdGVjdGlvbiBpcw0KPiBvbmx5IHBvc3NpYmxlIGlu IDErMSB1bmlkaXJlY3Rpb25hbCBhcmNoaXRlY3R1cmVzLiBBbmQgeWVzLCBJIGtub3cNCj4gdGhh dCBNUExTLVRQIHJlcXVpcmVzIGEgIG1lY2hhbmlzbSB0byBzdXBwb3J0IHRoaXM7IHdoZXRoZXIg YW55Ym9keQ0KPiB3b3VsZCByZWFsbHkgZG8gdGhhdCBpbiB0aGUgcGFja2V0LXN3aXRjaGluZyBu ZXR3b3JrIGlzIG5vdCBjbGVhciB0bw0KPiBtZS4gQW5kIEkgYWNrbm93bGVkZ2UgdGhhdCB0aGUg UFcgcmVkdW5kYW5jeSBkcmFmdHMgZG8gbm90IHN1cHBvcnQNCj4gMSsxIHVuaWRpcmVjdGlvbmFs IHNjaGVtZS4NCj4NCj4gLSAgICAgICAgICBJdCBkb2VzbqGvdCBkZWZpbmUgcmV0cmFuc21pc3Np b24gb2YgcHJvdGVjdGlvbg0KPiBjb29yZGluYXRpb24gbWVzc2FnZXMsIHNvIGxvc3Mgb2YgYSBz aW5nbGUgUERVIGNhbiByZXN1bHQgaW4NCj4gc3dpdGNob3ZlciBub3QgdGFraW5nIHBsYWNlLCB0 aHVzIG5vdCBzdXBwb3J0aW5nIHN1Yi01MCBtcyByZWNvdmVyeQ0KPiBpbiB0aGlzIGNhc2UNCj4g W1tbU2FzaGFdXV0gVGhlIFBXIHJlZHVuZGFuY3kgcHJvdG9jb2wgcnVucyBlaXRoZXIgb24gdG9w IG9mIExEUA0KPiAod2hpY2ggYmVuZWZpdHMgZnJvbSBUQ1AgcmV0cmFuc21pc3Npb25zKSBvciBv biB0b3Agb2Ygc3RhdGljIFBXDQo+IHN0YXR1cyBtZXNzYWdlcyAod2hlcmUgcmV0cmFuc21pc3Np b24gaXMgZGVmaW5lZCkuDQo+IFtEQ10gVHJ1ZSCoQyBidXQgc3RhdGljIFBXIHN0YXR1cyBkZWZp bmVzIHNsb3cgcmV0cmFuc21pc3Npb24gKKGwd2lsbA0KPiBiZSB0cmFuc21pdHRlZCB0d2ljZSBh dCBhbiBpbml0aWFsIGludGVydmFsIG9mIG9uZSBzZWNvbmShsSkgd2hpbGUNCj4gZHJhZnQtaWV0 Zi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uIHNwZWNpZmllcyBmYXN0IHJldHJhbnNtaXNzaW9u DQo+IHdoZW4gcmVxdWlyZWQgZm9yIGZhc3QgcmVjb3ZlcnkgKHNlY3Rpb24gMy4xLjQpLg0KPg0K PiBJbiBzdW1tYXJ5LCBQVyByZWR1bmRhbmN5IHdhcyBub3QgZGVzaWduZWQgd2l0aCBUUCByZXF1 aXJlbWVudHMgaW4NCj4gbWluZCwgYW5kIGFzIHN1Y2ggZG9lcyBub3QgbWVldCB0aGUgVFAgcmVx dWlyZW1lbnRzLiBPZiBjb3Vyc2UNCj4gbW9kaWZpY2F0aW9ucyBtYXkgYmUgaW50cm9kdWNlZCwg YnV0IHdoeSByZWludmVudCB0aGUgd2hlZWwgd2hlbg0KPiB0aGVyZSBpcyBhIHByb3RvY29sIChk cmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tMDYpIGluIHRoZQ0KPiBzdGFuZGFy ZHMgdHJhY2sgdGhhdCBzdXBwb3J0cyBhbGwgdGhlIGFib3ZlIHJlcXVpcmVtZW50cyBhbmQgY2Fu IGJlDQo+IGFwcGxpZWQgdG8gTVMtUFcgcHJvdGVjdGlvbiB3aXRoIG1pbm9yIG1vZGlmaWNhdGlv bnM/DQo+IFtbW1Nhc2hhXV1dIEFzIEkgc2FpZCwgYmVjYXVzZSB0aGUgYXBwbGljYWJpbGl0eSBz Y29wZSBpcyBieSBmYXIgdG9vDQo+IG5hcnJvdyB0byBqdXN0aWZ5IGEgZGVkaWNhdGVkIHByb3Rv Y29sLg0KPiBbRENdIElmIHdlIHdlcmUgZGlzY3Vzc2luZyBkZXNpZ25pbmcgYSBuZXcgcHJvdG9j b2wsIEkgbWlnaHQgYWdyZWUNCj4gd2l0aCB5b3UuIEJ1dCBmcm9tIGEgcHJhY3RpY2FsIHN0YW5k cG9pbnQsIHRoZSBQVyBwcm90ZWN0aW9uIGRyYWZ0DQo+IGlzIG5vdCBhIGRlZGljYXRlZCBwcm90 b2NvbCCoQyBpdKGvcyBhbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0byBhbg0KPiBleGlzdGlu ZyBwcm90b2NvbC4gQm90aCBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIG9wZXJhdGlv bmFsDQo+IHBvaW50IG9mIHZpZXcgaXQgZGVmaW5lcyBhIG5ldyB1c2UgY2FzZSBmb3IgYW4gZXhp c3RpbmcgcHJvdG9jb2wgYW5kIGNvbmNlcHQuDQo+DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IERhbmll bA0KPg0KPg0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hv ZCBIYVNoYXJvbikNCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDQ6MDIgUE0NCj4gVG86 IGV4dCBBbGV4YW5kZXIgVmFpbnNodGVpbjsgbWEueXV4aWFAenRlLmNvbS5jbg0KPiBDYzogbXBs c0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIFtQV0UzXSBT ZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0aW9uIEFwcGxp Y2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IEhpLA0KPiBJIHdvdWxkIGxpa2UgdG8gc2Vjb25kIFNh c2hhLg0KPiBFbmQtdG8tZW5kIFBXIHByb3RlY3Rpb24gKHdpdGggZGl2ZXJzZSBwYXRocykgZG9l cyBub3Qgc2NhbGUsIGFuZA0KPiBwdXQgaGFyZCByZXN0cmljdGlvbnMgb24gdGhlIHV0aWxpemF0 aW9uIG9mIHRoZSByZXNvdXJjZXMuDQo+IE1QTFMtVFAgUFdzIGFyZSBjYXJyaWVkIGFjcm9zcyB0 aGUgbmV0d29yayBpbnNpZGUgTVBMUy1UUCBMU1BzLg0KPiBUaGVyZWZvcmUsIGFuIG9idmlvdXMg d2F5IHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBmb3IgYSBQVyBpcyB0bw0KPiBwcm90ZWN0IHRoZSBM U1AgdGhhdCBjYXJyaWVzIGl0Lg0KPiBJZiB0aGUgUFcgaXMgYSBtdWx0aS1zZWdtZW50IFBXLCB0 aGVuIExTUCByZWNvdmVyeSBjYW4gb25seSBwcm90ZWN0DQo+IHRoZSBQVyBpbiBpbmRpdmlkdWFs IHNlZ21lbnRzLiAgVGhpcyBtZWFucyB0aGF0IGEgc2luZ2xlIExTUA0KPiByZWNvdmVyeSBhY3Rp b24gY2Fubm90IHByb3RlY3QgYWdhaW5zdCBhIGZhaWx1cmUgb2YgYSBQVyBzd2l0Y2hpbmcNCj4g cG9pbnQgKGFuIFMtUEUpLg0KPiBXaGVuIHByb3RlY3RpbmcgYWdhaW5zdCBhbiBBQyBvciBUL1Mt UEUgZmFpbHVyZSBieSBkdWFsDQo+IGNvbm5lY3Rpdml0eSwgUFcgcmVkdW5kYW5jeSBtZWNoYW5p c21zIHByb3ZpZGUgbWVhbnMgZm9yIHRoZSBQRXMgdG8NCj4gY29vcmRpbmF0ZSBvdmVyIHdoaWNo IExTUCB0aGUgdHJhZmZpYyBvZiB0aGUgUFcgaXMgY2FycmllZC4NCj4gSSBhbHNvIGRvdWJ0IHdo eSB0aGVyZSBpcyBhIG5lZWQgZm9yIGFkZGl0aW9uYWwgbWVjaGFuaXNtLg0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IE51cml0DQo+DQo+IEZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnB3 ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGV4dCBBbGV4YW5kZXIgVmFpbnNo dGVpbg0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgMzo0MyBQTQ0KPiBUbzogbWEueXV4 aWFAenRlLmNvbS5jbg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW1BXRTNdIFttcGxzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUA0K PiBMaW5lYXJQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IERlYXIgTWEg YW5kIGFsbCwNCj4gQWRkaW5nIHRoZSBQV0UzIFdHIHRvIG15IHJlc3BvbnNlLg0KPg0KPiBUaGUg UFcgcmVkdW5kYW5jeSBtZWNoYW5pc20gc3VwcG9ydHMgbGluZWFyIHByb3RlY3Rpb24gb2YgTVMt UFdzIGFzDQo+IG9uZSBvZiBtYW55IGFkZGl0aW9uYWwgYXBwbGljYXRpb24gdXNlIGNhc2VzOg0K PiBBcHBlbmRpeCBBIG9mIHRoZSBQVyByZWR1bmRhbmN5IEJpdCBkcmFmdCBkZXNjcmliZXMgNSBh cHBsaWNhdGlvbg0KPiB1c2VzIGNhc2VzIGluIGFkZGl0aW9uIHRvIE1TLVBXIHdpdGggc2luZ2xl LWhvbWVkIENFcyAod2hpY2ggaXMNCj4gbGlzdGVkIHRoZXJlIGFzIHVzZSBjYXNlIDUpLg0KPiBB bmQgaXQgaXMgZXF1YWxseSBhcHBsaWNhYmxlIHRvIElQL01QTFMgYW5kIE1QTFMgLSB3aXRoIHRo ZSBoZWxwIG9mICB0aGUNCj4gU3RhdGljIFBXIFN0YXR1cyBNZXNzYWdlcyBkcmFmdCggaWYsIGZv ciB3aGF0ZXZlciByZWFzb24sIHlvdSBkbyBub3QNCj4gd2FudCAgdG8sIG9yIGNhbm5vdCwgdXNl IFJGQyA0NDQ3KS4NCj4NCj4gSGVuY2UgSSBkb3VidCB0aGUgbmVlZCBmb3IgeWV0IGFub3RoZXIg UFcgcmVkdW5kYW5jeSAgbWVjaGFuaXNtIHdpdGgNCj4gbmFycm93IHNjb3BlIG9mIGFwcGxpY2Fi aWxpdHkuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgICAgU2FzaGENCj4NCj4gRnJvbTogbXBscy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cj4gbWEueXV4aWFAenRlLmNvbS5jbg0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgMzoy NSBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIFNlZWtpbmcg ZmVlZGJhY2sgb24gSS1EICJNUExTLVRQIExpbmVhcg0KPiBQcm90ZWN0aW9uIEFwcGxpY2FiaWxp dHkgdG8gTVMtUFciDQo+DQo+IEhpIGFsbCwNCj4NCj4gVGhlIGxpbmVhciBwcm90ZWN0aW9uIG1l Y2hhbmlzbSBmb3IgTFNQIGFuZCBQVyhpbmNsdWRpbmcgTVMtUFcpDQo+IHNob3VsZCBiZSB0aGUg c2FtZSBhbmQgaXQgaXMgdmFsdWFibGUgdG8gZGVzY3JpYmUgaXQgY2xlYXJseS4NCj4NCj4gQlRX LCB0aGVyZSBpcyBhIHR5cG8sIGl0IGlzICJULVBFIFoiIGluc3RlYWQgb2YgIlQtUEUgQiIuDQo+ DQo+ICAiDQo+ICAgRmlndXJlIDEgaWxsdXN0cmF0ZXMgc3VjaCBhIHNjZW5hcmlvLCB3aGVyZSB0 d28gTVMtUFdzIGFyZQ0KPiAgIGVzdGFibGlzaGVkIGJldHdlZW4gVC1QRSBBIGFuZCBULVBFIEIs IG92ZXIgUy1QRXMgMS0yIGFuZCAzLTQNCj4gICByZXNwZWN0aXZlbHkuIEVhY2ggUFcgc2VnbWVu dCBpcyBlc3RhYmxpc2hlZCBvdmVyIGFuIExTUCAoZS5nLiBQVy0NCj4gICBzMTIgb3ZlciBMU1Ax MikuDQo+ICAiDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhbmllbCBD b2huDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxMSA0OjE0IFBNDQo+IFRvOiBtcGxzDQo+ IFN1YmplY3Q6IFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQIExpbmVhciBQcm90ZWN0 aW9uDQo+IEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+IEltcG9ydGFuY2U6IEhpZ2gNCj4NCj4g SGkgTVBMU2VycywNCj4NCj4gSSB1cGxvYWRlZCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBB cHBsaWNhYmlsaXR5IHRvIE1TLVBXIiBJLUQNCj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWNvaG4tbXBscy10cC1wdy1wcm90ZWN0aW9uLTAwKQ0KPg0KPiBUaGUgYWJzdHJhY3Qg Z29lczoNCj4NCj4gT25lIG9mIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIE1QTFMgdHJhbnNwb3J0 IHByb2ZpbGUgW1JGQyA1NjU0XSBpcw0KPiB0byBwcm92aWRlIGxpbmVhciBwcm90ZWN0aW9uIGZv ciB0cmFuc3BvcnQgcGF0aHMsIHdoaWNoIGluY2x1ZGUgYm90aA0KPiBMU1BzIGFuZCBQV3MuIFRo ZSBmdW5jdGlvbmFsIGFyY2hpdGVjdHVyZSBkZXNjcmliZWQgaW4gW1N1cnZpdkZ3a10NCj4gaXMg YXBwbGljYWJsZSB0byBib3RoIExTUCBhbmQgUFdzLCBob3dldmVyIFtMaW5lYXJQcm90XSBkb2Vz IG5vdA0KPiBleHBsaWNpdGx5IGRlc2NyaWJlIG1lY2hhbmlzbXMgZm9yIFBXIHByb3RlY3Rpb24g aW4gTVBMUy1UUC4NCj4NCj4gVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIHRoZSBsaW5lYXIgcHJvdGVjdGlvbg0KPiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtMaW5l YXJQcm90XSB0byBNUExTLVRQIHNlZ21lbnRlZCBQV3MNCj4gKE1TLVBXcykgYXMgZGVmaW5lZCBp biBbUkZDIDYwNzNdLg0KPg0KPiBDb3VsZCB5b3UgcGxlYXNlIHJldmlldyBpdCBhbmQgc2VuZCBm ZWVkYmFjayB0byB0aGUgbWFpbGluZyBsaXN0IG9yDQo+IGRpcmVjdGx5IHRvIHRoZSBhdXRob3I/ DQo+DQo+IExvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGZlZWRiYWNrLA0KPg0KPiBEYW5pZWwNCj4g VGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFu ZCBjb250YWlucw0KPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNo IG1heSBiZSBwcm9wcmlldGFyeSB0bw0KPiBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPiBpbmZvcm0gdXMgYnkgZS1t YWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+IGFs bCBjb3BpZXMgdGhlcmVvZi4NCj4gVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3Ig dGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucw0KPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBD T05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0bw0KPiBFQ0kgVGVsZWNv bS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFz ZQ0KPiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kDQo+IGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4gVGhpcyBlLW1haWwgbWVz c2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucw0KPiBp bmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmll dGFyeSB0bw0KPiBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBm YXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+IGFsbCBjb3BpZXMgdGhlcmVv Zi4gqW16udo/P2JyPg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS4NCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBm b3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBD T05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCg0K From eric.gray@ericsson.com Tue Jun 21 07:52: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 71B2111E818B for ; Tue, 21 Jun 2011 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-2.108, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 w+fk8nnc-j5i for ; Tue, 21 Jun 2011 07:52:16 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8D27D11E80A4 for ; Tue, 21 Jun 2011 07:52:15 -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 p5LEqDwx031441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jun 2011 09:52:14 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 21 Jun 2011 10:52:13 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 21 Jun 2011 10:52:10 -0400 Thread-Topic: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvgAD8cIWA= 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] FW: RE: [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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, 21 Jun 2011 14:52:17 -0000 Rm9yd2FyZGluZyBpbiBwbGFpbiB0ZXh0IC0gd2l0aCBaVEUgYW5kIEVDSSBUZWxlY29tIGRpc2Ns YWltZXJzIHJlbW92ZWQuLi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAyMCwgMjAxMSA0OjUwIEFNDQpUbzogbWEu eXV4aWFAenRlLmNvbS5jbg0KQ2M6IERhbmllbCBDb2huOyBtcGxzQGlldGYub3JnOyBTcHJlY2hl ciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IHB3ZTNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJFOiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUCBM aW5lYXIgUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KDQoNCg0KRGVhciBNYSwN Cg0KTG90cyBvZiB0aGFua3MgZm9yIG91ciByZXNwb25zZS4gUGxlYXNlIHNlZSBzb21lIGNvbW1l bnRzL2Fuc3dlcnMgaW5saW5lIGJlbG93Lg0KDQoNCg0KUmVnYXJkcywNCg0KICAgICBTYXNoYQ0K DQoNCg0KRnJvbTogbWEueXV4aWFAenRlLmNvbS5jbiBbbWFpbHRvOm1hLnl1eGlhQHp0ZS5jb20u Y25dDQpTZW50OiBNb25kYXksIEp1bmUgMjAsIDIwMTEgMTE6MzEgQU0NClRvOiBBbGV4YW5kZXIg VmFpbnNodGVpbg0KQ2M6IERhbmllbCBDb2huOyBtcGxzQGlldGYub3JnOyBTcHJlY2hlciwgTnVy aXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IHB3ZTNAaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6 IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQTGluZWFy UHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQoNCg0KDQoNCkhpIFNhc2hhLA0KDQoi TGluZWFyIHByb3RlY3Rpb24iIGlzIGRpZmZlcmVudCBmcm9tICJNdWx0aS1ob21lZCBDRSByZWR1 bmRhbmN5IiBhbmQgaGFzIG5vIHJlZmVyZW5jZSB3aXRoIEFDLg0KDQpbW1tTYXNoYV1dXSBBYnNv bHV0ZWx5Lg0KDQoNCldvcmtpbmcgcGF0aChzKSBhbmQgcHJvdGVjdGlvbiBwYXRoKHMpIGhhdmUg c2FtZSBzb3VyY2UgYW5kIHNpbmsgZW5kcG9pbnRzIGluIGxpbmVhciBwcm90ZWN0aW9uIHR5cGUu DQoNCltbW1Nhc2hhXV1dIE9mIGNvdXJzZS4NCg0KDQoNCklNSE8sIFdoZW4gUy1QRSBmYWlscywg aXQgaXMgbW9yZSBzaW1wbGUgdG8gdXNlICJMaW5lYXIgcHJvdGVjdGlvbiIgdG8gcHJvdGVjdCBp dC4NCg0KW1tbU2FzaGFdXV0gV2VsbCwgc2ltcGxpY2l0eSAsIGxpa2UgYmVhdXR5LCBpcyBpbiB0 aGUgZXllIG9mIHRoZSBiZWhvbGRlckouDQoNCkJ1dCBJTUhPICBpbnRyb2R1Y2luZyBtdWx0aXBs ZSBzaW1wbGUgYWQgaG9jIHNvbHV0aW9ucyAoZWFjaCBmb3IgaXRzIHNwZWNpZmljIGNhc2UpIGFu ZCBtYWludGFpbmluZyB0aGVtICBldmVudHVhbGx5IG1ha2UgeW91ciBsaWZlIG1vcmUgIGNvbXBs aWNhdGVkIHdoZW4gY29tcGFyZWQgd2l0aCBvbmUgZ2VuZXJpYyBtZWNoYW5pc22hrQ0KDQoNCg0K QmVzdCBSZWdhcmRzLA0KTWENCg0KDQpBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20+INC009ogMjAxMS0wNi0xNCAyMDowMjoxMDoNCg0KPiBEYW5p ZWwsDQo+IFBsZWFzZSBzZWUgbW9yZSBpbmxpbmUgKGJvbGQgcHVycGxlIGl0YWxpY3MpLiBJoa92 ZSBhbHNvIHN0cmlwcGVkIHRoZQ0KPiBwb3J0aW9ucyBvZiB0aGUgdGV4dCB0aGF0IGFyZSBub3Qg cmVsYXRlZCB0byB0aGlzIHJvdW5kIG9mIGNvbW1lbnRzLg0KPg0KPiBSZWdhcmRzLA0KPiAgICAg IFNhc2hhDQo+DQo+IEZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29t XQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE0LCAyMDExIDI6MzQgUE0NCj4gVG86IEFsZXhhbmRl ciBWYWluc2h0ZWluDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hl ciwgTnVyaXQgKE5TTiAtIElML0hvZA0KPiBIYVNoYXJvbik7IG1hLnl1eGlhQHp0ZS5jb20uY24N Cj4gU3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1Q TFMtDQo+IFRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IEhp IFNhc2hhLCB0aGFua3MgYWdhaW4gYW5kIHNlZSBpbmxpbmUgd2l0aCBbRENdLg0KPg0KPiBGcm9t OiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgNjoxMSBQTQ0KPiBUbzogRGFu aWVsIENvaG4NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBO dXJpdCAoTlNOIC0gSUwvSG9kDQo+IEhhU2hhcm9uKTsgbWEueXV4aWFAenRlLmNvbS5jbg0KPiBT dWJqZWN0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy0N Cj4gVFBMaW5lYXJQcm90ZWN0aW9uQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gRGFuaWVs IGFuZCBhbGwsDQo+IFBsZWFzZSBzZWUgc29tZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+DQo+ IFJlZ2FyZHMsDQo+ICAgICAgU2FzaGENCj4NCj4gRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpE YW5pZWxDQG9yY2tpdC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSA1OjU1IFBN DQo+IFRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IEFsZXhhbmRl ciBWYWluc2h0ZWluOw0KPiBtYS55dXhpYUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3Jn OyBwd2UzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVl ZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0 byBNUy1QVyINCj4NCj4gSGksDQo+DQo+IFRoYW5rcyBhbGwgZm9yIHRoZSBmZWVkYmFjay4gSSBi ZWxpZXZlIHdlIGFsbCBhZ3JlZSB0aGF0IFBXDQo+IHByb3RlY3Rpb24gaXMgb25seSByZXF1aXJl ZCBpbiB0aGUgZXZlbnQgb2YgUy1QRSBmYWlsdXJlIGF0IGFuIE1TLVBXDQo+IKhDIHRoaXMgIGlz IGNsZWFybHkgc3RhdGVkIGluIHRoZSBkcmFmdC4gTm93LCBib3RoIFNhc2hhIGFuZCBOdXJpdA0K PiBtZW50aW9uIHRoYXQgdGhlIFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtIGNhbiBtZWV0IHRoZSBN UExTLVRQIFBXDQo+IHByb3RlY3Rpb24gcmVxdWlyZW1lbnRzLg0KPiBbW1tTYXNoYV1dXSChrSBz bmlwcGVkIKGtDQo+IEUuZy4sIHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgdGFrZSBjYXJl IG9mIGR1YWwtaG9tZWQgQ0VzIGluDQo+IFNTLSBhbmQgTVMtUFdzIKhDIHNvbWV0aGluZyB0aGF0 IGxpbmVyIHByb3RlY3Rpb24gb2YgUFdzIGNhbm5vdCBkby4NCj4gW0RDXSBJoa9tIGFmcmFpZCBJ IGRvbqGvdCBmb2xsb3cgeW91IGhlcmUuIFdoZXJlIGRvZXMgUFcgcmVkdW5kYW5jeQ0KPiB0YWtl IGNhcmUgb2YgZHVhbC1ob21lZCBDRT8gQWN0dWFsbHkgUFcgcmVkdW5kYW5jeSBkcmFmdCBleHBs aWNpdGx5DQo+IHN0YXRlczogobBUaGUgbWV0aG9kIGZvciBkdWFsLWhvbWluZyBvZiBDRTEgdG8g UEUxIGFuZCB0byBQRTMgbm9kZXMsDQo+IGFuZCB0aGUgcHJvdG9jb2xzIHVzZWQsIGFyZSBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50obEuDQo+IFtbW1Nhc2hhXV1dIFF1b3Rpbmcg ZnJvbSB0aGUgZHJhZnQ6DQo+IDE1LjIuIE11bHRpcGxlIE11bHRpLWhvbWVkIENFcyB3aXRoIHNp bmdsZSBTUy1QVyByZWR1bmRhbmN5DQo+DQo+ICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0t IEVtdWxhdGVkIFNlcnZpY2UgLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAg ICAgICAgICB8ICAgICAgICAgIHw8LS0tLS0tLSBQc2V1ZG8gV2lyZSAtLS0tLS0+fCAgICAgICAg ICB8DQo+ICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICB8DQo+ICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgfDwtLSBQU04g VHVubmVscy0tPnwgICAgfCAgICAgICAgICB8DQo+ICAgICAgICAgICAgICB8ICAgICAgICAgIFYg ICAgViAgICAobm90IHNob3duKSAgIFYgICAgViAgICAgICAgICB8DQo+ICAgICAgICAgICAgICBW ICAgIEFDICAgICstLS0tKyAgICAgICAgICAgICAgICAgICstLS0tKyAgICAgQUMgICBWDQo+ICAg ICAgICArLS0tLS0rICAgIHwgICAgIHwuLi4ufC4uLi4uLi5QVzEuLi4uLi4uLnwuLi4ufCAgICAg fCAgICArLS0tLS0rDQo+ICAgICAgICB8ICAgICB8LS0tLS0tLS0tLXwgUEUxfC4uLi4uLiAgIC4u Li4uLi4uLnwgUEUzfC0tLS0tLS0tLS18ICAgICB8DQo+ICAgICAgICB8IENFMSB8ICAgICAgICAg ICstLS0tKyAgICAgIFwgLyAgUFczICAgICstLS0tKyAgICAgICAgICB8IENFMiB8DQo+ICAgICAg ICB8ICAgICB8ICAgICAgICAgICstLS0tKyAgICAgICBYICAgICAgICAgICstLS0tKyAgICAgICAg ICB8ICAgICB8DQo+ICAgICAgICB8ICAgICB8ICAgICAgICAgIHwgICAgfC4uLi4uLi8gXC4uUFc0 Li4uLnwgICAgfCAgICAgICAgICB8ICAgICB8DQo+ICAgICAgICB8ICAgICB8LS0tLS0tLS0tLXwg UEUyfCAgICAgICAgICAgICAgICAgIHwgUEU0fC0tLS0tLS0tLSB8ICAgICB8DQo+ICAgICAgICAr LS0tLS0rICAgIHwgICAgIHwuLi4ufC4uLi4uUFcyLi4uLi4uLi4uLnwuLi4ufCAgICAgfCAgICAr LS0tLS0rDQo+ICAgICAgICAgICAgICAgICAgIEFDICAgICstLS0tKyAgICAgICAgICAgICAgICAg ICstLS0tKyAgICBBQw0KPg0KPg0KPiAgICAgIEZpZ3VyZSAxNS0yIE11bHRpcGxlIE11bHRpLWhv bWVkIENFcyB3aXRoIHNpbmdsZSBTUy1QVyByZWR1bmRhbmN5DQo+DQo+ICAgIFRoZSBhcHBsaWNh dGlvbiBpbiBGaWd1cmUgMTUtMiBtYWtlcyB1c2Ugb2YgdGhlIEluZGVwZW5kZW50IG1vZGUgb2YN Cj4gICAgb3BlcmF0aW9uLg0KPg0KPiAgICBDRTEgaXMgZHVhbC1ob21lZCB0byBQRTEgYW5kIFBF Mi4gQ0UyIGlzIGR1YWwtaG9tZWQgUEUzIGFuZCBQRTQuIFRoZQ0KPiAgICBtZXRob2QgZm9yIGR1 YWwtaG9taW5nIGFuZCB0aGUgdXNlZCBwcm90b2NvbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlDQo+ ICAgIG9mIHRoaXMgZG9jdW1lbnQuICBOb3RlIHRoYXQgdGhlIFBTTiB0dW5uZWxzIGFyZSBub3Qg c2hvd24gaW4gdGhpcw0KPiAgICBmaWd1cmUgZm9yIGNsYXJpdHkuIEhvd2V2ZXIsIGl0IGNhbiBi ZSBhc3N1bWVkIHRoYXQgZWFjaCBvZiB0aGUgUFdzDQo+ICAgIHNob3duIGlzIGVuY2Fwc3VsYXRl ZCBpbiBhIHNlcGFyYXRlIFBTTiB0dW5uZWwuDQo+DQo+ICAgIEFzc3VtZSB0aGF0IHRoZSBBQyBm cm9tIENFMSB0byBQRTEgaXMgQWN0aXZlLCBmcm9tIENFMSB0byBQRTIgaXMNCj4gICAgU3RhbmRi eTsgZnVydGhlcm1vcmUsIGFzc3VtZSB0aGF0IHRoZSBBQyBmcm9tIENFMiB0byBQRTMgaXMgU3Rh bmRieQ0KPiAgICBhbmQgZnJvbSBDRTIgdG8gUEU0IGlzIEFjdGl2ZS4gVGhlIG1ldGhvZCBvZiBk ZXJpdmluZyBBY3RpdmUvU3RhbmRieQ0KPiAgICBzdGF0dXMgb2YgdGhlIEFDIGlzIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+DQo+ICAgIFBFMSBhZHZlcnRpc2VzIHRoZSBw cmVmZXJlbnRpYWwgc3RhdHVzICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAgICBzdGF0dXMg IlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMSBhbmQgUFc0IGNvbm5l Y3RlZA0KPiAgICB0byBQRTMgYW5kIFBFNC4gVGhpcyBzdGF0dXMgcmVmbGVjdHMgdGhlIGZvcndh cmRpbmcgc3RhdGUgb2YgdGhlIEFDDQo+ICAgIGF0dGFjaGVkIHRvIFBFMS4gUEUyIGFkdmVydGlz ZXMgcHJlZmVyZW50aWFsIHN0YXR1cyAiU3RhbmRieSIgYW5kDQo+ICAgIG9wZXJhdGlvbmFsIHN0 YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMgUFcyIGFuZA0KPiAg ICBQVzMgdG8gUEUzIGFuZCBQRTQuIFBFMyBhZHZlcnRpc2VzIHByZWZlcmVudGlhbCBzdGF0dXMg IlN0YW5kYnkiIGFuZA0KPiAgICBvcGVyYXRpb25hbCBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2Fy ZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMSBhbmQNCj4gICAgUFczIHRvIFBFMSBhbmQgUEUyLiBQ RTQgYWR2ZXJ0aXNlIHRoZSBwcmVmZXJlbnRpYWwgc3RhdHVzICJBY3RpdmUiDQo+ICAgIGFuZCBv cGVyYXRpb25hbCBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dpcmVz IFBXMg0KPiAgICBhbmQgUFc0IHRvIFBFMiBhbmQgUEUxIHJlc3BlY3RpdmVseS4gVGh1cyBieSBt YXRjaGluZyB0aGUgbG9jYWwgYW5kDQo+ICAgIHJlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2FyZGlu ZyBzdGF0dXMgb2YgIkFjdGl2ZSIgYW5kIG9wZXJhdGlvbmFsDQo+ICAgIHN0YXR1cyBvZiAiUHNl dWRvd2lyZSBmb3J3YXJkaW5nIiBvZiBwc2V1ZG93aXJlcywgdGhlIFBFIG5vZGVzDQo+ICAgIGRl dGVybWluZSB3aGljaCBQVyBzaG91bGQgYmUgaW4gdGhlIEFjdGl2ZSBzdGF0ZS4gSW4gdGhpcyBj YXNlIGl0IGlzDQo+ICAgIFBXNCB0aGF0IHdpbGwgYmUgc2VsZWN0ZWQuDQo+DQo+ICAgIE9uIGZh aWx1cmUgb2YgdGhlIEFDIGJldHdlZW4gQ0UxIGFuZCBQRTEsIHRoZSBmb3J3YXJkaW5nIHN0YXRl IG9mDQo+ICAgIHRoZSBBQyBvbiBQRTIgaXMgY2hhbmdlZCB0byBBY3RpdmUuIFBFMiB0aGVuIGFu bm91bmNlcyB0aGUgbmV3bHkNCj4gICAgY2hhbmdlZCAncHJlZmVyZW50aWFsIGZvcndhcmRpbmcn IHN0YXR1cyBiaXQgb2YgImFjdGl2ZSIgdG8gUEUzIGFuZA0KPiAgICBQRTQuIFBFMSB3aWxsIGFk dmVydGlzZSBhIFBXIHN0YXR1cyBub3RpZmljYXRpb24gbWVzc2FnZSBpbmRpY2F0aW5nDQo+ICAg IHRoYXQgdGhlIEFDIGJldHdlZW4gQ0UxIGFuZCBQRTEgaXMgb3BlcmF0aW9uYWxseSBkb3duLiBQ RTIgYW5kIFBFNA0KPiAgICBtYXRjaCB0aGUgbG9jYWwgYW5kIHJlbW90ZSBwcmVmZXJlbnRpYWwg Zm9yd2FyZGluZyBzdGF0dXMgb2YNCj4gICAgIkFjdGl2ZSIgYW5kIG9wZXJhdGlvbmFsIHN0YXR1 cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBhbmQgc2VsZWN0DQo+ICAgIFBXMiBhcyB0aGUgbmV3 IGFjdGl2ZSBwc2V1ZG93aXJlIHRvIHNlbmQgdHJhZmZpYyB0by4NCj4NCj4gICAgT24gZmFpbHVy ZSBvZiBQRTEgbm9kZSwgUEUyIHdpbGwgZGV0ZWN0IGl0IGFuZCB3aWxsIHRyYW5zaXRpb24gdGhl DQo+ICAgIGZvcndhcmRpbmcgc3RhdGUgb2YgaXRzIEFDIHRvIEFjdGl2ZS4gVGhlIG1ldGhvZCBi eSB3aGljaCBQRTINCj4gICAgZGV0ZWN0cyB0aGF0IFBFMSBpcyBkb3duIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIFBFMg0KPiAgICB0aGVuIGFubm91bmNlcyB0aGUgbmV3 bHkgY2hhbmdlZCAncHJlZmVyZW50aWFsIGZvcndhcmRpbmcnIHN0YXR1cw0KPiAgICBiaXQgb2Yg IkFjdGl2ZSIgdG8gUEUzIGFuZCBQRTQuIFBFMiBhbmQgUEU0IG1hdGNoIHRoZSBsb2NhbCBhbmQN Cj4gICAgcmVtb3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0aXZlIiBh bmQgb3BlcmF0aW9uYWwNCj4gICAgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGFuZCBz ZWxlY3QgUFcyIGFzIHRoZSBuZXcgYWN0aXZlDQo+ICAgIHBzZXVkb3dpcmUgdG8gc2VuZCB0cmFm ZmljIHRvLiBOb3RlIHRoYXQgUEUzIGFuZCBQRTQgbWF5IGhhdmUNCj4gICAgZGV0ZWN0ZWQgdGhh dCB0aGUgUFcgdG8gUEUxIHdlbnQgZG93biB2aWEgVC1MRFAgSGVsbG8gdGltZW91dCBvciB2aWEN Cj4gICAgb3RoZXIgbWVhbnMuIEhvd2V2ZXIsIHRoZXkgd2lsbCBub3QgYmUgYWJsZSB0byBmb3J3 YXJkIHVzZXIgdHJhZmZpYw0KPiAgICB1bnRpbCB0aGV5IHJlY2VpdmVkIHRoZSB1cGRhdGVkIHN0 YXR1cyBiaXQgZnJvbSBQRTIuDQo+DQo+ICAgIEJlY2F1c2UgZWFjaCBkdWFsLWhvbWluZyBhbGdv cml0aG0gcnVubmluZyBvbiB0aGUgdHdvIG5vZGUgc2V0cywNCj4gICAgaS5lLiwge0NFMSwgUEUx LCBQRTJ9IGFuZCB7Q0UyLCBQRTMsIFBFNH0sIHNlbGVjdHMgdGhlIGFjdGl2ZSBBQw0KPiAgICBp bmRlcGVuZGVudGx5LCB0aGVyZSBpcyBhIG5lZWQgdG8gc2lnbmFsIHRoZSBhY3RpdmUgc3RhdHVz IG9mIHRoZSBBQw0KPiAgICBzdWNoIHRoYXQgdGhlIFBFIG5vZGVzIGNhbiBzZWxlY3QgYSBjb21t b24gYWN0aXZlIFBXIGZvciBlbmQtdG8tZW5kDQo+ICAgIGZvcndhcmRpbmcgYmV0d2VlbiBDRTEg YW5kIENFMiBhcyBwZXIgdGhlIHByb2NlZHVyZXMgaW4gdGhlDQo+ICAgIGluZGVwZW5kZW50IG1v ZGUuDQo+DQo+ICAgIE5vdGUgdGhhdCBhbnkgcHJpbWFyeS9zZWNvbmRhcnkgcHJvY2VkdXJlcywg YXMgZGVmaW5lZCBpbiBzZWN0aW9ucw0KPiAgICA1LjEuICBhbmQgNS4yLiAsIGRvIG5vdCBhcHBs eSBpbiB0aGlzIHVzZSBjYXNlIGFzIHRoZSBBY3RpdmUvU3RhbmRieQ0KPiAgICBzdGF0dXMgaXMg ZHJpdmVuIGJ5IHRoZSBBQyBmb3J3YXJkaW5nIHN0YXRlIGFzIGRldGVybWluZWQgYnkgdGhlIEFD DQo+ICAgIGR1YWwtaG9taW5nIHByb3RvY29sIHVzZWQuDQo+DQo+DQo+IEkgYmVsaWV2ZSB5b3Wh r3ZlIHRha2VuIHlvdXIgobBvdXQgb2Ygc2NvcGWhsSByZWZlcmVuY2UgZnJvbSB0aGlzIHRleHQs DQo+IGJ1dCBJTUhPIHlvdSBtaXNpbnRlcnByZXRlZCBpdC4NCj4gV2hhdCBpdCBtZWFucyAob3Ig c28gSSByZWFkIGl0KSBpcyB0aGF0IHNwZWNpZmljIGR1YWwtaG9taW5nDQo+IHByb3RvY29sIGlz IG91dCBvZiBzY29wZSBhcyBsb25nIGFzIGl0IG1lZXRzIGNlcnRhaW4gYXNzdW1wdGlvbnMuDQo+ IEFzaWRlOiBJdCB3b3VsZCBiZSBnb29kIGlmIHRoZSBhdXRob3JzIG9mIHRoZSBQVyByZWR1bmRh bmN5IGRyYWZ0cw0KPiBjb3VsZCBleHBsaWNpdGx5IHNwZWNpZnkgdGhlc2UgYXNzdW1wdGlvbnMu DQo+DQo+IFtbW1Nhc2hhXV1dIKGtIHNuaXBwZWQgoa0NCj4NCj4gTm93IGxldKGvcyB0dXJuIG91 ciBhdHRlbnRpb24gYmFjayB0byB3aGV0aGVyIHRoZSBQVyByZWR1bmRhbmN5DQo+IGRyYWFmdCBj YW4gYmUgdXNlZCB0byBtZWV0IE1QTFMtVFAgUFcgcHJvdGVjdGlvbiByZXF1aXJlbWVudHMuIEkg Y2FuDQo+IGlkZW50aWZ5IHRoZSBmb2xsb3dpbmcgcmVhc29ucyB3aHkgaW4gaXRzIGN1cnJlbnQg Zm9ybSBpdCBkb2VzbqGvdDoNCj4NCj4gLSAgICAgICAgICBJdCBleHBsaWNpdGx5ICihsG91dHNp ZGUgdGhlIHNjb3BlobEpIGRvZXMgbm90IGRlZmluZQ0KPiBwcm90ZWN0aW9uIHRyaWdnZXJzIGFu ZCBob3cgdG8gaGFuZGxlIGNvZXhpc3RpbmcgdHJpZ2dlcnMsIGFzDQo+IHJlcXVlc3RlZCBpbiBS RkMgNTY1NCAoTVBMUy1UUCBSZXF1aXJlbWVudHMpLCByZXFzICM3NSwgIzc2IGFuZCAjNzkNCj4g W1tbU2FzaGFdXV0gU28gd2hhdD8gRGVmaW5pdGlvbiBvZiB0cmlnZ2VycyBpcyBvcnRob2dvbmFs IHRvIGhvdw0KPiBjb29yZGluYXRlZCBwcm90ZWN0aW9uIHN3aXRjaGluZyBoYXBwZW5zLg0KPiBb RENdIEl0IGlzLiBCdXQgc3RpbGwgaXQgbmVlZHMgdG8gYmUgZGVmaW5lZCBieSB0aGUgcmVjb3Zl cnkNCj4gZnJhbWV3b3JrLCBlLmcuIHdoYXQgc2hvdWxkIHRoZSBlbmRwb2ludCBkbyB3aGVuIG9u ZSBQVyBpcyBpbiBTRiBhbmQNCj4gdGhlIG90aGVyIGlzIGluIFNELCBvciB3aGVuIGJvdGggYXJl IGluIFNELiBPcGVyYXRvcnMgZXhwZWN0IHdlbGwtDQo+IGRlZmluZWQgYmVoYXZpb3IgaW4gdGhl c2UgYW5kIG90aGVyIHNjZW5hcmlvcywgYW5kIFBXIHJlZHVuZGFuY3kNCj4gZG9lcyBub3QgZGVm aW5lIHRoZW0gKGJlY2F1c2UgaXQgd2FzIG5vdCBpbiB0aGVpciBzY29wZSkuDQo+IFtbW1Nhc2hh XV1dIEkgd29uZGVyIGlmIHlvdSBoYXZlIGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uIHJlZ2FyZGlu Zw0KPiBhYmlsaXR5IHRvIGRlZmluZSBTRCBjb25kaXRpb24gZm9yIExTUHMgYW5kIFBXcyBvbiB0 aGUgTVBMUy1UUCBsaXN0Pw0KPiBJTU8gaXQgaXMgbm90IHBvc3NpYmxlIHRvIGRlZmluZSBpdCBp biBhIG1lYW5pbmdmdWwgd2F5LiBIZW5jZSBJIGRvDQo+IG5vdCBzZWUgYSBwcm9wb3NhbCB0aGF0 IGRvZXMgbm90IGFkZHJlc3MgYSBzY2VuYXJpbyB0aGF0IGRvZXMgbm90DQo+IGV4aXN0IGluIHJl YWxpdHkgYXMgYSBmbGF3ZWQgb25lLg0KPg0KPiAtICAgICAgICAgIEl0IGRvZXMgbm90IHN1cHBv cnQgdGhlIGFiaWxpdHkgdG8gZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KPiBkaWZmZXJlbnQgdHlwZXMg b2YgdHJpZ2dlcnMgKGkuZS4gb25lIGVuZCBkb2VzbqGvdCBrbm93IHdoeSB0aGUgb3RoZXINCj4g ZW5kIHRyaWdnZXJlZCBzd2l0Y2gpLCBhcyByZXF1ZXN0ZWQgaW4gUkZDIDU2NTQgKE1QTFMtVFAN Cj4gUmVxdWlyZW1lbnRzKSwgcmVxICM3Nw0KPiAtICAgICAgICAgIEl0IGRvZXMgbm90IGRlZmlu ZSByZXZlcnRpdmUvbm9ucmV2ZXJ0aXZlIGJlaGF2aW9yLCBhcw0KPiByZXF1ZXN0ZWQgaW4gUkZD IDU2NTQgKE1QTFMtVFAgUmVxdWlyZW1lbnRzKSwgcmVxICM2NA0KPiAtICAgICAgICAgIEl0IGRv ZXMgbm90IGRlZmluZSBob2xkb2ZmIHN1cHBvcnQsIHdoaWNoIGlzIGVzcGVjaWFsbHkNCj4gaW1w b3J0YW50IHRvIGF2b2lkIHJhY2UgY29uZGl0aW9ucyB3aXRoIExTUCBwcm90ZWN0aW9uIHdoZW4g aXQgZXhpc3RzDQo+IC0gICAgICAgICAgSXQgZG9lc26hr3Qgc3VwcG9ydCAxKzEgbW9kZSwgYXMg cmVxdWVzdGVkIGluIFJGQyA1NjU0DQo+IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjUN Cj4gW1tbU2FzaGFdXV0gQWxsIHRoZXNlIGNsYWltcyBhcmUgY29ycmVjdCCoQyBhbmQgIHRoaXMg c2hvdWxkIG5vdCBiZSBhDQo+IHN1cnByaXNlLCBiZWNhdXNlIE1QTFMtVFAgcmVxdWlyZW1lbnRz IGhhdmUgYmVlbiBkZWZpbmVkIG11Y2ggbGF0ZXINCj4gdGhhbiB0aGUgUFcgcmVkdW5kYW5jeSBt ZWNoYW5pc20uDQo+IEJ1dCBJIGRvIG5vdCB0aGluayB0aGF0IHRoaXMganVzdGlmaWVzIGNvLWV4 aXN0ZW5jZSBvZiB0d28gZGlmZmVyZW50DQo+IG1lY2hhbmlzbXMuDQo+IFtEQ10gU28gaG93IGRv IHlvdSBwcm9wb3NlIHRvIG1lZXQgdGhlIFBXIHByb3RlY3Rpb24gcmVxdWlyZW1lbnQ/DQo+IC0g ICAgICAgICAgSXShr3MgYSB0d28tcGhhc2UgcHJvdG9jb2wsIHdpdGggdGhlIGNvbnNlcXVlbnQg aW1wYWN0IG9uIHRpbWluZw0KPiBbW1tTYXNoYV1dXSBDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0 ZT8gW0RDXSBJbiBkcmFmdC1pZXRmLW1wbHMtdHAtDQo+IGxpbmVhci1wcm90ZWN0aW9uLCBlYWNo IGVuZHBvaW50IHdpbGwgaW1tZWRpYXRlbHkgc3dpdGNoIHRyYWZmaWMgdG8NCj4gdGhlIG90aGVy IHBhdGggdXBvbiBpZGVudGlmeWluZyBhbiBTRiBjb25kaXRpb24gaW4gYSBwYXRoLCB3aXRob3V0 DQo+IHdhaXRpbmcgZm9yIHRoZSBmYXIgZW5kIHRvIGFja25vd2xlZGdlIHRoZSBzd2l0Y2ggKDEt cGhhc2UpLiBJbiBQVw0KPiByZWR1bmRhbmN5LCBhbiBlbmRwb2ludCBkZXRlY3RpbmcgYW4gU0Yg Y29uZGl0aW9uIGluIGEgcGF0aCB3aWxsIG5vdA0KPiBzd2l0Y2ggdW50aWwgdGhlIGZhciBlbmQg aGFzIGFja25vd2xlZGdlZCB0aGUgc3dpdGNoICgyLXBoYXNlKS4NCj4gTmVlZGxlc3MgdG8gc2F5 LCByZWNvdmVyeSBpcyBzbG93ZXIgaW4gYSAyLXBoYXNlIHByb3RvY29sLg0KPiBbW1tTYXNoYV1d XSBUbyB0aGUgYmVzdCBvZiBteSB1bmRlcnN0YW5kaW5nLCAxLXBoYXNlIHByb3RlY3Rpb24gaXMN Cj4gb25seSBwb3NzaWJsZSBpbiAxKzEgdW5pZGlyZWN0aW9uYWwgYXJjaGl0ZWN0dXJlcy4gQW5k IHllcywgSSBrbm93DQo+IHRoYXQgTVBMUy1UUCByZXF1aXJlcyBhICBtZWNoYW5pc20gdG8gc3Vw cG9ydCB0aGlzOyB3aGV0aGVyIGFueWJvZHkNCj4gd291bGQgcmVhbGx5IGRvIHRoYXQgaW4gdGhl IHBhY2tldC1zd2l0Y2hpbmcgbmV0d29yayBpcyBub3QgY2xlYXIgdG8NCj4gbWUuIEFuZCBJIGFj a25vd2xlZGdlIHRoYXQgdGhlIFBXIHJlZHVuZGFuY3kgZHJhZnRzIGRvIG5vdCBzdXBwb3J0DQo+ IDErMSB1bmlkaXJlY3Rpb25hbCBzY2hlbWUuDQo+DQo+IC0gICAgICAgICAgSXQgZG9lc26hr3Qg ZGVmaW5lIHJldHJhbnNtaXNzaW9uIG9mIHByb3RlY3Rpb24NCj4gY29vcmRpbmF0aW9uIG1lc3Nh Z2VzLCBzbyBsb3NzIG9mIGEgc2luZ2xlIFBEVSBjYW4gcmVzdWx0IGluDQo+IHN3aXRjaG92ZXIg bm90IHRha2luZyBwbGFjZSwgdGh1cyBub3Qgc3VwcG9ydGluZyBzdWItNTAgbXMgcmVjb3ZlcnkN Cj4gaW4gdGhpcyBjYXNlDQo+IFtbW1Nhc2hhXV1dIFRoZSBQVyByZWR1bmRhbmN5IHByb3RvY29s IHJ1bnMgZWl0aGVyIG9uIHRvcCBvZiBMRFANCj4gKHdoaWNoIGJlbmVmaXRzIGZyb20gVENQIHJl dHJhbnNtaXNzaW9ucykgb3Igb24gdG9wIG9mIHN0YXRpYyBQVw0KPiBzdGF0dXMgbWVzc2FnZXMg KHdoZXJlIHJldHJhbnNtaXNzaW9uIGlzIGRlZmluZWQpLg0KPiBbRENdIFRydWUgqEMgYnV0IHN0 YXRpYyBQVyBzdGF0dXMgZGVmaW5lcyBzbG93IHJldHJhbnNtaXNzaW9uICihsHdpbGwNCj4gYmUg dHJhbnNtaXR0ZWQgdHdpY2UgYXQgYW4gaW5pdGlhbCBpbnRlcnZhbCBvZiBvbmUgc2Vjb25kobEp IHdoaWxlDQo+IGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbiBzcGVjaWZpZXMg ZmFzdCByZXRyYW5zbWlzc2lvbg0KPiB3aGVuIHJlcXVpcmVkIGZvciBmYXN0IHJlY292ZXJ5IChz ZWN0aW9uIDMuMS40KS4NCj4NCj4gSW4gc3VtbWFyeSwgUFcgcmVkdW5kYW5jeSB3YXMgbm90IGRl c2lnbmVkIHdpdGggVFAgcmVxdWlyZW1lbnRzIGluDQo+IG1pbmQsIGFuZCBhcyBzdWNoIGRvZXMg bm90IG1lZXQgdGhlIFRQIHJlcXVpcmVtZW50cy4gT2YgY291cnNlDQo+IG1vZGlmaWNhdGlvbnMg bWF5IGJlIGludHJvZHVjZWQsIGJ1dCB3aHkgcmVpbnZlbnQgdGhlIHdoZWVsIHdoZW4NCj4gdGhl cmUgaXMgYSBwcm90b2NvbCAoZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uLTA2 KSBpbiB0aGUNCj4gc3RhbmRhcmRzIHRyYWNrIHRoYXQgc3VwcG9ydHMgYWxsIHRoZSBhYm92ZSBy ZXF1aXJlbWVudHMgYW5kIGNhbiBiZQ0KPiBhcHBsaWVkIHRvIE1TLVBXIHByb3RlY3Rpb24gd2l0 aCBtaW5vciBtb2RpZmljYXRpb25zPw0KPiBbW1tTYXNoYV1dXSBBcyBJIHNhaWQsIGJlY2F1c2Ug dGhlIGFwcGxpY2FiaWxpdHkgc2NvcGUgaXMgYnkgZmFyIHRvbw0KPiBuYXJyb3cgdG8ganVzdGlm eSBhIGRlZGljYXRlZCBwcm90b2NvbC4NCj4gW0RDXSBJZiB3ZSB3ZXJlIGRpc2N1c3NpbmcgZGVz aWduaW5nIGEgbmV3IHByb3RvY29sLCBJIG1pZ2h0IGFncmVlDQo+IHdpdGggeW91LiBCdXQgZnJv bSBhIHByYWN0aWNhbCBzdGFuZHBvaW50LCB0aGUgUFcgcHJvdGVjdGlvbiBkcmFmdA0KPiBpcyBu b3QgYSBkZWRpY2F0ZWQgcHJvdG9jb2wgqEMgaXShr3MgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgdG8gYW4NCj4gZXhpc3RpbmcgcHJvdG9jb2wuIEJvdGggZnJvbSB0aGUgaW1wbGVtZW50YXRp b24gYW5kIHRoZSBvcGVyYXRpb25hbA0KPiBwb2ludCBvZiB2aWV3IGl0IGRlZmluZXMgYSBuZXcg dXNlIGNhc2UgZm9yIGFuIGV4aXN0aW5nIHByb3RvY29sIGFuZCBjb25jZXB0Lg0KPg0KPg0KPiBS ZWdhcmRzLA0KPg0KPiBEYW5pZWwNCj4NCj4NCj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gU3ByZWNoZXIs IE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywg MjAxMSA0OjAyIFBNDQo+IFRvOiBleHQgQWxleGFuZGVyIFZhaW5zaHRlaW47IG1hLnl1eGlhQHp0 ZS5jb20uY24NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtDQo+IFRQTGlu ZWFyUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBIaSwNCj4gSSB3b3Vs ZCBsaWtlIHRvIHNlY29uZCBTYXNoYS4NCj4gRW5kLXRvLWVuZCBQVyBwcm90ZWN0aW9uICh3aXRo IGRpdmVyc2UgcGF0aHMpIGRvZXMgbm90IHNjYWxlLCBhbmQNCj4gcHV0IGhhcmQgcmVzdHJpY3Rp b25zIG9uIHRoZSB1dGlsaXphdGlvbiBvZiB0aGUgcmVzb3VyY2VzLg0KPiBNUExTLVRQIFBXcyBh cmUgY2FycmllZCBhY3Jvc3MgdGhlIG5ldHdvcmsgaW5zaWRlIE1QTFMtVFAgTFNQcy4NCj4gVGhl cmVmb3JlLCBhbiBvYnZpb3VzIHdheSB0byBwcm92aWRlIHByb3RlY3Rpb24gZm9yIGEgUFcgaXMg dG8NCj4gcHJvdGVjdCB0aGUgTFNQIHRoYXQgY2FycmllcyBpdC4NCj4gSWYgdGhlIFBXIGlzIGEg bXVsdGktc2VnbWVudCBQVywgdGhlbiBMU1AgcmVjb3ZlcnkgY2FuIG9ubHkgcHJvdGVjdA0KPiB0 aGUgUFcgaW4gaW5kaXZpZHVhbCBzZWdtZW50cy4gIFRoaXMgbWVhbnMgdGhhdCBhIHNpbmdsZSBM U1ANCj4gcmVjb3ZlcnkgYWN0aW9uIGNhbm5vdCBwcm90ZWN0IGFnYWluc3QgYSBmYWlsdXJlIG9m IGEgUFcgc3dpdGNoaW5nDQo+IHBvaW50IChhbiBTLVBFKS4NCj4gV2hlbiBwcm90ZWN0aW5nIGFn YWluc3QgYW4gQUMgb3IgVC9TLVBFIGZhaWx1cmUgYnkgZHVhbA0KPiBjb25uZWN0aXZpdHksIFBX IHJlZHVuZGFuY3kgbWVjaGFuaXNtcyBwcm92aWRlIG1lYW5zIGZvciB0aGUgUEVzIHRvDQo+IGNv b3JkaW5hdGUgb3ZlciB3aGljaCBMU1AgdGhlIHRyYWZmaWMgb2YgdGhlIFBXIGlzIGNhcnJpZWQu DQo+IEkgYWxzbyBkb3VidCB3aHkgdGhlcmUgaXMgYSBuZWVkIGZvciBhZGRpdGlvbmFsIG1lY2hh bmlzbS4NCj4gQmVzdCByZWdhcmRzLA0KPiBOdXJpdA0KPg0KPiBGcm9tOiBwd2UzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBl eHQgQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDM6 NDMgUE0NCj4gVG86IG1hLnl1eGlhQHp0ZS5jb20uY24NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3 ZTNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtQV0UzXSBbbXBsc10gU2Vla2luZyBmZWVkYmFj ayBvbiBJLUQgIk1QTFMtVFANCj4gTGluZWFyUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1T LVBXIg0KPg0KPiBEZWFyIE1hIGFuZCBhbGwsDQo+IEFkZGluZyB0aGUgUFdFMyBXRyB0byBteSBy ZXNwb25zZS4NCj4NCj4gVGhlIFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtIHN1cHBvcnRzIGxpbmVh ciBwcm90ZWN0aW9uIG9mIE1TLVBXcyBhcw0KPiBvbmUgb2YgbWFueSBhZGRpdGlvbmFsIGFwcGxp Y2F0aW9uIHVzZSBjYXNlczoNCj4gQXBwZW5kaXggQSBvZiB0aGUgUFcgcmVkdW5kYW5jeSBCaXQg ZHJhZnQgZGVzY3JpYmVzIDUgYXBwbGljYXRpb24NCj4gdXNlcyBjYXNlcyBpbiBhZGRpdGlvbiB0 byBNUy1QVyB3aXRoIHNpbmdsZS1ob21lZCBDRXMgKHdoaWNoIGlzDQo+IGxpc3RlZCB0aGVyZSBh cyB1c2UgY2FzZSA1KS4NCj4gQW5kIGl0IGlzIGVxdWFsbHkgYXBwbGljYWJsZSB0byBJUC9NUExT IGFuZCBNUExTIC0gd2l0aCB0aGUgaGVscCBvZiAgdGhlDQo+IFN0YXRpYyBQVyBTdGF0dXMgTWVz c2FnZXMgZHJhZnQoIGlmLCBmb3Igd2hhdGV2ZXIgcmVhc29uLCB5b3UgZG8gbm90DQo+IHdhbnQg IHRvLCBvciBjYW5ub3QsIHVzZSBSRkMgNDQ0NykuDQo+DQo+IEhlbmNlIEkgZG91YnQgdGhlIG5l ZWQgZm9yIHlldCBhbm90aGVyIFBXIHJlZHVuZGFuY3kgIG1lY2hhbmlzbSB3aXRoDQo+IG5hcnJv dyBzY29wZSBvZiBhcHBsaWNhYmlsaXR5Lg0KPg0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+ DQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+IG1hLnl1eGlhQHp0ZS5jb20uY24NCj4gU2VudDogTW9uZGF5 LCBKdW5lIDEzLCAyMDExIDM6MjUgUE0NCj4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFttcGxzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUCBMaW5lYXINCj4gUHJv dGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBIaSBhbGwsDQo+DQo+IFRoZSBs aW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20gZm9yIExTUCBhbmQgUFcoaW5jbHVkaW5nIE1TLVBX KQ0KPiBzaG91bGQgYmUgdGhlIHNhbWUgYW5kIGl0IGlzIHZhbHVhYmxlIHRvIGRlc2NyaWJlIGl0 IGNsZWFybHkuDQo+DQo+IEJUVywgdGhlcmUgaXMgYSB0eXBvLCBpdCBpcyAiVC1QRSBaIiBpbnN0 ZWFkIG9mICJULVBFIEIiLg0KPg0KPiAgIg0KPiAgIEZpZ3VyZSAxIGlsbHVzdHJhdGVzIHN1Y2gg YSBzY2VuYXJpbywgd2hlcmUgdHdvIE1TLVBXcyBhcmUNCj4gICBlc3RhYmxpc2hlZCBiZXR3ZWVu IFQtUEUgQSBhbmQgVC1QRSBCLCBvdmVyIFMtUEVzIDEtMiBhbmQgMy00DQo+ICAgcmVzcGVjdGl2 ZWx5LiBFYWNoIFBXIHNlZ21lbnQgaXMgZXN0YWJsaXNoZWQgb3ZlciBhbiBMU1AgKGUuZy4gUFct DQo+ICAgczEyIG92ZXIgTFNQMTIpLg0KPiAgIg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBEYW5pZWwgQ29obg0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTEgNDox NCBQTQ0KPiBUbzogbXBscw0KPiBTdWJqZWN0OiBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBM Uy1UUCBMaW5lYXIgUHJvdGVjdGlvbg0KPiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPiBJbXBv cnRhbmNlOiBIaWdoDQo+DQo+IEhpIE1QTFNlcnMsDQo+DQo+IEkgdXBsb2FkZWQgIk1QTFMtVFAg TGluZWFyIFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyIgSS1EDQo+IChodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jb2huLW1wbHMtdHAtcHctcHJvdGVjdGlvbi0wMCkN Cj4NCj4gVGhlIGFic3RyYWN0IGdvZXM6DQo+DQo+IE9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG9m IHRoZSBNUExTIHRyYW5zcG9ydCBwcm9maWxlIFtSRkMgNTY1NF0gaXMNCj4gdG8gcHJvdmlkZSBs aW5lYXIgcHJvdGVjdGlvbiBmb3IgdHJhbnNwb3J0IHBhdGhzLCB3aGljaCBpbmNsdWRlIGJvdGgN Cj4gTFNQcyBhbmQgUFdzLiBUaGUgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgZGVzY3JpYmVkIGlu IFtTdXJ2aXZGd2tdDQo+IGlzIGFwcGxpY2FibGUgdG8gYm90aCBMU1AgYW5kIFBXcywgaG93ZXZl ciBbTGluZWFyUHJvdF0gZG9lcyBub3QNCj4gZXhwbGljaXRseSBkZXNjcmliZSBtZWNoYW5pc21z IGZvciBQVyBwcm90ZWN0aW9uIGluIE1QTFMtVFAuDQo+DQo+IFRoaXMgZG9jdW1lbnQgZXh0ZW5k cyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgbGluZWFyIHByb3RlY3Rpb24NCj4gbWVjaGFuaXNt IGRlc2NyaWJlZCBpbiBbTGluZWFyUHJvdF0gdG8gTVBMUy1UUCBzZWdtZW50ZWQgUFdzDQo+IChN Uy1QV3MpIGFzIGRlZmluZWQgaW4gW1JGQyA2MDczXS4NCj4NCj4gQ291bGQgeW91IHBsZWFzZSBy ZXZpZXcgaXQgYW5kIHNlbmQgZmVlZGJhY2sgdG8gdGhlIG1haWxpbmcgbGlzdCBvcg0KPiBkaXJl Y3RseSB0byB0aGUgYXV0aG9yPw0KPg0KPiBMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFj aywNCj4NCj4gRGFuaWVsDQo+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRo ZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09O RklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8NCj4gRUNJIFRlbGVjb20u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UN Cj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZA0KPiBhbGwgY29waWVzIHRoZXJlb2YuDQo+IFRoaXMgZS1tYWlsIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4gaW5m b3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRh cnkgdG8NCj4gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UNCj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4 LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPiBhbGwgY29waWVzIHRoZXJlb2Yu DQo+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25s eSBhbmQgY29udGFpbnMNCj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3 aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8NCj4gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UNCj4gaW5mb3JtIHVzIGJ5 IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0K PiBhbGwgY29waWVzIHRoZXJlb2YuIKlternaPz9icj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From eric.gray@ericsson.com Tue Jun 21 07:54: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 7B14C11E8203 for ; Tue, 21 Jun 2011 07:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.764 X-Spam-Level: X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 HapeMtgVGXhv for ; Tue, 21 Jun 2011 07:54:40 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id F2A6811E81A9 for ; Tue, 21 Jun 2011 07:54:39 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5LEsaXv018463 for ; Tue, 21 Jun 2011 09:54:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 21 Jun 2011 10:54:36 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 21 Jun 2011 10:54:34 -0400 Thread-Topic: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwvJH9shJARwtdOSROxK3itlENKYgA/nugA 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] FW: RE: [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-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, 21 Jun 2011 14:54:41 -0000 Rm9yd2FyZGluZyBpbiBwbGFpbiB0ZXh0IC0gd2l0aCBaVEUgZGlzY2xhaW1lciByZW1vdmVkLi4u DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IG1hLnl1eGlhQHp0 ZS5jb20uY24gW21haWx0bzptYS55dXhpYUB6dGUuY29tLmNuXQ0KU2VudDogTW9uZGF5LCBKdW5l IDIwLCAyMDExIDQ6MzEgQU0NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KQ2M6IERhbmllbCBD b2huOyBtcGxzQGlldGYub3JnOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJv bik7IHB3ZTNAaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtp bmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkg dG8gTVMtUFciDQoNCg0KDQpIaSBTYXNoYSwNCg0KIkxpbmVhciBwcm90ZWN0aW9uIiBpcyBkaWZm ZXJlbnQgZnJvbSAiTXVsdGktaG9tZWQgQ0UgcmVkdW5kYW5jeSIgYW5kIGhhcyBubyByZWZlcmVu Y2Ugd2l0aCBBQy4NCg0KV29ya2luZyBwYXRoKHMpIGFuZCBwcm90ZWN0aW9uIHBhdGgocykgaGF2 ZSBzYW1lIHNvdXJjZSBhbmQgc2luayBlbmRwb2ludHMgaW4gbGluZWFyIHByb3RlY3Rpb24gdHlw ZS4NCg0KSU1ITywgV2hlbiBTLVBFIGZhaWxzLCBpdCBpcyBtb3JlIHNpbXBsZSB0byB1c2UgIkxp bmVhciBwcm90ZWN0aW9uIiB0byBwcm90ZWN0IGl0Lg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KTWEN Cg0KDQpBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20+INC009ogMjAxMS0wNi0xNCAyMDowMjoxMDoNCg0KPiBEYW5pZWwsDQo+IFBsZWFzZSBzZWUg bW9yZSBpbmxpbmUgKGJvbGQgcHVycGxlIGl0YWxpY3MpLiBJoa92ZSBhbHNvIHN0cmlwcGVkIHRo ZQ0KPiBwb3J0aW9ucyBvZiB0aGUgdGV4dCB0aGF0IGFyZSBub3QgcmVsYXRlZCB0byB0aGlzIHJv dW5kIG9mIGNvbW1lbnRzLg0KPg0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+DQo+IEZyb206 IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPiBTZW50OiBUdWVzZGF5 LCBKdW5lIDE0LCAyMDExIDI6MzQgUE0NCj4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENj OiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElM L0hvZA0KPiBIYVNoYXJvbik7IG1hLnl1eGlhQHp0ZS5jb20uY24NCj4gU3ViamVjdDogUkU6IFtt cGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtDQo+IFRQTGluZWFyUHJv dGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IEhpIFNhc2hhLCB0aGFua3MgYWdh aW4gYW5kIHNlZSBpbmxpbmUgd2l0aCBbRENdLg0KPg0KPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNo dGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiBTZW50OiBN b25kYXksIEp1bmUgMTMsIDIwMTEgNjoxMSBQTQ0KPiBUbzogRGFuaWVsIENvaG4NCj4gQ2M6IG1w bHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9k DQo+IEhhU2hhcm9uKTsgbWEueXV4aWFAenRlLmNvbS5jbg0KPiBTdWJqZWN0OiBSRTogW21wbHNd IFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0 aW9uQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gRGFuaWVsIGFuZCBhbGwsDQo+IFBsZWFz ZSBzZWUgc29tZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgICAg U2FzaGENCj4NCj4gRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21d DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSA1OjU1IFBNDQo+IFRvOiBTcHJlY2hlciwg TnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IEFsZXhhbmRlciBWYWluc2h0ZWluOw0KPiBt YS55dXhpYUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExT LQ0KPiBUUExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gSGks DQo+DQo+IFRoYW5rcyBhbGwgZm9yIHRoZSBmZWVkYmFjay4gSSBiZWxpZXZlIHdlIGFsbCBhZ3Jl ZSB0aGF0IFBXDQo+IHByb3RlY3Rpb24gaXMgb25seSByZXF1aXJlZCBpbiB0aGUgZXZlbnQgb2Yg Uy1QRSBmYWlsdXJlIGF0IGFuIE1TLVBXDQo+IKhDIHRoaXMgIGlzIGNsZWFybHkgc3RhdGVkIGlu IHRoZSBkcmFmdC4gTm93LCBib3RoIFNhc2hhIGFuZCBOdXJpdA0KPiBtZW50aW9uIHRoYXQgdGhl IFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtIGNhbiBtZWV0IHRoZSBNUExTLVRQIFBXDQo+IHByb3Rl Y3Rpb24gcmVxdWlyZW1lbnRzLg0KPiBbW1tTYXNoYV1dXSChrSBzbmlwcGVkIKGtDQo+IEUuZy4s IHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgdGFrZSBjYXJlIG9mIGR1YWwtaG9tZWQgQ0Vz IGluDQo+IFNTLSBhbmQgTVMtUFdzIKhDIHNvbWV0aGluZyB0aGF0IGxpbmVyIHByb3RlY3Rpb24g b2YgUFdzIGNhbm5vdCBkby4NCj4gW0RDXSBJoa9tIGFmcmFpZCBJIGRvbqGvdCBmb2xsb3cgeW91 IGhlcmUuIFdoZXJlIGRvZXMgUFcgcmVkdW5kYW5jeQ0KPiB0YWtlIGNhcmUgb2YgZHVhbC1ob21l ZCBDRT8gQWN0dWFsbHkgUFcgcmVkdW5kYW5jeSBkcmFmdCBleHBsaWNpdGx5DQo+IHN0YXRlczog obBUaGUgbWV0aG9kIGZvciBkdWFsLWhvbWluZyBvZiBDRTEgdG8gUEUxIGFuZCB0byBQRTMgbm9k ZXMsDQo+IGFuZCB0aGUgcHJvdG9jb2xzIHVzZWQsIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50obEuDQo+IFtbW1Nhc2hhXV1dIFF1b3RpbmcgZnJvbSB0aGUgZHJhZnQ6DQo+ IDE1LjIuIE11bHRpcGxlIE11bHRpLWhvbWVkIENFcyB3aXRoIHNpbmdsZSBTUy1QVyByZWR1bmRh bmN5DQo+DQo+ICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tIEVtdWxhdGVkIFNlcnZpY2Ug LS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICB8ICAgICAgICAg IHw8LS0tLS0tLSBQc2V1ZG8gV2lyZSAtLS0tLS0+fCAgICAgICAgICB8DQo+ICAgICAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8DQo+ ICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgfDwtLSBQU04gVHVubmVscy0tPnwgICAgfCAg ICAgICAgICB8DQo+ICAgICAgICAgICAgICB8ICAgICAgICAgIFYgICAgViAgICAobm90IHNob3du KSAgIFYgICAgViAgICAgICAgICB8DQo+ICAgICAgICAgICAgICBWICAgIEFDICAgICstLS0tKyAg ICAgICAgICAgICAgICAgICstLS0tKyAgICAgQUMgICBWDQo+ICAgICAgICArLS0tLS0rICAgIHwg ICAgIHwuLi4ufC4uLi4uLi5QVzEuLi4uLi4uLnwuLi4ufCAgICAgfCAgICArLS0tLS0rDQo+ICAg ICAgICB8ICAgICB8LS0tLS0tLS0tLXwgUEUxfC4uLi4uLiAgIC4uLi4uLi4uLnwgUEUzfC0tLS0t LS0tLS18ICAgICB8DQo+ICAgICAgICB8IENFMSB8ICAgICAgICAgICstLS0tKyAgICAgIFwgLyAg UFczICAgICstLS0tKyAgICAgICAgICB8IENFMiB8DQo+ICAgICAgICB8ICAgICB8ICAgICAgICAg ICstLS0tKyAgICAgICBYICAgICAgICAgICstLS0tKyAgICAgICAgICB8ICAgICB8DQo+ICAgICAg ICB8ICAgICB8ICAgICAgICAgIHwgICAgfC4uLi4uLi8gXC4uUFc0Li4uLnwgICAgfCAgICAgICAg ICB8ICAgICB8DQo+ICAgICAgICB8ICAgICB8LS0tLS0tLS0tLXwgUEUyfCAgICAgICAgICAgICAg ICAgIHwgUEU0fC0tLS0tLS0tLSB8ICAgICB8DQo+ICAgICAgICArLS0tLS0rICAgIHwgICAgIHwu Li4ufC4uLi4uUFcyLi4uLi4uLi4uLnwuLi4ufCAgICAgfCAgICArLS0tLS0rDQo+ICAgICAgICAg ICAgICAgICAgIEFDICAgICstLS0tKyAgICAgICAgICAgICAgICAgICstLS0tKyAgICBBQw0KPg0K Pg0KPiAgICAgIEZpZ3VyZSAxNS0yIE11bHRpcGxlIE11bHRpLWhvbWVkIENFcyB3aXRoIHNpbmds ZSBTUy1QVyByZWR1bmRhbmN5DQo+DQo+ICAgIFRoZSBhcHBsaWNhdGlvbiBpbiBGaWd1cmUgMTUt MiBtYWtlcyB1c2Ugb2YgdGhlIEluZGVwZW5kZW50IG1vZGUgb2YNCj4gICAgb3BlcmF0aW9uLg0K Pg0KPiAgICBDRTEgaXMgZHVhbC1ob21lZCB0byBQRTEgYW5kIFBFMi4gQ0UyIGlzIGR1YWwtaG9t ZWQgUEUzIGFuZCBQRTQuIFRoZQ0KPiAgICBtZXRob2QgZm9yIGR1YWwtaG9taW5nIGFuZCB0aGUg dXNlZCBwcm90b2NvbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlDQo+ICAgIG9mIHRoaXMgZG9jdW1l bnQuICBOb3RlIHRoYXQgdGhlIFBTTiB0dW5uZWxzIGFyZSBub3Qgc2hvd24gaW4gdGhpcw0KPiAg ICBmaWd1cmUgZm9yIGNsYXJpdHkuIEhvd2V2ZXIsIGl0IGNhbiBiZSBhc3N1bWVkIHRoYXQgZWFj aCBvZiB0aGUgUFdzDQo+ICAgIHNob3duIGlzIGVuY2Fwc3VsYXRlZCBpbiBhIHNlcGFyYXRlIFBT TiB0dW5uZWwuDQo+DQo+ICAgIEFzc3VtZSB0aGF0IHRoZSBBQyBmcm9tIENFMSB0byBQRTEgaXMg QWN0aXZlLCBmcm9tIENFMSB0byBQRTIgaXMNCj4gICAgU3RhbmRieTsgZnVydGhlcm1vcmUsIGFz c3VtZSB0aGF0IHRoZSBBQyBmcm9tIENFMiB0byBQRTMgaXMgU3RhbmRieQ0KPiAgICBhbmQgZnJv bSBDRTIgdG8gUEU0IGlzIEFjdGl2ZS4gVGhlIG1ldGhvZCBvZiBkZXJpdmluZyBBY3RpdmUvU3Rh bmRieQ0KPiAgICBzdGF0dXMgb2YgdGhlIEFDIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQo+DQo+ICAgIFBFMSBhZHZlcnRpc2VzIHRoZSBwcmVmZXJlbnRpYWwgc3RhdHVz ICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAgICBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2Fy ZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMSBhbmQgUFc0IGNvbm5lY3RlZA0KPiAgICB0byBQRTMg YW5kIFBFNC4gVGhpcyBzdGF0dXMgcmVmbGVjdHMgdGhlIGZvcndhcmRpbmcgc3RhdGUgb2YgdGhl IEFDDQo+ICAgIGF0dGFjaGVkIHRvIFBFMS4gUEUyIGFkdmVydGlzZXMgcHJlZmVyZW50aWFsIHN0 YXR1cyAiU3RhbmRieSIgYW5kDQo+ICAgIG9wZXJhdGlvbmFsIHN0YXR1cyAiUHNldWRvd2lyZSBm b3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMgUFcyIGFuZA0KPiAgICBQVzMgdG8gUEUzIGFuZCBQ RTQuIFBFMyBhZHZlcnRpc2VzIHByZWZlcmVudGlhbCBzdGF0dXMgIlN0YW5kYnkiIGFuZA0KPiAg ICBvcGVyYXRpb25hbCBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dp cmVzIFBXMSBhbmQNCj4gICAgUFczIHRvIFBFMSBhbmQgUEUyLiBQRTQgYWR2ZXJ0aXNlIHRoZSBw cmVmZXJlbnRpYWwgc3RhdHVzICJBY3RpdmUiDQo+ICAgIGFuZCBvcGVyYXRpb25hbCBzdGF0dXMg IlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMg0KPiAgICBhbmQgUFc0 IHRvIFBFMiBhbmQgUEUxIHJlc3BlY3RpdmVseS4gVGh1cyBieSBtYXRjaGluZyB0aGUgbG9jYWwg YW5kDQo+ICAgIHJlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2FyZGluZyBzdGF0dXMgb2YgIkFjdGl2 ZSIgYW5kIG9wZXJhdGlvbmFsDQo+ICAgIHN0YXR1cyBvZiAiUHNldWRvd2lyZSBmb3J3YXJkaW5n IiBvZiBwc2V1ZG93aXJlcywgdGhlIFBFIG5vZGVzDQo+ICAgIGRldGVybWluZSB3aGljaCBQVyBz aG91bGQgYmUgaW4gdGhlIEFjdGl2ZSBzdGF0ZS4gSW4gdGhpcyBjYXNlIGl0IGlzDQo+ICAgIFBX NCB0aGF0IHdpbGwgYmUgc2VsZWN0ZWQuDQo+DQo+ICAgIE9uIGZhaWx1cmUgb2YgdGhlIEFDIGJl dHdlZW4gQ0UxIGFuZCBQRTEsIHRoZSBmb3J3YXJkaW5nIHN0YXRlIG9mDQo+ICAgIHRoZSBBQyBv biBQRTIgaXMgY2hhbmdlZCB0byBBY3RpdmUuIFBFMiB0aGVuIGFubm91bmNlcyB0aGUgbmV3bHkN Cj4gICAgY2hhbmdlZCAncHJlZmVyZW50aWFsIGZvcndhcmRpbmcnIHN0YXR1cyBiaXQgb2YgImFj dGl2ZSIgdG8gUEUzIGFuZA0KPiAgICBQRTQuIFBFMSB3aWxsIGFkdmVydGlzZSBhIFBXIHN0YXR1 cyBub3RpZmljYXRpb24gbWVzc2FnZSBpbmRpY2F0aW5nDQo+ICAgIHRoYXQgdGhlIEFDIGJldHdl ZW4gQ0UxIGFuZCBQRTEgaXMgb3BlcmF0aW9uYWxseSBkb3duLiBQRTIgYW5kIFBFNA0KPiAgICBt YXRjaCB0aGUgbG9jYWwgYW5kIHJlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2FyZGluZyBzdGF0dXMg b2YNCj4gICAgIkFjdGl2ZSIgYW5kIG9wZXJhdGlvbmFsIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3 YXJkaW5nIiBhbmQgc2VsZWN0DQo+ICAgIFBXMiBhcyB0aGUgbmV3IGFjdGl2ZSBwc2V1ZG93aXJl IHRvIHNlbmQgdHJhZmZpYyB0by4NCj4NCj4gICAgT24gZmFpbHVyZSBvZiBQRTEgbm9kZSwgUEUy IHdpbGwgZGV0ZWN0IGl0IGFuZCB3aWxsIHRyYW5zaXRpb24gdGhlDQo+ICAgIGZvcndhcmRpbmcg c3RhdGUgb2YgaXRzIEFDIHRvIEFjdGl2ZS4gVGhlIG1ldGhvZCBieSB3aGljaCBQRTINCj4gICAg ZGV0ZWN0cyB0aGF0IFBFMSBpcyBkb3duIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuIFBFMg0KPiAgICB0aGVuIGFubm91bmNlcyB0aGUgbmV3bHkgY2hhbmdlZCAncHJlZmVy ZW50aWFsIGZvcndhcmRpbmcnIHN0YXR1cw0KPiAgICBiaXQgb2YgIkFjdGl2ZSIgdG8gUEUzIGFu ZCBQRTQuIFBFMiBhbmQgUEU0IG1hdGNoIHRoZSBsb2NhbCBhbmQNCj4gICAgcmVtb3RlIHByZWZl cmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0aXZlIiBhbmQgb3BlcmF0aW9uYWwNCj4g ICAgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGFuZCBzZWxlY3QgUFcyIGFzIHRoZSBu ZXcgYWN0aXZlDQo+ICAgIHBzZXVkb3dpcmUgdG8gc2VuZCB0cmFmZmljIHRvLiBOb3RlIHRoYXQg UEUzIGFuZCBQRTQgbWF5IGhhdmUNCj4gICAgZGV0ZWN0ZWQgdGhhdCB0aGUgUFcgdG8gUEUxIHdl bnQgZG93biB2aWEgVC1MRFAgSGVsbG8gdGltZW91dCBvciB2aWENCj4gICAgb3RoZXIgbWVhbnMu IEhvd2V2ZXIsIHRoZXkgd2lsbCBub3QgYmUgYWJsZSB0byBmb3J3YXJkIHVzZXIgdHJhZmZpYw0K PiAgICB1bnRpbCB0aGV5IHJlY2VpdmVkIHRoZSB1cGRhdGVkIHN0YXR1cyBiaXQgZnJvbSBQRTIu DQo+DQo+ICAgIEJlY2F1c2UgZWFjaCBkdWFsLWhvbWluZyBhbGdvcml0aG0gcnVubmluZyBvbiB0 aGUgdHdvIG5vZGUgc2V0cywNCj4gICAgaS5lLiwge0NFMSwgUEUxLCBQRTJ9IGFuZCB7Q0UyLCBQ RTMsIFBFNH0sIHNlbGVjdHMgdGhlIGFjdGl2ZSBBQw0KPiAgICBpbmRlcGVuZGVudGx5LCB0aGVy ZSBpcyBhIG5lZWQgdG8gc2lnbmFsIHRoZSBhY3RpdmUgc3RhdHVzIG9mIHRoZSBBQw0KPiAgICBz dWNoIHRoYXQgdGhlIFBFIG5vZGVzIGNhbiBzZWxlY3QgYSBjb21tb24gYWN0aXZlIFBXIGZvciBl bmQtdG8tZW5kDQo+ICAgIGZvcndhcmRpbmcgYmV0d2VlbiBDRTEgYW5kIENFMiBhcyBwZXIgdGhl IHByb2NlZHVyZXMgaW4gdGhlDQo+ICAgIGluZGVwZW5kZW50IG1vZGUuDQo+DQo+ICAgIE5vdGUg dGhhdCBhbnkgcHJpbWFyeS9zZWNvbmRhcnkgcHJvY2VkdXJlcywgYXMgZGVmaW5lZCBpbiBzZWN0 aW9ucw0KPiAgICA1LjEuICBhbmQgNS4yLiAsIGRvIG5vdCBhcHBseSBpbiB0aGlzIHVzZSBjYXNl IGFzIHRoZSBBY3RpdmUvU3RhbmRieQ0KPiAgICBzdGF0dXMgaXMgZHJpdmVuIGJ5IHRoZSBBQyBm b3J3YXJkaW5nIHN0YXRlIGFzIGRldGVybWluZWQgYnkgdGhlIEFDDQo+ICAgIGR1YWwtaG9taW5n IHByb3RvY29sIHVzZWQuDQo+DQo+DQo+IEkgYmVsaWV2ZSB5b3Whr3ZlIHRha2VuIHlvdXIgobBv dXQgb2Ygc2NvcGWhsSByZWZlcmVuY2UgZnJvbSB0aGlzIHRleHQsDQo+IGJ1dCBJTUhPIHlvdSBt aXNpbnRlcnByZXRlZCBpdC4NCj4gV2hhdCBpdCBtZWFucyAob3Igc28gSSByZWFkIGl0KSBpcyB0 aGF0IHNwZWNpZmljIGR1YWwtaG9taW5nDQo+IHByb3RvY29sIGlzIG91dCBvZiBzY29wZSBhcyBs b25nIGFzIGl0IG1lZXRzIGNlcnRhaW4gYXNzdW1wdGlvbnMuDQo+IEFzaWRlOiBJdCB3b3VsZCBi ZSBnb29kIGlmIHRoZSBhdXRob3JzIG9mIHRoZSBQVyByZWR1bmRhbmN5IGRyYWZ0cw0KPiBjb3Vs ZCBleHBsaWNpdGx5IHNwZWNpZnkgdGhlc2UgYXNzdW1wdGlvbnMuDQo+DQo+IFtbW1Nhc2hhXV1d IKGtIHNuaXBwZWQgoa0NCj4NCj4gTm93IGxldKGvcyB0dXJuIG91ciBhdHRlbnRpb24gYmFjayB0 byB3aGV0aGVyIHRoZSBQVyByZWR1bmRhbmN5DQo+IGRyYWFmdCBjYW4gYmUgdXNlZCB0byBtZWV0 IE1QTFMtVFAgUFcgcHJvdGVjdGlvbiByZXF1aXJlbWVudHMuIEkgY2FuDQo+IGlkZW50aWZ5IHRo ZSBmb2xsb3dpbmcgcmVhc29ucyB3aHkgaW4gaXRzIGN1cnJlbnQgZm9ybSBpdCBkb2VzbqGvdDoN Cj4NCj4gLSAgICAgICAgICBJdCBleHBsaWNpdGx5ICihsG91dHNpZGUgdGhlIHNjb3BlobEpIGRv ZXMgbm90IGRlZmluZQ0KPiBwcm90ZWN0aW9uIHRyaWdnZXJzIGFuZCBob3cgdG8gaGFuZGxlIGNv ZXhpc3RpbmcgdHJpZ2dlcnMsIGFzDQo+IHJlcXVlc3RlZCBpbiBSRkMgNTY1NCAoTVBMUy1UUCBS ZXF1aXJlbWVudHMpLCByZXFzICM3NSwgIzc2IGFuZCAjNzkNCj4gW1tbU2FzaGFdXV0gU28gd2hh dD8gRGVmaW5pdGlvbiBvZiB0cmlnZ2VycyBpcyBvcnRob2dvbmFsIHRvIGhvdw0KPiBjb29yZGlu YXRlZCBwcm90ZWN0aW9uIHN3aXRjaGluZyBoYXBwZW5zLg0KPiBbRENdIEl0IGlzLiBCdXQgc3Rp bGwgaXQgbmVlZHMgdG8gYmUgZGVmaW5lZCBieSB0aGUgcmVjb3ZlcnkNCj4gZnJhbWV3b3JrLCBl LmcuIHdoYXQgc2hvdWxkIHRoZSBlbmRwb2ludCBkbyB3aGVuIG9uZSBQVyBpcyBpbiBTRiBhbmQN Cj4gdGhlIG90aGVyIGlzIGluIFNELCBvciB3aGVuIGJvdGggYXJlIGluIFNELiBPcGVyYXRvcnMg ZXhwZWN0IHdlbGwtDQo+IGRlZmluZWQgYmVoYXZpb3IgaW4gdGhlc2UgYW5kIG90aGVyIHNjZW5h cmlvcywgYW5kIFBXIHJlZHVuZGFuY3kNCj4gZG9lcyBub3QgZGVmaW5lIHRoZW0gKGJlY2F1c2Ug aXQgd2FzIG5vdCBpbiB0aGVpciBzY29wZSkuDQo+IFtbW1Nhc2hhXV1dIEkgd29uZGVyIGlmIHlv dSBoYXZlIGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uIHJlZ2FyZGluZw0KPiBhYmlsaXR5IHRvIGRl ZmluZSBTRCBjb25kaXRpb24gZm9yIExTUHMgYW5kIFBXcyBvbiB0aGUgTVBMUy1UUCBsaXN0Pw0K PiBJTU8gaXQgaXMgbm90IHBvc3NpYmxlIHRvIGRlZmluZSBpdCBpbiBhIG1lYW5pbmdmdWwgd2F5 LiBIZW5jZSBJIGRvDQo+IG5vdCBzZWUgYSBwcm9wb3NhbCB0aGF0IGRvZXMgbm90IGFkZHJlc3Mg YSBzY2VuYXJpbyB0aGF0IGRvZXMgbm90DQo+IGV4aXN0IGluIHJlYWxpdHkgYXMgYSBmbGF3ZWQg b25lLg0KPg0KPiAtICAgICAgICAgIEl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8g ZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KPiBkaWZmZXJlbnQgdHlwZXMgb2YgdHJpZ2dlcnMgKGkuZS4g b25lIGVuZCBkb2VzbqGvdCBrbm93IHdoeSB0aGUgb3RoZXINCj4gZW5kIHRyaWdnZXJlZCBzd2l0 Y2gpLCBhcyByZXF1ZXN0ZWQgaW4gUkZDIDU2NTQgKE1QTFMtVFANCj4gUmVxdWlyZW1lbnRzKSwg cmVxICM3Nw0KPiAtICAgICAgICAgIEl0IGRvZXMgbm90IGRlZmluZSByZXZlcnRpdmUvbm9ucmV2 ZXJ0aXZlIGJlaGF2aW9yLCBhcw0KPiByZXF1ZXN0ZWQgaW4gUkZDIDU2NTQgKE1QTFMtVFAgUmVx dWlyZW1lbnRzKSwgcmVxICM2NA0KPiAtICAgICAgICAgIEl0IGRvZXMgbm90IGRlZmluZSBob2xk b2ZmIHN1cHBvcnQsIHdoaWNoIGlzIGVzcGVjaWFsbHkNCj4gaW1wb3J0YW50IHRvIGF2b2lkIHJh Y2UgY29uZGl0aW9ucyB3aXRoIExTUCBwcm90ZWN0aW9uIHdoZW4gaXQgZXhpc3RzDQo+IC0gICAg ICAgICAgSXQgZG9lc26hr3Qgc3VwcG9ydCAxKzEgbW9kZSwgYXMgcmVxdWVzdGVkIGluIFJGQyA1 NjU0DQo+IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjUNCj4gW1tbU2FzaGFdXV0gQWxs IHRoZXNlIGNsYWltcyBhcmUgY29ycmVjdCCoQyBhbmQgIHRoaXMgc2hvdWxkIG5vdCBiZSBhDQo+ IHN1cnByaXNlLCBiZWNhdXNlIE1QTFMtVFAgcmVxdWlyZW1lbnRzIGhhdmUgYmVlbiBkZWZpbmVk IG11Y2ggbGF0ZXINCj4gdGhhbiB0aGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc20uDQo+IEJ1dCBJ IGRvIG5vdCB0aGluayB0aGF0IHRoaXMganVzdGlmaWVzIGNvLWV4aXN0ZW5jZSBvZiB0d28gZGlm ZmVyZW50DQo+IG1lY2hhbmlzbXMuDQo+IFtEQ10gU28gaG93IGRvIHlvdSBwcm9wb3NlIHRvIG1l ZXQgdGhlIFBXIHByb3RlY3Rpb24gcmVxdWlyZW1lbnQ/DQo+IC0gICAgICAgICAgSXShr3MgYSB0 d28tcGhhc2UgcHJvdG9jb2wsIHdpdGggdGhlIGNvbnNlcXVlbnQgaW1wYWN0IG9uIHRpbWluZw0K PiBbW1tTYXNoYV1dXSBDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZT8gW0RDXSBJbiBkcmFmdC1p ZXRmLW1wbHMtdHAtDQo+IGxpbmVhci1wcm90ZWN0aW9uLCBlYWNoIGVuZHBvaW50IHdpbGwgaW1t ZWRpYXRlbHkgc3dpdGNoIHRyYWZmaWMgdG8NCj4gdGhlIG90aGVyIHBhdGggdXBvbiBpZGVudGlm eWluZyBhbiBTRiBjb25kaXRpb24gaW4gYSBwYXRoLCB3aXRob3V0DQo+IHdhaXRpbmcgZm9yIHRo ZSBmYXIgZW5kIHRvIGFja25vd2xlZGdlIHRoZSBzd2l0Y2ggKDEtcGhhc2UpLiBJbiBQVw0KPiBy ZWR1bmRhbmN5LCBhbiBlbmRwb2ludCBkZXRlY3RpbmcgYW4gU0YgY29uZGl0aW9uIGluIGEgcGF0 aCB3aWxsIG5vdA0KPiBzd2l0Y2ggdW50aWwgdGhlIGZhciBlbmQgaGFzIGFja25vd2xlZGdlZCB0 aGUgc3dpdGNoICgyLXBoYXNlKS4NCj4gTmVlZGxlc3MgdG8gc2F5LCByZWNvdmVyeSBpcyBzbG93 ZXIgaW4gYSAyLXBoYXNlIHByb3RvY29sLg0KPiBbW1tTYXNoYV1dXSBUbyB0aGUgYmVzdCBvZiBt eSB1bmRlcnN0YW5kaW5nLCAxLXBoYXNlIHByb3RlY3Rpb24gaXMNCj4gb25seSBwb3NzaWJsZSBp biAxKzEgdW5pZGlyZWN0aW9uYWwgYXJjaGl0ZWN0dXJlcy4gQW5kIHllcywgSSBrbm93DQo+IHRo YXQgTVBMUy1UUCByZXF1aXJlcyBhICBtZWNoYW5pc20gdG8gc3VwcG9ydCB0aGlzOyB3aGV0aGVy IGFueWJvZHkNCj4gd291bGQgcmVhbGx5IGRvIHRoYXQgaW4gdGhlIHBhY2tldC1zd2l0Y2hpbmcg bmV0d29yayBpcyBub3QgY2xlYXIgdG8NCj4gbWUuIEFuZCBJIGFja25vd2xlZGdlIHRoYXQgdGhl IFBXIHJlZHVuZGFuY3kgZHJhZnRzIGRvIG5vdCBzdXBwb3J0DQo+IDErMSB1bmlkaXJlY3Rpb25h bCBzY2hlbWUuDQo+DQo+IC0gICAgICAgICAgSXQgZG9lc26hr3QgZGVmaW5lIHJldHJhbnNtaXNz aW9uIG9mIHByb3RlY3Rpb24NCj4gY29vcmRpbmF0aW9uIG1lc3NhZ2VzLCBzbyBsb3NzIG9mIGEg c2luZ2xlIFBEVSBjYW4gcmVzdWx0IGluDQo+IHN3aXRjaG92ZXIgbm90IHRha2luZyBwbGFjZSwg dGh1cyBub3Qgc3VwcG9ydGluZyBzdWItNTAgbXMgcmVjb3ZlcnkNCj4gaW4gdGhpcyBjYXNlDQo+ IFtbW1Nhc2hhXV1dIFRoZSBQVyByZWR1bmRhbmN5IHByb3RvY29sIHJ1bnMgZWl0aGVyIG9uIHRv cCBvZiBMRFANCj4gKHdoaWNoIGJlbmVmaXRzIGZyb20gVENQIHJldHJhbnNtaXNzaW9ucykgb3Ig b24gdG9wIG9mIHN0YXRpYyBQVw0KPiBzdGF0dXMgbWVzc2FnZXMgKHdoZXJlIHJldHJhbnNtaXNz aW9uIGlzIGRlZmluZWQpLg0KPiBbRENdIFRydWUgqEMgYnV0IHN0YXRpYyBQVyBzdGF0dXMgZGVm aW5lcyBzbG93IHJldHJhbnNtaXNzaW9uICihsHdpbGwNCj4gYmUgdHJhbnNtaXR0ZWQgdHdpY2Ug YXQgYW4gaW5pdGlhbCBpbnRlcnZhbCBvZiBvbmUgc2Vjb25kobEpIHdoaWxlDQo+IGRyYWZ0LWll dGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbiBzcGVjaWZpZXMgZmFzdCByZXRyYW5zbWlzc2lv bg0KPiB3aGVuIHJlcXVpcmVkIGZvciBmYXN0IHJlY292ZXJ5IChzZWN0aW9uIDMuMS40KS4NCj4N Cj4gSW4gc3VtbWFyeSwgUFcgcmVkdW5kYW5jeSB3YXMgbm90IGRlc2lnbmVkIHdpdGggVFAgcmVx dWlyZW1lbnRzIGluDQo+IG1pbmQsIGFuZCBhcyBzdWNoIGRvZXMgbm90IG1lZXQgdGhlIFRQIHJl cXVpcmVtZW50cy4gT2YgY291cnNlDQo+IG1vZGlmaWNhdGlvbnMgbWF5IGJlIGludHJvZHVjZWQs IGJ1dCB3aHkgcmVpbnZlbnQgdGhlIHdoZWVsIHdoZW4NCj4gdGhlcmUgaXMgYSBwcm90b2NvbCAo ZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uLTA2KSBpbiB0aGUNCj4gc3RhbmRh cmRzIHRyYWNrIHRoYXQgc3VwcG9ydHMgYWxsIHRoZSBhYm92ZSByZXF1aXJlbWVudHMgYW5kIGNh biBiZQ0KPiBhcHBsaWVkIHRvIE1TLVBXIHByb3RlY3Rpb24gd2l0aCBtaW5vciBtb2RpZmljYXRp b25zPw0KPiBbW1tTYXNoYV1dXSBBcyBJIHNhaWQsIGJlY2F1c2UgdGhlIGFwcGxpY2FiaWxpdHkg c2NvcGUgaXMgYnkgZmFyIHRvbw0KPiBuYXJyb3cgdG8ganVzdGlmeSBhIGRlZGljYXRlZCBwcm90 b2NvbC4NCj4gW0RDXSBJZiB3ZSB3ZXJlIGRpc2N1c3NpbmcgZGVzaWduaW5nIGEgbmV3IHByb3Rv Y29sLCBJIG1pZ2h0IGFncmVlDQo+IHdpdGggeW91LiBCdXQgZnJvbSBhIHByYWN0aWNhbCBzdGFu ZHBvaW50LCB0aGUgUFcgcHJvdGVjdGlvbiBkcmFmdA0KPiBpcyBub3QgYSBkZWRpY2F0ZWQgcHJv dG9jb2wgqEMgaXShr3MgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgdG8gYW4NCj4gZXhpc3Rp bmcgcHJvdG9jb2wuIEJvdGggZnJvbSB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBvcGVyYXRp b25hbA0KPiBwb2ludCBvZiB2aWV3IGl0IGRlZmluZXMgYSBuZXcgdXNlIGNhc2UgZm9yIGFuIGV4 aXN0aW5nIHByb3RvY29sIGFuZCBjb25jZXB0Lg0KPg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBEYW5p ZWwNCj4NCj4NCj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9I b2QgSGFTaGFyb24pDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSA0OjAyIFBNDQo+IFRv OiBleHQgQWxleGFuZGVyIFZhaW5zaHRlaW47IG1hLnl1eGlhQHp0ZS5jb20uY24NCj4gQ2M6IG1w bHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBbUFdFM10g U2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtDQo+IFRQTGluZWFyUHJvdGVjdGlvbiBBcHBs aWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBIaSwNCj4gSSB3b3VsZCBsaWtlIHRvIHNlY29uZCBT YXNoYS4NCj4gRW5kLXRvLWVuZCBQVyBwcm90ZWN0aW9uICh3aXRoIGRpdmVyc2UgcGF0aHMpIGRv ZXMgbm90IHNjYWxlLCBhbmQNCj4gcHV0IGhhcmQgcmVzdHJpY3Rpb25zIG9uIHRoZSB1dGlsaXph dGlvbiBvZiB0aGUgcmVzb3VyY2VzLg0KPiBNUExTLVRQIFBXcyBhcmUgY2FycmllZCBhY3Jvc3Mg dGhlIG5ldHdvcmsgaW5zaWRlIE1QTFMtVFAgTFNQcy4NCj4gVGhlcmVmb3JlLCBhbiBvYnZpb3Vz IHdheSB0byBwcm92aWRlIHByb3RlY3Rpb24gZm9yIGEgUFcgaXMgdG8NCj4gcHJvdGVjdCB0aGUg TFNQIHRoYXQgY2FycmllcyBpdC4NCj4gSWYgdGhlIFBXIGlzIGEgbXVsdGktc2VnbWVudCBQVywg dGhlbiBMU1AgcmVjb3ZlcnkgY2FuIG9ubHkgcHJvdGVjdA0KPiB0aGUgUFcgaW4gaW5kaXZpZHVh bCBzZWdtZW50cy4gIFRoaXMgbWVhbnMgdGhhdCBhIHNpbmdsZSBMU1ANCj4gcmVjb3ZlcnkgYWN0 aW9uIGNhbm5vdCBwcm90ZWN0IGFnYWluc3QgYSBmYWlsdXJlIG9mIGEgUFcgc3dpdGNoaW5nDQo+ IHBvaW50IChhbiBTLVBFKS4NCj4gV2hlbiBwcm90ZWN0aW5nIGFnYWluc3QgYW4gQUMgb3IgVC9T LVBFIGZhaWx1cmUgYnkgZHVhbA0KPiBjb25uZWN0aXZpdHksIFBXIHJlZHVuZGFuY3kgbWVjaGFu aXNtcyBwcm92aWRlIG1lYW5zIGZvciB0aGUgUEVzIHRvDQo+IGNvb3JkaW5hdGUgb3ZlciB3aGlj aCBMU1AgdGhlIHRyYWZmaWMgb2YgdGhlIFBXIGlzIGNhcnJpZWQuDQo+IEkgYWxzbyBkb3VidCB3 aHkgdGhlcmUgaXMgYSBuZWVkIGZvciBhZGRpdGlvbmFsIG1lY2hhbmlzbS4NCj4gQmVzdCByZWdh cmRzLA0KPiBOdXJpdA0KPg0KPiBGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpw d2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBleHQgQWxleGFuZGVyIFZhaW5z aHRlaW4NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDM6NDMgUE0NCj4gVG86IG1hLnl1 eGlhQHp0ZS5jb20uY24NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtQV0UzXSBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFAN Cj4gTGluZWFyUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBEZWFyIE1h IGFuZCBhbGwsDQo+IEFkZGluZyB0aGUgUFdFMyBXRyB0byBteSByZXNwb25zZS4NCj4NCj4gVGhl IFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtIHN1cHBvcnRzIGxpbmVhciBwcm90ZWN0aW9uIG9mIE1T LVBXcyBhcw0KPiBvbmUgb2YgbWFueSBhZGRpdGlvbmFsIGFwcGxpY2F0aW9uIHVzZSBjYXNlczoN Cj4gQXBwZW5kaXggQSBvZiB0aGUgUFcgcmVkdW5kYW5jeSBCaXQgZHJhZnQgZGVzY3JpYmVzIDUg YXBwbGljYXRpb24NCj4gdXNlcyBjYXNlcyBpbiBhZGRpdGlvbiB0byBNUy1QVyB3aXRoIHNpbmds ZS1ob21lZCBDRXMgKHdoaWNoIGlzDQo+IGxpc3RlZCB0aGVyZSBhcyB1c2UgY2FzZSA1KS4NCj4g QW5kIGl0IGlzIGVxdWFsbHkgYXBwbGljYWJsZSB0byBJUC9NUExTIGFuZCBNUExTIC0gd2l0aCB0 aGUgaGVscCBvZiAgdGhlDQo+IFN0YXRpYyBQVyBTdGF0dXMgTWVzc2FnZXMgZHJhZnQoIGlmLCBm b3Igd2hhdGV2ZXIgcmVhc29uLCB5b3UgZG8gbm90DQo+IHdhbnQgIHRvLCBvciBjYW5ub3QsIHVz ZSBSRkMgNDQ0NykuDQo+DQo+IEhlbmNlIEkgZG91YnQgdGhlIG5lZWQgZm9yIHlldCBhbm90aGVy IFBXIHJlZHVuZGFuY3kgIG1lY2hhbmlzbSB3aXRoDQo+IG5hcnJvdyBzY29wZSBvZiBhcHBsaWNh YmlsaXR5Lg0KPg0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+DQo+IEZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m DQo+IG1hLnl1eGlhQHp0ZS5jb20uY24NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDM6 MjUgUE0NCj4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBTZWVraW5n IGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUCBMaW5lYXINCj4gUHJvdGVjdGlvbiBBcHBsaWNhYmls aXR5IHRvIE1TLVBXIg0KPg0KPiBIaSBhbGwsDQo+DQo+IFRoZSBsaW5lYXIgcHJvdGVjdGlvbiBt ZWNoYW5pc20gZm9yIExTUCBhbmQgUFcoaW5jbHVkaW5nIE1TLVBXKQ0KPiBzaG91bGQgYmUgdGhl IHNhbWUgYW5kIGl0IGlzIHZhbHVhYmxlIHRvIGRlc2NyaWJlIGl0IGNsZWFybHkuDQo+DQo+IEJU VywgdGhlcmUgaXMgYSB0eXBvLCBpdCBpcyAiVC1QRSBaIiBpbnN0ZWFkIG9mICJULVBFIEIiLg0K Pg0KPiAgIg0KPiAgIEZpZ3VyZSAxIGlsbHVzdHJhdGVzIHN1Y2ggYSBzY2VuYXJpbywgd2hlcmUg dHdvIE1TLVBXcyBhcmUNCj4gICBlc3RhYmxpc2hlZCBiZXR3ZWVuIFQtUEUgQSBhbmQgVC1QRSBC LCBvdmVyIFMtUEVzIDEtMiBhbmQgMy00DQo+ICAgcmVzcGVjdGl2ZWx5LiBFYWNoIFBXIHNlZ21l bnQgaXMgZXN0YWJsaXNoZWQgb3ZlciBhbiBMU1AgKGUuZy4gUFctDQo+ICAgczEyIG92ZXIgTFNQ MTIpLg0KPiAgIg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW5pZWwg Q29obg0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTEgNDoxNCBQTQ0KPiBUbzogbXBscw0K PiBTdWJqZWN0OiBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVj dGlvbg0KPiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPiBJbXBvcnRhbmNlOiBIaWdoDQo+DQo+ IEhpIE1QTFNlcnMsDQo+DQo+IEkgdXBsb2FkZWQgIk1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24g QXBwbGljYWJpbGl0eSB0byBNUy1QVyIgSS1EDQo+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jb2huLW1wbHMtdHAtcHctcHJvdGVjdGlvbi0wMCkNCj4NCj4gVGhlIGFic3RyYWN0 IGdvZXM6DQo+DQo+IE9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBNUExTIHRyYW5zcG9y dCBwcm9maWxlIFtSRkMgNTY1NF0gaXMNCj4gdG8gcHJvdmlkZSBsaW5lYXIgcHJvdGVjdGlvbiBm b3IgdHJhbnNwb3J0IHBhdGhzLCB3aGljaCBpbmNsdWRlIGJvdGgNCj4gTFNQcyBhbmQgUFdzLiBU aGUgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgZGVzY3JpYmVkIGluIFtTdXJ2aXZGd2tdDQo+IGlz IGFwcGxpY2FibGUgdG8gYm90aCBMU1AgYW5kIFBXcywgaG93ZXZlciBbTGluZWFyUHJvdF0gZG9l cyBub3QNCj4gZXhwbGljaXRseSBkZXNjcmliZSBtZWNoYW5pc21zIGZvciBQVyBwcm90ZWN0aW9u IGluIE1QTFMtVFAuDQo+DQo+IFRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgYXBwbGljYWJpbGl0 eSBvZiB0aGUgbGluZWFyIHByb3RlY3Rpb24NCj4gbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBbTGlu ZWFyUHJvdF0gdG8gTVBMUy1UUCBzZWdtZW50ZWQgUFdzDQo+IChNUy1QV3MpIGFzIGRlZmluZWQg aW4gW1JGQyA2MDczXS4NCj4NCj4gQ291bGQgeW91IHBsZWFzZSByZXZpZXcgaXQgYW5kIHNlbmQg ZmVlZGJhY2sgdG8gdGhlIG1haWxpbmcgbGlzdCBvcg0KPiBkaXJlY3RseSB0byB0aGUgYXV0aG9y Pw0KPg0KPiBMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjaywNCj4NCj4gRGFuaWVsDQo+ IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBh bmQgY29udGFpbnMNCj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGlj aCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8NCj4gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UNCj4gaW5mb3JtIHVzIGJ5IGUt bWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPiBh bGwgY29waWVzIHRoZXJlb2YuDQo+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9y IHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4gaW5mb3JtYXRpb24gd2hpY2ggaXMg Q09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8NCj4gRUNJIFRlbGVj b20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2UNCj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZA0KPiBhbGwgY29waWVzIHRoZXJlb2YuDQo+IFRoaXMgZS1tYWlsIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4g aW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJp ZXRhcnkgdG8NCj4gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNt aXNzaW9uIGluIGVycm9yLCBwbGVhc2UNCj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3Ig ZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPiBhbGwgY29waWVzIHRoZXJl b2YuIAGpbXq52j8/YnI+DQoNCg== From internet-drafts@ietf.org Tue Jun 21 10:49: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 AB4E911E82C6; Tue, 21 Jun 2011 10:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 OV-faGdsr4Uv; Tue, 21 Jun 2011 10:49:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED60F11E8178; Tue, 21 Jun 2011 10:49:22 -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.55 Message-ID: <20110621174922.14706.43517.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 10:49:22 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-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: Tue, 21 Jun 2011 17:49:23 -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 : An Overview of the OAM Tool Set for MPLS based Transport= Networks Author(s) : Nurit Sprecher Luyuan Fang Filename : draft-ietf-mpls-tp-oam-analysis-04.txt Pages : 21 Date : 2011-06-21 This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in [MPLS-TP OAM Reqs] and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this 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-oam-analysis-04.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-oam-analysis-04.txt From internet-drafts@ietf.org Thu Jun 23 10:41: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 1C00A11E8193; Thu, 23 Jun 2011 10:41:00 -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 jx0u1DvwkE7l; Thu, 23 Jun 2011 10:40:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC4311E8184; Thu, 23 Jun 2011 10:40: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.55 Message-ID: <20110623174059.26282.33594.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2011 10:40:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-recurs-fec-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: Thu, 23 Jun 2011 17:41: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 : Using Multipoint LDP when the Backbone has no Route to t= he Root Author(s) : IJsbrand Wijnands Eric C. Rosen Maria Napierala Nicolai Leymann Filename : draft-ietf-mpls-mldp-recurs-fec-03.txt Pages : 12 Date : 2011-06-23 The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") cont= ains a field that identifies the address of a "root node". Intermedi= ate 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 the intermediate nodes are part of a BGP-free core, this is not possible. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-recurs-fec-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-mldp-recurs-fec-03.txt From Rolf.Winter@neclab.eu Thu Jun 23 12: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 2454611E80AC for ; Thu, 23 Jun 2011 12:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.06 X-Spam-Level: X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 NKhSci1Txata for ; Thu, 23 Jun 2011 12:57:43 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4725211E8072 for ; Thu, 23 Jun 2011 12:57:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 317CD28000211; Thu, 23 Jun 2011 21:57:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAMlW182y2yM; Thu, 23 Jun 2011 21:57:42 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 140D6280001AA; Thu, 23 Jun 2011 21:57:32 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 23 Jun 2011 22:00:44 +0200 From: Rolf Winter To: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7Q Date: Thu, 23 Jun 2011 20:00:44 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> References: <4DFA60E3.90807@pi.nu> In-Reply-To: <4DFA60E3.90807@pi.nu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 23 Jun 2011 19:57:44 -0000 Hi, some comments/questions: In section 3.3. you say: "The On-demand CV payload MUST directly follow the= ACH header (and any ACH TLVs)" but the document does not allow ACH TLVs as= per the IANA section. The static LSP target FEC stack sub-TLVs is 22 not 24 octets long I believe= and the PW one 32 (table section 2.3). Can we live without any ICC-based IDs in the draft to function in all envir= onments? Which return code to send when identifiers are wrong (Malformed echo reques= t received?) or drop the packet. Using the per-interface model and say the DSMAP TLV did not match the ingre= ss IF identifier, then should this request frame be dropped? Should we repl= y to the requestor? Can this way two answers be generated? Nit (section 2.1): s/mpls/MPLS/ 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 > Loa Andersson > Sent: Donnerstag, 16. Juni 2011 22:01 > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; Ross > Callon; George Swallow; MPLS-TP ad hoc team > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv >=20 > Working Group. >=20 > 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. >=20 > A document detailing how the comments have been addressed will be > found at: > http://www.pi.nu/~loa/comments-on-03.xls >=20 > 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. >=20 > Loa > on behalf of the MPLS wg co-chairs >=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 From eric.gray@ericsson.com Thu Jun 23 14:39: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 8A06011E819D for ; Thu, 23 Jun 2011 14:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-1.845, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 8qATgvgkqpTt for ; Thu, 23 Jun 2011 14:39:36 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A642611E817E for ; Thu, 23 Jun 2011 14:39:36 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5NLdZ29004187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jun 2011 16:39:36 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 23 Jun 2011 17:39:35 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Thu, 23 Jun 2011 17:39:32 -0400 Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvgAAI39/AAoPt2UAAOvWrg 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] FW: [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-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, 23 Jun 2011 21:39:38 -0000 Rm9yd2FyZGluZyBpbiBwbGFpbiB0ZXh0Li4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkZyb206IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8gW21haWx0bzph bGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXRdDQpTZW50OiBUaHVyc2RheSwg SnVuZSAyMywgMjAxMSAxMToyMyBBTQ0KVG86IERhbmllbCBDb2huDQpDYzogbXBsc0BpZXRmLm9y ZzsgcHdlM0BpZXRmLm9yZzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IG1hLnl1eGlhQHp0ZS5jb20u Y24NClN1YmplY3Q6IFI6IFtQV0UzXSBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1Q TFMtVFAgTGluZWFyIFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KDQoNCkRl YXIgRGFuaWVsLA0KDQptYW55IHRoYW5rcyBmb3IgYnJpbmdpbmcgdG8gb3VyIGF0dGVudGlvbiB0 aGlzIGlzc3VlLg0KDQoNCg0KSXQgbWFrZXMgc2Vuc2UgZm9yIG1lIGhhdmluZyB0aGUgc2FtZSBs aW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGFwcGxpZWQgYXQgYm90aCBMU1AgYW5kIFBXIGxl dmVsIChpbiB0aGUgTVBMUy1UUCBmcmFtZXdvcmspLg0KDQoNCg0KSXQgaXMgb2J2aW91cyB0aGF0 IHRoZXJlIGFyZSBjaXJjdW1zdGFuY2VzIHdoZXJlIFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtcyBj YW4gYmUgZXhwbG9pdGVkIGJlY2F1c2UgdGhleSBjb3ZlciB0aGUgcmVxdWlyZW1lbnRzIG9mIGNl cnRhaW4gYXJjaGl0ZWN0dXJhbCBhcHByb2FjaGVzDQoNCmJ1dCBJIGRvIG5vdCBiZWxpZXZlIGl0 IGNhbiBiZSBjbGFpbWVkIHRoYXQgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc21zIGNvdmVyIHRoZSBz YW1lIHJlcXVpcmVtZW50cyAgY292ZXJlZCBieSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20u IFRoZXJlZm9yZSB0aGVyZSBpcyBhIGdhcCB0aGF0IG5lZWQgdG8gYmUgZmlsbGVkIGFuZCBleHRl bmRpbmcgdGhlIGFscmVhZHkgZGVmaW5lZCBsaW5lYXIgcHJvdGVjdGlvbiBmb3IgTFNQcyBzZWVt cyB0aGUgbW9zdCBhcHByb3ByaWF0ZSB3YXkgdG8gcHJvY2VlZC4NCg0KDQoNCkFjdHVhbGx5LCBJ IGRvIG5vdCBzZWUgYW55IGFyZ3VtZW50IGJlbG93IGNvbmZ1dGluZyB5b3VyIGh5cG90aGVzaXMg YW5kIHRoZXJlZm9yZSBJIHN1cHBvcnQgeW91ciBwcm9wb3NhbC4NCg0KDQoNCkJlc3QgcmVnYXJk cywNCg0KQWxlc3NhbmRybw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlbGVjb20gSXRhbGlhDQpBbGVzc2FuZHJv IEQnQWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRpb24NClZpYSBSZWlzcyBSb21vbGksIDI3 NCAtIDEwMTQ4IFRvcmlubw0KcGhvbmU6ICArMzkgMDExIDIyOCA1ODg3DQptb2JpbGU6ICszOSAz MzUgNzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2MzkgMDcNCg0KDQoNCkRhOiBwd2UzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBE YW5pZWwgQ29obg0KSW52aWF0bzogbHVuZWSorCAyMCBnaXVnbm8gMjAxMSAxMTo1MQ0KQTogQWxl eGFuZGVyIFZhaW5zaHRlaW47IG1hLnl1eGlhQHp0ZS5jb20uY24NCkNjOiBtcGxzQGlldGYub3Jn OyBwd2UzQGlldGYub3JnDQpPZ2dldHRvOiBSZTogW1BXRTNdIFttcGxzXSBTZWVraW5nIGZlZWRi YWNrIG9uIEktRCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1T LVBXIg0KDQoNCg0KU2FzaGEsDQoNCg0KDQpJIHRoaW5rIHRoZSBtYWluIHF1ZXN0aW9uIGhlcmUg aXMgd2h5IGNhbGwgUFcgbGluZWFyIHByb3RlY3Rpb24gYW4gYWQtaG9jIG1lY2hhbmlzbSB3aGVu IGl0oa9zIHNpbXBseSBhbiBleHRlbnNpb24gb2YgTFNQIGxpbmVhciBwcm90ZWN0aW9uLiBGcm9t IGFuIGltcGxlbWVudGF0aW9uIHBvaW50IG9mIHZpZXcsIHRoZSBkaWZmZXJlbmNlcyBhcmUgbWlu aW1hbCCoQyB5b3UgY291bGQgZXZlbiBzYXkgc2VtYW50aWMuIEkgdGhpbmsgdGhpcyBpcyB3aGF0 IE1hIG1lYW5zIGJ5IHNpbXBsaWNpdHkgYW5kIEkgd2hvbGx5IGFncmVlIHdpdGggaGVyIKhDIHlv dSBoYXZlIGEgc2luZ2xlIG1lY2hhbmlzbSB0byBwcm90ZWN0IGFsbCB0cmFuc3BvcnQgcGF0aHMg qEMgYmUgdGhlbSBMU1Agb3IgUFcuDQoNCg0KDQpNeSB0d28gY2VudHMsDQoNCg0KDQpEQw0KDQoN Cg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAyMCwgMjAxMSAxMTo1MCBBTQ0KVG86 IG1hLnl1eGlhQHp0ZS5jb20uY24NCkNjOiBEYW5pZWwgQ29objsgbXBsc0BpZXRmLm9yZzsgU3By ZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBwd2UzQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMt VFAgTGluZWFyIFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KDQoNCkRlYXIg TWEsDQoNCkxvdHMgb2YgdGhhbmtzIGZvciBvdXIgcmVzcG9uc2UuIFBsZWFzZSBzZWUgc29tZSBj b21tZW50cy9hbnN3ZXJzIGlubGluZSBiZWxvdy4NCg0KDQoNClJlZ2FyZHMsDQoNCiAgICAgU2Fz aGENCg0KDQoNCkZyb206IG1hLnl1eGlhQHp0ZS5jb20uY24gW21haWx0bzptYS55dXhpYUB6dGUu Y29tLmNuXQ0KU2VudDogTW9uZGF5LCBKdW5lIDIwLCAyMDExIDExOjMxIEFNDQpUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW4NCkNjOiBEYW5pZWwgQ29objsgbXBsc0BpZXRmLm9yZzsgU3ByZWNoZXIs IE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiC0 8Li0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUExp bmVhclByb3RlY3Rpb25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KDQoNCg0KDQpIaSBTYXNoYSwN Cg0KIkxpbmVhciBwcm90ZWN0aW9uIiBpcyBkaWZmZXJlbnQgZnJvbSAiTXVsdGktaG9tZWQgQ0Ug cmVkdW5kYW5jeSIgYW5kIGhhcyBubyByZWZlcmVuY2Ugd2l0aCBBQy4NCg0KW1tbU2FzaGFdXV0g QWJzb2x1dGVseS4NCg0KDQpXb3JraW5nIHBhdGgocykgYW5kIHByb3RlY3Rpb24gcGF0aChzKSBo YXZlIHNhbWUgc291cmNlIGFuZCBzaW5rIGVuZHBvaW50cyBpbiBsaW5lYXIgcHJvdGVjdGlvbiB0 eXBlLg0KDQpbW1tTYXNoYV1dXSBPZiBjb3Vyc2UuDQoNCg0KDQpJTUhPLCBXaGVuIFMtUEUgZmFp bHMsIGl0IGlzIG1vcmUgc2ltcGxlIHRvIHVzZSAiTGluZWFyIHByb3RlY3Rpb24iIHRvIHByb3Rl Y3QgaXQuDQoNCltbW1Nhc2hhXV1dIFdlbGwsIHNpbXBsaWNpdHkgLCBsaWtlIGJlYXV0eSwgaXMg aW4gdGhlIGV5ZSBvZiB0aGUgYmVob2xkZXJKLg0KDQpCdXQgSU1ITyAgaW50cm9kdWNpbmcgbXVs dGlwbGUgc2ltcGxlIGFkIGhvYyBzb2x1dGlvbnMgKGVhY2ggZm9yIGl0cyBzcGVjaWZpYyBjYXNl KSBhbmQgbWFpbnRhaW5pbmcgdGhlbSAgZXZlbnR1YWxseSBtYWtlIHlvdXIgbGlmZSBtb3JlICBj b21wbGljYXRlZCB3aGVuIGNvbXBhcmVkIHdpdGggb25lIGdlbmVyaWMgbWVjaGFuaXNtoa0NCg0K DQoNCkJlc3QgUmVnYXJkcywNCk1hDQoNCg0KQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiDQtNPaIDIwMTEtMDYtMTQgMjA6MDI6MTA6DQoNCj4g RGFuaWVsLA0KPiBQbGVhc2Ugc2VlIG1vcmUgaW5saW5lIChib2xkIHB1cnBsZSBpdGFsaWNzKS4g SaGvdmUgYWxzbyBzdHJpcHBlZCB0aGUNCj4gcG9ydGlvbnMgb2YgdGhlIHRleHQgdGhhdCBhcmUg bm90IHJlbGF0ZWQgdG8gdGhpcyByb3VuZCBvZiBjb21tZW50cy4NCj4NCj4gUmVnYXJkcywNCj4g ICAgICBTYXNoYQ0KPg0KPiBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0 LmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVuZSAxNCwgMjAxMSAyOjM0IFBNDQo+IFRvOiBBbGV4 YW5kZXIgVmFpbnNodGVpbg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZzsgU3By ZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QNCj4gSGFTaGFyb24pOyBtYS55dXhpYUB6dGUuY29t LmNuDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1E ICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rpb25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0K PiBIaSBTYXNoYSwgdGhhbmtzIGFnYWluIGFuZCBzZWUgaW5saW5lIHdpdGggW0RDXS4NCj4NCj4g RnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDY6MTEgUE0NCj4gVG86 IERhbmllbCBDb2huDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hl ciwgTnVyaXQgKE5TTiAtIElML0hvZA0KPiBIYVNoYXJvbik7IG1hLnl1eGlhQHp0ZS5jb20uY24N Cj4gU3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1Q TFMtDQo+IFRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IERh bmllbCBhbmQgYWxsLA0KPiBQbGVhc2Ugc2VlIHNvbWUgY29tbWVudHMgaW5saW5lIGJlbG93Lg0K Pg0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+DQo+IEZyb206IERhbmllbCBDb2huIFttYWls dG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgNTo1 NSBQTQ0KPiBUbzogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBBbGV4 YW5kZXIgVmFpbnNodGVpbjsNCj4gbWEueXV4aWFAenRlLmNvbS5jbg0KPiBDYzogbXBsc0BpZXRm Lm9yZzsgcHdlM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5n IGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0aW9uIEFwcGxpY2FiaWxp dHkgdG8gTVMtUFciDQo+DQo+IEhpLA0KPg0KPiBUaGFua3MgYWxsIGZvciB0aGUgZmVlZGJhY2su IEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgdGhhdCBQVw0KPiBwcm90ZWN0aW9uIGlzIG9ubHkgcmVx dWlyZWQgaW4gdGhlIGV2ZW50IG9mIFMtUEUgZmFpbHVyZSBhdCBhbiBNUy1QVw0KPiCoQyB0aGlz ICBpcyBjbGVhcmx5IHN0YXRlZCBpbiB0aGUgZHJhZnQuIE5vdywgYm90aCBTYXNoYSBhbmQgTnVy aXQNCj4gbWVudGlvbiB0aGF0IHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbSBjYW4gbWVldCB0 aGUgTVBMUy1UUCBQVw0KPiBwcm90ZWN0aW9uIHJlcXVpcmVtZW50cy4NCj4gW1tbU2FzaGFdXV0g oa0gc25pcHBlZCChrQ0KPiBFLmcuLCB0aGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc21zIHRha2Ug Y2FyZSBvZiBkdWFsLWhvbWVkIENFcyBpbg0KPiBTUy0gYW5kIE1TLVBXcyCoQyBzb21ldGhpbmcg dGhhdCBsaW5lciBwcm90ZWN0aW9uIG9mIFBXcyBjYW5ub3QgZG8uDQo+IFtEQ10gSaGvbSBhZnJh aWQgSSBkb26hr3QgZm9sbG93IHlvdSBoZXJlLiBXaGVyZSBkb2VzIFBXIHJlZHVuZGFuY3kNCj4g dGFrZSBjYXJlIG9mIGR1YWwtaG9tZWQgQ0U/IEFjdHVhbGx5IFBXIHJlZHVuZGFuY3kgZHJhZnQg ZXhwbGljaXRseQ0KPiBzdGF0ZXM6IKGwVGhlIG1ldGhvZCBmb3IgZHVhbC1ob21pbmcgb2YgQ0Ux IHRvIFBFMSBhbmQgdG8gUEUzIG5vZGVzLA0KPiBhbmQgdGhlIHByb3RvY29scyB1c2VkLCBhcmUg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudKGxLg0KPiBbW1tTYXNoYV1dXSBRdW90 aW5nIGZyb20gdGhlIGRyYWZ0Og0KPiAxNS4yLiBNdWx0aXBsZSBNdWx0aS1ob21lZCBDRXMgd2l0 aCBzaW5nbGUgU1MtUFcgcmVkdW5kYW5jeQ0KPg0KPiAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t LS0tLSBFbXVsYXRlZCBTZXJ2aWNlIC0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAg ICAgICAgICAgICAgfCAgICAgICAgICB8PC0tLS0tLS0gUHNldWRvIFdpcmUgLS0tLS0tPnwgICAg ICAgICAgfA0KPiAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgIHw8LS0g UFNOIFR1bm5lbHMtLT58ICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgfCAgICAgICAg ICBWICAgIFYgICAgKG5vdCBzaG93bikgICBWICAgIFYgICAgICAgICAgfA0KPiAgICAgICAgICAg ICAgViAgICBBQyAgICArLS0tLSsgICAgICAgICAgICAgICAgICArLS0tLSsgICAgIEFDICAgVg0K PiAgICAgICAgKy0tLS0tKyAgICB8ICAgICB8Li4uLnwuLi4uLi4uUFcxLi4uLi4uLi58Li4uLnwg ICAgIHwgICAgKy0tLS0tKw0KPiAgICAgICAgfCAgICAgfC0tLS0tLS0tLS18IFBFMXwuLi4uLi4g ICAuLi4uLi4uLi58IFBFM3wtLS0tLS0tLS0tfCAgICAgfA0KPiAgICAgICAgfCBDRTEgfCAgICAg ICAgICArLS0tLSsgICAgICBcIC8gIFBXMyAgICArLS0tLSsgICAgICAgICAgfCBDRTIgfA0KPiAg ICAgICAgfCAgICAgfCAgICAgICAgICArLS0tLSsgICAgICAgWCAgICAgICAgICArLS0tLSsgICAg ICAgICAgfCAgICAgfA0KPiAgICAgICAgfCAgICAgfCAgICAgICAgICB8ICAgIHwuLi4uLi4vIFwu LlBXNC4uLi58ICAgIHwgICAgICAgICAgfCAgICAgfA0KPiAgICAgICAgfCAgICAgfC0tLS0tLS0t LS18IFBFMnwgICAgICAgICAgICAgICAgICB8IFBFNHwtLS0tLS0tLS0gfCAgICAgfA0KPiAgICAg ICAgKy0tLS0tKyAgICB8ICAgICB8Li4uLnwuLi4uLlBXMi4uLi4uLi4uLi58Li4uLnwgICAgIHwg ICAgKy0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICBBQyAgICArLS0tLSsgICAgICAgICAgICAg ICAgICArLS0tLSsgICAgQUMNCj4NCj4NCj4gICAgICBGaWd1cmUgMTUtMiBNdWx0aXBsZSBNdWx0 aS1ob21lZCBDRXMgd2l0aCBzaW5nbGUgU1MtUFcgcmVkdW5kYW5jeQ0KPg0KPiAgICBUaGUgYXBw bGljYXRpb24gaW4gRmlndXJlIDE1LTIgbWFrZXMgdXNlIG9mIHRoZSBJbmRlcGVuZGVudCBtb2Rl IG9mDQo+ICAgIG9wZXJhdGlvbi4NCj4NCj4gICAgQ0UxIGlzIGR1YWwtaG9tZWQgdG8gUEUxIGFu ZCBQRTIuIENFMiBpcyBkdWFsLWhvbWVkIFBFMyBhbmQgUEU0LiBUaGUNCj4gICAgbWV0aG9kIGZv ciBkdWFsLWhvbWluZyBhbmQgdGhlIHVzZWQgcHJvdG9jb2xzIGFyZSBvdXRzaWRlIHRoZSBzY29w ZQ0KPiAgICBvZiB0aGlzIGRvY3VtZW50LiAgTm90ZSB0aGF0IHRoZSBQU04gdHVubmVscyBhcmUg bm90IHNob3duIGluIHRoaXMNCj4gICAgZmlndXJlIGZvciBjbGFyaXR5LiBIb3dldmVyLCBpdCBj YW4gYmUgYXNzdW1lZCB0aGF0IGVhY2ggb2YgdGhlIFBXcw0KPiAgICBzaG93biBpcyBlbmNhcHN1 bGF0ZWQgaW4gYSBzZXBhcmF0ZSBQU04gdHVubmVsLg0KPg0KPiAgICBBc3N1bWUgdGhhdCB0aGUg QUMgZnJvbSBDRTEgdG8gUEUxIGlzIEFjdGl2ZSwgZnJvbSBDRTEgdG8gUEUyIGlzDQo+ICAgIFN0 YW5kYnk7IGZ1cnRoZXJtb3JlLCBhc3N1bWUgdGhhdCB0aGUgQUMgZnJvbSBDRTIgdG8gUEUzIGlz IFN0YW5kYnkNCj4gICAgYW5kIGZyb20gQ0UyIHRvIFBFNCBpcyBBY3RpdmUuIFRoZSBtZXRob2Qg b2YgZGVyaXZpbmcgQWN0aXZlL1N0YW5kYnkNCj4gICAgc3RhdHVzIG9mIHRoZSBBQyBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPg0KPiAgICBQRTEgYWR2ZXJ0aXNlcyB0 aGUgcHJlZmVyZW50aWFsIHN0YXR1cyAiQWN0aXZlIiBhbmQgb3BlcmF0aW9uYWwNCj4gICAgc3Rh dHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzEgYW5kIFBXNCBj b25uZWN0ZWQNCj4gICAgdG8gUEUzIGFuZCBQRTQuIFRoaXMgc3RhdHVzIHJlZmxlY3RzIHRoZSBm b3J3YXJkaW5nIHN0YXRlIG9mIHRoZSBBQw0KPiAgICBhdHRhY2hlZCB0byBQRTEuIFBFMiBhZHZl cnRpc2VzIHByZWZlcmVudGlhbCBzdGF0dXMgIlN0YW5kYnkiIGFuZA0KPiAgICBvcGVyYXRpb25h bCBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMiBhbmQN Cj4gICAgUFczIHRvIFBFMyBhbmQgUEU0LiBQRTMgYWR2ZXJ0aXNlcyBwcmVmZXJlbnRpYWwgc3Rh dHVzICJTdGFuZGJ5IiBhbmQNCj4gICAgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZv cndhcmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzEgYW5kDQo+ICAgIFBXMyB0byBQRTEgYW5kIFBF Mi4gUEU0IGFkdmVydGlzZSB0aGUgcHJlZmVyZW50aWFsIHN0YXR1cyAiQWN0aXZlIg0KPiAgICBh bmQgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93 aXJlcyBQVzINCj4gICAgYW5kIFBXNCB0byBQRTIgYW5kIFBFMSByZXNwZWN0aXZlbHkuIFRodXMg YnkgbWF0Y2hpbmcgdGhlIGxvY2FsIGFuZA0KPiAgICByZW1vdGUgcHJlZmVyZW50aWFsIGZvcndh cmRpbmcgc3RhdHVzIG9mICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAgICBzdGF0dXMgb2Yg IlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgb2YgcHNldWRvd2lyZXMsIHRoZSBQRSBub2Rlcw0KPiAg ICBkZXRlcm1pbmUgd2hpY2ggUFcgc2hvdWxkIGJlIGluIHRoZSBBY3RpdmUgc3RhdGUuIEluIHRo aXMgY2FzZSBpdCBpcw0KPiAgICBQVzQgdGhhdCB3aWxsIGJlIHNlbGVjdGVkLg0KPg0KPiAgICBP biBmYWlsdXJlIG9mIHRoZSBBQyBiZXR3ZWVuIENFMSBhbmQgUEUxLCB0aGUgZm9yd2FyZGluZyBz dGF0ZSBvZg0KPiAgICB0aGUgQUMgb24gUEUyIGlzIGNoYW5nZWQgdG8gQWN0aXZlLiBQRTIgdGhl biBhbm5vdW5jZXMgdGhlIG5ld2x5DQo+ICAgIGNoYW5nZWQgJ3ByZWZlcmVudGlhbCBmb3J3YXJk aW5nJyBzdGF0dXMgYml0IG9mICJhY3RpdmUiIHRvIFBFMyBhbmQNCj4gICAgUEU0LiBQRTEgd2ls bCBhZHZlcnRpc2UgYSBQVyBzdGF0dXMgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaW5kaWNhdGluZw0K PiAgICB0aGF0IHRoZSBBQyBiZXR3ZWVuIENFMSBhbmQgUEUxIGlzIG9wZXJhdGlvbmFsbHkgZG93 bi4gUEUyIGFuZCBQRTQNCj4gICAgbWF0Y2ggdGhlIGxvY2FsIGFuZCByZW1vdGUgcHJlZmVyZW50 aWFsIGZvcndhcmRpbmcgc3RhdHVzIG9mDQo+ICAgICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbCBz dGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgYW5kIHNlbGVjdA0KPiAgICBQVzIgYXMgdGhl IG5ldyBhY3RpdmUgcHNldWRvd2lyZSB0byBzZW5kIHRyYWZmaWMgdG8uDQo+DQo+ICAgIE9uIGZh aWx1cmUgb2YgUEUxIG5vZGUsIFBFMiB3aWxsIGRldGVjdCBpdCBhbmQgd2lsbCB0cmFuc2l0aW9u IHRoZQ0KPiAgICBmb3J3YXJkaW5nIHN0YXRlIG9mIGl0cyBBQyB0byBBY3RpdmUuIFRoZSBtZXRo b2QgYnkgd2hpY2ggUEUyDQo+ICAgIGRldGVjdHMgdGhhdCBQRTEgaXMgZG93biBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBQRTINCj4gICAgdGhlbiBhbm5vdW5jZXMgdGhl IG5ld2x5IGNoYW5nZWQgJ3ByZWZlcmVudGlhbCBmb3J3YXJkaW5nJyBzdGF0dXMNCj4gICAgYml0 IG9mICJBY3RpdmUiIHRvIFBFMyBhbmQgUEU0LiBQRTIgYW5kIFBFNCBtYXRjaCB0aGUgbG9jYWwg YW5kDQo+ICAgIHJlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2FyZGluZyBzdGF0dXMgb2YgIkFjdGl2 ZSIgYW5kIG9wZXJhdGlvbmFsDQo+ICAgIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBh bmQgc2VsZWN0IFBXMiBhcyB0aGUgbmV3IGFjdGl2ZQ0KPiAgICBwc2V1ZG93aXJlIHRvIHNlbmQg dHJhZmZpYyB0by4gTm90ZSB0aGF0IFBFMyBhbmQgUEU0IG1heSBoYXZlDQo+ICAgIGRldGVjdGVk IHRoYXQgdGhlIFBXIHRvIFBFMSB3ZW50IGRvd24gdmlhIFQtTERQIEhlbGxvIHRpbWVvdXQgb3Ig dmlhDQo+ICAgIG90aGVyIG1lYW5zLiBIb3dldmVyLCB0aGV5IHdpbGwgbm90IGJlIGFibGUgdG8g Zm9yd2FyZCB1c2VyIHRyYWZmaWMNCj4gICAgdW50aWwgdGhleSByZWNlaXZlZCB0aGUgdXBkYXRl ZCBzdGF0dXMgYml0IGZyb20gUEUyLg0KPg0KPiAgICBCZWNhdXNlIGVhY2ggZHVhbC1ob21pbmcg YWxnb3JpdGhtIHJ1bm5pbmcgb24gdGhlIHR3byBub2RlIHNldHMsDQo+ICAgIGkuZS4sIHtDRTEs IFBFMSwgUEUyfSBhbmQge0NFMiwgUEUzLCBQRTR9LCBzZWxlY3RzIHRoZSBhY3RpdmUgQUMNCj4g ICAgaW5kZXBlbmRlbnRseSwgdGhlcmUgaXMgYSBuZWVkIHRvIHNpZ25hbCB0aGUgYWN0aXZlIHN0 YXR1cyBvZiB0aGUgQUMNCj4gICAgc3VjaCB0aGF0IHRoZSBQRSBub2RlcyBjYW4gc2VsZWN0IGEg Y29tbW9uIGFjdGl2ZSBQVyBmb3IgZW5kLXRvLWVuZA0KPiAgICBmb3J3YXJkaW5nIGJldHdlZW4g Q0UxIGFuZCBDRTIgYXMgcGVyIHRoZSBwcm9jZWR1cmVzIGluIHRoZQ0KPiAgICBpbmRlcGVuZGVu dCBtb2RlLg0KPg0KPiAgICBOb3RlIHRoYXQgYW55IHByaW1hcnkvc2Vjb25kYXJ5IHByb2NlZHVy ZXMsIGFzIGRlZmluZWQgaW4gc2VjdGlvbnMNCj4gICAgNS4xLiAgYW5kIDUuMi4gLCBkbyBub3Qg YXBwbHkgaW4gdGhpcyB1c2UgY2FzZSBhcyB0aGUgQWN0aXZlL1N0YW5kYnkNCj4gICAgc3RhdHVz IGlzIGRyaXZlbiBieSB0aGUgQUMgZm9yd2FyZGluZyBzdGF0ZSBhcyBkZXRlcm1pbmVkIGJ5IHRo ZSBBQw0KPiAgICBkdWFsLWhvbWluZyBwcm90b2NvbCB1c2VkLg0KPg0KPg0KPiBJIGJlbGlldmUg eW91oa92ZSB0YWtlbiB5b3VyIKGwb3V0IG9mIHNjb3BlobEgcmVmZXJlbmNlIGZyb20gdGhpcyB0 ZXh0LA0KPiBidXQgSU1ITyB5b3UgbWlzaW50ZXJwcmV0ZWQgaXQuDQo+IFdoYXQgaXQgbWVhbnMg KG9yIHNvIEkgcmVhZCBpdCkgaXMgdGhhdCBzcGVjaWZpYyBkdWFsLWhvbWluZw0KPiBwcm90b2Nv bCBpcyBvdXQgb2Ygc2NvcGUgYXMgbG9uZyBhcyBpdCBtZWV0cyBjZXJ0YWluIGFzc3VtcHRpb25z Lg0KPiBBc2lkZTogSXQgd291bGQgYmUgZ29vZCBpZiB0aGUgYXV0aG9ycyBvZiB0aGUgUFcgcmVk dW5kYW5jeSBkcmFmdHMNCj4gY291bGQgZXhwbGljaXRseSBzcGVjaWZ5IHRoZXNlIGFzc3VtcHRp b25zLg0KPg0KPiBbW1tTYXNoYV1dXSChrSBzbmlwcGVkIKGtDQo+DQo+IE5vdyBsZXShr3MgdHVy biBvdXIgYXR0ZW50aW9uIGJhY2sgdG8gd2hldGhlciB0aGUgUFcgcmVkdW5kYW5jeQ0KPiBkcmFh ZnQgY2FuIGJlIHVzZWQgdG8gbWVldCBNUExTLVRQIFBXIHByb3RlY3Rpb24gcmVxdWlyZW1lbnRz LiBJIGNhbg0KPiBpZGVudGlmeSB0aGUgZm9sbG93aW5nIHJlYXNvbnMgd2h5IGluIGl0cyBjdXJy ZW50IGZvcm0gaXQgZG9lc26hr3Q6DQo+DQo+IC0gICAgICAgICAgSXQgZXhwbGljaXRseSAoobBv dXRzaWRlIHRoZSBzY29wZaGxKSBkb2VzIG5vdCBkZWZpbmUNCj4gcHJvdGVjdGlvbiB0cmlnZ2Vy cyBhbmQgaG93IHRvIGhhbmRsZSBjb2V4aXN0aW5nIHRyaWdnZXJzLCBhcw0KPiByZXF1ZXN0ZWQg aW4gUkZDIDU2NTQgKE1QTFMtVFAgUmVxdWlyZW1lbnRzKSwgcmVxcyAjNzUsICM3NiBhbmQgIzc5 DQo+IFtbW1Nhc2hhXV1dIFNvIHdoYXQ/IERlZmluaXRpb24gb2YgdHJpZ2dlcnMgaXMgb3J0aG9n b25hbCB0byBob3cNCj4gY29vcmRpbmF0ZWQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaGFwcGVucy4N Cj4gW0RDXSBJdCBpcy4gQnV0IHN0aWxsIGl0IG5lZWRzIHRvIGJlIGRlZmluZWQgYnkgdGhlIHJl Y292ZXJ5DQo+IGZyYW1ld29yaywgZS5nLiB3aGF0IHNob3VsZCB0aGUgZW5kcG9pbnQgZG8gd2hl biBvbmUgUFcgaXMgaW4gU0YgYW5kDQo+IHRoZSBvdGhlciBpcyBpbiBTRCwgb3Igd2hlbiBib3Ro IGFyZSBpbiBTRC4gT3BlcmF0b3JzIGV4cGVjdCB3ZWxsLQ0KPiBkZWZpbmVkIGJlaGF2aW9yIGlu IHRoZXNlIGFuZCBvdGhlciBzY2VuYXJpb3MsIGFuZCBQVyByZWR1bmRhbmN5DQo+IGRvZXMgbm90 IGRlZmluZSB0aGVtIChiZWNhdXNlIGl0IHdhcyBub3QgaW4gdGhlaXIgc2NvcGUpLg0KPiBbW1tT YXNoYV1dXSBJIHdvbmRlciBpZiB5b3UgaGF2ZSBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lvbiByZWdh cmRpbmcNCj4gYWJpbGl0eSB0byBkZWZpbmUgU0QgY29uZGl0aW9uIGZvciBMU1BzIGFuZCBQV3Mg b24gdGhlIE1QTFMtVFAgbGlzdD8NCj4gSU1PIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBkZWZpbmUg aXQgaW4gYSBtZWFuaW5nZnVsIHdheS4gSGVuY2UgSSBkbw0KPiBub3Qgc2VlIGEgcHJvcG9zYWwg dGhhdCBkb2VzIG5vdCBhZGRyZXNzIGEgc2NlbmFyaW8gdGhhdCBkb2VzIG5vdA0KPiBleGlzdCBp biByZWFsaXR5IGFzIGEgZmxhd2VkIG9uZS4NCj4NCj4gLSAgICAgICAgICBJdCBkb2VzIG5vdCBz dXBwb3J0IHRoZSBhYmlsaXR5IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4NCj4gZGlmZmVyZW50IHR5 cGVzIG9mIHRyaWdnZXJzIChpLmUuIG9uZSBlbmQgZG9lc26hr3Qga25vdyB3aHkgdGhlIG90aGVy DQo+IGVuZCB0cmlnZ2VyZWQgc3dpdGNoKSwgYXMgcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExT LVRQDQo+IFJlcXVpcmVtZW50cyksIHJlcSAjNzcNCj4gLSAgICAgICAgICBJdCBkb2VzIG5vdCBk ZWZpbmUgcmV2ZXJ0aXZlL25vbnJldmVydGl2ZSBiZWhhdmlvciwgYXMNCj4gcmVxdWVzdGVkIGlu IFJGQyA1NjU0IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjQNCj4gLSAgICAgICAgICBJ dCBkb2VzIG5vdCBkZWZpbmUgaG9sZG9mZiBzdXBwb3J0LCB3aGljaCBpcyBlc3BlY2lhbGx5DQo+ IGltcG9ydGFudCB0byBhdm9pZCByYWNlIGNvbmRpdGlvbnMgd2l0aCBMU1AgcHJvdGVjdGlvbiB3 aGVuIGl0IGV4aXN0cw0KPiAtICAgICAgICAgIEl0IGRvZXNuoa90IHN1cHBvcnQgMSsxIG1vZGUs IGFzIHJlcXVlc3RlZCBpbiBSRkMgNTY1NA0KPiAoTVBMUy1UUCBSZXF1aXJlbWVudHMpLCByZXEg IzY1DQo+IFtbW1Nhc2hhXV1dIEFsbCB0aGVzZSBjbGFpbXMgYXJlIGNvcnJlY3QgqEMgYW5kICB0 aGlzIHNob3VsZCBub3QgYmUgYQ0KPiBzdXJwcmlzZSwgYmVjYXVzZSBNUExTLVRQIHJlcXVpcmVt ZW50cyBoYXZlIGJlZW4gZGVmaW5lZCBtdWNoIGxhdGVyDQo+IHRoYW4gdGhlIFBXIHJlZHVuZGFu Y3kgbWVjaGFuaXNtLg0KPiBCdXQgSSBkbyBub3QgdGhpbmsgdGhhdCB0aGlzIGp1c3RpZmllcyBj by1leGlzdGVuY2Ugb2YgdHdvIGRpZmZlcmVudA0KPiBtZWNoYW5pc21zLg0KPiBbRENdIFNvIGhv dyBkbyB5b3UgcHJvcG9zZSB0byBtZWV0IHRoZSBQVyBwcm90ZWN0aW9uIHJlcXVpcmVtZW50Pw0K PiAtICAgICAgICAgIEl0oa9zIGEgdHdvLXBoYXNlIHByb3RvY29sLCB3aXRoIHRoZSBjb25zZXF1 ZW50IGltcGFjdCBvbiB0aW1pbmcNCj4gW1tbU2FzaGFdXV0gQ291bGQgeW91IHBsZWFzZSBlbGFi b3JhdGU/IFtEQ10gSW4gZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPiBsaW5lYXItcHJvdGVjdGlvbiwg ZWFjaCBlbmRwb2ludCB3aWxsIGltbWVkaWF0ZWx5IHN3aXRjaCB0cmFmZmljIHRvDQo+IHRoZSBv dGhlciBwYXRoIHVwb24gaWRlbnRpZnlpbmcgYW4gU0YgY29uZGl0aW9uIGluIGEgcGF0aCwgd2l0 aG91dA0KPiB3YWl0aW5nIGZvciB0aGUgZmFyIGVuZCB0byBhY2tub3dsZWRnZSB0aGUgc3dpdGNo ICgxLXBoYXNlKS4gSW4gUFcNCj4gcmVkdW5kYW5jeSwgYW4gZW5kcG9pbnQgZGV0ZWN0aW5nIGFu IFNGIGNvbmRpdGlvbiBpbiBhIHBhdGggd2lsbCBub3QNCj4gc3dpdGNoIHVudGlsIHRoZSBmYXIg ZW5kIGhhcyBhY2tub3dsZWRnZWQgdGhlIHN3aXRjaCAoMi1waGFzZSkuDQo+IE5lZWRsZXNzIHRv IHNheSwgcmVjb3ZlcnkgaXMgc2xvd2VyIGluIGEgMi1waGFzZSBwcm90b2NvbC4NCj4gW1tbU2Fz aGFdXV0gVG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgMS1waGFzZSBwcm90ZWN0aW9u IGlzDQo+IG9ubHkgcG9zc2libGUgaW4gMSsxIHVuaWRpcmVjdGlvbmFsIGFyY2hpdGVjdHVyZXMu IEFuZCB5ZXMsIEkga25vdw0KPiB0aGF0IE1QTFMtVFAgcmVxdWlyZXMgYSAgbWVjaGFuaXNtIHRv IHN1cHBvcnQgdGhpczsgd2hldGhlciBhbnlib2R5DQo+IHdvdWxkIHJlYWxseSBkbyB0aGF0IGlu IHRoZSBwYWNrZXQtc3dpdGNoaW5nIG5ldHdvcmsgaXMgbm90IGNsZWFyIHRvDQo+IG1lLiBBbmQg SSBhY2tub3dsZWRnZSB0aGF0IHRoZSBQVyByZWR1bmRhbmN5IGRyYWZ0cyBkbyBub3Qgc3VwcG9y dA0KPiAxKzEgdW5pZGlyZWN0aW9uYWwgc2NoZW1lLg0KPg0KPiAtICAgICAgICAgIEl0IGRvZXNu oa90IGRlZmluZSByZXRyYW5zbWlzc2lvbiBvZiBwcm90ZWN0aW9uDQo+IGNvb3JkaW5hdGlvbiBt ZXNzYWdlcywgc28gbG9zcyBvZiBhIHNpbmdsZSBQRFUgY2FuIHJlc3VsdCBpbg0KPiBzd2l0Y2hv dmVyIG5vdCB0YWtpbmcgcGxhY2UsIHRodXMgbm90IHN1cHBvcnRpbmcgc3ViLTUwIG1zIHJlY292 ZXJ5DQo+IGluIHRoaXMgY2FzZQ0KPiBbW1tTYXNoYV1dXSBUaGUgUFcgcmVkdW5kYW5jeSBwcm90 b2NvbCBydW5zIGVpdGhlciBvbiB0b3Agb2YgTERQDQo+ICh3aGljaCBiZW5lZml0cyBmcm9tIFRD UCByZXRyYW5zbWlzc2lvbnMpIG9yIG9uIHRvcCBvZiBzdGF0aWMgUFcNCj4gc3RhdHVzIG1lc3Nh Z2VzICh3aGVyZSByZXRyYW5zbWlzc2lvbiBpcyBkZWZpbmVkKS4NCj4gW0RDXSBUcnVlIKhDIGJ1 dCBzdGF0aWMgUFcgc3RhdHVzIGRlZmluZXMgc2xvdyByZXRyYW5zbWlzc2lvbiAoobB3aWxsDQo+ IGJlIHRyYW5zbWl0dGVkIHR3aWNlIGF0IGFuIGluaXRpYWwgaW50ZXJ2YWwgb2Ygb25lIHNlY29u ZKGxKSB3aGlsZQ0KPiBkcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24gc3BlY2lm aWVzIGZhc3QgcmV0cmFuc21pc3Npb24NCj4gd2hlbiByZXF1aXJlZCBmb3IgZmFzdCByZWNvdmVy eSAoc2VjdGlvbiAzLjEuNCkuDQo+DQo+IEluIHN1bW1hcnksIFBXIHJlZHVuZGFuY3kgd2FzIG5v dCBkZXNpZ25lZCB3aXRoIFRQIHJlcXVpcmVtZW50cyBpbg0KPiBtaW5kLCBhbmQgYXMgc3VjaCBk b2VzIG5vdCBtZWV0IHRoZSBUUCByZXF1aXJlbWVudHMuIE9mIGNvdXJzZQ0KPiBtb2RpZmljYXRp b25zIG1heSBiZSBpbnRyb2R1Y2VkLCBidXQgd2h5IHJlaW52ZW50IHRoZSB3aGVlbCB3aGVuDQo+ IHRoZXJlIGlzIGEgcHJvdG9jb2wgKGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlv bi0wNikgaW4gdGhlDQo+IHN0YW5kYXJkcyB0cmFjayB0aGF0IHN1cHBvcnRzIGFsbCB0aGUgYWJv dmUgcmVxdWlyZW1lbnRzIGFuZCBjYW4gYmUNCj4gYXBwbGllZCB0byBNUy1QVyBwcm90ZWN0aW9u IHdpdGggbWlub3IgbW9kaWZpY2F0aW9ucz8NCj4gW1tbU2FzaGFdXV0gQXMgSSBzYWlkLCBiZWNh dXNlIHRoZSBhcHBsaWNhYmlsaXR5IHNjb3BlIGlzIGJ5IGZhciB0b28NCj4gbmFycm93IHRvIGp1 c3RpZnkgYSBkZWRpY2F0ZWQgcHJvdG9jb2wuDQo+IFtEQ10gSWYgd2Ugd2VyZSBkaXNjdXNzaW5n IGRlc2lnbmluZyBhIG5ldyBwcm90b2NvbCwgSSBtaWdodCBhZ3JlZQ0KPiB3aXRoIHlvdS4gQnV0 IGZyb20gYSBwcmFjdGljYWwgc3RhbmRwb2ludCwgdGhlIFBXIHByb3RlY3Rpb24gZHJhZnQNCj4g aXMgbm90IGEgZGVkaWNhdGVkIHByb3RvY29sIKhDIGl0oa9zIGFuIGFwcGxpY2FiaWxpdHkgc3Rh dGVtZW50IHRvIGFuDQo+IGV4aXN0aW5nIHByb3RvY29sLiBCb3RoIGZyb20gdGhlIGltcGxlbWVu dGF0aW9uIGFuZCB0aGUgb3BlcmF0aW9uYWwNCj4gcG9pbnQgb2YgdmlldyBpdCBkZWZpbmVzIGEg bmV3IHVzZSBjYXNlIGZvciBhbiBleGlzdGluZyBwcm90b2NvbCBhbmQgY29uY2VwdC4NCj4NCj4N Cj4gUmVnYXJkcywNCj4NCj4gRGFuaWVsDQo+DQo+DQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFNwcmVj aGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKQ0KPiBTZW50OiBNb25kYXksIEp1bmUg MTMsIDIwMTEgNDowMiBQTQ0KPiBUbzogZXh0IEFsZXhhbmRlciBWYWluc2h0ZWluOyBtYS55dXhp YUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBU UExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gSGksDQo+IEkg d291bGQgbGlrZSB0byBzZWNvbmQgU2FzaGEuDQo+IEVuZC10by1lbmQgUFcgcHJvdGVjdGlvbiAo d2l0aCBkaXZlcnNlIHBhdGhzKSBkb2VzIG5vdCBzY2FsZSwgYW5kDQo+IHB1dCBoYXJkIHJlc3Ry aWN0aW9ucyBvbiB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIHJlc291cmNlcy4NCj4gTVBMUy1UUCBQ V3MgYXJlIGNhcnJpZWQgYWNyb3NzIHRoZSBuZXR3b3JrIGluc2lkZSBNUExTLVRQIExTUHMuDQo+ IFRoZXJlZm9yZSwgYW4gb2J2aW91cyB3YXkgdG8gcHJvdmlkZSBwcm90ZWN0aW9uIGZvciBhIFBX IGlzIHRvDQo+IHByb3RlY3QgdGhlIExTUCB0aGF0IGNhcnJpZXMgaXQuDQo+IElmIHRoZSBQVyBp cyBhIG11bHRpLXNlZ21lbnQgUFcsIHRoZW4gTFNQIHJlY292ZXJ5IGNhbiBvbmx5IHByb3RlY3QN Cj4gdGhlIFBXIGluIGluZGl2aWR1YWwgc2VnbWVudHMuICBUaGlzIG1lYW5zIHRoYXQgYSBzaW5n bGUgTFNQDQo+IHJlY292ZXJ5IGFjdGlvbiBjYW5ub3QgcHJvdGVjdCBhZ2FpbnN0IGEgZmFpbHVy ZSBvZiBhIFBXIHN3aXRjaGluZw0KPiBwb2ludCAoYW4gUy1QRSkuDQo+IFdoZW4gcHJvdGVjdGlu ZyBhZ2FpbnN0IGFuIEFDIG9yIFQvUy1QRSBmYWlsdXJlIGJ5IGR1YWwNCj4gY29ubmVjdGl2aXR5 LCBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgcHJvdmlkZSBtZWFucyBmb3IgdGhlIFBFcyB0bw0K PiBjb29yZGluYXRlIG92ZXIgd2hpY2ggTFNQIHRoZSB0cmFmZmljIG9mIHRoZSBQVyBpcyBjYXJy aWVkLg0KPiBJIGFsc28gZG91YnQgd2h5IHRoZXJlIGlzIGEgbmVlZCBmb3IgYWRkaXRpb25hbCBt ZWNoYW5pc20uDQo+IEJlc3QgcmVnYXJkcywNCj4gTnVyaXQNCj4NCj4gRnJvbTogcHdlMy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cj4gZXh0IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAx MSAzOjQzIFBNDQo+IFRvOiBtYS55dXhpYUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3Jn OyBwd2UzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUFdFM10gW21wbHNdIFNlZWtpbmcgZmVl ZGJhY2sgb24gSS1EICJNUExTLVRQDQo+IExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0 byBNUy1QVyINCj4NCj4gRGVhciBNYSBhbmQgYWxsLA0KPiBBZGRpbmcgdGhlIFBXRTMgV0cgdG8g bXkgcmVzcG9uc2UuDQo+DQo+IFRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbSBzdXBwb3J0cyBs aW5lYXIgcHJvdGVjdGlvbiBvZiBNUy1QV3MgYXMNCj4gb25lIG9mIG1hbnkgYWRkaXRpb25hbCBh cHBsaWNhdGlvbiB1c2UgY2FzZXM6DQo+IEFwcGVuZGl4IEEgb2YgdGhlIFBXIHJlZHVuZGFuY3kg Qml0IGRyYWZ0IGRlc2NyaWJlcyA1IGFwcGxpY2F0aW9uDQo+IHVzZXMgY2FzZXMgaW4gYWRkaXRp b24gdG8gTVMtUFcgd2l0aCBzaW5nbGUtaG9tZWQgQ0VzICh3aGljaCBpcw0KPiBsaXN0ZWQgdGhl cmUgYXMgdXNlIGNhc2UgNSkuDQo+IEFuZCBpdCBpcyBlcXVhbGx5IGFwcGxpY2FibGUgdG8gSVAv TVBMUyBhbmQgTVBMUyAtIHdpdGggdGhlIGhlbHAgb2YgIHRoZQ0KPiBTdGF0aWMgUFcgU3RhdHVz IE1lc3NhZ2VzIGRyYWZ0KCBpZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgeW91IGRvIG5vdA0KPiB3 YW50ICB0bywgb3IgY2Fubm90LCB1c2UgUkZDIDQ0NDcpLg0KPg0KPiBIZW5jZSBJIGRvdWJ0IHRo ZSBuZWVkIGZvciB5ZXQgYW5vdGhlciBQVyByZWR1bmRhbmN5ICBtZWNoYW5pc20gd2l0aA0KPiBu YXJyb3cgc2NvcGUgb2YgYXBwbGljYWJpbGl0eS4NCj4NCj4gUmVnYXJkcywNCj4gICAgICBTYXNo YQ0KPg0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBtYS55dXhpYUB6dGUuY29tLmNuDQo+IFNlbnQ6IE1v bmRheSwgSnVuZSAxMywgMjAxMSAzOjI1IFBNDQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFAgTGluZWFyDQo+ IFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gSGkgYWxsLA0KPg0KPiBU aGUgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGZvciBMU1AgYW5kIFBXKGluY2x1ZGluZyBN Uy1QVykNCj4gc2hvdWxkIGJlIHRoZSBzYW1lIGFuZCBpdCBpcyB2YWx1YWJsZSB0byBkZXNjcmli ZSBpdCBjbGVhcmx5Lg0KPg0KPiBCVFcsIHRoZXJlIGlzIGEgdHlwbywgaXQgaXMgIlQtUEUgWiIg aW5zdGVhZCBvZiAiVC1QRSBCIi4NCj4NCj4gICINCj4gICBGaWd1cmUgMSBpbGx1c3RyYXRlcyBz dWNoIGEgc2NlbmFyaW8sIHdoZXJlIHR3byBNUy1QV3MgYXJlDQo+ICAgZXN0YWJsaXNoZWQgYmV0 d2VlbiBULVBFIEEgYW5kIFQtUEUgQiwgb3ZlciBTLVBFcyAxLTIgYW5kIDMtNA0KPiAgIHJlc3Bl Y3RpdmVseS4gRWFjaCBQVyBzZWdtZW50IGlzIGVzdGFibGlzaGVkIG92ZXIgYW4gTFNQIChlLmcu IFBXLQ0KPiAgIHMxMiBvdmVyIExTUDEyKS4NCj4gICINCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogRGFuaWVsIENvaG4NCj4gU2VudDogVHVlc2RheSwgTWF5IDE3LCAyMDEx IDQ6MTQgUE0NCj4gVG86IG1wbHMNCj4gU3ViamVjdDogU2Vla2luZyBmZWVkYmFjayBvbiBJLUQg Ik1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24NCj4gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4g SW1wb3J0YW5jZTogSGlnaA0KPg0KPiBIaSBNUExTZXJzLA0KPg0KPiBJIHVwbG9hZGVkICJNUExT LVRQIExpbmVhciBQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciIEktRA0KPiAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29obi1tcGxzLXRwLXB3LXByb3RlY3Rpb24t MDApDQo+DQo+IFRoZSBhYnN0cmFjdCBnb2VzOg0KPg0KPiBPbmUgb2YgdGhlIHJlcXVpcmVtZW50 cyBvZiB0aGUgTVBMUyB0cmFuc3BvcnQgcHJvZmlsZSBbUkZDIDU2NTRdIGlzDQo+IHRvIHByb3Zp ZGUgbGluZWFyIHByb3RlY3Rpb24gZm9yIHRyYW5zcG9ydCBwYXRocywgd2hpY2ggaW5jbHVkZSBi b3RoDQo+IExTUHMgYW5kIFBXcy4gVGhlIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIGRlc2NyaWJl ZCBpbiBbU3Vydml2RndrXQ0KPiBpcyBhcHBsaWNhYmxlIHRvIGJvdGggTFNQIGFuZCBQV3MsIGhv d2V2ZXIgW0xpbmVhclByb3RdIGRvZXMgbm90DQo+IGV4cGxpY2l0bHkgZGVzY3JpYmUgbWVjaGFu aXNtcyBmb3IgUFcgcHJvdGVjdGlvbiBpbiBNUExTLVRQLg0KPg0KPiBUaGlzIGRvY3VtZW50IGV4 dGVuZHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGxpbmVhciBwcm90ZWN0aW9uDQo+IG1lY2hh bmlzbSBkZXNjcmliZWQgaW4gW0xpbmVhclByb3RdIHRvIE1QTFMtVFAgc2VnbWVudGVkIFBXcw0K PiAoTVMtUFdzKSBhcyBkZWZpbmVkIGluIFtSRkMgNjA3M10uDQo+DQo+IENvdWxkIHlvdSBwbGVh c2UgcmV2aWV3IGl0IGFuZCBzZW5kIGZlZWRiYWNrIHRvIHRoZSBtYWlsaW5nIGxpc3Qgb3INCj4g ZGlyZWN0bHkgdG8gdGhlIGF1dGhvcj8NCj4NCj4gTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgZmVl ZGJhY2ssDQo+DQo+IERhbmllbA0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZv ciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlz IENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo+IEVDSSBUZWxl Y29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQNCj4gYWxsIGNvcGllcyB0aGVyZW9mLg0KPiBUaGlzIGUtbWFpbCBt ZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+ IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3By aWV0YXJ5IHRvDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQNCj4gYWxsIGNvcGllcyB0aGVy ZW9mLg0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50 IG9ubHkgYW5kIGNvbnRhaW5zDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBh bmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1 cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQNCj4gYWxsIGNvcGllcyB0aGVyZW9mLiCpbXq52j8/YnI+DQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KDQpUaGlzIGUtbWFp bCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5z IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3By aWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwg YW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KDQpR dWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVz aXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1 YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3Rl IGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRl IHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUg cHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRp IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KcmlzcGV0dGEgbCdhbWJpZW50ZVJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVj ZXNzYXJpby4NCg0KDQo= From Hanzheng.Zhang@alcatel-sbell.com.cn Fri Jun 24 03:16:50 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 DBF2C21F84CC for ; Fri, 24 Jun 2011 03:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 LOONDh5R+N+y for ; Fri, 24 Jun 2011 03:16:50 -0700 (PDT) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 993A121F84BD for ; Fri, 24 Jun 2011 03:16:49 -0700 (PDT) X-AuditID: ac189297-b7bfeae000004d20-ce-4e04640e7278 Received: from cnshgsbhs02.ad4.ad.alcatel.com (Unknown_Domain [172.24.146.147]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id D4.39.19744.E04640E4; Fri, 24 Jun 2011 18:16:46 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 18:16:46 +0800 Received: from 172.24.146.162 ([172.24.146.162]) by CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.181]) with Microsoft Exchange Server HTTP-DAV ; Fri, 24 Jun 2011 10:16:46 +0000 Message-ID: <3B9B6C21-19B8-42F8-AE55-41F4DD8457B6@alcatel-sbell.com.cn> From: "ZHANG Hanzheng" To: thread-topic: Xadgsfxf. Ghjnn thread-index: AcwyV9IsDhYIxpLSS22EP9GplOQp/A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPad Mail 7B500) Date: Fri, 24 Jun 2011 16:39:02 +0800 X-OriginalArrivalTime: 24 Jun 2011 10:16:46.0757 (UTC) FILETIME=[D2D43D50:01CC3257] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Subject: [mpls] Xadgsfxf. Ghjnn 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, 24 Jun 2011 10:16:51 -0000 Ghjhjhhjkjljkb. N. H Best Regards William From loa@pi.nu Fri Jun 24 09:00: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 7CDE611E8096 for ; Fri, 24 Jun 2011 09:00:46 -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 Yp88B8IF8GaN for ; Fri, 24 Jun 2011 09:00:45 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 90C419E8004 for ; Fri, 24 Jun 2011 09:00:45 -0700 (PDT) Received: from [109.58.85.109] (109.58.85.109.bredband.tre.se [109.58.85.109]) (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 D4033514044; Fri, 24 Jun 2011 18:00:43 +0200 (CEST) Message-ID: <4E04B4A7.4010106@pi.nu> Date: Fri, 24 Jun 2011 18:00:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team References: <4DF89286.4050103@pi.nu> In-Reply-To: <4DF89286.4050103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: [mpls] Callclosed - Re: verification call on draft-ietf-mpls-tp-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: Fri, 24 Jun 2011 16:00:46 -0000 Working Group, this verification call has ended! The working group chairs has discussed how to proceed with this draft. We have noted the concerns about ICC representation and usage. In view of this we have decided split the document and leave work on ICC to a future document. The authors should update the document according to this decision and as necessary after the verification and re-publish the draft. /Loa for the wg co-chairs On 2011-06-15 13:07, Loa Andersson wrote: > Working Group, > > the authors of draft-ietf-mpls-tp-identifiers has updated > the draft after working group last call and published version -05 > of the document, that will be found at: > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ > > A detailed list of how the wg lc comments has been addressed is > found at: > > http://www.pi.nu/~loa/identifiers-resolution.xls > > This is to start a one week call to verify that the comments been > correctly addressed. Please send your comments to the mpls working > group mailing-list eob June 23 2011. > > /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 From tnadeau@lucidvision.com Fri Jun 24 12:48:01 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 3265611E80A7; Fri, 24 Jun 2011 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, 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 32cF4ybUuZ2X; Fri, 24 Jun 2011 12:48:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3322211E80A3; Fri, 24 Jun 2011 12:48:00 -0700 (PDT) Received: from [10.100.69.31] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id E8AD71C054F4; Fri, 24 Jun 2011 15:47:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--74804653 From: Thomas Nadeau In-Reply-To: Date: Fri, 24 Jun 2011 15:47:56 -0400 Message-Id: <878D233B-D3BA-4A3A-8E2A-314C171F10D9@lucidvision.com> References: To: Greg Mirsky X-Mailer: Apple Mail (2.1084) Cc: pwe3 , mpls@ietf.org Subject: Re: [mpls] Comments to draft-nadeau-pwe3-vccv-2-01 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, 24 Jun 2011 19:48:01 -0000 --Apple-Mail-3--74804653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg, =20 On Jun 9, 2011, at 5:58 PM, Greg Mirsky wrote: > Dear Authors, > perhaps I've missed your response and I've decided to re-post. Apologies for the delay in responding. =20 >=20 > Regards, > Greg >=20 > On Fri, Mar 11, 2011 at 2:26 PM, Greg Mirsky = wrote: > Dear Authors, > please find my comments below. > this proposal is closely related to changes to RFC 5586 put forward in = draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the = draft. TOM: Cool. We can add that as a requirement. > RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains = that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS = netowrks GAL might be not a BoS. In your proposal the GAL precedes the = PW and thus is not BoS. But the document's scope is for all MPLS PWs, = including over MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In = MPLS-TP (GAL) ... MUST always be at the bottom of the label stack (i.e., = S bit set to 1)" updated proposed use of GAL is allowed only in non-TP = MPLS PSN. TOM: That was a typo. We've swapped the GAL and PW labels in = version -02. > Section 2 lists of allowed ACH. Since these are hexadecimal numbers = I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". = And I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or = "MUST" be limited to ... A, B, C"? TOM: We copied the format of the base VCCV RFC, but I can update = this way if no one else objects. > In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and = to appropriate value in MS-PW to reach intended PE. Hence my question, = Is this mechanism to reach MIP, i.e. S-PE, or this is mechanism to = generate exception? But that is how PW VCCV Control Channel Type 3 = works. TOM: We added those restrictions so that the protocol behaved = properly for SS and MH PWs. > What is the interpretation of GAL in a label stack? To indicate PW CW = after the PW LSE? TOM: Do you mean the interpretation of the GAL in the label = stack as defined in the draft, or in general? > editorial - in Abstract s/The MPLS/the MPLS or a reference to, = perhaps, RFC 5654. TOM: Will add to version -03 with the other changes above. --Tom >=20 > Regards, > Greg >=20 >=20 >=20 >=20 >=20 --Apple-Mail-3--74804653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Greg,
             

            On Jun 9, 2011, = at 5:58 PM, Greg Mirsky wrote:

            Dear = Authors,
            perhaps I've missed your response and I've decided to = re-post.


            Apologies = for the delay in responding.  


            Regards,
            Greg

            On = Fri, Mar 11, 2011 at 2:26 PM, Greg Mirsky <gregimirsky@gmail.com>= wrote:
            Dear = Authors,
            please find my comments below.
            • this proposal is = closely related to changes to RFC 5586 put forward in = draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the = draft.

            TOM: = Cool. We can add that as a requirement.
            • RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains = that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS = netowrks GAL might be not a BoS. In your proposal the GAL precedes the = PW and thus is not BoS. But the document's scope is for all MPLS PWs, = including over MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In = MPLS-TP (GAL) ... MUST always be at the bottom of the label stack = (i.e., S bit set to 1)" updated proposed use of GAL is allowed only in = non-TP MPLS PSN.
            TOM: That = was a typo. We've swapped the GAL and PW labels in version = -02.
            • Section 2 lists of allowed ACH. Since these are hexadecimal numbers = I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". = And I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or = "MUST" be limited to ... A, B, = C"?
            TOM: We = copied the format of the base VCCV RFC, but I can update this way if no = one else objects.
            • In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW = and to appropriate value in MS-PW to reach intended PE. Hence my = question, Is this mechanism to reach MIP, i.e. S-PE, or this is = mechanism to generate exception? But that is how PW VCCV Control Channel = Type 3 works.
            TOM: We = added those restrictions so that the protocol behaved properly for SS = and MH PWs.
            • What is = the interpretation of GAL in a label stack? To indicate PW CW after the = PW LSE?
            TOM: Do = you mean the interpretation of the GAL in the label stack as defined in = the draft, or in general?
            • editorial - in Abstract s/The MPLS/the MPLS or a reference to, = perhaps, RFC 5654.
            TOM: Will = add to version -03 with the other changes = above.

            = --Tom



            Regards,
            Greg





            = --Apple-Mail-3--74804653-- From eric.gray@ericsson.com Fri Jun 24 13:41: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 B83F211E8073 for ; Fri, 24 Jun 2011 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 pAL4KczAaXKt for ; Fri, 24 Jun 2011 13:41:19 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0611E8072 for ; Fri, 24 Jun 2011 13:41:19 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5OKfGhj029627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jun 2011 15:41:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 24 Jun 2011 16:41:16 -0400 From: Eric Gray To: Rolf Winter , "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Date: Fri, 24 Jun 2011 16:41:14 -0400 Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYA= Message-ID: References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> 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: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 24 Jun 2011 20:41:20 -0000 Rolf, See lines beginning with "EG >" below... -- Eric=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rol= f Winter Sent: Thursday, June 23, 2011 4:01 PM To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Hi, some comments/questions: In section 3.3. you say: "The On-demand CV payload MUST directly follow the= ACH header (and any ACH TLVs)" but the document does not allow ACH TLVs as= per the IANA section. EG > WE can remove the parenthetic phrase. I don't think this EG > was identified in last call, and this period is not meant EG > to be an extension of last call. Strictly speaking this EG > parenthetical statement is not incorrect (it is, however, EG > not useful either). The static LSP target FEC stack sub-TLVs is 22 not 24 octets long I believe= and the PW one 32 (table section 2.3). EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, EG > even if the last two octets "Must be Zero"). The length of EG > the Static Pseudowire Sub-TLV - on the other hand - was made EG > longer by the addition of the 2-word AGI. Nice catch! Can we live without any ICC-based IDs in the draft to function in all envir= onments? EG > Apparently. Which return code to send when identifiers are wrong (Malformed echo reques= t received?) or drop the packet. EG > Drop the packet, probably log the error, possibly run off EG > screaming into the night. What does one do when one gets EG > something either not recognizably intended for one, or not EG > from a source that one recognizes? From a security point EG > of view, we cannot require an implementation to reply to EG > the requester in this case (this is an attack vector for EG > all kinds of hate and discontent). Nor can we forbid it. Using the per-interface model and say the DSMAP TLV did not match the ingre= ss IF identifier, then should this request frame be dropped? Should we repl= y to the requestor? Can this way two answers be generated? Nit (section 2.1): s/mpls/MPLS/ EG > Thanks. 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 > Loa Andersson > Sent: Donnerstag, 16. Juni 2011 22:01 > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; Ross > Callon; George Swallow; MPLS-TP ad hoc team > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv >=20 > Working Group. >=20 > 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. >=20 > A document detailing how the comments have been addressed will be > found at: > http://www.pi.nu/~loa/comments-on-03.xls >=20 > 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. >=20 > Loa > on behalf of the MPLS wg co-chairs >=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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sat Jun 25 01:18: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 6162D21F8499 for ; Sat, 25 Jun 2011 01:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 lVGPsdlT-bK5 for ; Sat, 25 Jun 2011 01:18:15 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 52F1B21F8498 for ; Sat, 25 Jun 2011 01:18:15 -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 AC5E8514044; Sat, 25 Jun 2011 10:18:12 +0200 (CEST) Message-ID: <4E0599AD.2070809@pi.nu> Date: Sat, 25 Jun 2011 10:17:49 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" , Ross Callon , George Swallow , MPLS-TP ad hoc team References: <4DFA60E3.90807@pi.nu> In-Reply-To: <4DFA60E3.90807@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closing verification call: Re: Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 25 Jun 2011 08:18:16 -0000 Working Group, this verification call has ended, there has been a few comments, could the authors please evaluate the comments and take the actions required. /Loa On 2011-06-16 22:00, 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 From internet-drafts@ietf.org Sun Jun 26 10:32: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 BDE079E8012; Sun, 26 Jun 2011 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 rcgc+8gMr2GX; Sun, 26 Jun 2011 10:32:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453A99E800B; Sun, 26 Jun 2011 10:32:20 -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.55 Message-ID: <20110626173220.11299.8956.idtracker@ietfa.amsl.com> Date: Sun, 26 Jun 2011 10:32:20 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08.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: Sun, 26 Jun 2011 17:32: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 : 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-08.txt Pages : 11 Date : 2011-06-26 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-08.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-08.txt From internet-drafts@ietf.org Sun Jun 26 16:29: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 BB39B11E8078; Sun, 26 Jun 2011 16:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=0.928, 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 W28w2tuO8m17; Sun, 26 Jun 2011 16:29:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1E6228013; Sun, 26 Jun 2011 16:29:45 -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.55 Message-ID: <20110626232945.3137.71184.idtracker@ietfa.amsl.com> Date: Sun, 26 Jun 2011 16:29:45 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-identifiers-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: Sun, 26 Jun 2011 23:29:45 -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 Identifiers Author(s) : Matthew Bocci George Swallow Eric Gray Filename : draft-ietf-mpls-tp-identifiers-06.txt Pages : 17 Date : 2011-06-26 This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and OAM functions suitable to IP/MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (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-identifiers-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-identifiers-06.txt From N.Leymann@telekom.de Mon Jun 27 00:41:32 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 8DDC111E8081; Mon, 27 Jun 2011 00:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 xOsAsym8w7Qd; Mon, 27 Jun 2011 00:41:32 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1911E8086; Mon, 27 Jun 2011 00:41:31 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jun 2011 09:41:14 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.228]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Mon, 27 Jun 2011 09:41:14 +0200 From: To: , Date: Mon, 27 Jun 2011 09:41:13 +0200 Thread-Topic: LDP DoD and PW Signalling ... Thread-Index: Acw0nZayI9OcF0gpR7qbFZfRRe6WPg== Message-ID: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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: Mon, 27 Jun 2011 07:41:32 -0000 Hi, We came across an issue related to the Seamless MPLS Architecture when runn= ing LDP DoD between two nodes if we are trying to set up an PW between the = same nodes. Assume we have an Access Node (AN) and an Aggregation Mode (AG). The AN est= ablishes a LDP DoD with the AG. When we are going to establish a PW between= the AN and the AG as well we run into the problem that RFC4447 specifies o= nly the DU mode for the targeted LDP session (section 3): "An LDP session must be set up between the pseudowire endpoints. LDP MUST be used in its 'downstream unsolicited' mode. LDP's 'liberal label retention' mode SHOULD be used." >From our point of view we should reuse the existing LDP session and go with= only a single LDP session between AN and AG. That has the advantage that w= e do not change the behaviour of PW FECs 128/129 (there are other options l= ike using two LDP sessions with additonal lookbacks or two sessions with si= ngle loopback and LDP DoD for IP FECs, but those have an heavy - negative = impact - on the existing implementations and/or standards). For a more long term approach we are in favour of a change to RFC5036 by de= fining a new TLV which denotes the DU/DoD mode per FEC type. Any comments on that? Regards Nic From martin.vigoureux@alcatel-lucent.com Mon Jun 27 01:40: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 4BFBE21F863D for ; Mon, 27 Jun 2011 01:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 irZQzmzgo-rV for ; Mon, 27 Jun 2011 01:40:38 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D61321F862A for ; Mon, 27 Jun 2011 01:40:37 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5R8a8VV002537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 27 Jun 2011 10:40:28 +0200 Received: from [172.27.205.189] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 27 Jun 2011 10:39:32 +0200 Message-ID: <4E0841C4.1000005@alcatel-lucent.com> Date: Mon, 27 Jun 2011 10:39:32 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [mpls] Slots requests for IETF 81 - Quebec Ciity 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, 27 Jun 2011 08:40:39 -0000 All, it is time we start building the agenda for Quebec. Please send me your requests for a presentation slot indicating: draft name, speaker and duration Please be aware that we might not be able to satisfy all requests. Thank you. MPLS Sessions are currently scheduled: Monday, Morning Session I 0900-1130 Wednesday, Afternoon Session I 1300-1500 Note that the IETF Agenda is subject to change. regards, martin From Rolf.Winter@neclab.eu Mon Jun 27 01:53: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 78B9E11E807A for ; Mon, 27 Jun 2011 01:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.649 X-Spam-Level: X-Spam-Status: No, score=-99.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 gpSeICUiqIyG for ; Mon, 27 Jun 2011 01:53:08 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6D511E808A for ; Mon, 27 Jun 2011 01:53:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8A2832800022A; Mon, 27 Jun 2011 10:53:07 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vphebbvbKDuZ; Mon, 27 Jun 2011 10:53:07 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6D7FD2800022B; Mon, 27 Jun 2011 10:52:52 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 27 Jun 2011 11:05:31 +0200 From: Rolf Winter To: Eric Gray , "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQA== Date: Mon, 27 Jun 2011 09:05:31 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> In-Reply-To: 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] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 27 Jun 2011 08:53:09 -0000 Hi Eric, just one more to follow up. You say: > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > EG > even if the last two octets "Must be Zero"). The length of > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > EG > longer by the addition of the 2-word AGI. Nice catch! In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be included = in the length of the sub-TLVs. Why are they included here? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 >=20 > EG > Apparently. >=20 > Which return code to send when identifiers are wrong (Malformed echo > request received?) or drop the packet. >=20 > EG > Drop the packet, probably log the error, possibly run off > EG > screaming into the night. What does one do when one gets > EG > something either not recognizably intended for one, or not > EG > from a source that one recognizes? From a security point > EG > of view, we cannot require an implementation to reply to > EG > the requester in this case (this is an attack vector for > EG > all kinds of hate and discontent). Nor can we forbid it. >=20 > Using the per-interface model and say the DSMAP TLV did not match the > ingress IF identifier, then should this request frame be dropped? > Should we reply to the requestor? Can this way two answers be > generated? >=20 > Nit (section 2.1): s/mpls/MPLS/ >=20 > EG > Thanks. >=20 >=20 > Best, >=20 >=20 >=20 > Rolf >=20 >=20 >=20 >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Loa Andersson > > Sent: Donnerstag, 16. Juni 2011 22:01 > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > Ross > > Callon; George Swallow; MPLS-TP ad hoc team > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > > > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Mon Jun 27 04:46: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 4F97421F8603 for ; Mon, 27 Jun 2011 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8jj3u9XVkQR for ; Mon, 27 Jun 2011 04:46:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id A1FB111E80D2 for ; Mon, 27 Jun 2011 03:49:30 -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 p5RAftq7019411; Mon, 27 Jun 2011 05:41:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 27 Jun 2011 06:41:49 -0400 From: Eric Gray To: Rolf Winter , "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Date: Mon, 27 Jun 2011 06:41:48 -0400 Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryg Message-ID: References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> 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: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 27 Jun 2011 11:46:07 -0000 IMO, that would be a problem with RFC 4379. Perhaps there is an errata? TLVs are meant to follow each other, where the beginning of the next TLV is determined by the length of the current TLV - hence=20 it is not correct to specify any content as having any value at all if it is beyond the end of the TLV. -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Monday, June 27, 2011 5:06 AM To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.or= g Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Importance: High Hi Eric, just one more to follow up. You say: > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > EG > even if the last two octets "Must be Zero"). The length of > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > EG > longer by the addition of the 2-word AGI. Nice catch! In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be included = in the length of the sub-TLVs. Why are they included here? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 >=20 > EG > Apparently. >=20 > Which return code to send when identifiers are wrong (Malformed echo > request received?) or drop the packet. >=20 > EG > Drop the packet, probably log the error, possibly run off > EG > screaming into the night. What does one do when one gets > EG > something either not recognizably intended for one, or not > EG > from a source that one recognizes? From a security point > EG > of view, we cannot require an implementation to reply to > EG > the requester in this case (this is an attack vector for > EG > all kinds of hate and discontent). Nor can we forbid it. >=20 > Using the per-interface model and say the DSMAP TLV did not match the > ingress IF identifier, then should this request frame be dropped? > Should we reply to the requestor? Can this way two answers be > generated? >=20 > Nit (section 2.1): s/mpls/MPLS/ >=20 > EG > Thanks. >=20 >=20 > Best, >=20 >=20 >=20 > Rolf >=20 >=20 >=20 >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Loa Andersson > > Sent: Donnerstag, 16. Juni 2011 22:01 > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > Ross > > Callon; George Swallow; MPLS-TP ad hoc team > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > > > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Jun 27 04:54: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 5F14011E80CA; Mon, 27 Jun 2011 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 1caRTqzWjlYS; Mon, 27 Jun 2011 04:54:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2DB11E80CD; Mon, 27 Jun 2011 04:54:42 -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.55 Message-ID: <20110627115442.5936.28629.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 04:54:42 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-on-demand-cv-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: Mon, 27 Jun 2011 11:54:45 -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-05.txt Pages : 20 Date : 2011-06-27 LSP-Ping is an existing and widely deployed OAM mechanism for MPLS LSPs. This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS-TP LSPs. 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 a registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-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-on-demand-cv-05.txt From eric.gray@ericsson.com Mon Jun 27 04:56: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 8147411E80CB for ; Mon, 27 Jun 2011 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E70YsTMlwSyL for ; Mon, 27 Jun 2011 04:56:57 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E4F9E11E80CA for ; Mon, 27 Jun 2011 04:56:56 -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 p5RBusgG030237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2011 06:56:55 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 27 Jun 2011 07:56:55 -0400 From: Eric Gray To: Loa Andersson , "George Swallow (swallow)" , Ross Callon Importance: high X-Priority: 1 Date: Mon, 27 Jun 2011 07:56:53 -0400 Thread-Topic: New Version Notification for draft-ietf-mpls-tp-on-demand-cv-05.txt Thread-Index: Acw0wQPC+YQ3meC0SF+EyBltMNGDiwAACRqQ 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 Cc: "mpls@ietf.org" Subject: [mpls] FW: New Version Notification for draft-ietf-mpls-tp-on-demand-cv-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: Mon, 27 Jun 2011 11:56:57 -0000 =20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, June 27, 2011 7:55 AM To: Eric Gray Cc: nitinb@juniper.net; sboutros@cisco.com; rahul@juniper.net; Eric Gray Subject: New Version Notification for draft-ietf-mpls-tp-on-demand-cv-05.tx= t Importance: High A new version of I-D, draft-ietf-mpls-tp-on-demand-cv-05.txt has been succe= ssfully submitted by Eric Gray and posted to the IETF repository. Filename: draft-ietf-mpls-tp-on-demand-cv Revision: 05 Title: MPLS On-demand Connectivity Verification and Route Tracing Creation date: 2011-06-25 WG ID: mpls Number of pages: 20 Abstract: LSP-Ping is an existing and widely deployed OAM mechanism for MPLS LSPs. This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS-TP LSPs. 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 a registry. = =20 The IETF Secretariat From eric.gray@ericsson.com Mon Jun 27 05:18: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 D06E711E80D6 for ; Mon, 27 Jun 2011 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0OJEkDjj+7k for ; Mon, 27 Jun 2011 05:16:35 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4F16821F860D for ; Mon, 27 Jun 2011 05:16:32 -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 p5RCGVFP031436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2011 07:16:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 27 Jun 2011 08:16:31 -0400 From: Eric Gray To: Rolf Winter Date: Mon, 27 Jun 2011 08:16:29 -0400 Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZCAAAaTEA== Message-ID: References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> 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" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 27 Jun 2011 12:18:48 -0000 X-List-Received-Date: Mon, 27 Jun 2011 12:18:48 -0000 X-List-Received-Date: Mon, 27 Jun 2011 12:18:48 -0000 Rolf, Now that you point this out, the way that we specify the TLV length is inconsistent with the way that RFC 4379 specifies length in other TLVs. This was not previously obvious, since all previously defined DSMAP/DDMAP TLVs naturally align on 32-bit word=20 boundaries. Also, there are no similar examples in the DDMAP draft (draft-ietf-mpls-lsp-ping-enhanced-dsmap - which deprecates the DSMAP TLV in favor of a detailed-DSMAP TLV). DDMAP TLVs contain sub-TLVs and there is no explicit mention of alignment with word boundaries in that draft (in fact, a search for "align" does not find any match, and "word" only=20 matches references to RFC 2119). Note that I say "inconsistent", not "incorrect." In our draft, the "Must be Zero" field is not called "padding" explicitly. We specify the contents of the TLV, and hence we could (as RFC 4379 appears to do) include just the meaningful value fields in the length, or we could use the correct length. I maintain that the use of length in RFC 4379 is not correct. In fact, it probably causes some implementation issues, since - as TLV length is specified in RFC 4379 - it is necessary for an implementer to "correct" the length of these TLVs by adding the length of the PAD, in order to be able to find the start of the next TLV. I suspect that doing this for each such TLV may be=20 more complex than dealing with TLVs that are not aligned. Or, it could be simple enough if the implementation assumes that all TLVs (for RFC 4379 TLVs at least) are word aligned. I also note that one cannot assume at this time that TLVs always will be word aligned in the general case. The=20 requirement for word alignment of field contents went out=20 the window, with the inception of 64 bit processors (since=20 nobody has AFAIK ever intended to do 64-bit double word=20 alignment). At that time, many folks then participating in IETF activities pointed out that 32-bit boundaries are not all that convenient for hardware processing (particualrly for hardware processing the information in serial bit-stream format). Word alignment of TLVs, in particular, is problematic as that means there may be wasted space in every TLV in a message - adding greatly to message sizes. Padding in the case of TLVs that contain sub-TLVs can be worse in several ways. But - even if we insist on word alignment - the TLV length should include the required pad bits so that it is easier to go from TLV to TLV. Finally, you should consider that in general, some TLVs do not need to be understood (meaning I may not need to recognize the type) for some applications. That is=20 clearly not the case in RFC 4379, but - for robustness - it should always be the case that I can directly find all TLVs and then parse them for type information, etc. If you have first to correct the TLV length based on the TLV type, then this doesn't work. In any case, I just talked to one of the WG chairs. The draft has been re-posted, and will be forwarded to the IESG for publication. We can re-visit this in IETF last call, or the issue can be resolved either way in IESG review. -- Eric -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Monday, June 27, 2011 7:04 AM To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.or= g Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Importance: High I think that's OK, since the value is not beyond but within the TLV. Taken = from 4379: Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a 4-octet boundary. That means the length is the length of the actual value (excluding the padd= ing). So the beginning of the next TLV is determined by the length plus a v= alue that makes it align on a 4-octet boundary (which of course can be 0). = I cannot follow your argument why this is not correct. I am sure I am missi= ng something trivial, so sorry for spamming the list. But all information i= s encoded in the packet (plus the simple rule quoted above). Otherwise, a n= ode needs to understand the internal structure of each TLV to extract the v= alue instead of applying the simple rule above.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Montag, 27. Juni 2011 12:42 > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > cv@tools.ietf.org > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv >=20 > IMO, that would be a problem with RFC 4379. Perhaps there is > an errata? >=20 > TLVs are meant to follow each other, where the beginning of the > next TLV is determined by the length of the current TLV - hence > it is not correct to specify any content as having any value at > all if it is beyond the end of the TLV. >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Monday, June 27, 2011 5:06 AM > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > cv@tools.ietf.org > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv > Importance: High >=20 > Hi Eric, >=20 > just one more to follow up. You say: >=20 > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > EG > even if the last two octets "Must be Zero"). The length of > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > EG > longer by the addition of the 2-word AGI. Nice catch! >=20 > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > included in the length of the sub-TLVs. Why are they included here? >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > > > EG > Apparently. > > > > Which return code to send when identifiers are wrong (Malformed echo > > request received?) or drop the packet. > > > > EG > Drop the packet, probably log the error, possibly run off > > EG > screaming into the night. What does one do when one gets > > EG > something either not recognizably intended for one, or not > > EG > from a source that one recognizes? From a security point > > EG > of view, we cannot require an implementation to reply to > > EG > the requester in this case (this is an attack vector for > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > Using the per-interface model and say the DSMAP TLV did not match the > > ingress IF identifier, then should this request frame be dropped? > > Should we reply to the requestor? Can this way two answers be > > generated? > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > EG > Thanks. > > > > > > Best, > > > > > > > > Rolf > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Loa Andersson > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > Ross > > > Callon; George Swallow; MPLS-TP ad hoc team > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv > > > > > > 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 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Mon Jun 27 05:28: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 2272711E80DC for ; Mon, 27 Jun 2011 05:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.949 X-Spam-Level: X-Spam-Status: No, score=-100.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 uVFU5axt1PB8 for ; Mon, 27 Jun 2011 05:23:34 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6F21F85FC for ; Mon, 27 Jun 2011 05:21:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C11012800022B; Mon, 27 Jun 2011 13:04:19 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBlEnixrGVkS; Mon, 27 Jun 2011 13:04:19 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A2B8A2800022A; Mon, 27 Jun 2011 13:04:04 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 27 Jun 2011 13:04:05 +0200 From: Rolf Winter To: Eric Gray , "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZA= Date: Mon, 27 Jun 2011 11:04:02 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> In-Reply-To: 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] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 27 Jun 2011 12:28:13 -0000 I think that's OK, since the value is not beyond but within the TLV. Taken = from 4379: Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a 4-octet boundary. That means the length is the length of the actual value (excluding the padd= ing). So the beginning of the next TLV is determined by the length plus a v= alue that makes it align on a 4-octet boundary (which of course can be 0). = I cannot follow your argument why this is not correct. I am sure I am missi= ng something trivial, so sorry for spamming the list. But all information i= s encoded in the packet (plus the simple rule quoted above). Otherwise, a n= ode needs to understand the internal structure of each TLV to extract the v= alue instead of applying the simple rule above.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Montag, 27. Juni 2011 12:42 > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > cv@tools.ietf.org > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv >=20 > IMO, that would be a problem with RFC 4379. Perhaps there is > an errata? >=20 > TLVs are meant to follow each other, where the beginning of the > next TLV is determined by the length of the current TLV - hence > it is not correct to specify any content as having any value at > all if it is beyond the end of the TLV. >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Monday, June 27, 2011 5:06 AM > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > cv@tools.ietf.org > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv > Importance: High >=20 > Hi Eric, >=20 > just one more to follow up. You say: >=20 > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > EG > even if the last two octets "Must be Zero"). The length of > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > EG > longer by the addition of the 2-word AGI. Nice catch! >=20 > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > included in the length of the sub-TLVs. Why are they included here? >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > > > EG > Apparently. > > > > Which return code to send when identifiers are wrong (Malformed echo > > request received?) or drop the packet. > > > > EG > Drop the packet, probably log the error, possibly run off > > EG > screaming into the night. What does one do when one gets > > EG > something either not recognizably intended for one, or not > > EG > from a source that one recognizes? From a security point > > EG > of view, we cannot require an implementation to reply to > > EG > the requester in this case (this is an attack vector for > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > Using the per-interface model and say the DSMAP TLV did not match the > > ingress IF identifier, then should this request frame be dropped? > > Should we reply to the requestor? Can this way two answers be > > generated? > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > EG > Thanks. > > > > > > Best, > > > > > > > > Rolf > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Loa Andersson > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > Ross > > > Callon; George Swallow; MPLS-TP ad hoc team > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv > > > > > > 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 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Mon Jun 27 05:58: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 BF47E11E80EB for ; Mon, 27 Jun 2011 05:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qESSQIfxNyiU for ; Mon, 27 Jun 2011 05:55:53 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2483B11E80DF for ; Mon, 27 Jun 2011 05:42:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DF3A82800022A; Mon, 27 Jun 2011 14:38:06 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td3xEWDDMiuc; Mon, 27 Jun 2011 14:38:06 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C2A752800022B; Mon, 27 Jun 2011 14:37:56 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 27 Jun 2011 14:37:57 +0200 From: Rolf Winter To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Callclosed - Re: verification call on draft-ietf-mpls-tp-identifiers Thread-Index: AQHMMojGgcKXA8rc4UuzHkOhNUgVP5TQ7b8Q Date: Mon, 27 Jun 2011 12:37:55 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B697D5@Polydeuces.office.hd> References: <4DF89286.4050103@pi.nu> <4E04B4A7.4010106@pi.nu> In-Reply-To: <4E04B4A7.4010106@pi.nu> 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] Callclosed - Re: verification call on draft-ietf-mpls-tp-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: Mon, 27 Jun 2011 12:58:24 -0000 Hi Loa, I think I understand your reasoning behind this decision but I'd like to br= iefly comment on it, mostly to clarify things for myself I guess. So the qu= estion I have is what impact will this decision have on the progress of the= solution documents? I mean, since the ICC-based IDs are not specified as o= f now in the identifiers document, will all solutions now need to wait for = this new draft that specifies the ICC-based IDs or need all solution docume= nts an additional draft that specifies how to use the ICC-based IDs or some= other thing needs to happen. I am just curious (maybe it'll be as simple a= s another TLV to use and done). Wouldn't it be much easier to set a tight d= eadline on the ITU-T folks to get the country-code issue clarified and move= the draft forward as is? 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 > Loa Andersson > Sent: Freitag, 24. Juni 2011 18:01 > To: mpls@ietf.org; MPLS-TP ad hoc team > Cc: Ross Callon; draft-ietf-mpls-tp-identifiers@tools.ietf.org > Subject: [mpls] Callclosed - Re: verification call on draft-ietf-mpls- > tp-identifiers >=20 > Working Group, >=20 > this verification call has ended! >=20 > The working group chairs has discussed how to proceed with this draft. >=20 > We have noted the concerns about ICC representation and usage. In view > of this we have decided split the document and leave work on ICC to a > future document. >=20 > The authors should update the document according to this decision and > as necessary after the verification and re-publish the draft. >=20 > /Loa > for the wg co-chairs >=20 > On 2011-06-15 13:07, Loa Andersson wrote: > > Working Group, > > > > the authors of draft-ietf-mpls-tp-identifiers has updated > > the draft after working group last call and published version -05 > > of the document, that will be found at: > > > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ > > > > A detailed list of how the wg lc comments has been addressed is > > found at: > > > > http://www.pi.nu/~loa/identifiers-resolution.xls > > > > This is to start a one week call to verify that the comments been > > correctly addressed. Please send your comments to the mpls working > > group mailing-list eob June 23 2011. > > > > /Loa > > on behalf of the mpls wg co-chairs >=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 From Rolf.Winter@neclab.eu Mon Jun 27 05:59: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 149D321F8607 for ; Mon, 27 Jun 2011 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.816 X-Spam-Level: X-Spam-Status: No, score=-101.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qUFJMpnVrwgw for ; Mon, 27 Jun 2011 05:59:01 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6F21F85FC for ; Mon, 27 Jun 2011 05:21:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C11012800022B; Mon, 27 Jun 2011 13:04:19 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBlEnixrGVkS; Mon, 27 Jun 2011 13:04:19 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A2B8A2800022A; Mon, 27 Jun 2011 13:04:04 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 27 Jun 2011 13:04:05 +0200 From: Rolf Winter To: Eric Gray , "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZA= Date: Mon, 27 Jun 2011 11:04:02 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> In-Reply-To: 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] Verification call on draft-ietf-mpls-tp-on-demand-cv 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, 27 Jun 2011 12:59:06 -0000 I think that's OK, since the value is not beyond but within the TLV. Taken = from 4379: Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a 4-octet boundary. That means the length is the length of the actual value (excluding the padd= ing). So the beginning of the next TLV is determined by the length plus a v= alue that makes it align on a 4-octet boundary (which of course can be 0). = I cannot follow your argument why this is not correct. I am sure I am missi= ng something trivial, so sorry for spamming the list. But all information i= s encoded in the packet (plus the simple rule quoted above). Otherwise, a n= ode needs to understand the internal structure of each TLV to extract the v= alue instead of applying the simple rule above.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Montag, 27. Juni 2011 12:42 > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > cv@tools.ietf.org > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv >=20 > IMO, that would be a problem with RFC 4379. Perhaps there is > an errata? >=20 > TLVs are meant to follow each other, where the beginning of the > next TLV is determined by the length of the current TLV - hence > it is not correct to specify any content as having any value at > all if it is beyond the end of the TLV. >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Monday, June 27, 2011 5:06 AM > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > cv@tools.ietf.org > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv > Importance: High >=20 > Hi Eric, >=20 > just one more to follow up. You say: >=20 > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > EG > even if the last two octets "Must be Zero"). The length of > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > EG > longer by the addition of the 2-word AGI. Nice catch! >=20 > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > included in the length of the sub-TLVs. Why are they included here? >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > > > EG > Apparently. > > > > Which return code to send when identifiers are wrong (Malformed echo > > request received?) or drop the packet. > > > > EG > Drop the packet, probably log the error, possibly run off > > EG > screaming into the night. What does one do when one gets > > EG > something either not recognizably intended for one, or not > > EG > from a source that one recognizes? From a security point > > EG > of view, we cannot require an implementation to reply to > > EG > the requester in this case (this is an attack vector for > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > Using the per-interface model and say the DSMAP TLV did not match the > > ingress IF identifier, then should this request frame be dropped? > > Should we reply to the requestor? Can this way two answers be > > generated? > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > EG > Thanks. > > > > > > Best, > > > > > > > > Rolf > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Loa Andersson > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > Ross > > > Callon; George Swallow; MPLS-TP ad hoc team > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > cv > > > > > > 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 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Mon Jun 27 06:56: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 88A9521F8624 for ; Mon, 27 Jun 2011 06:56:23 -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 BryVEyA0pN0J for ; Mon, 27 Jun 2011 06:56:22 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 492FA21F8573 for ; Mon, 27 Jun 2011 06:56:22 -0700 (PDT) Received: from [10.154.12.19] (unknown [192.165.126.77]) (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 D8E53514045; Mon, 27 Jun 2011 15:08:29 +0200 (CEST) Message-ID: <4E0880CB.7030706@pi.nu> Date: Mon, 27 Jun 2011 15:08:27 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Rolf Winter References: <4DF89286.4050103@pi.nu> <4E04B4A7.4010106@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B697D5@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B697D5@Polydeuces.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Callclosed - Re: verification call on draft-ietf-mpls-tp-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: Mon, 27 Jun 2011 13:56:23 -0000 Rolf, I think the real question is whether ITU-T has a global "ICC identifier"? If they do, they could have told us long time ago, e.g. when we asked (repeatedly). If they don't, there is no way a tight deadline will help. If they have it, the draft could be written in two weeks, and expeditiously taken through the process. If they don't I think there is a meeting cycle of time before we can have it. /Loa On 2011-06-27 14:37, Rolf Winter wrote: > Hi Loa, > > I think I understand your reasoning behind this decision but I'd like to briefly comment on it, mostly to clarify things for myself I guess. So the question I have is what impact will this decision have on the progress of the solution documents? I mean, since the ICC-based IDs are not specified as of now in the identifiers document, will all solutions now need to wait for this new draft that specifies the ICC-based IDs or need all solution documents an additional draft that specifies how to use the ICC-based IDs or some other thing needs to happen. I am just curious (maybe it'll be as simple as another TLV to use and done). Wouldn't it be much easier to set a tight deadline on the ITU-T folks to get the country-code issue clarified and move the draft forward as is? > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Freitag, 24. Juni 2011 18:01 >> To: mpls@ietf.org; MPLS-TP ad hoc team >> Cc: Ross Callon; draft-ietf-mpls-tp-identifiers@tools.ietf.org >> Subject: [mpls] Callclosed - Re: verification call on draft-ietf-mpls- >> tp-identifiers >> >> Working Group, >> >> this verification call has ended! >> >> The working group chairs has discussed how to proceed with this draft. >> >> We have noted the concerns about ICC representation and usage. In view >> of this we have decided split the document and leave work on ICC to a >> future document. >> >> The authors should update the document according to this decision and >> as necessary after the verification and re-publish the draft. >> >> /Loa >> for the wg co-chairs >> >> On 2011-06-15 13:07, Loa Andersson wrote: >>> Working Group, >>> >>> the authors of draft-ietf-mpls-tp-identifiers has updated >>> the draft after working group last call and published version -05 >>> of the document, that will be found at: >>> >>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ >>> >>> A detailed list of how the wg lc comments has been addressed is >>> found at: >>> >>> http://www.pi.nu/~loa/identifiers-resolution.xls >>> >>> This is to start a one week call to verify that the comments been >>> correctly addressed. Please send your comments to the mpls working >>> group mailing-list eob June 23 2011. >>> >>> /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 -- 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 iesg-secretary@ietf.org Mon Jun 27 10:29:01 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 9985011E8134; Mon, 27 Jun 2011 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=0.495, 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 EAZbv2UZtBFy; Mon, 27 Jun 2011 10:29:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1FC11E811C; Mon, 27 Jun 2011 10:29:01 -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.55 Message-ID: <20110627172901.27512.9477.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 10:29:01 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Using Multipoint LDP when the Backbone has no Route to the Root) 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: Mon, 27 Jun 2011 17:29:01 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Using Multipoint LDP when the Backbone has no Route to the Root' 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-07-11. 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 The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") 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 the intermediate nodes are part of a BGP-free core, this is not possible. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-recurs-fec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-recurs-fec/ No IPR declarations have been submitted directly on this I-D. From rcallon@juniper.net Mon Jun 27 11:51:50 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 A289621F85BA for ; Mon, 27 Jun 2011 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 ZJ2MuR9IAtus for ; Mon, 27 Jun 2011 11:51:50 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id AD9EC21F85B9 for ; Mon, 27 Jun 2011 11:51:49 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTgjRRWxA2NwI0cU5NiGQb3hBwxga0MFW@postini.com; Mon, 27 Jun 2011 11:51:49 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; Mon, 27 Jun 2011 11:49:59 -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; Mon, 27 Jun 2011 14:49:58 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Mon, 27 Jun 2011 14:49:55 -0400 Thread-Topic: Request to Publish draft-ietf-mpls-tp-identifiers-06 Thread-Index: Acw0bZ0cu8bCENHeSEmkdTCB9f6zjAAjSKqA 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_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] FW: Request to Publish draft-ietf-mpls-tp-identifiers-06 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, 27 Jun 2011 18:51:50 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI. _____________________________________________ From: Ross Callon Sent: Sunday, June 26, 2011 9:58 PM To: 'adrian@olddog.co.uk' Cc: 'Loa Andersson'; Ross Callon; 'Stewart Bryant (stbryant)'; 'George Swal= low (swallow)' Subject: Request to Publish draft-ietf-mpls-tp-identifiers-06 The MPLS WG requests that draft-ietf-mpls-tp-identifiers-06 be published as= a standards track RFC. The PROTO writeup is attached. Thanks, Ross --_000_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
            FYI.
             
            _________________________= ____________________
            From: Ross Callon
            Sent: Sunday, June 26, 2011 9:58 PM
            To: 'adrian@olddog.co.uk'
            Cc: 'Loa Andersson'; Ross Callon; 'Stewart Bryant (stbryant)'; 'Geor= ge Swallow (swallow)'
            Subject: Request to Publish draft-ietf-mpls-tp-identifiers-06            =
             
             
            The MPLS WG requests that draft-iet= f-mpls-tp-identifiers-06 be published as a standards track RFC. The PROTO w= riteup is attached.
             
            Thanks, Ross
             
             
             --_000_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="PROTO writeup for draft-ietf-mpls-tp-identifiers-06.docx" Content-Description: PROTO writeup for draft-ietf-mpls-tp-identifiers-06.docx Content-Disposition: attachment; filename="PROTO writeup for draft-ietf-mpls-tp-identifiers-06.docx"; size=16314; creation-date="Mon, 13 Jun 2011 14:33:23 GMT"; modification-date="Sun, 26 Jun 2011 21:54:30 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDd/JU3ZgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMtuwjAQvFfqP0S+Vomhh6qqCBz6OLZIpR9g7A1Y9Uv28vr7bgJEVQtBKuUSKVnvzOzsxIPR2pps CTFp70rWL3osAye90m5Wso/JS37PsoTCKWG8g5JtILHR8PpqMNkESBl1u1SyOWJ44DzJOViRCh/A UaXy0Qqk1zjjQchPMQN+2+vdcekdgsMcaww2HDxBJRYGs+c1fd4qiWASyx63B2uukokQjJYCSSlf OvWDJd8xFNTZnElzHdINyWD8IENdOU6w63sja6JWkI1FxFdhSQZf+ai48nJhaYaiG+aATl9VWkLb X6OF6CWkRJ5bU7QVK7Tb6z+qI+HGQPp/FVvcLnrSOY4+JE57OZsf6s0rUDlZESCihnZ1x0cHRLLs EsPvkLvGb1KAlHfgzbN/tgcNzEnKin6JiZgaOJvvV/Ja6JMiVjB9v5j738C7hLT5kz7+wYz9dVF3 H0gdb+634RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYz sKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdh b9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687 HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDWZLNR+gAAADEDAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKySzWrDMBCE74W+g9h7LTv9oYTIuZRArq37AIq9/qGyJLSbtn77CkNShwb34otgRmjmk7Sb7Xdv xCcG6pxVkCUpCLSlqzrbKHgvdnfPIIi1rbRxFhUMSLDNb282r2g0x0PUdp5ETLGkoGX2aympbLHX lDiPNu7ULvSaowyN9Lr80A3KVZo+yTDNgPwiU+wrBWFf3YMoBh+b/892dd2V+OLKY4+Wr1TILzy8 IXO8HMVYHRpkBRMzibQgr4OslgShPxQnZw4hWxSBBxM/8/wMNOq5+scl6zmOCP62j1KOazbH8LAk Q+0sF/pgJhxn6wQhLwY9/wEAAP//AwBQSwMEFAAGAAgAAAAhAKut19+kEwAAhGYAABEAAAB3b3Jk L2RvY3VtZW50LnhtbOxc3W7bRha+X2DfYaCrGrBly02c1mgUyHacGmhTr+0iu5cUObLYUCSXQ1px r/ogu8A+yz5Kn2S/Mz/kDEVSlGzHKbaLRdKI5PD8fOd3zvC7N58WEbvjmQiT+PVgNDwYMB77SRDG t68HP9+c730zYCL34sCLkpi/HtxzMXgz/utfvlseB4lfLHicMywRi+M7XJ3neXq8vy/8OV94Ypik PMbFWZItvBz/zG73F172sUj3/GSRenk4DaMwv98/PDg4GuhlkteDIouP9RJ7i9DPEpHMcnrkOJnN Qp/rv8wTWZ/3qifPNMnyjfsZj0BDEot5mAqz2mLb1cDi3Cxy18XE3SIy9y3TPm8LMm8JfSwiRfYy yYI0S3wuBH49UxfLFUcHXe/WAqQlyif6kOC+01Cy8MK4XIbQUdN/qbwhlLev3r1PS1WMQBZjYGma BPf0d8qWx8BicPV6cHBw+Orw5fm3A/PTGZ95RZTTlaMXB+eHb+WTGT0mMXgsUs8HEWnGBc/u+GB8 efXTzU/su33cMKY/5b0QXTJ7m2VYNr9Pcb9IeRRd516WD/ZpMbXieJmFOS/SXk+/jQP7WYLyKjUM dlAnhqio+B0dvZxMSn4vAWwIQf0ouRwHNWqcx49evXoxeSWFko8zDyYT8ny2t0gjsZene2EAWw1n IWx97+DIWQiiSVekr2VsCFyVvhSWo7BvJofnZxUDq4/oxS6JMX2zlLh5iWLZ0m6LYhn7ajT0dtiH ecJCwfI5Z8a02fWcp3OeBVLc+RyXjaN640q/ket2FtwrkgVN6CaCaF+lgl4zfK4SIdipF8EPG54N Y0zYPDuqBbxc4Vpiz8dB1naztDIbUISn2s3rLcm8emU1Qmav1SrLal3rEcnStvJolFk2V1uzy20N 2feczT3BMu4FADcgrCM0S2YS7KXiEZjZlEchv+NkBl7OQvxfPXkvLQBOZ+llFM9ZnsiHL95ev5OX 0mIahb4MgcPNTcOxVaMcy+Tbkb5qLzVfs25p93bbFLf3JtMd9j1ETq6klO4c4vcC/s/CyzmUcRfy JZsm+ZzNsmTBPvJ79uEdW/DFFD61hwBdsq8+O5dM/o8gU9IfJ/FexcMbeFGJoyZ3Ovfu+B+IyXvm J7HPs1gwb5oUudIsT6E9hOEpmRb9p7InpVttQY6lNgaJmiIt0LtXHgGZSmdS9lPOY5byjNJpHrxh PZTh2uCVRah7xSZ01Trde/ut0mCIehm6gsjjSLlMumTaUru0PsyoJbeIKerBzQOIem67aKHfaYUG 6evJ1/BPOY9FCDuznc2yJo8yoFNUfXlwMEHOKBdtzhtCBJBYov/Hyx+uyWORB8BPFzc/793syn9R sJHwKtIAvg4xxRP4E5kG+cOFF5M1LajYo9Dic5AYDNkN+cpQpIkIqYwiY+KePze3SrbkqsahYkm8 F6VhGJlgpGn6M/74O2udb+nQZKB3IpUDkT4+65mCT8x5INgiyUqIy1DksRTlV+gXkZcp95wg7mbk 7VCd+TnwttvD3bne97kCLB/eDneZ4H6BCvJ+l6ELkskky4vINNKIf5K/i2TB0VNhM2+BNggYX8JU N+fScuou/7ZTJ/9Q+g1H9x2eQ8UexuBgdmG4OYKp5iP8Vf4HqervP/7wJdRVL0ejk6pXsMK6crrv E+Y7lmIJpVaSthSeOqX4010F690VRQ2yXvQc/CoZq/dAvmBnFQpRIB2WZuk0EhAVUWmRA77iCH8I 2dOIswlySnYWIj7miVtX9+Gx24y/Hb0YHZ3JML+1GSPs70P6RLYsAcU8KSIqH5mHCpEjfPcxZE1J Q8HnXpEmqH9aTSnde+2U0r1iryJ9WIe7IuvewD7dF60NFu7tNl2r3Ll+eO3S7u0rvsuIur/bRnOM o5xNlkwkUYikS9W1SP0gIIEUs6B0D2mh7i6Y/EzXf2ghOF6yD3wd4gzF3ZjWbEu1miecZTp0bUJT xlPq9mITgmAt8ixBn4NQUGQZ9jEI1MxjM9TtYDa8C4PCi8TulpHWIc5Q/PQ8ouFA/YUppx6OCCNw i6QiQ5tC1+qU0qPKZct5AjdUxMic5JaNTO031uTTM+TdZpwrHYQ56tgeaNumBF21S9eGba/jrm9b N4EwvZTtukz9NT0VWBpGIf9NxqEvG0gonNjlbnNldmM3p1nAZ2EMjToKqyUoTosfuJYba20P9CVD 9gLbFqG0qCY2ta7+UVpvk1yoyKfibu/mkv1wfckuqu2HHu/qWrZZmFXJehslU6TacRIg0J0J9lXt fev7CUaRFvNdBI1D3usVzb3sPoLcZReX6EQG8HWCix2pMdmI5DHKKd3EgpRrZJSpAjFiYacRyKSw IbukzkNSiOheelRsPc5yBp+ZaHyiIaphJ4kwGra7Gbp30EVLD56btYyuxekpVIreBfZCsgy7WewU ihY7tZS83XBamb95Eorhu+HrpH/O0EnmIlfd166X6WKmE3MqqqU8QT3ZtdbWoqYODe02LVkhZByt 2xVtZ1L9CgxaEJRBRyqpi6oeYGwGgAIXmXXX8lszTTxRJiFjrs2Z8Bac/NiQTWYohK1WHTpgfoGt eGqAuX021eiKQoF4TTHc4MCPOKr9KhXr4sTq77UBt1lQ0B4cHSItdg2JI5Pjdcqth1rGVA5RP10U aZpkQHOt2KlZ3taqYIvwExqGAN/DTfu6mAoyvjiP7rukrfk3/l8nfNU26GYq6BT1i6PRaHKoKrq2 +Jl30aoXcGntsyr35zG2/SLCB+rWRVnhIlyenhrvviS8ErYT7D1St/e//zkruGnbehgl8EOM8EBD AcZo7qmxe8vzXO4zzpGSo0+M4gN94t0uJnoArhneEtNErnIIdvyRlGd8AcL1TpeN/yE7oR28WkrS qar1REaeyK/gB0lSl94tP0Er4KPMP1v6SGV/vZI4yhJqzBOt6KirloL2vMoSbB6/kk2JBu9b3kSW Q8qQrtgsXLm1lfu0d4dn3UHjHlsQsnMfcYR/coqzIiMXhhKrCO5rBtlYH2q7N/C0qgr3yja5duML 3RTeTu4bXmjVniZ7bzJCK7nvCsbNEP1JCgytIooKKMFlO4n0qwMBRt9y1GuIAyhbaYMfvWKjqNJb 4znqmROSoYVwQS4XxteJ161jBornhDBTt9gu3seY5/pIkU+ngsP6wwYBlINuTZlLUqP+XS1fOVWK oaEbhRuCopEKt5ejqaj9aFHhXnmc1s9MTTKg/Ur+IZ/DF2FbEQgCEL005fD8lLkREJchHDV1RjAF ghuw/wi/+cfZ5Q/CLrBZsTAfI45hAyNGu+Fihq7YLkPajD1OZDELjKSGv7YtpFOAat6wxaGToNFI haxlPYa3zTBbg1mcuAd0XRR8ftCobprg2IQDDvQG7QKZI0IZskc1NnTV1uoeohyrOaQv0jQ0l2XX G6rxsE3nMD3lvkdBVzpsWa0hr489NPWpieqApA+PT2npih1AmpIO4MxMd52xm8zzP/JsuNOD4JrX tAh2r9iuaZPGWvsqMqjQHy0WhXa+9laVC9si8XAMeKM4sMrmc9sp+vq31ZjamZm/Lydeabs8iVG0 39PAIM36Uj6pt6rWg/fkm6PDo655ay0+iQV9s9SiEasj6w7VKuiyqiYV2E4WIBdd7ChC047FYS76 7EbVNGLB173SDd92xt0r9ioVfMf/4EIPwxiNpB716QwjqtUdJ4xnWZIJRxG1avn84OuXJ+dd4zwy RcRa2LKLkautrNYh9j7W4zK8NhS5t9vy+SKtZ15ZT5lhixSJOMZmabJpBl+KXSPk6uROY9lep3Es SssdtfVx/o41GBPphdAHGVUYo1LAYRTQ/Yb2pCkxwZ8VMxabYNLIYdvhx2fikjas4ySHzrxADTp7 wZ0H3ckTSchv5Y62leNS9lvEqvW2XpUuru1issGv6JsfpDVs2OXQ10Moc2nutkX3Xps/94q9SuXx muvdq8p8lE0hfGdJmoXgLELPYALX3ohCUhWQqI6ZZdjQyCmBYVfnp+iJ8E8+hnZl9YsfDkejb7HP GWLKEPmYx05O0ZHdWGjrMNsugy/Sq4WVV1vNCVYTAWPx7GLyftJDeC7i14YE9/YVABlH6OigI2iZ XAEVFc6F6Uk6mq6TI6cYpRPw3OSfgQd5j6AyzwztoI2Fk2WbM9ntpjU+HmTwetPOKOPRTV/TuApY F9yPY/oSSa5OamZp5TlK85YM8/GNDFHKpytYelK/m2Q30kU4Y1o1Ehpjdk0aDioNVC0wuLfb4F4V tGsIn99uUC380t8zaO2Vu8nrnepz86c8gzEgVegQhOjgJnwAtV70XnXEIi++LdDNwFxugdiBJg3m Vjd3C+vg4YrEhseDfAXOY4Pyk/fnLCsijqD448WJ2o+Xg/cUJXMfM8d3Hqa9qIPjJxh/8rHZtVX/ ycL7EzFEncgiT5ClokLFYXFqVzy6B9S0rxrm5ODF6dGrgTFvpdTaj5YM2m2elFrbPpBva50Q6ohz 75HMTlLUIr6HTbma67K8J7XRNa0dq9HZDJiCzJGQJqtpbVUXlIMctKGg5nPvqelf7ghlwFOZYskp E8zVeeHtPMcTKDupkQyt0SY2ABbIsSVqQFGhYZUT+MFEhNHwa/b7b/9yXEozS406kbbTtD1DIyuQ m+TOizAIEt8h9qNjtxI3zLr9pPf7b/+uKeD/MHZ83JEHfOSosMzk4V2g+ThBFaWqrBDlVIHZG7jZ Mu90dNwoNdelPFlY3HhL1iSaE5vFD/QRgL2fUwxGqf0CVDSYIqV9AwojXyDfLd3UTu7esCsc6kLW zD95dD4FmTQ89BRHU6BsY9pfjGbXcDiYyNRx4GBVyOxQwRghxyQNum9XwntjHq0w4eL60WK/Y3Eo cHJ8c0NN9MwSms4i121yt+MeGY0bzdaan3u7zdVqXHUl8DiVRW04uBY1am900rOO6HhTjsBcy+2/ PgWiK4h+zDWISM0SmXBkwccd55GC1q+U4a+DG1fpNQnVyFYSshZuNSbHFJoX7aLpSYhyB6b12SLq 1gYU9uWnTaSdm6nUZPoLsmAYObtQoQqpC2VF1e0Ol83hqlVj7rDYRhqDN3be3Cxfg5LeSquv2aWg +r3mZZQhrQXNWOWHJEw60YgEjA5AyZkk2ZEhp3RxiToFA+C77J36C1ljj5duQDNi8Zov+WzG1KXg RQCPmtUHaptf9Lb86M9Gr2luntrlnDtC04xKNZBgXuw4PvOj5VxcP7mtF29fhZRWDps7xHSo8wMG hwgo77KkSFl/Tzw5P5q8GpXlm8Wme6WbTfde25+7V+Qq+ifJZgdHKslyvVSgj3U0js3XpxDLscD6 rLVjOI2IcKl+TH42Pz8hRbT5qQj1WN+zDpucVXhO8VGZbQKSFXmq8ypyQrPxRIMq4hsOD3hu+PjM gKDjdOrgwYPPCCjAr4zzf26GoCJqXlTjsbo7v/3U/3Mibv2JA+y2IaY1HA5oGO7Xc/jPyZA8A2DP 8LO8zODBxwZD7MyaYX9OjjaZn5fQ7DHq/pz8yK942P2/ljH7MsD1mnt/To6eYOb+OdkpI485F/DY 8/7b5B+r9fE2q/TLyp5gGn+9PmuFVHequlGSWZ0EMEP7nXP4jQHVbTmsbQW5t8u8WP+0qke3VLCz UVckdo6+Vo+OvK2Cg0rW2gv71iBl3/pv+DAAvsrTI69yGXgk1mr9gEZ1PcmLu2SqtSvT8paq1ZUX dNJ5s/pimBmSLD86Vn72DNtJ6sNnaNHqkQ70oSuoI3pgR4sSagN6h/xGqb09fzk6/7qpWnTlWUei u69H+8eoq7EF8nrA4713J/S5X7wvo20peq/anupk36G1Bt/HF3XdHaxoyrQJyHq0kKQFKk46GZZn +7vYqQldWePmL2kGHX1XSOfnZVTD9zHUcTczRIZP3NycmyPz1GVAdzDCaBm1rBzKNwSNy9njgUYC aXm8TuzNEnE5aofWw15SveV/AgAAAP//zFXbbqMwEP0Vi/e2hJJsN2oiUTXpy1ZCzf6AwUNiyWDL NkmzX79jA7uQyzZS8rAvyPYMnmOfM8dTPX/etZ/UjwWt1mQ33VIxC6C6e3sJHubPD5jThC35LMXU KJrDLFAaDOgtBHNCiEuyTarfEzfRhrOPVM+CMFwsx6PlY+Aj1xSiQgNle8JLJaCEygIj2Z4wKGgt LOEVeU9/rAit2CEgpaUsFlojLrtXiN4oEGJlqbbuiIj2WsRzZaBmcsc1HFzG6dqLit2o8hlSzN5Y KM09SUhVlxloIosBMqRMuaOr7ug9qrql1+ZqjyOpW5rE4TJaeF5Vw2srlH/qyNVts69WxCHPf2h0 8OLJaJRE18vuWN7X4z4L/LYdQ7ZQMakNoRpIVnPBOHa465K7nykxUtSWywrD2DI7LgT2UC5qBoQz bC9ecJRNIXVJrcE2M7nmGfbc1zJ6eZpEk+9BJ6PmUK1cusWLteWt6RJlYXOfaYZjCjsU/7tQBnd9 C59Cl7QbjnTKvHYeej+ocNIUxmGYJMnFbA7TvVO0S75v3OdCnk6iOZDRV9oapvd9yxv/wP2GuR89 hbYR/4uB3KYDpxn+t8K4d8x4tBiPG3tcr36h4nazYBRFceiucoPj8ROOGxjrd+q2tFLhetykaL7e 4E7dNJPWyvLvXEDRi27waQR8br9FfvtCStubrmvrp225XAqD1dqn3P3iUaAm3jRHK5gKXkHKbY4o Hyc+ilw0B/fPfCbZ3g86Gc1/AwAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdv cmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA 0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scM HRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErX l5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6 wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6 bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8 if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHk YA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo 1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUv v/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSi m+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQ iYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4U DklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeosc ukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq 3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+v Brdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0 u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWma ZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd 2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZ fDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA2Knw kT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe 4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8y00w 60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6ASriZM RdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUcxv8z VfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRomreHA p/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDgTsaf +55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJW lvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08 kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGz J1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQU AAYACAAAACEAuE776XwDAAD2CAAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFbbjts2EH0v0H8w9Fyv RV0oW4g38EVqU+y2RZ18ACXRtrC8CCRtr/v1HUpitNuyQdAnkefMHA5nyKE+fHzlbHalSrdSrAP0 EAYzKmrZtOK0Dr58LufLYKYNEQ1hUtB1cKc6+Pj44w8fbrmmxoCZnoGE0LlcBxclcl2fKSd6ztta SS2PZl5Lnsvjsa3p+AlGD7UOzsZ0+WIxOj3IjgpQO0rFidEPUp0Wg+de1hdOhVlEYYgXijJiIGB9 bjvt1Pj/VYOlzk7k+q1NXDlzdjcUfsty3O5Nquarx/eEZx06JWuqNWSWs2G7nLTCyWj2PTpDPp/a ShF1fyPyCGX7S0o+u+UdVTUkFGoehsHCErCwPB4MMRRo3VHG+kNQM0rEYNHQI7kw85lUByM7sLoS CCeLRoH6TBSpDVWHjtTgu5PCKMmcXSN/k2Yneadge4MgHI2OmH51OIGNtmHYwZ9SGucGBU/CMioG D8tOTIRwutn4mHiPtlHmYxKM0CbyMWkYbvxqKULbcuX1SfGuwF5mj8td6mUKXKZ+nxKjIvb54DDd x979/Hd2cBrheOlVy7Jk41XL4jAuvcwyzNL93qe2TLICeTO63ETl3lufFUoQ9qqtcBTvvLleZbgo vD6bMNlhb9SbEm8y5It6u8QR9q6z3UYx9tZnvwxRUfrUigQVqbfaRZmi0lvTMozTrVetLOGE+H3K DKOdjWAxXBW4Mzy3LewP5UYl3LsZHy7njvBKtWT2bJscePG8Ui/bVji+otBs6VvmcKkcOZ8PhOaE sRLutiOgvw1M0+puT4+9MHsm6jQp902B58qLQif59aua7UNU/azkpRtUb4p0n0QDsFsQJcmo1wrz 1HKH60t1cF4Cet0b6iKa36/KCi6mBN1yA88TtRl6IuLkOgkV8y8Ha3rLa6YO9gmjz6TroImBSXVC 64C1p7NBAUwNzBqiXvpJdYpGLuo5mFmun5Da7gysx4E1GIZgNQ4mLHZYPGGJw5IJSx2WThh2GLbY +Q7NHZr3CzwVbmjxo2RM3mjziwPXwb+gIQn6TDoKdbXdHg6YzHtgbP96ds3pK7wctGkN/B10bcPJ 6zpYolVi3UdrRu7yYt7ZWs4ad+/QWUMMgXeoL9U75/6Q/yOWW97QuoUDebjzanpcHobAWavNgXbw DhmpYMv9A/VTrzz9sDz+DQAA//8DAFBLAwQUAAYACAAAACEAowPb8Z8BAAAQBQAAEgAAAHdvcmQv Zm9udFRhYmxlLnhtbLyT3UrDQBCF7wXfIey9ZptWrcVUtNpLL0QfYJpMmoX9CTtro2/vJBsVqYVW 0A0Ecmb3ZPLlzNX1q9HJBj0pZ3MxOpUiQVu4Utl1Lp6flidTkVAAW4J2FnPxhiSu58dHV+2scjZQ wuctzXwu6hCaWZpSUaMBOnUNWq5VzhsI/OjXqasqVeCdK14M2pBmUp6nHjUEfjfVqiExuLX7uLXO l413BRJxs0ZHPwPKivnQXdLOLBjuegFarbzqCw1YRzji2gZ0LmQml/KM7901kePuLtLOoajBE4bP jTLKFRil3z5UahVRLDQqFPWHvgGvYKUxlkitufBCK5mLG8kru1+KqIxyMekEeXE7KBk3NaxBGX9X it4nbrnsfVhhn89T3H4a/88WiSdlkJIHbJNHZyCi2iaSyXMmccY8OjLjg4j43rcnuCcRDoLMbqYX X0Sm37//iwinsee4m8hoeSCRBRiOBuzIRkcgkuiIHJaNw0n8nA0pJ/+SjQWPodNAO1DcciguGcFv xsS4Er39YU4q9Yrl/kPyRyCGaaH5OwAAAP//AwBQSwMEFAAGAAgAAAAhAA61UrzrBAAAq1kAABQA AAB3b3JkL3dlYlNldHRpbmdzLnhtbOxcS4/bRgy+F+h/MHRvPE/OjBFvgG2QXtIH0jR3ra1dC5A1 hqSsu/n1pSV5bTerwEItj1PzsLA8euyYFPmRHznz+s3fy2z0mBRl6vNpxF+xaJTkMz9P84dp9NfH dz/ZaFRWcT6PM58n0+gpKaM3Nz/+8Ho9WSd3fyZVhVeWI3xKXk6KabSoqtVkPC5ni2QZl6/8Ksnx 3L0vlnGFX4uHsb+/T2fJWz/7vEzyaiwYg3GRZHGFMygX6aqM2qetj3na2hfzVeFnSVniRJZZ87xl nObRDc5xnj6W7edoPUnn0wg0cA22Pnvn509v00c88xhn+Ouj8ebaZVy8T+6r51HNnsc/pA+LF098 9KuXrr/1VeWXX53BWd3Oi83/qnb35SjfCC8tv0wj1AIerOIZSrw+nvnMo3Tjz5VvJpPtzbDfnXcH c+p3b7H/+/vcOq5VUf/o5vBQKVppzYV1pJXmTewj2vVkKK1IDkYaLchYWgdxGWpRYIySSsLx1tLh wXbDe/5rN3jovdrxq/ZdDaD8vEiz+aEDU1YZzrlhtU7+hSA7iR7gx26YpN8NdXvI0Sl9wYUUwJVu AITE/1W4cAqI6BS/1NooZrQO8fJvwr7sOXCCvcCpPm4lIZSUGr730KlTA/jqgwTFHPmfjnh5UAPg xnLnjJbkfwYU/zZxaD7LFoWHHq1tDrOxOndUwiDQaEORV59cdVDbA8GZBKnI9AY0vW7g4Q7B31kl QmB/v3zs+6VMOsUv2CbvcMY2uSAFvoMEvqeDmEMw0QDOcWJXLopdMcw6DkzJ4zGeE0P8zEufAuu3 9rZvLY5p0NL2UcuOX/mwT1vvhol2+W+0CwcBzGrLGlsh9BkEfTrB31jBlJC2ARCS/nmlz62zmmM6 GIRyIdYLS7lYBuGM2yYbp/f/zO+/1lY66xSnzO/lEv0pQ6FwnBcXDHWs0NNRQHxJxXkuuMH0HwmA 4/WyC30pIq47fvoQSI0Jtn07m76iF8rAXFmJLRMYFpNTHM4pdkbEnDkAaQzVgbvaxk6BSd3iF1iD FFYbKgR/o3NvWBVgN6UWmBcGUUEfd7qe/A/5eGMtGKbCGMC1SH9LD4aMiYW1VmB/5PGxF5HEu+bl U7jA7VuwTxJzJbASzKygmLhXM/kp9NEdFTDptDPAKSYOUqEHY43k28oJ0WTnpckkA2cF/oVICIkl RpYYW+U1xzU/FBEHcT9Owoam4lQjHFD822AoYEgMABawFalB+aNW1hEdeZq1W92hFxiQDElJKpEF M76D/ASs3NRTGC10vKieL24FJvNCtW2U5LyOXIQ8bN4IgM0tTgsK3C7DeTkLykhMaI4nvQjhh0Z4 pQ2uflQmSH55LYxzd4BluEaD4JK4rQF9VKf4cc0v1tuR7yVypXunkGFBGtdeGWxBhYZxJ3bxvOyi NhIsuv8Q7/+1OP/w3AoCPOfSiZbCpPTkItITKRXmjazdHYc833k9H5bTOTZaIMFFvi9Epx2y+gC4 N1QI6VNZC8taXCqhrcL11yFUcC3g35164Mor3IWLUeI3YOJ3CaGXklZi+ZK2/LikjqLNwjstKe8J 0+aNPfYIPpIq+gO6vk7gUUwxyTD1INgfLu49OfBsdov0qypdpl+Sd764Lfy6TIp6u2Hc+/jp9/zT r+/rb3GW+fUfv/2CX3ASe1ss3/wDAAD//wMAUEsDBBQABgAIAAAAIQAbpvcf+wEAAPkDAAAQAAgB ZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTy27b MBC8F+g/CDo3puQ6qWPQDAoHRVq0iQEryZmlVjYRiSTItRrn67uUYkVue6pPsw8Mx7MjfvXc1EkL Pmhrlmk+ydIEjLKlNttlel98OZunSUBpSllbA8v0ACG9Eu/f8bW3DjxqCAlRmLBMd4huwVhQO2hk mNDY0KSyvpFIpd8yW1VawbVV+wYMsmmWXTB4RjAllGduIEx7xkWL/0taWhX1hYfi4Eiw4AU0rpYI 4jbKqSelxYazocsLi7IudAMiz8/nNBlqvpZbCCLnrAf80foyiMvskrMe8tVOeqmQTBTn+fwTZ6MG /+xcrZVE8lf80MrbYCtM7jonkkjA2XiFkzsbUHuv8SAyzsYl/64NSZl95KxHpM3LrZduRwKnUeFQ 8o2SNazIBFHJOgBnbw1+AzIeeC01SeYtLlpQaH0S9AudeJomP2WAaN0ybaXX0iBZGNf6osO1C+hF obEmbpr1dQfHa2OsZ9FG2iVwuhibvQYanKrrXgh3Ff03/IfYfCy209BLHckZweGNP1hXtnHSHMS3 vdGU6uQW8Jf1T+FD8tWoCR30dR4v8BTuXWGvY5henT1tjuLwqHG3cVLR0S6y+WwcjNGIbyg/UNKl j4RvDX5DV/B1fJVCZbZQHnf+HsSoPfRfMqVhktGvy9axR/kYPjHxGwAA//8DAFBLAwQUAAYACAAA ACEAEpXDOXsBAADmAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAjFLBTsMwDL0j8Q9V7m2adYypajsJ0E5MQqIIxC0k3hbWplGSrevfk7Zb twoO3GK/52f7OcniWBbeAbQRlUwRCULkgWQVF3KTord86c+RZyyVnBaVhBQ1YNAiu71JmIpZpeFF Vwq0FWA8pyRNzFSKttaqGGPDtlBSEziGdOC60iW1LtQbrCjb0Q3gSRjOcAmWcmopbgV9NSiikyRn g6Ta66IT4AxDASVIazAJCL5wLejS/FnQIVfMUthGuZ1O415rc9aDA/toxECs6zqoo24MNz/BH6vn 125VX8jWKwYoSziLrbAFZAm+PN3L7L++gdk+PQQOYBqorXSmGS2c113ZOde6vYOmrjQ3rnIUuVIO hmmhrLthrztKOHZBjV25o64F8Ifm0uI31HbScBDtf8jItOs1xG6pzsN+VuCecyXuPTwj79HjU75E 2SQkxA9nPolyMo+jKA7Dz3alUX3rUp8oT8P9Q3Fyn4ckvpuOFc8CvTvjn5n9AAAA//8DAFBLAwQU AAYACAAAACEAwykSTaEIAAD5QQAADwAAAHdvcmQvc3R5bGVzLnhtbNxbS3PbOAy+78z+B43ubfxI 7CZTt5PmselMmqZ1MnumJTrWRpa8opxHf/2CoCTraQGRetlcHFEkPoAAPtAJ8fHzy9q3nmSkvDCY 2cP3A9uSgRO6XvAws+/vLt99sC0Vi8AVfhjImf0qlf35059/fHw+UfGrL5UFAgJ1Es3sVRxvTg4O lLOSa6HehxsZwLtlGK1FDI/Rw0G4XHqOPA+d7VoG8cFoMJgcRNIXMYCrlbdRdiLtmSLtOYzcTRQ6 UinQdu0beWvhBfYnUM8NnXO5FFs/Vvoxuo2Sx+QJPy7DIFbW84lQjufdgeJg4toLwujqNFCeDW+k UPGp8kTty5WeVfvGUXFO2hfP9ewDjah+gcwn4c/s0SgdOdMaFMZ8ETykYzJ4dz/PazKzs6EFyJ3Z Ino3P9XCDtDM9DNn7qZgPDyhKhvhwMYBju9p146mEw2jH35ufRgQ2zhMxOISEJ8XBI+lPQZPgl/n Ji7grVxeh86jdOcxvJjZEFs4eP/1NvLCyItfZ/bxcTI4l2vvynNdqcMwnRisPFf+vZLBvZLubvzH JQZVItEJt0EM6k+m6HdfuRcvjtzooAK8QGif3ugFvharcjio0NbbaWMGSqg4+G8KOTReq0VZSaET x0L99wKh1dvOQCNtUd4AlMvSddxdxGF3EUfdRWDwdtuLaXctgC67esTERi4q6U6NQ8cEX34fxsd7 QlavqERR64pK0LSuqMRI64pKSLSuqERA64qKw1tXVPzbuqLizr0rHIHEVY6iMe4GKbHvvNiXev1e Ahp2pLqkuFi3IhIPkdisLF1Ky2rvI8v5dhHTVEU6fTtZzuMoDB5adwTqsU7dN3PyxXqzEsqDM0zL 1o86bv2dWPjS+ivy3FaoIxN8FZvwKFJbwm594chV6Lsysu7ki/EoY/1NaM3NuaJVuY5uvfYeVrE1 X2HJbQWbNGx6804Y+deewj3Ym0yTBlPahJN8OGmIy2bh36Trbdfp1hBOIxPD5ww3lyBQxf1bdKhd VM2uViu0AygmmHLBNwHlE/Q3xYUvX/uYor8pRW+UT9DfFK43ysf42O9fNtOci+jRIqXXlJ27Z6Ef Rsutn+ZAKz1M2RmcQdBMYCdxJp9EElN2Bhfo0zp1HPjmRolTti92PMpAYbvDoGCy0W1hO6VEe0OG RWwHlbBGDKxuXMsAYpPuT/nk6T81cYsBsnR21mxN53HDDkAJIp2hf2zDuP0MPWrgPCrK1wD+XKKk RUMbN2QeFS2JJ1PvGD7uVvgYQN0qIAOoWylkADXER/OZJ6uJdJDuxZGBxablrIph2JGZecpm5gyI VwJ6qpuE81dD9jbHQrVuElDYDqrWTQIK2zulWpbVTQJWb3WTgNVQNZp9lOdUjlHsupkHyk4CBIv6 IW8CUD/kTQDqh7wJQN3Jux2kP/ImYLG5IePUPHkTgHAK56t+BpQnbwIQmxsM2yV/M0rrHkrZ/+W2 B/ImoLAdVCVvAgrbO03kTcDCKZxIKGFlVEfA6oe8CUD9kDcBqB/yJgD1Q94EoH7ImwDUnbzbQfoj bwIWmxsyTs2TNwGITQ8ZUJ68CUA4hcMNteSNWf/byZuAwnZQlbwJKGzvlAg1O6QSsNgOKmFl5E3A wimcYEiwMLg5RvVD3gSL+iFvAlA/5E0A6oe8CUDdybsdpD/yJmCxuSHj1Dx5E4DY9JAB5cmbAMTm hlryxmT87eRNQGE7qEreBBS2d0qEmvEcAYvtoBJWRt4ELIyXzuRNAMIpbwXiWNQPeRMs6oe8CUD9 kDcBqDt5t4P0R94ELDY3ZJyaJ28CEJseMqA8eROA2NxQS96YI7+dvAkobAdVyZuAwvZOiVAz8iZg sR1UwsqojoDVD3kTgDAwO5M3AQinvAEIs4jjpn7Im2BRP+RNAOpO3u0g/ZE3AYvNDRmn5smbAMSm hwwoT94EIDY36Hu2cF+UfD112BAE1HsG6a0GMuCowUlUwMTAn3IpI+hdku23QzoCphYyEBvCg2ri lzB8tGgXu8cNAUKG8ha+F+KV7le8pZNrRBhP93QS3H0/s65MA0xlHYZU8eYNdA/l24WwIUk3DoGe 8esGWnY26c1yLQ1aiXQnV9IChJ1nX6EhKGnr0Yt1nw9MxDaqZBj/b5ug4u/Q5eamcwaDi8PhxdFR 0uCEIluUyGATM8fYb5QHThuAxmafFgLalr7rLqSKWgHcra4bh+6rx3Q8hTlbicgI3LV1pHOS3o7d OQwNLVa/ln04Hh4OJ+cGIGkNe5RycwMa4kr9cA1NYQqfVNY1tpDQ2weOgjY+szjcxrp57PrJT7XD FjfTNqb3Fnrw8KO26078s6frTr+8SDrxdDwUGu8KK3eNd3p413i3QO0XZ8YKR18QTbU8vPww/HKu xWLPHjIzdL/hlUjsYAALUHX4bIgTB1wknFhGe4I1aZnIbrFhw0Q5dBv6KlD5qveT/oo27zfrHete gj06Y6/B3iyzcEpjeL4pPuOFbyIFfvka6JSFhlD8H6yhBvdFGEB4fyZ9/5vAuIrDTfNUXy51woGg 4QDPUyVRizCOw3Xz+gjbDRoFwBbnlTGP2ojmvQ+264WMoF9wz/7fhPocUuEZ6LLA8YawgKZKk6tZ r6OZWLj9DUPNuhXiecd7QMyRZqiKQlfZG0QqEV9t5BuVsuoCO48kmepeQ2FF+p4cDi5HF8bQhFgK WT2An8vLclaviopuU1jdQgyZYDaFk+zOVkHczHXpKlenAn+XEz15aY2tHb2Tt62uSpidqHJEfSwU 9zJfAv6/JF04UeyC+u7b9W2kaxn0qcfSrcY2TLAKM+piPH/mKLinJH7n7RpX1fuqNRXy7ksq+K5M 65IMRfoQ+VM/1Dd3N1TnmX0GvfmhL5TOJCy7uSHciFxLe3IQUL9yLe04BkzTV1LV7Wclucou65xk JdTGZKv3IDPbcjvc76anhK8+/QcAAP//AwBQSwECLQAUAAYACAAAACEA3fyVN2YBAAAgBQAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAA AE4CAAALAAAAAAAAAAAAAAAAAJ8DAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDWZLNR+gAA ADEDAAAcAAAAAAAAAAAAAAAAAMMGAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhAKut19+kEwAAhGYAABEAAAAAAAAAAAAAAAAA/wgAAHdvcmQvZG9jdW1lbnQueG1s UEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAA0hwAAHdvcmQvdGhlbWUv dGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQC4TvvpfAMAAPYIAAARAAAAAAAAAAAAAAAAAJsjAAB3 b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCjA9vxnwEAABAFAAASAAAAAAAAAAAAAAAA AEYnAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEADrVSvOsEAACrWQAAFAAAAAAA AAAAAAAAAAAVKQAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAG6b3H/sBAAD5 AwAAEAAAAAAAAAAAAAAAAAAyLgAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQASlcM5 ewEAAOYCAAARAAAAAAAAAAAAAAAAAGMxAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAA IQDDKRJNoQgAAPlBAAAPAAAAAAAAAAAAAAAAABU0AAB3b3JkL3N0eWxlcy54bWxQSwUGAAAAAAsA CwDBAgAA4zwAAAAA --_004_DF7F294AF4153D498141CBEFADB17704C29E7B9DF8EMBX01WFjnprn_-- From rcallon@juniper.net Mon Jun 27 11:57: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 B7A3A21F85C1 for ; Mon, 27 Jun 2011 11:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 qUq8HHv3GHRC for ; Mon, 27 Jun 2011 11:57:49 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id A741221F85BF for ; Mon, 27 Jun 2011 11:57:48 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTgjSrDR+RzpXjKmQ+cc3/0atqPEZCQPI@postini.com; Mon, 27 Jun 2011 11:57:48 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; Mon, 27 Jun 2011 11:55:56 -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; Mon, 27 Jun 2011 14:55:55 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Mon, 27 Jun 2011 14:55:50 -0400 Thread-Topic: Publication Request: draft-ietf-mpls-tp-on-demand-cv-05 Thread-Index: Acw0yCF7/izB8GVsSlqRHsHB/LCfVQAM45eg 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="_002_DF7F294AF4153D498141CBEFADB17704C29E7B9E1EEMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] FW: Publication Request: 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: Mon, 27 Jun 2011 18:57:49 -0000 --_002_DF7F294AF4153D498141CBEFADB17704C29E7B9E1EEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI. This was supposed to go to "mpls@ietf.org" rather than "mpls-tp@ietf.o= rg".=20 -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, June 27, 2011 8:45 AM To: IETF-IESG via RT Cc: Adrian Farrel; Ross Callon; George Swallow; draft-ietf-mpls-tp-on-deman= d-cv@tools.ietf.org; mpls-tp@ietf.org Subject: Publication Request: draft-ietf-mpls-tp-on-demand-cv-05 IESG, the MPLS Working Group that draft-ietf-mpls-tp-on-demand-cv-05 is published as an RFC on the Standards Track. The shepherd write-up is attached. /Loa for the mpls wg --=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 --_002_DF7F294AF4153D498141CBEFADB17704C29E7B9E1EEMBX01WFjnprn_ Content-Type: text/plain; name="Proto Writeup on-demand-cv.txt" Content-Description: Proto Writeup on-demand-cv.txt Content-Disposition: attachment; filename="Proto Writeup on-demand-cv.txt"; size=6676; creation-date="Mon, 27 Jun 2011 08:45:44 GMT"; modification-date="Mon, 27 Jun 2011 08:45:44 GMT" Content-Transfer-Encoding: base64 DQoNClRoZSBNUExTIFdHIHJlcXVlc3RzIHRoYXQ6DQoNCiAgICAgICBNUExTIE9uLWRlbWFuZCBD b25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIGFuZCBSb3V0ZSBUcmFjaW5nDQogICAgICAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC1jdi0wNQ0KDQppcyBwdWJsaXNoZWQg YXMgYW4gUkZDIG9uIHRoZSBzdGFuZGFyZHMgdHJhY2suDQoNCg0KPiAoMS5hKSBXaG8gaXMgdGhl IERvY3VtZW50IFNoZXBoZXJkIGZvciB0aGlzIGRvY3VtZW50PyBIYXMgdGhlDQo+ICAgICAgIERv Y3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3ZWQgdGhpcyB2ZXJzaW9uIG9mIHRoZQ0K PiAgICAgICBkb2N1bWVudCBhbmQsIGluIHBhcnRpY3VsYXIsIGRvZXMgaGUgb3Igc2hlIGJlbGll dmUgdGhpcw0KPiAgICAgICB2ZXJzaW9uIGlzIHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJ RVNHIGZvciBwdWJsaWNhdGlvbj8NCg0KTG9hIEFuZGVyc3NvbiBpcyB0aGUgRG9jdW1lbnQgU2hl cGhlcmQuDQpIZSBoYXMgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBiZWxpZXZlcyBpdCBpcyBy ZWFkeSB0byBiZQ0KZm9yd2FyZGVkIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4NCg0KDQo+ ICgxLmIpIEhhcyB0aGUgZG9jdW1lbnQgaGFkIGFkZXF1YXRlIHJldmlldyBib3RoIGZyb20ga2V5 IFdHIG1lbWJlcnMNCj4gICAgICAgYW5kIGZyb20ga2V5IG5vbi1XRyBtZW1iZXJzPyBEb2VzIHRo ZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlDQo+ICAgICAgIGFueSBjb25jZXJucyBhYm91dCB0aGUg ZGVwdGggb3IgYnJlYWR0aCBvZiB0aGUgcmV2aWV3cyB0aGF0DQo+ICAgICAgIGhhdmUgYmVlbiBw ZXJmb3JtZWQ/DQoNClRoZSBkb2N1bWVudCBoYXMgYmVlbiByZXZpZXdlZCBpbiB0aGUgbXBscyB3 b3JraW5nIGdyb3VwIGFuZCBieSBTRzE1DQpvZiB0aGUgSVRVLVQuDQoNClRoZSBzaGVwaGVyZWQg aXMgY29udmluY2VkIHRoYXQgdGhpcyBpcyBhbXBsZSByZXZpZXcgZm9yIHRoaXMgDQpkb2N1bWVu dC4NCg0KDQo+ICgxLmMpIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgY29uY2VybnMg dGhhdCB0aGUgZG9jdW1lbnQNCj4gICAgICAgbmVlZHMgbW9yZSByZXZpZXcgZnJvbSBhIHBhcnRp Y3VsYXIgb3IgYnJvYWRlciBwZXJzcGVjdGl2ZSwNCj4gICAgICAgZS5nLiwgc2VjdXJpdHksIG9w ZXJhdGlvbmFsIGNvbXBsZXhpdHksIHNvbWVvbmUgZmFtaWxpYXIgd2l0aA0KPiAgICAgICBBQUEs IGludGVybmF0aW9uYWxpemF0aW9uIG9yIFhNTD8NCg0KTm8uDQoNCg0KPiAoMS5kKSBEb2VzIHRo ZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBzcGVjaWZpYyBjb25jZXJucyBvcg0KPiAgICAg ICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGly ZWN0b3INCj4gICAgICAgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gRm9yIGV4 YW1wbGUsIHBlcmhhcHMgaGUNCj4gICAgICAgb3Igc2hlIGlzIHVuY29tZm9ydGFibGUgd2l0aCBj ZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3INCj4gICAgICAgaGFzIGNvbmNlcm5zIHdo ZXRoZXIgdGhlcmUgcmVhbGx5IGlzIGEgbmVlZCBmb3IgaXQuIEluIGFueQ0KPiAgICAgICBldmVu dCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVk DQo+ICAgICAgIHRoYXQgaXQgc3RpbGwgd2lzaGVzIHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50LCBk ZXRhaWwgdGhvc2UNCj4gICAgICAgY29uY2VybnMgaGVyZS4gSGFzIGFuIElQUiBkaXNjbG9zdXJl IHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudA0KPiAgICAgICBiZWVuIGZpbGVkPyBJZiBzbywgcGxl YXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlDQo+ICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1 bW1hcml6ZSB0aGUgV0cgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBvbg0KPiAgICAgICB0aGlz IGlzc3VlLg0KDQpObyBzdWNoIGNvbmNlcm5zLiBUaGVyZSBpcyBubyBJUFIgY2xhaW0gZm9yIHRo aXMgZHJhZnQuDQoNCg0KPiAoMS5lKSBIb3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1cyBiZWhp bmQgdGhpcyBkb2N1bWVudD8gRG9lcyBpdA0KPiAgICAgICByZXByZXNlbnQgdGhlIHN0cm9uZyBj b25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aA0KPiAgICAgICBvdGhlcnMgYmVp bmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBhIHdob2xlIHVuZGVyc3RhbmQgYW5kDQo+ICAg ICAgIGFncmVlIHdpdGggaXQ/DQoNClRoZXJlIGlzIGEgZ29vZCBjb25zZW5zdXMgYXJvdW5kIHRo aXMgZHJhZnQsIGl0IGhhcyBwYXNzZWQgdGhlIGNhbGwgdG8gdmVyaWZ5IA0KdGhhdCBMQyBjb21t ZW50cyB3ZXJlIGNvcnJlY3RseSBhZGRyZXNzZWQgd2l0aCBvbmx5IG1pbm9yIGNvbW1lbnRzLiAN Cg0KDQo+ICgxLmYpIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNl IGluZGljYXRlZCBleHRyZW1lDQo+ICAgICAgIGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3Vt bWFyaXNlIHRoZSBhcmVhcyBvZiBjb25mbGljdCBpbg0KPiAgICAgICBzZXBhcmF0ZSBlbWFpbCBt ZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0DQo+ICAgICAgIHNo b3VsZCBiZSBpbiBhIHNlcGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlz DQo+ICAgICAgIGVudGVyZWQgaW50byB0aGUgSUQgVHJhY2tlci4pDQoNCk5vIHRocmVhdHMgb3Ig ZXh0cmVtZSBkaXNjb250ZW50Lg0KDQoNCj4gKDEuZykgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVy ZCBwZXJzb25hbGx5IHZlcmlmaWVkIHRoYXQgdGhlDQo+ICAgICAgIGRvY3VtZW50IHNhdGlzZmll cyBhbGwgSUQgbml0cz8gKFNlZSB0aGUgSW50ZXJuZXQtRHJhZnRzIENoZWNrbGlzdA0KPiAgICAg ICBhbmQgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8pLiBCb2lsZXJwbGF0ZSBj aGVja3MgYXJlDQo+ICAgICAgIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUgdGhv cm91Z2guIEhhcyB0aGUgZG9jdW1lbnQNCj4gICAgICAgbWV0IGFsbCBmb3JtYWwgcmV2aWV3IGNy aXRlcmlhIGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRoZSBNSUINCj4gICAgICAgRG9jdG9yLCBtZWRp YSB0eXBlIGFuZCBVUkkgdHlwZSByZXZpZXdzPw0KDQpZZXMgLSB0aGVyZSBpcyBvbmUgY2FzZSB3 aGVyZSB0aGVyZSBpcyBhIGxhdGVyIGRvY3VtZW50IHRoYW4gdGhlIG9uZQ0KcmVmZXJlbmNlZCwg YnV0IGJvdGggZG9jdW1lbnRzIGFyZSBzdGlsbCBtb3Zpbmcgc28gaXQgaXMgdmVyeSBoYXJkIHRv IA0KY29vcmRpbmF0ZSB0aGF0IChhbmQgbm90IHJlYWxseSBuZWNjZXNzYXJ5KS4NCg0KDQo+ICgx LmgpIEhhcyB0aGUgZG9jdW1lbnQgc3BsaXQgaXRzIHJlZmVyZW5jZXMgaW50byBub3JtYXRpdmUg YW5kDQo+ICAgICAgIGluZm9ybWF0aXZlPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMg dG8gZG9jdW1lbnRzIHRoYXQNCj4gICAgICAgYXJlIG5vdCByZWFkeSBmb3IgYWR2YW5jZW1lbnQg b3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyDQo+ICAgICAgIHN0YXRlPyBJZiBzdWNoIG5v cm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZQ0KPiAgICAgICBzdHJhdGVneSBm b3IgdGhlaXIgY29tcGxldGlvbj8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzDQo+ICAg ICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2NyaWJlZCBpbiBbUkZDMzk2 N10/IElmDQo+ICAgICAgIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3Vw cG9ydCB0aGUgQXJlYQ0KPiAgICAgICBEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxsIHByb2NlZHVy ZSBmb3IgdGhlbSBbUkZDMzk2N10uDQoNClJlZmVyZW5jZXMgYXJlIGNvcnJlY3RseSBzcGxpdC4N Cg0KQWxsIGRvY3VtZW50cyB0aGF0IGFyZSByZWZlcmVuY2VkIGFyZSBwYXN0IHdvcmtpbmcgZ3Jv dXAgbGFzdA0KY2FsbCAoUkZDcywgYXBwcm92ZWQgYnkgdGUgSUVTRyBvciBwdWJsaWNhdGlvbiBy ZXF1ZXN0ZWQpLiBJbg0Kb25lIGNhc2Ugd2UgYXJlIHdyaXRpbmcgdGhlIHJlcXVlc3QgZm9yIHB1 YmxpY2F0aW9uIGluIHBhcmFsbGVsIA0Kd2l0aCB0aGlzIG9uZS4NCg0KDQo+ICgxLmkpIEhhcyB0 aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUgZG9jdW1lbnQgSUFOQQ0KPiAg ICAgICBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGgg dGhlIGJvZHkNCj4gICAgICAgb2YgdGhlIGRvY3VtZW50PyBJZiB0aGUgZG9jdW1lbnQgc3BlY2lm aWVzIHByb3RvY29sDQo+ICAgICAgIGV4dGVuc2lvbnMsIGFyZSByZXNlcnZhdGlvbnMgcmVxdWVz dGVkIGluIGFwcHJvcHJpYXRlIElBTkENCj4gICAgICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5B IHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVkPyBJZg0KPiAgICAgICB0aGUgZG9jdW1lbnQg Y3JlYXRlcyBhIG5ldyByZWdpc3RyeSwgZG9lcyBpdCBkZWZpbmUgdGhlDQo+ICAgICAgIHByb3Bv c2VkIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5IGFuZCBhbiBhbGxvY2F0aW9uDQo+ ICAgICAgIHByb2NlZHVyZSBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2Vz dCBhDQo+ICAgICAgIHJlYXNvbmFibGUgbmFtZSBmb3IgdGhlIG5ldyByZWdpc3RyeT8gU2VlIFtS RkM1MjI2XS4gSWYgdGhlDQo+ICAgICAgIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBFeHBlcnQgUmV2 aWV3IHByb2Nlc3MgaGFzIFNoZXBoZXJkDQo+ICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNw b25zaWJsZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cNCj4gICAgICAgY2FuIGFwcG9p bnQgdGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIHRoZSBJRVNHIEV2YWx1YXRpb24/DQoNClRoZXJl IGlzIGEgd2VsbC13cml0dGVuIElBTkEgc2VjdGlvbiBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCj4g KDEuaikgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0aGF0IHNlY3Rpb25zIG9m IHRoZQ0KPiAgICAgICBkb2N1bWVudCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1 YWdlLCBzdWNoIGFzIFhNTA0KPiAgICAgICBjb2RlLCBCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9u cywgZXRjLiwgdmFsaWRhdGUgY29ycmVjdGx5IGluDQo+ICAgICAgIGFuIGF1dG9tYXRlZCBjaGVj a2VyPw0KDQpObyBzdWNoIGZvcm1hbCBsYW5ndWFnZS4NCg0KDQo+ICgxLmspIFRoZSBJRVNHIGFw cHJvdmFsIGFubm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50DQo+ICAgICAgIEFubm91bmNl bWVudCBXcml0ZS1VcC4gUGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3VtZW50DQo+ICAgICAgIEFu bm91bmNlbWVudCBXcml0ZS1VcD8gUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUN Cj4gICAgICAgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBU aGUgYXBwcm92YWwNCj4gICAgICAgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcg c2VjdGlvbnM6DQoNClRlY2huaWNhbCBTdW1tYXJ5DQoNCiAgIExTUC1QaW5nIGlzIGEgcHJvdG9j b2wgdGhhdCBoYXMgYmVlbiB1c2VkIGZvciBNUExTIExTUHMgYWxtb3N0DQogICBzaW5jZSB0aGUg TVBMUyBuZXR3b3JrcyB3ZXJlIGZpcnN0IGRlcGxveWVkLCBpdCBpcyB0aGUgbW9zdCAgd2lkZWx5 IA0KICAgZGVwbG95ZWQgT0FNIG1lY2hhbmlzbSBmb3IgTVBMUyBMU1BzLiAgDQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBleHRlbnNpb25zIHRvIExTUC1QaW5nIHNvIHRoYXQgTFNQLQ0KICAg UGluZyBjYW4gYmUgdXNlZCBmb3IgT24tZGVtYW5kIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24g b2YgTVBMUy1UUA0KICAgTFNQcy4gIFRoaXMgZG9jdW1lbnQgYWxzbyBjbGFyaWZpZXMgcHJvY2Vk dXJlcyB0byBiZSB1c2VkIGZvcg0KICAgcHJvY2Vzc2luZyB0aGUgcmVsYXRlZCBPQU0gcGFja2V0 cy4gIEZ1cnRoZXIsIGl0IGRlc2NyaWJlcyBwcm9jZWR1cmVzDQogICBmb3IgdXNpbmcgTFNQLVBp bmcgdG8gcGVyZm9ybSBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIGFuZCBSb3V0ZQ0KICAgVHJh Y2luZyBmdW5jdGlvbnMgaW4gTVBMUy1UUCBuZXR3b3Jrcy4gIEZpbmFsbHkgdGhpcyBkb2N1bWVu dCB1cGRhdGVzDQogICBSRkMgNDM3OSBieSBhZGRpbmcgYSBuZXcgYWRkcmVzcyB0eXBlIGFuZCBy ZXF1ZXN0aW5nIGEgcmVnaXN0cnkuDQoNCldvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KDQogICBUaGlz IGRvY3VtZW50IGlzIGEgTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LCBhbmQgcGFydCBvZiB0 aGUgam9pbnQNCiAgIElFVEYgYW5kIElUVS5UIE1QTFMtVFAgcHJvamVjdC4gSXQgaGFzIGJlZW4g cmV2aWV3ZWQgaW4gYm90aCBvcmdhbml6YXRpb25zDQogICBhbmQgdGhlcmUgaXMgYSBzb2xpZCBz dXBwb3J0IGZvciB0aGUgZG9jdW1lbnQuDQoNCkRvY3VtZW50IFF1YWxpdHkNCg0KICAgVGhlIGRv Y3VtZW50IGlzIHdlbGwgcmV2aWV3ZWQgaW4gdGhlIE1QTFMgd29ya2luZyBncm91cCBhbmQgSVRV LVQuDQoNCg== --_002_DF7F294AF4153D498141CBEFADB17704C29E7B9E1EEMBX01WFjnprn_-- From loa@pi.nu Mon Jun 27 13:37: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 8C06911E8175 for ; Mon, 27 Jun 2011 13:37:56 -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 Z5JB58ut6gv8 for ; Mon, 27 Jun 2011 13:37:55 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 33D0911E8174 for ; Mon, 27 Jun 2011 13:37:53 -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 418A1514044 for ; Mon, 27 Jun 2011 22:37:51 +0200 (CEST) Message-ID: <4E08EA1D.6010208@pi.nu> Date: Mon, 27 Jun 2011 22:37:49 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: Nomcom 2011-2012: Second Call for Volunteers 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, 27 Jun 2011 20:37:56 -0000 Working Group, it is the time of the year when we form a new NomCom, please find the call for volunteers below. /Loa -------- Original Message -------- Subject: Nomcom 2011-2012: Second Call for Volunteers Date: Fri, 24 Jun 2011 14:12:41 -0400 From: Suresh Krishnan To: IETF Discussion This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are: Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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 adrian@olddog.co.uk Mon Jun 27 14:38: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 D9F5F11E8164 for ; Mon, 27 Jun 2011 14:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=-0.253, 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 GdRoj9iCa-LM for ; Mon, 27 Jun 2011 14:38:59 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD911E815C for ; Mon, 27 Jun 2011 14:38:59 -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 p5RLcvUs023925; Mon, 27 Jun 2011 22:38:58 +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 p5RLcupg023919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 22:38:57 +0100 From: "Adrian Farrel" To: Date: Mon, 27 Jun 2011 22:38:56 +0100 Message-ID: <066b01cc3512$9f0721f0$dd1565d0$@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: Acw1Epl1e9a+4No9S6KI0ZM/JsUxMg== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-tp-identifiers 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: Mon, 27 Jun 2011 21:39:00 -0000 Hi, I have done my AD review of this document. In view of the fact that my comments are quite small, could you please handle them as part of the IETF last call which I will start forthwith. Thanks, Adrian --- You seem to be missing a section on MEP_IDs for MPLS_TP Sections. Insert before 7.2.1? --- Nits 1.3 OLD The notation does define a preferred ordering of the fields. NEW The notation defines a preferred ordering of the fields. END OLD Z9 is used to indicated the NEW Z9 is used to indicate the END From iesg-secretary@ietf.org Mon Jun 27 15:16: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 45CB021F8705; Mon, 27 Jun 2011 15:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 KqN0cVeJpoFk; Mon, 27 Jun 2011 15:16:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774421F86FA; Mon, 27 Jun 2011 15:16:11 -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.55 Message-ID: <20110627221611.11293.46784.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 15:16:11 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS-TP Identifiers) 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: Mon, 27 Jun 2011 22:16:12 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Identifiers' 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-07-11. 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 This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and OAM functions suitable to IP/MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ No IPR declarations have been submitted directly on this I-D. From rajiva@cisco.com Mon Jun 27 16:10: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 3537521F8450; Mon, 27 Jun 2011 16:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fqo7h7pFCzzi; Mon, 27 Jun 2011 16:10:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E4F8721F8558; Mon, 27 Jun 2011 16:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2452; q=dns/txt; s=iport; t=1309216213; x=1310425813; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=95mEuMYp4I5VkmdniqJDOmp96jgZEKtBliDpBPydGMY=; b=iCSGSNX5jnsoz8+EPWK0iNCXHUEIYWJsurAmFCqguQe4LyzyLiJJ+d5e Fzo78gEVHjTtKDGes+q0ldOp+9chP3LrFdo9/sQPUCRoOqhX4p/UNo+fG CktAUbDvDDn1UYyEPSLra0hj4NS4dNDYMA4RbMElglDGPxIgHVwXAhyHb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBAMQMCU6tJV2Y/2dsb2JhbABSmAmPLneIdKIrniaGMASHLI9Oi0I X-IronPort-AV: E=Sophos;i="4.65,434,1304294400"; d="scan'208";a="723055401" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 23:10:08 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5RNA783009836; Mon, 27 Jun 2011 23:10:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 18:10:08 -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: Mon, 27 Jun 2011 18:10:06 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C054B05F5@XMB-RCD-111.cisco.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] LDP DoD and PW Signalling ... Thread-Index: Acw0nZayI9OcF0gpR7qbFZfRRe6WPgAfV8uQ References: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> From: "Rajiv Asati (rajiva)" To: , , X-OriginalArrivalTime: 27 Jun 2011 23:10:08.0012 (UTC) FILETIME=[5B5F1CC0:01CC351F] Subject: Re: [mpls] [PWE3] 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: Mon, 27 Jun 2011 23:10:15 -0000 Hi Nic, > 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. You mean, define a new 'Common Session Parameters TLV' (in the initialization message) to denote the DU/DoD mode per FEC type? Or a new 'optional parameter' TLV (in the initialization message) to denote the same? Or simply a new capability? I hope that it is not the former. > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's Have we concluded that the above restriction in RFC4447 can not be relaxed? =20 Cheers, Rajiv > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > N.Leymann@telekom.de > Sent: Monday, June 27, 2011 3:41 AM > To: mpls@ietf.org; pwe3@ietf.org > Subject: [PWE3] LDP DoD and PW Signalling ... >=20 > Hi, >=20 > We came across an issue related to the Seamless MPLS Architecture when running > LDP DoD between two nodes if we are trying to set up an PW between the same > nodes. >=20 > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The AN > establishes a LDP DoD with the AG. When we are going to establish a PW between > the AN and the AG as well we run into the problem that RFC4447 specifies only > the DU mode for the targeted LDP session (section 3): >=20 > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." >=20 > From our point of view we should reuse the existing LDP session and go with > only a single LDP session between AN and AG. That has the advantage that we do > not change the behaviour of PW FECs 128/129 (there are other options like > using two LDP sessions with additonal lookbacks or two sessions with single > loopback and LDP DoD for IP FECs, but those have an heavy - negative impact - > on the existing implementations and/or standards). >=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. >=20 > Any comments on that? >=20 > Regards >=20 > Nic > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lizhong.jin@zte.com.cn Mon Jun 27 18:26:51 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 7B38A21F8590; Mon, 27 Jun 2011 18:26:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jj6DlFtFozi; Mon, 27 Jun 2011 18:26:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7972121F84EC; Mon, 27 Jun 2011 18:26:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Tue, 28 Jun 2011 09:23:41 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 20345.3628770995; Tue, 28 Jun 2011 09:26:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5S1QQ8J018105; Tue, 28 Jun 2011 09:26:26 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: N.Leymann@telekom.de MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 28 Jun 2011 09:26:07 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-28 09:26:27, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-28 09:26:27, Serialize complete at 2011-06-28 09:26:27, S/MIME Sign failed at 2011-06-28 09:26:27: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-28 09:26:26, Serialize complete at 2011-06-28 09:26:26 Content-Type: multipart/alternative; boundary="=_alternative 0007EA36482578BD_=" X-MAIL: mse01.zte.com.cn p5S1QQ8J018105 Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [PWE3] 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: Tue, 28 Jun 2011 01:26:51 -0000 This is a multipart message in MIME format. --=_alternative 0007EA36482578BD_= Content-Type: text/plain; charset="US-ASCII" Nic, It does seem an issue. Since PW in RFC4447 only supports DU mode, then PW could still work in DU whatever DU or DoD mode indicated by LDP initializtion message. And the mode indicated by LDP initializtion message would be valid for other FECs, not PW FEC. I agree for a long term, if there are two FECs supported both DU and DoD on one LDP session, then your proposal is a one good option. What's more, in RFC5036 section 3.5.3, it says: "If one LSR proposes Downstream Unsolicited and the other proposes Downstream on Demand, the rules for resolving this difference is: - If the session is for a label-controlled ATM link or a label-controlled Frame Relay link, then Downstream on Demand MUST be used. - Otherwise, Downstream Unsolicited MUST be used. If the label advertisement discipline determined in this way is unacceptable to an LSR, it MUST send a Session Rejected/Parameters Advertisement Mode Notification message in response to the Initialization message and not establish the session." That means if link between AN and AG is Ethernet, then session with DoD mode can not be established. I think we should also remove this restriction in 5036. Regards Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jun 2011 09:41:13 +0200 > From: > To: , > Subject: [PWE3] LDP DoD and PW Signalling ... > Message-ID: > <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds. > t-internal.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, > > We came across an issue related to the Seamless MPLS Architecture > when running LDP DoD between two nodes if we are trying to set up an > PW between the same nodes. > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The > AN establishes a LDP DoD with the AG. When we are going to establish > a PW between the AN and the AG as well we run into the problem that > RFC4447 specifies only the DU mode for the targeted LDP session (section 3): > > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." > > From our point of view we should reuse the existing LDP session and go with > only a single LDP session between AN and AG. That has the advantage that we > do not change the behaviour of PW FECs 128/129 (there are other options like > using two LDP sessions with additonal lookbacks or two sessions with single > loopback and LDP DoD for IP FECs, but those have an heavy - negative > impact - on the existing implementations and/or standards). > > For a more long term approach we are in favour of a change to RFC5036 by de- > fining a new TLV which denotes the DU/DoD mode per FEC type. > > Any comments on that? > > Regards > > Nic > > > ------------------------------ > -------------------------------------------------------- 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 0007EA36482578BD_= Content-Type: text/html; charset="US-ASCII"
            Nic,
            It does seem an issue. Since PW in RFC4447 only supports DU mode, then PW could still work in DU whatever DU or DoD mode indicated by LDP initializtion message. And the mode indicated by LDP initializtion message would be valid for other FECs, not PW FEC. I agree for a long term, if there are two FECs supported both DU and DoD on one LDP session, then your proposal is a one good option.

            What's more, in RFC5036 section 3.5.3, it says:
            "If one LSR proposes Downstream Unsolicited and the other
            proposes Downstream on Demand, the rules for resolving this
            difference is:
            - If the session is for a label-controlled ATM link or a
            label-controlled Frame Relay link, then Downstream on Demand
            MUST be used.
            - Otherwise, Downstream Unsolicited MUST be used.
            If the label advertisement discipline determined in this way
            is unacceptable to an LSR, it MUST send a Session
            Rejected/Parameters Advertisement Mode Notification message
            in response to the Initialization message and not establish
            the session."

            That means if link between AN and AG is Ethernet, then session with DoD mode can not be established. I think we should also remove this restriction in 5036.

            Regards
            Lizhong


            >
            > ----------------------------------------------------------------------
            >
            > Message: 1
            > Date: Mon, 27 Jun 2011 09:41:13 +0200
            > From: <N.Leymann@telekom.de>
            > To: <mpls@ietf.org>, <pwe3@ietf.org>
            > Subject: [PWE3] LDP DoD and PW Signalling ...
            > Message-ID:
            >    <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.
            > t-internal.com>
            >    
            > Content-Type: text/plain; charset="us-ascii"
            >
            > Hi,
            >
            > We came across an issue related to the Seamless MPLS Architecture
            > when running LDP DoD between two nodes if we are trying to set up an
            > PW between the same nodes.
            >
            > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The
            > AN establishes a LDP DoD with the AG. When we are going to establish
            > a PW between the AN and the AG as well we run into the problem that
            > RFC4447 specifies only the DU mode for the targeted LDP session (section 3):
            >
            >    "An LDP session must be set up between the pseudowire endpoints.
            >     LDP MUST be used in its 'downstream unsolicited' mode.  LDP's
            >     'liberal label retention' mode SHOULD be used."
            >
            > From our point of view we should reuse the existing LDP session and go with
            > only a single LDP session between AN and AG. That has the advantage that we
            > do not change the behaviour of PW FECs 128/129 (there are other options like
            > using two LDP sessions with additonal lookbacks or two sessions with single
            > loopback and LDP DoD for IP FECs, but those have an heavy -  negative
            > impact - on the existing implementations and/or standards).
            >
            > For a more long term approach we are in favour of a change to RFC5036 by de-
            > fining a new TLV which denotes the DU/DoD mode per FEC type.
            >
            > Any comments on that?
            >
            >   Regards
            >
            >      Nic
            >
            >
            > ------------------------------
            > 

            --------------------------------------------------------
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 0007EA36482578BD_=-- From mach.chen@huawei.com Tue Jun 28 01:51: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 CF5CC21F8625; Tue, 28 Jun 2011 01:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E75QKifL--K; Tue, 28 Jun 2011 01:51:13 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0149C21F8624; Tue, 28 Jun 2011 01:51:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNH003ENSLC60@szxga04-in.huawei.com>; Tue, 28 Jun 2011 16:51:12 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNH00D71SLCWL@szxga04-in.huawei.com>; Tue, 28 Jun 2011 16:51:12 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABO39116; Tue, 28 Jun 2011 16:51:11 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 28 Jun 2011 16:51:09 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.87]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Tue, 28 Jun 2011 16:51:11 +0800 Date: Tue, 28 Jun 2011 08:51:10 +0000 From: Mach Chen In-reply-to: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> X-Originating-IP: [10.110.98.37] To: "N.Leymann@telekom.de" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: LDP DoD and PW Signalling ... Thread-index: Acw0nZayI9OcF0gpR7qbFZfRRe6WPgAqnZYw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [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: Tue, 28 Jun 2011 08:51:13 -0000 Hi Nic, IMHO, if we could category the existing FECs into two types: 1) Controlled by the LDP Session mode( e.g., IPv4/IPv6 FEC, P2MP/MP2MP FEC); 2). Independent of the LDP Session mode (e.g., FEC 128/129); then it just need to relax the restriction of FECs 128/129(the specific mode is determined by the FEC type and does not controlled by the session mode), and the issue in question could be solved easily. And from the view of implementation, it's easy to change the L2VPN module to relax the restriction. BTW, I know some implementations that have already done like this. Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > N.Leymann@telekom.de > Sent: Monday, June 27, 2011 3:41 PM > To: mpls@ietf.org; pwe3@ietf.org > Subject: [PWE3] LDP DoD and PW Signalling ... > > Hi, > > We came across an issue related to the Seamless MPLS Architecture when > running LDP DoD between two nodes if we are trying to set up an PW between > the same nodes. > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The AN > establishes a LDP DoD with the AG. When we are going to establish a PW > between the AN and the AG as well we run into the problem that RFC4447 > specifies only the DU mode for the targeted LDP session (section 3): > > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." > > From our point of view we should reuse the existing LDP session and go with > only a single LDP session between AN and AG. That has the advantage that we > do not change the behaviour of PW FECs 128/129 (there are other options like > using two LDP sessions with additonal lookbacks or two sessions with single > loopback and LDP DoD for IP FECs, but those have an heavy - negative impact > - on the existing implementations and/or standards). > > 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. > > Any comments on that? > > Regards > > Nic > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From kishoret@juniper.net Tue Jun 28 11:38: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 1FB1911E811A; Tue, 28 Jun 2011 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JuLEDqYk1B4J; Tue, 28 Jun 2011 11:38:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0991E11E80EE; Tue, 28 Jun 2011 11:38:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTgofqwhYHoXplr5yf4kctVmn4miFXFNQ@postini.com; Tue, 28 Jun 2011 11:38:45 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 28 Jun 2011 11:35:17 -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; Tue, 28 Jun 2011 14:35:16 -0400 From: Kishore Tiruveedhula To: "lizhong.jin@zte.com.cn" , "N.Leymann@telekom.de" Date: Tue, 28 Jun 2011 14:35:15 -0400 Thread-Topic: [mpls] [PWE3] LDP DoD and PW Signalling ... Thread-Index: Acw1MpfrB9L9SCAqTImcEs1XcwLRqgAjTVvA 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_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] 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: Tue, 28 Jun 2011 18:38:49 -0000 --_000_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That means if link between AN and AG is Ethernet, then session with DoD mod= e can not be established. I think we should also remove this restriction in= 5036. [Kishore] If both AN and AGN proposes the DOD, then DOD session can be esta= blished over Ethernet. Right? Thanks, Kishore Regards Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jun 2011 09:41:13 +0200 > From: > To: , > Subject: [PWE3] LDP DoD and PW Signalling ... > Message-ID: > <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds. > t-internal.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi, > > We came across an issue related to the Seamless MPLS Architecture > when running LDP DoD between two nodes if we are trying to set up an > PW between the same nodes. > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The > AN establishes a LDP DoD with the AG. When we are going to establish > a PW between the AN and the AG as well we run into the problem that > RFC4447 specifies only the DU mode for the targeted LDP session (section = 3): > > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." > > From our point of view we should reuse the existing LDP session and go wi= th > only a single LDP session between AN and AG. That has the advantage that = we > do not change the behaviour of PW FECs 128/129 (there are other options l= ike > using two LDP sessions with additonal lookbacks or two sessions with sing= le > loopback and LDP DoD for IP FECs, but those have an heavy - negative > impact - on the existing implementations and/or standards). > > For a more long term approach we are in favour of a change to RFC5036 by = de- > fining a new TLV which denotes the DU/DoD mode per FEC type. > > Any comments on that? > > Regards > > Nic > > > ------------------------------ > -------------------------------------------------------- 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_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

            That means if link between AN and AG is Ethernet, then session= with DoD mode can not be established. I think we should also remove this r= estriction in 5036.

            [Kishore] If both AN and AGN proposes the DOD, then DOD ses= sion can be established over Ethernet. Right?

            Thanks,

            Kishore


            Regards
            Lizhong


            >
            &= gt; ----------------------------------------------------------------------<= /tt>
            >
            > Message: 1
            > Date: Mon, 2= 7 Jun 2011 09:41:13 +0200
            > From: <N.Leymann@telekom.de&g= t;
            > To: <mpls@ietf.org>, <pwe3@ietf.org>> Subject: [PWE3] LDP DoD and PW Signalling ...
            > M= essage-ID:
            >    <9762ACF04FA26B4388476841256BDE= 0201151F467921@HE111543.emea1.cds.
            > t-internal.com>=
            >    
            > Content-Type: text/plain; chars= et=3D"us-ascii"
            >
            > Hi,
            >
            > We came across an issue related to the Seamless MP= LS Architecture
            > when running LDP DoD between two nodes if= we are trying to set up an
            > PW between the same nodes.
            >
            > Assume we have an Access Node (AN) and an A= ggregation Mode (AG). The
            > AN establishes a LDP DoD with th= e AG. When we are going to establish
            > a PW between the AN a= nd the AG as well we run into the problem that
            > RFC4447 sp= ecifies only the DU mode for the targeted LDP session (section 3):
            = >
            >    "An LDP session must be set up= between the pseudowire endpoints.
            >     LDP MUST = be used in its 'downstream unsolicited' mode.  LDP's
            > =     'liberal label retention' mode SHOULD be used."
            = >
            > From our point of view we should reuse the exist= ing LDP session and go with
            > only a single LDP session between AN and AG. That has the advant= age that we
            > do not change the behaviour of PW FECs 128/129 (there = are other options like
            > using two LDP sessions with additon= al lookbacks or two sessions with single
            > loopback and LDP = DoD for IP FECs, but those have an heavy -  negative
            >= impact - on the existing implementations and/or standards).
            &g= t;
            > For a more long term approach we are in favour of a ch= ange to RFC5036 by de-
            > fining a new TLV which denotes the = DU/DoD mode per FEC type.
            >
            > Any comments o= n that?
            >
            >   Regards
            > =
            >      Nic
            >
            >= ;
            > ------------------------------
            > 

             
            ----------------------=
----------------------------------
            ZTE Informatio=
n Security Notice: The information contained =
in this mail is solely property of the&n=
bsp;sender's organization. This mail communication =
;is confidential. Recipients named above are =
obligated to maintain secrecy and are not&nbs=
p;permitted to disclose the contents of this&=
nbsp;communication to others.
            This emai=
l and any files transmitted with it are&=
nbsp;confidential and intended solely for the =
;use of the individual or entity to whom=
 they are addressed. If you have receive=
d this email in error please notify the&=
nbsp;originator of the message. Any views exp=
ressed in this message are those of the&=
nbsp;individual sender.
            This message ha=
s been scanned for viruses and Spam by&n=
bsp;ZTE Anti-Spam system.
            = --_000_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_-- From internet-drafts@ietf.org Tue Jun 28 14:46: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 7D5D911E8143; Tue, 28 Jun 2011 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 gwjlTE7MiSbM; Tue, 28 Jun 2011 14:46:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95911E8112; Tue, 28 Jun 2011 14:46:43 -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.55 Message-ID: <20110628214643.13946.7388.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 14:46:43 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-cc-cv-rdi-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: Tue, 28 Jun 2011 21:46:43 -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-04.txt Pages : 21 Date : 2011-06-28 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. 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 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-cc-cv-rdi-04.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-04.txt From loa@pi.nu Tue Jun 28 16:36:50 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 0FACE1F0C38; Tue, 28 Jun 2011 16:36:50 -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_53=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 i2murnB1jp71; Tue, 28 Jun 2011 16:36:49 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id BE8BE1F0C34; Tue, 28 Jun 2011 16:36:46 -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 8854E514044; Wed, 29 Jun 2011 01:36:43 +0200 (CEST) Message-ID: <4E0A6584.5010609@pi.nu> Date: Wed, 29 Jun 2011 01:36:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: The IESG Content-Type: multipart/mixed; boundary="------------040401050505090305070308" Cc: draft-ietf-mpls-tp-cc-cv-rdi@tools.ietf.org, "mpls@ietf.org" Subject: [mpls] publication request for draft-ietf-mpls-tp-cc-cv-rdi 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, 28 Jun 2011 23:36:50 -0000 This is a multi-part message in MIME format. --------------040401050505090305070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IESG, the MPLS wg requests that draft-ietf-mpls-tp-cc-cv-rdi-04.txt is published as an RFC on the Standards Track. Please find the shepherd write-up included. /Loa for the mpls wg -- 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 --------------040401050505090305070308 Content-Type: text/plain; name="cc-cv-rdi.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cc-cv-rdi.txt" The MPLS WG requests that: Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile draft-ietf-mpls-tp-cc-cv-rdi-04 is published as an RFC on the standards track. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Loa Andersson is the Document Shepherd. He has reviewed the document and believes it is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been reviewed in the mpls working group and in the SG15 of the ITU-T. The shephered is convinced that this is sufficient review for this framework document. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No such concerns. There is no IPR claim for this draft. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is a good consensus around this draft, it has been through working group last call. The last call was brought to the notice of SG15 in ITU-U who reviewed the document. It has also passed a working roup call to verify that LC comments were correctly with minor comments. The comments has been carefully discussed between the authors and people making the comments and has been resolved. A separate wg last call has been issued in the BFD working group, primarily to ensure that we keep compatibility between the base and MPLS earlier developed and the extensions developed by the mpls-tp project. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats or extreme discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? check!! > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References are correctly split. All documents that are referenced are past working group last call (RFCs, approved by te IESG or publication requested). > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? There is a clear and concise IANA section in this document. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: Technical Summary MPLS LSPs [emulating traditional transport circuits are expected to deliver the same the capabilities for monitoring connections as in earlier types of transport networks. The document describe and specify, as required in RFC 5860, Continuity Check (CC), proactive Connection Verfication (CV) and Remoted Defect Indication (RDI). This document describes the use of BFD for for these functions for PWs, LSPs or 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, proactive CV monitoring and the RDI functional requirements for both co-routed and associated bi-directional LSPs. Supported encapsulations include GAL/G-ACh, VCCV and UDP/IP. 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 ahs been reviewed in both organizations and there is a solid support for the document. Document Quality The document is well reviewed in the MPLS working group,the ITU-T and the BFD working group. --------------040401050505090305070308-- From lizhong.jin@zte.com.cn Tue Jun 28 19:05:50 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 D7EE79E800A; Tue, 28 Jun 2011 19:05:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD0Q94QkPfpN; Tue, 28 Jun 2011 19:05:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2729E9E8004; Tue, 28 Jun 2011 19:05:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48642203882679; Wed, 29 Jun 2011 10:04:40 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 51452.5226469288; Wed, 29 Jun 2011 10:05:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5T25SWU026570; Wed, 29 Jun 2011 10:05:28 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Kishore Tiruveedhula 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, 29 Jun 2011 10:05:05 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-29 10:05:27, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-29 10:05:27, Serialize complete at 2011-06-29 10:05:27, S/MIME Sign failed at 2011-06-29 10:05:27: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-29 10:05:28, Serialize complete at 2011-06-29 10:05:28 Content-Type: multipart/alternative; boundary="=_alternative 000B7C71482578BE_=" X-MAIL: mse01.zte.com.cn p5T25SWU026570 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] 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, 29 Jun 2011 02:05:51 -0000 This is a multipart message in MIME format. --=_alternative 000B7C71482578BE_= Content-Type: text/plain; charset="US-ASCII" Kishore, Yes, in that case, the session can be established. And then all the sessions over the AGN's link have to be DoD. Now I guess it is a rare case there are two sessions with different mode over one Ehternet link on AGN. Thanks Lizhong Kishore Tiruveedhula wrote on 2011-06-29 02:35:15: > That means if link between AN and AG is Ethernet, then session with > DoD mode can not be established. I think we should also remove this > restriction in 5036. > [Kishore] If both AN and AGN proposes the DOD, then DOD session can > be established over Ethernet. Right? > Thanks, > Kishore > > Regards > Lizhong > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 27 Jun 2011 09:41:13 +0200 > > From: > > To: , > > Subject: [PWE3] LDP DoD and PW Signalling ... > > Message-ID: > > <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds. > > t-internal.com> > > > > Content-Type: text/plain; charset="us-ascii" > > > > Hi, > > > > We came across an issue related to the Seamless MPLS Architecture > > when running LDP DoD between two nodes if we are trying to set up an > > PW between the same nodes. > > > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The > > AN establishes a LDP DoD with the AG. When we are going to establish > > a PW between the AN and the AG as well we run into the problem that > > RFC4447 specifies only the DU mode for the targeted LDP session (section 3): > > > > "An LDP session must be set up between the pseudowire endpoints. > > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > > 'liberal label retention' mode SHOULD be used." > > > > From our point of view we should reuse the existing LDP session and go with > > only a single LDP session between AN and AG. That has the advantage that we > > do not change the behaviour of PW FECs 128/129 (there are other options like > > using two LDP sessions with additonal lookbacks or two sessions with single > > loopback and LDP DoD for IP FECs, but those have an heavy - negative > > impact - on the existing implementations and/or standards). > > > > For a more long term approach we are in favour of a change to RFC5036 by de- > > fining a new TLV which denotes the DU/DoD mode per FEC type. > > > > Any comments on that? > > > > Regards > > > > Nic > > > > > > ------------------------------ > > > -------------------------------------------------------- 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 000B7C71482578BE_= Content-Type: text/html; charset="US-ASCII"
            Kishore,
            Yes, in that case, the session can be established. And then all the sessions over the AGN's link have to be DoD. Now I guess it is a rare case there are two sessions with different mode over one Ehternet link on AGN.

            Thanks
            Lizhong
             

            Kishore Tiruveedhula <kishoret@juniper.net> wrote on 2011-06-29 02:35:15:

            > That means if link between AN and AG is Ethernet, then session with
            > DoD mode can not be established. I think we should also remove this
            > restriction in 5036.

            > [Kishore] If both AN and AGN proposes the DOD, then DOD session can
            > be established over Ethernet. Right?
            > Thanks,
            > Kishore
            >
            > Regards
            > Lizhong
            >
            >
            > >
            > > ----------------------------------------------------------------------
            > >
            > > Message: 1
            > > Date: Mon, 27 Jun 2011 09:41:13 +0200
            > > From: <N.Leymann@telekom.de>
            > > To: <mpls@ietf.org>, <pwe3@ietf.org>
            > > Subject: [PWE3] LDP DoD and PW Signalling ...
            > > Message-ID:
            > >    <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.
            > > t-internal.com>
            > >    
            > > Content-Type: text/plain; charset="us-ascii"
            > >
            > > Hi,
            > >
            > > We came across an issue related to the Seamless MPLS Architecture
            > > when running LDP DoD between two nodes if we are trying to set up an
            > > PW between the same nodes.
            > >
            > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The
            > > AN establishes a LDP DoD with the AG. When we are going to establish
            > > a PW between the AN and the AG as well we run into the problem that
            > > RFC4447 specifies only the DU mode for the targeted LDP session (section 3):
            > >
            > >    "An LDP session must be set up between the pseudowire endpoints.
            > >     LDP MUST be used in its 'downstream unsolicited' mode.  LDP's
            > >     'liberal label retention' mode SHOULD be used."
            > >
            > > From our point of view we should reuse the existing LDP session and go with
            > > only a single LDP session between AN and AG. That has the advantage that we
            > > do not change the behaviour of PW FECs 128/129 (there are other options like
            > > using two LDP sessions with additonal lookbacks or two sessions with single
            > > loopback and LDP DoD for IP FECs, but those have an heavy -  negative
            > > impact - on the existing implementations and/or standards).
            > >
            > > For a more long term approach we are in favour of a change to RFC5036 by de-
            > > fining a new TLV which denotes the DU/DoD mode per FEC type.
            > >
            > > Any comments on that?
            > >
            > >   Regards
            > >
            > >      Nic
            > >
            > >
            > > ------------------------------
            > >
            >  
            --------------------------------------------------------
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 000B7C71482578BE_=-- From maciek@juniper.net Wed Jun 29 00:51: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 91B0121F8537; Wed, 29 Jun 2011 00:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 OK5tRb4Hm-3G; Wed, 29 Jun 2011 00:51:03 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40121F8532; Wed, 29 Jun 2011 00:50:59 -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 DSNKTgrZYhaF64Ef+p3bY+P4HcPEtB4Zf4nk@postini.com; Wed, 29 Jun 2011 00:51:02 PDT Received: from [172.26.205.106] (172.26.205.106) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 29 Jun 2011 00:48:24 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Maciek Konstantynowicz In-Reply-To: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Date: Wed, 29 Jun 2011 08:48:20 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <16DF3958-C763-4A39-AA34-3C7BCF18F99E@juniper.net> References: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> To: Nicolai Leymann X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [PWE3] 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, 29 Jun 2011 07:51:05 -0000 Nic, I don't believe this is a major issue. Proposed short term approach of using DoD mode (negotiated during LDP = session establishment per 'Common Session Parameters' TLV) for IP FECs = and fixed DU mode for PW FECs makes sense to me. I also agree that going forward we should consider introducing per FEC = type indication of label advertisement discipline. The least disruptive approach seems to be to amend rfc5036 and define a = new 'Optional Parameter' TLV in the LDP Initialization message to = indicate label advertisement discipline per FEC type, if different from = the one advertised in 'Common Session Parameters' TLV. Cheers, Maciek. On 27 Jun 2011, at 08:41, = wrote: > Hi, >=20 > We came across an issue related to the Seamless MPLS Architecture when = running LDP DoD between two nodes if we are trying to set up an PW = between the same nodes. >=20 > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The = AN establishes a LDP DoD with the AG. When we are going to establish a = PW between the AN and the AG as well we run into the problem that = RFC4447 specifies only the DU mode for the targeted LDP session (section = 3): >=20 > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." >=20 > =46rom our point of view we should reuse the existing LDP session and = go with only a single LDP session between AN and AG. That has the = advantage that we do not change the behaviour of PW FECs 128/129 (there = are other options like using two LDP sessions with additonal lookbacks = or two sessions with single loopback and LDP DoD for IP FECs, but those = have an heavy - negative impact - on the existing implementations = and/or standards). >=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. >=20 > Any comments on that? >=20 > Regards >=20 > Nic > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From erosen@cisco.com Wed Jun 29 07:56: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 B8C0D21F8607 for ; Wed, 29 Jun 2011 07:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KVDNGdNuszPR for ; Wed, 29 Jun 2011 07:56:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 128A721F8600 for ; Wed, 29 Jun 2011 07:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1239; q=dns/txt; s=iport; t=1309359383; x=1310568983; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=kjqmIr1unyIjfYSGNwf4iJ0IVS8J6PYx3A+XDT5DkHY=; b=T9pDaJI4P/8aGHDdunZBcI+Thika6NaYI8kq41jMTZBoafFHSjorV7R/ AEZ+Eof5UUtQmhrJIFsZoxz3zTK72rDSbOXH3R2QQLdejBSjXDDaKaomH D8kPDcYAv11gt5pz4NWEnPutV7D5N7PMt186HB48mjc1u4dKAot1aAIp0 w=; X-IronPort-AV: E=Sophos;i="4.65,443,1304294400"; d="scan'208";a="472049894" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2011 14:56:20 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5TEuKVI008577; Wed, 29 Jun 2011 14:56:20 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 p5TEuJI7023533; Wed, 29 Jun 2011 10:56:19 -0400 To: N.Leymann@telekom.de In-reply-to: Your message of Mon, 27 Jun 2011 09:41:13 +0200. <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Date: Wed, 29 Jun 2011 10:56:19 -0400 Message-ID: <23532.1309359379@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org Subject: Re: [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: Wed, 29 Jun 2011 14:56:24 -0000 > 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. >From 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. From adrian@olddog.co.uk Wed Jun 29 08:24: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 9DE0621F8610 for ; Wed, 29 Jun 2011 08:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 CYdpq1zpjG5T for ; Wed, 29 Jun 2011 08:24:07 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9A21F860C for ; Wed, 29 Jun 2011 08:24:07 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5TFMK6g014499; Wed, 29 Jun 2011 16:22:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5TFMIZ0014468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jun 2011 16:22:19 +0100 From: "Adrian Farrel" To: Date: Wed, 29 Jun 2011 16:24:03 +0100 Message-ID: <09ff01cc3670$94a4b100$bdee1300$@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: Acw2b+W+6WSHOAIFQwKk8/Lwc7Ha1w== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-tp-cc-cv-rdi 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: Wed, 29 Jun 2011 15:24:08 -0000 Hi authors, I have done my usual AD review of your draft having received a publication request from the working group. The purpose of the review is to ensure that the document has a smooth passage through IETF last call and the IESG. Listed below are a nuber of editorial issues that I would like you to resolve before I advance the document. All points are open for discussion. I have put the document into "revised I-D needed" state, but as soon as I see a revised version I will request IETF last call. Thanks for the work. Adrian --- idnits shows that reference [12] is not used. Either insert this where it is needed, or remove the reference. --- BFD is not a "recognized" acronym. Please expand it on first use in the Introduction. Please also include a reference to [4]. --- s/sub path/sub-path/ --- G-ACh, p2p and p2mp need to be expanded on first use. --- Section 1.1 is unusual and seems unnecessary in view of the Authors' Addresses section. The RFC Editor will ask you why you need this section and I would encourage you to remove it. --- Section 2.1 LSP is missing MPLS-TP LSP s/Label Switch Path/Label Switched Path/ --- Section 3.1 Implementations MAY also interoperate with existing equipment by implementing [2], or [8] in addition to the procedures documented in this memo. s/MAY/may/ s/existing/legacy/ But this is a strange sentence. It implies that there are two different ways to interoperate with same legacy equipment. Is that right? It also implies that in order to interoperate with legacy equipment you must implement *all* the procudures in this document. I can't parse whether you mean... 2 or (8 and this memo) or (2 or 8) and this memo --- Section 3.2 RDI is communicated via the BFD diagnostic field in BFD CC messages. It is not a distinct PDU. A sink MEP will encode a diagnostic code of "1 - Control detection time expired" when the interval times detect multiplier have been exceeded, and with "5 - Path Down" as a consequence of the sink MEP receiving AIS with LDI set. A sink MEP that has started sending diagnostic code 5 SHOULD NOT change it to 1 when the detection timer expires. I couldn't work out whether this is new behavior or existing behavion. I think the latter. If so, you need a reference like "As defined in [foo] a sink MEP..." Probably s/will/SHOULD/ according to the referenced text? --- Section 3.3 This launches straight into the figure without saying what is going on. Can you add a short paragraph to say "Figure 1 shows..." The first nibble (0001b) indicates the ACH. This is not a new definition, so can you add the reference? - BFD CC code point = 0xXX. [HH to be assigned by IANA from the PW Associated Channel Type registry.] or, - BFD proactive CV code point = 0xXX+1. [HH to be assigned by IANA from the PW Associated Channel Type registry.] s/HH/XX/ twice --- Section 3.4 I believe you will want the XX in the figure to be updated by the RFC Editor. You need to add a note to ask the RFC Editor to do this. --- Section 3.5 Similarly, you will want XX+1 replaced with an absolute number The length in the BFD control packet is as per [4], the MEP Source ID TLV is not included. Is that s/The length/If the length/ ? When GAL label is used, the time to live (TTL) field of the GAL MUST be set to at least 1, and the GAL will be the end of stack label (S=1). s/GAL label/GAL/ You say "will be" because this behavior is defined elsewhere. Please give a reference. --- Section 3.5.1 I understand why this section is the way it is. However, you should remove this section and add text to the Introduction such as... This document utilizes identifiers for MPLS-TP systems as defined in [9]. Work is on-going in the ITU-T to define a globally-unique semantic for ITU Carrier Codes (ICCs), and future work may extend this document to utilize ICCs as identifiers for MPLS-TP systems. --- Section 3.5.2 - 3.5.4 There are stray "=" characters in the figures. A bit odd that these figures are not numbered. --- Section 3.5.3 The format for the LSP MEP-ID is as defined in [9] The referenced document does not define any format. This is good because it means you are not duplicating a format definition, but is bad because the text is wrong. --- Section 3.5.4 As 3.5.3 --- Section 3.7.3 The blocking of traffic as a consequent action MUST be driven only by a defect's consequent action as specified in draft-ietf-mpls-tp-oam- framework [11] section 5.1.1.2. Please don't name the document in the text. Use the reference. --- Section 3.7.5 It may be helpful to show the event "LDI set" in quotes in the text to make things easier to parse. For independent mode, there are two state machines. One for the source MEP (who requested bfd.MinRxInterval=0) and the sink MEP (who agreed to bfd.MinRxInterval=0). s/who/which/ twice --- Section 4 The following is an exemplary set of configuration parameters for a BFD session: Nothing perfect about that set :-) s/exemplary/example/ --- Section 5 Dave Ward is an author. You can remove hi from this section. --- Section 6 This draft requires the creations of a source MEP-ID TLV registry with initial values of: Xx - Section MEP-ID Xx+1 - LSP MEP-ID Xx+2 - PW MEP-ID You will need to say what the parent registry of this new subregistry is. You need to say what information needs to be tracked (maybe just TLV Type, Name, and reference. You should reference RFC 5226 for the allocations policy. In section 3.5 you use X1, X2 and X3. I think you should use that here. --- Section 7 is very thin! Anyway, in 3.5 you say... When digest based authentication is used, the Source ID TLV MUST NOT be included in the digest But doesn't this give us a problem making sure that the TLV has not been modified? It is clearly important that this is not modified because you wrote: A node MUST NOT change the value in the MEP Source ID TLV. If this field cannot be protected, you need to note this in Section 7 and observe the consequences if it is modified. Also helpful to state the mitgation. From swallow@cisco.com Wed Jun 29 16:03: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 A954511E80E3 for ; Wed, 29 Jun 2011 16:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 4ZdzzdtIqkHi for ; Wed, 29 Jun 2011 16:03:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5611E80B4 for ; Wed, 29 Jun 2011 16:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=3761; q=dns/txt; s=iport; t=1309388624; x=1310598224; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=0VR82SfOKQKXj2h2SYCdWSjy1cm2pTotbq7A5lSToJ8=; b=AvvmoQr1DojHX487XMnkBYuPbCJpWmqgUsIXH09rmtUI1b8AfAkbbg11 F4fnVVbkAOeR2QzHTW/7+ZPAUJl/N2O7oWkPKHI8mojEeVN1v9UBdbhLT cUdCmfOHToGqcVInaHDL2wqMtmEU+KWtllEZq7hBPlYvtFkW2SD+Zwg8E k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE2uC06tJV2a/2dsb2JhbABSglGkF3V3iHijEJ17hjAEkhaEfotI X-IronPort-AV: E=Sophos;i="4.65,446,1304294400"; d="scan'208,217";a="472376962" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2011 23:03:43 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5TN3hLq021453; Wed, 29 Jun 2011 23:03:43 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); Wed, 29 Jun 2011 18:03:43 -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, 29 Jun 2011 23:03:43 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 29 Jun 2011 19:03:40 -0400 From: George Swallow To: g67564 , Loa Andersson , , Message-ID: Thread-Topic: [mpls] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlrY6pzaQPGLDTRSwwtw9z+OhdgFcUP8gG2ozrec= In-Reply-To: <01b501cbc908$1dbba830$5932f890$@com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392219021_104595777" X-OriginalArrivalTime: 29 Jun 2011 23:03:43.0169 (UTC) FILETIME=[CAD03B10:01CC36B0] Cc: Ross Callon , ahmpls-tp@lists.itu.int Subject: Re: [mpls] 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, 29 Jun 2011 23:03:45 -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_3392219021_104595777 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Xinchun - On 2/10/11 4:51 AM, "g67564" wrote: > Dear authors >=20 > After read the document, I have a question about the FM massage procedure= . >=20 > In the section 5.1, the third paragraph, it said "The message is then sen= t. > The message MUST be refreshed two more times at an interval of one second= . > Further refreshes are sent according to the value of the refresh timer." = I > don't know why the refreshing massage must be first sent two more times i= n > one second and then sent as the refresh timer interval. Is it ok if the > refreshing massage is sent only according to the value of the refresh tim= er? > If it is not, what problem may be introduced? Hope authors could explain = it > for me. >=20 Fault OAM messages are not sent reliably. The reason for sending 3 times @ 1 second is to add some element of reliability before the =B3soak=B2 timer expires. >=20 > In addition, figure 2 is about the fault management massage format, so I > think naming the figure" MPLS-TP fault Management Message Format " other > than" MPLS-TP OAM Message Format " is more suitable. >=20 Fixed. ...George >=20 > Best Regards > Xinchun --B_3392219021_104595777 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] wg last call on draft-ietf-mpls-tp-fault-03 Xinchun= -


            On 2/10/11 4:51 AM, "g67564" <= guoxinchun@huawei.com> wrote:

            Dear authors

            After read the document, I have a question about the FM massage procedure.<= BR>
            In the section 5.1, the third paragraph, it said "The message is then = sent.
            The message MUST be refreshed two more times at an interval of one second.<= BR> Further refreshes are sent according to the value of the refresh timer.&quo= t;  I
            don't know why the refreshing massage must be first sent two more times in<= BR> one second and then sent as the refresh timer interval.  Is it ok if t= he
            refreshing massage is sent only according to the value of the refresh timer= ?
            If it is not, what problem may be introduced? Hope authors could explain it=
            for me.

            Fault OAM messages are not sent reliably.  The reas= on for sending 3 times @ 1 second is to add some element of reliability befo= re the “soak” timer expires.

            In addition, figure 2 is about the fault management massage format, so I think naming the figure" MPLS-TP fault Management Message Format "= ; other
            than" MPLS-TP OAM Message Format " is more suitable.

            Fixed.

            ...George

            Best Regards
            Xinchun
            --B_3392219021_104595777-- From internet-drafts@ietf.org Wed Jun 29 16:56: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 D587E21F85E0; Wed, 29 Jun 2011 16:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 rOSA4GMtFnbc; Wed, 29 Jun 2011 16:56:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C9521F85DD; Wed, 29 Jun 2011 16:56:36 -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.55 Message-ID: <20110629235636.29602.85625.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 16:56:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-cc-cv-rdi-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: Wed, 29 Jun 2011 23:56:37 -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-05.txt Pages : 22 Date : 2011-06-29 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. 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 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-cc-cv-rdi-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-cc-cv-rdi-05.txt From internet-drafts@ietf.org Thu Jun 30 00:08: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 9DC8911E8156; Thu, 30 Jun 2011 00:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 4yxt07ujD-88; Thu, 30 Jun 2011 00:08:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AA11E8074; Thu, 30 Jun 2011 00:08:57 -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.55 Message-ID: <20110630070857.18474.79967.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 00:08:57 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-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, 30 Jun 2011 07:08:57 -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 : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Author(s) : Sami Boutros Siva Sivabalan George Swallow Shaleen Saxena Vishwas Manral Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-00.txt Pages : 6 Date : 2011-06-29 LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-ttl-tlv-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-lsp-ping-ttl-tlv-00.txt From loa@pi.nu Thu Jun 30 00:15:01 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 7D2A511E8150 for ; Thu, 30 Jun 2011 00:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 iyYwwoqs+DNO for ; Thu, 30 Jun 2011 00:15:00 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id D88AB11E816F for ; Thu, 30 Jun 2011 00:14:56 -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 D78F8514044; Thu, 30 Jun 2011 09:14:54 +0200 (CEST) Message-ID: <4E0C2270.4060209@pi.nu> Date: Thu, 30 Jun 2011 09:14:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: loa@pi.nu References: <4D0B5321.2050508@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , draft-ietf-mpls-lsp-ping-ttl-tlv@tools.ietf.org Subject: Re: [mpls] poll on draft-boutros-mpls-lsp-ping-ttl-tlv-02 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, 30 Jun 2011 07:15:01 -0000 Authors, I apologize for the treatment of this draft, I screwed up a couple of ways (see below). Ross, this is OK - I sent out the poll late last year, and then I did go on vacation. Between that and some other things, I didn't close the poll until end of March and accepted the draft as a new working group document. The author republished a new version about the same time. Now what is that the tool the working group chairs accept new wg drafts changed at the same time. I responded to the initial version verification request using the *old* tool. That tool seemed to work just fine, and I got the same response I received when earlier accepting new working group drafts. Obviously the the old toll had been disabled and the draft was never really listed as a wg document. I've have now accepted the draft via the *new* tool and I've seen the announcement of the new working group document coming through. Sorry for the inconveniences! /Loa On 2011-03-18 18:47, loa@pi.nu wrote: > > Working Group, > > hmmmmm.... > > this poll has ended; we have a new working group document. > > Could the authors please publish > > draft-ietf-mpls-lsp-ping-ttl-tlv-00 > > according to our normal procedures. > > /Loa > > PS. > > It is kind of obvious that this poll had ended, it actually > fell between the chairs (no pun intended) when I took an > extended period off over the holiday season. I'm sorry > about that. > > If anyone is aware of any other things that got dropped and > has not been picked up, please let me know. > >> All, >> >> this is to start a "two week" working group poll on making >> draft-boutros-mpls-lsp-ping-ttl-tlv-02 >> an mpls wg document. >> >> Please send your comments to the mpls@ietf.org mailing list. >> >> Since this is across the holidays the poll ends on January 6th. >> >> /Loa >> -- >> >> >> 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 >> > > -- 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 michelg@upperside.fr Thu Jun 30 03:23: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 197FB21F882A for ; Thu, 30 Jun 2011 03:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 jq5CjE3gMG+P for ; Thu, 30 Jun 2011 03:23:53 -0700 (PDT) Received: from smtp04.msg.oleane.net (smtp04.msg.oleane.net [62.161.4.4]) by ietfa.amsl.com (Postfix) with ESMTP id A221E21F8829 for ; Thu, 30 Jun 2011 03:23:51 -0700 (PDT) Received: from MichelGosseDel (AAubervilliers-752-1-16-37.w90-35.abo.wanadoo.fr [90.35.223.37]) (authenticated) by smtp04.msg.oleane.net (MSA) with ESMTP id p5UANnla007507 for ; Thu, 30 Jun 2011 12:23:49 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Thu, 30 Jun 2011 12:23:59 +0200 Message-ID: <001d01cc370f$d3b148f0$7b13dad0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01CC3720.973EACD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acw3D9NNddxYKf7pTzy1D3z9wBSF7Q== Content-Language: fr X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2011.6.30.100614 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Call for Papers: Deadline Extension to July 15th. 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, 30 Jun 2011 10:23:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01CC3720.973EACD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 14th edition of the MPLS & Ethernet World Congress will take place in Marriott Paris Rive Gauche, next 7 to 10 February, 2012. The call for proposals is open until July 15 at: http://www.upperside.fr/mplsworld2012/mplsworld2012cfp.html ------=_NextPart_000_001E_01CC3720.973EACD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

            The 14th edition of the MPLS & = Ethernet World Congress will take place in = Marriott Paris Rive Gauche, next 7 to 10 = February, 2012. =

              

            The call for proposals is open until July 15 = at:

             

            http://www.upperside.fr/mplsworld2012/m= plsworld2012cfp.html

             

            = ------=_NextPart_000_001E_01CC3720.973EACD0-- From iesg-secretary@ietf.org Thu Jun 30 06:46: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 63FFB11E8158; Thu, 30 Jun 2011 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 sDl5OEtapjZX; Thu, 30 Jun 2011 06:46:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58DF11E80C7; Thu, 30 Jun 2011 06:46: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.55 Message-ID: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 06:46:42 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) 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, 30 Jun 2011 13:46:43 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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-07-14. 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 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. 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 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. From ietf-ipr@ietf.org Thu Jun 30 14:15: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 AC86311E8274; Thu, 30 Jun 2011 14:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 zZDQMoBl2gZt; Thu, 30 Jun 2011 14:15:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706C11E81F8; Thu, 30 Jun 2011 14:15:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: , stbryant@cisco.com, danfrost@cisco.com X-Test-IDTracker: no Message-ID: <20110630211505.19733.64579.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 14:15:05 -0700 Cc: mpls@ietf.org, housley@vigilsec.com, rcallon@juniper.net, stbryant@cisco.com, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-mpls-tp-loss-delay-profile-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: Thu, 30 Jun 2011 21:15:07 -0000 Dear Dan Frost, Stewart Bryant: An IPR disclosure that pertains to your Internet-Draft entitled "A Packet = Loss and Delay Measurement Profile for MPLS-based Transport Networks" (draft-iet= f- mpls-tp-loss-delay-profile) was submitted to the IETF Secretariat on 2011-0= 6-30 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1583/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-mpls-tp-loss- delay-profile-03.""); The IETF Secretariat From ietf-ipr@ietf.org Thu Jun 30 14:19: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 B723F11E8287; Thu, 30 Jun 2011 14:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 eqshJ0UOnUfR; Thu, 30 Jun 2011 14:19:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5405B11E8080; Thu, 30 Jun 2011 14:19:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: , stbryant@cisco.com, X-Test-IDTracker: no Message-ID: <20110630211949.21669.46854.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 14:19:49 -0700 Cc: mpls@ietf.org, housley@vigilsec.com, rcallon@juniper.net, stbryant@cisco.com, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-mpls-loss-delay-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: Thu, 30 Jun 2011 21:19:49 -0000 Dear Dan Frost, Stewart Bryant: An IPR disclosure that pertains to your Internet-Draft entitled "Packet Lo= ss and Delay Measurement for MPLS Networks" (draft-ietf-mpls-loss-delay) was submitted to the IETF Secretariat on 2011-06-30 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1584/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-mpls-loss-delay-03.""); The IETF Secretariat From internet-drafts@ietf.org Thu Jun 30 15:08: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 ABC5421F862E; Thu, 30 Jun 2011 15:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 i2YjbLqp+6W4; Thu, 30 Jun 2011 15:08:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEA11E809B; Thu, 30 Jun 2011 15:08: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.55 Message-ID: <20110630220859.2430.59977.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 15:08:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-enhanced-dsmap-10.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, 30 Jun 2011 22:08:59 -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 : Mechanism for performing LSP-Ping over MPLS tunnels Author(s) : Nitin Bahadur Kireeti Kompella George Swallow Filename : draft-ietf-mpls-lsp-ping-enhanced-dsmap-10.txt Pages : 23 Date : 2011-06-30 This document describes methods for performing LSP-Ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS label-switched-paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap= -10.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-lsp-ping-enhanced-dsmap-= 10.txt