From martin.vigoureux@alcatel-lucent.com Mon Jul 1 02:58:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412A21F9DB3 for ; Mon, 1 Jul 2013 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIIw-1YtTmuw for ; Mon, 1 Jul 2013 02:58:15 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C02A021F9D4F for ; Mon, 1 Jul 2013 02:58:14 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r619wBsl023220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Jul 2013 04:58:13 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r619vrNL024072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 11:58:06 +0200 Received: from [172.27.205.220] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 1 Jul 2013 11:57:43 +0200 Message-ID: <51D15297.7040807@alcatel-lucent.com> Date: Mon, 1 Jul 2013 11:57:43 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Slots requests for MPLS Sessions - IETF 87 - Berlin X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 01 Jul 2013 09:58:31 -0000 All, it is time we start building the MPLS WG agenda for Berlin. The current IETF agenda, still subject to change, is available at: https://datatracker.ietf.org/meeting/87/agenda.html The MPLS WG sessions are for the moment scheduled on: Wednesday Morning Session I, 09:00-11:30 and Friday Morning Session I, 09:00-11:30 Please send *me* (replying to this e-mail and copying the co-chairs) your request for a presentation slot, indicating: draft name, speaker and desired duration (presentation + Q&As). Please send the requests before the 15th of July. Thank you Martin From martin.vigoureux@alcatel-lucent.com Mon Jul 1 02:58:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8221F9D91 for ; Mon, 1 Jul 2013 02:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaD-x7OpCeHy for ; Mon, 1 Jul 2013 02:58:31 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D0A4D21F9DC2 for ; Mon, 1 Jul 2013 02:58:30 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r619wP5f016949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Jul 2013 04:58:27 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r619wKCV024500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 11:58:25 +0200 Received: from [172.27.205.220] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 1 Jul 2013 11:58:03 +0200 Message-ID: <51D152AA.6020805@alcatel-lucent.com> Date: Mon, 1 Jul 2013 11:58:02 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Slots requests for MPLS Sessions - IETF 87 - Berlin X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 01 Jul 2013 09:58:37 -0000 All, it is time we start building the MPLS WG agenda for Berlin. The current IETF agenda, still subject to change, is available at: https://datatracker.ietf.org/meeting/87/agenda.html The MPLS WG sessions are for the moment scheduled on: Wednesday Morning Session I, 09:00-11:30 and Friday Morning Session I, 09:00-11:30 Please send *me* (replying to this e-mail and copying the co-chairs) your request for a presentation slot, indicating: draft name, speaker and desired duration (presentation + Q&As). Please send the requests before the 16th of July. Thank you Martin From martin.vigoureux@alcatel-lucent.com Mon Jul 1 03:08:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58E721F9DF9 for ; Mon, 1 Jul 2013 03:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcs3hSei+tpK for ; Mon, 1 Jul 2013 03:08:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F39C221F9E2C for ; Mon, 1 Jul 2013 03:08:15 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r61A8D97021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 Jul 2013 05:08:15 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r61A83di001609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Jul 2013 12:08:13 +0200 Received: from [172.27.205.220] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 1 Jul 2013 12:08:11 +0200 Message-ID: <51D1550A.8020007@alcatel-lucent.com> Date: Mon, 1 Jul 2013 12:08:10 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: References: <51D15297.7040807@alcatel-lucent.com> In-Reply-To: <51D15297.7040807@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [mpls] Slots requests for MPLS Sessions - IETF 87 - Berlin X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 01 Jul 2013 10:08:22 -0000 sorry for the duplicate. please ignore the first message below. Le 01/07/2013 11:57, Martin Vigoureux a crit : > All, > > it is time we start building the MPLS WG agenda for Berlin. > The current IETF agenda, still subject to change, is available at: > https://datatracker.ietf.org/meeting/87/agenda.html > The MPLS WG sessions are for the moment scheduled on: > Wednesday Morning Session I, 09:00-11:30 > and > Friday Morning Session I, 09:00-11:30 > > Please send *me* (replying to this e-mail and copying the co-chairs) > your request for a presentation slot, indicating: > draft name, speaker and desired duration (presentation + Q&As). > > Please send the requests before the 15th of July. > Thank you > > Martin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From adrian@olddog.co.uk Mon Jul 1 03:58:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EAF21F9C17 for ; Mon, 1 Jul 2013 03:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNCG+0KT6kfI for ; Mon, 1 Jul 2013 03:58:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7311D21F9C0A for ; Mon, 1 Jul 2013 03:58:26 -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 r61Aw2dn021335; Mon, 1 Jul 2013 11:58:02 +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 r61AvwFs021288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 11:57:59 +0100 From: "Adrian Farrel" To: "'Quintin Zhao'" , "'Alia Atlas'" Date: Mon, 1 Jul 2013 11:57:58 +0100 Message-ID: <00a701ce7649$da9bd920$8fd38b60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CE7652.3C71CD50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac52Sdi7XMxjqV3QRHmknd0dB9+FEQ== Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org Subject: [mpls] MT ID registry in draft-ietf-mpls-ldp-multi-topology 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, 01 Jul 2013 10:58:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A8_01CE7652.3C71CD50 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi all, I want to try to bring the two threads on the MT ID ranges for IANA back together to try to understand what is being proposed and what is possible. First step is to recognise that the OSPF and ISIS registries exist and already have numbers assigned from them. Thus we are not going to manage to converge the OSPF and ISIS MT IDs into a single registry with the same meanings. Alia says "it'd be very useful to have that range specifically set aside for cases where it matters that it be the same" but doesn't give a concrete example of such a case. Furthermore, I am not comfortable with the idea that both OSPF and ISIS might be running at the same time, as is implied here, each distributing a different default topology, but with the two topologies being aggregated for use by LDP. Perhaps I don't see the network that you are trying to build and deploy, and a picture will help explain it. My "understanding" of the use case is that a single instance of a single IGP runs in an area. That IGP may distribute information about multiple routing topologies, each topology having an MT ID. LDP is also running in the area and distributes labels based on the preferred routes in each topology. Thus each label advertisement includes a FEC and an MT ID. In order to use the labels correctly, there must be a mapping between the MT IDs used by the IGP, and those used by LDP. It is also possible that through network-wide configuration of policy on the LDP implementations, LDP will use the information from the IGP and the configured policy to formulate new and different MPLS-only topologies. Thus, LDP might use an MT ID for its own special topology. There are two options: 1. Create a registry that is agnostic to the IGP in use (i.e. doesn't indicate OSPF or ISIS) and which shows the use of the topology. 0 Default topology 1 IPv4 in-band management topology 2 IPv6 routing topology 3 IPv4 multicast routing topology 4 IPv6 multicast routing topology 5 IPv6 in-band management topology 6 - a Reserved for future IGP topologies (standards action) a+1 - b Reserved for IGP experimental topologies b+1 - c Reserved for LDP topologies (standards action) c+1 - d Reserved for LDP experimental topologies 2. Create a registry that is aware of the IGP in use and is built on the existing OSPF and ISIS registries. This would be modelled on what I suggested before, but adding allocations for LDP itself... 0 Default/standard topology in IS-IS 1 IPv4 in-band management in IS-IS 2 IPv6 routing topology in IS-IS 3 IPv4 multicast topology in IS-IS 4 IPv6 multicast topology in IS-IS 5 IPv6 in-band management in IS-IS 6-3995 Unassigned (intended to mirror IS-IS) 3996-4095 Reserved for private use (from IS-IS) 4096 Default/standard topology in OSPF 4097 Default multicast topology in OSPF 4098 IPv4 in-band management in OSPF 4099-4127 Unassigned (intended to mirror OSPF) 4128-4255 Reserved for private use (from OSPF) 4256-4351 Reserved (IANA does not assign) 4352-4511 Unassigned 4512-4607 LDP use (standards action) 4608-65531 Reserved for Private Use 64432-65535 Experimental use In all cases, my concern is what happens when a new IGP use is defined in an RFC. It would appear that the LDP registry has to be updated to keep it in synch. It is also unclear to me how we handle mapping an IGP private use into the LDP private use. The intention of the scheme in the second option is to make that mapping automatic so that when an MT ID is used in an IGP, we know how to map to the LDP MT ID even if we don't understand the meaning of the IGP's MT ID. It seems to me that what you might be asking for in your email is a single MT ID value that is the default topology used by LDP when it is based on OSPF or ISIS default topology and does not want to indicate which it comes from. It that is the case, you could assign 4512 in option 2 for this purpose. I am convinced that the solution to this problem is to work out what the mapping algorithm is. How does an LDP implementation decide which MT ID to use in a label advertisement? How does a packet-classifier decide which label to use? The answer may be: "It is assumed that this mapping is manually configured on every router" Or it may be: "There is an automatic mapping between IGP MT IDs and LDP MT IDs" Or it may be something else. Once the answer is agreed, making a registry will be easy. Cheers, Adrian From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Quintin Zhao Sent: 28 June 2013 21:41 To: 'Alia Atlas' Cc: mpls@ietf.org; draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology Hello Alia, Thanks for your review and suggestions. Indeed we need to allocate a MT ID range for the applications such as MRT so that MT ID can be the same for OSPF, ISIS and LDP. We need decide how big this range should be for the applications such as MRT. What is your recommendation for this range? This is what we have now from ISIS-MT(RFC5120): - MT ID #0: Equivalent to the "standard" topology. - MT ID #1: Reserved for IPv4 in-band management purposes. - MT ID #2: Reserved for IPv6 routing topology. - MT ID #3: Reserved for IPv4 multicast routing topology. - MT ID #4: Reserved for IPv6 multicast routing topology. - MT ID #5: Reserved for IPv6 in-band management purposes. - MT ID #6-#3995: Reserved for IETF consensus. - MT ID #3996-#4095: Reserved for development, experimental and proprietary features [RFC3692]. This is what have now from OSPF-MT(RFC4915) 0 - Reserved for advertising the metric associated with the default topology (see Section 4.2) 1 - Reserved for advertising the metric associated with the default multicast topology 2 - Reserved for IPv4 in-band management purposes 3-31 - Reserved for assignments by IANA 32-127 - Reserved for development, experimental and proprietary features [RFC3692] 128-255 - Invalid and SHOULD be ignored The range which is available for us to use is from 6 -127. Thanks, Quintin From: Alia Atlas [mailto:akatlas@gmail.com] Sent: 2013$BG/(B5$B7n(B29$BF|(B 8:52 To: Adrian Farrel Cc: draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology Hi Adrian & authors, I have a couple comments on the IANA registry and number overlapping. First, it would be useful to have a range that is clearly intended to be the same for OSPF, ISIS and LDP. Given the extremely limited range for OSPF multi-topology routing (http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of 3-127, it'd be very useful to have that range specifically set aside for cases where it matters that it be the same. One use that I see for this draft is for MRT, which is doing multi-topology forwarding but not multi-topology routing. This means that the MT-IDs used do not need to overlap with those in OSPF or ISIS. It would be good to ensure that there's a reasonable range in LDP for such purposes. LDP is one of the few mechanisms that easily lends itself to multi-topology forwarding. Alia P.S. Having the same values for mLDP and PIM may also be very useful for interworking. PIM doesn't actually have an IANA registry for MT-ID and leaves the meaning of the values up to the network operator. On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel wrote: Hi authors, Thanks for this document. I have done my usual AD review which is intended to catch any issues that I see, and to smooth out the wrinkles before the I-D goes to IETF last call and IESG review. As you will see below, I have a number of editorial comments (nits and larger changes) and also a few questions/issues. The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. I suggest you read the comments against those sections all together. Note that in my comment for section 9, I think I have worked out what you need to do, and so the resolution to the comments for 3.4 and 3.8 may simply be documenting this change to the IANA registry. As usual, all my comments are up for discussion, so please don't feel you are required to make changes if you think there is a good reason why things are the way they are. At the moment it looks like a new revision will be needed to address the review, so I have set the flag in the datatracker. Please work with your document shepherd to produce and post a new revision. Thanks, Adrian === The document seems to end with a spurious page header. --- The index seems to be considerably adrift from reality. In particular, there is no Appendix in this document. --- Why do you say that this updates RFC 4379? Is it your belief that an implementation of RFC 4379 will not be complete/conformant without these extensions? Or are you just defining extensions which an implementation in an MPLS-MT environment will need to support? I note that you (in my view, correctly) do not say that this document updates RFC 5036, yet it defines extensions to LDP in a similar way. --- Please expand all acronyms on first use unless they show with an asterisk in the RFC Editor's list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I see: CSP LSP QoS --- Abstract and Introduction "IGP protocol" is bad because the "P" in "IGP" is "protocol". --- The RFC Editor prefers documents to have the Introduction as Section 1. You may prefer to make this change yourself, because it will possibly cause some expansions of terms and acronyms that the RFC Editor might so in a way you don't like. --- In section 1, the term "MT Topology" is odd because the "T" of "MT" stands for "Topology". Surely you don't mean "Multi Topology Topology"? --- Section 3.1 s/infers/implies/ --- Section 3.2 I prefer that you don't repeat protocol encodings that are defined elsewhere. This can cause nasty problems if you make a mistake or if the original definition is updated. It is enough for you to write... The LDP base specification [RFC5036] (Section 4.1) defines the "Prefix" FEC Element. The "Prefix" encoding is defined for a given "Address Family" (AF), and has length (in bits) specified by the "PreLen" field. To extend IP address families for MT, two new Address Families named "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes within a topology scope. --- Section 3.2 Figure 2 This figure gives the impression that both IPv4 and IPv6 addresses are four bytes long! I think you need: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MT IP Address Family Format ...and... Where "IP Address" is a variable length field padded to a four octet boundary and containing an IPv4 or IPv6 address/prefix for the "MT IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to the 16-bit Topology ID for given address. ...but you need to check I got that right! However, before doing this work, see my comment on Section 3.3 --- Section 3.2 The proposed FEC Elements with "MT IP" Address Family can be used in You are not proposing any more, you are defining! See also section 3.6, 3.8, 4.1, 4.3, and 8 --- Section 3.2 [RFC5036] does not specify the handling of "Unknown" Address Families. Therefore, [RFC5036] will need to be updated to include the handling procedure for unknown address families. Ouch! This had me really worried because it implied that you are breaking existing LDP deployments. But I discussed it with Loa, and he pointed me at Section 3.4.1.1 of RFC 5036 "If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error. If it encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error." So I think you can just delete this paragraph. Furthermore, Section 3.5 defines a capability advertisement that enables you to know whether it is safe to use one of the new AFs. So surely you should also say "MUST NOT send an MT AF unless the peer has said it can handle it." See my re-write in the next comment. --- Section 3.3 appears to be repeating a lot of Section 3.2, but in a better and more concise way. For example, Figure 3 nicely shows how the Prefix FEC element works with the new AFs. This leads me to think that Section 3.2 could be reduced to just a few lines that say... The LDP base specification [RFC5036] (Section 4.1) defines the the use of an "Address Family" (AF) field in FEC Elements to indicate the encoding of the "Prefix" or "Address" that follows, and to indicate how the FEC should be interpreted. This document defines two new AF values named "MT IP" and "MT IPv6" that are used to specify the use of IPv4 or IPv6 within a topology scope. The data associated with these new AFs includes an "MT-ID" field that carries the 16-bit Topology ID for a topology. The value of MT-ID=0 corresponds to default topology and MUST be ignored on receipt so as to not cause any conflict/confusion with existing non-MT procedures. FEC Elements with the new AFs can be used in any LDP message and procedures that currently specify and allow the use of FEC Elements with the IP or IPv6 AFs, but MUST NOT be used unless the peer has indicated it can handle them as described in Section 3.5. Note that behavior by an LDP speaker that receives a FEC element containing an unknown AF is described in Section 3.4.1.1 of [RFC5036]. --- Section 3.4 is perfectly clear except it doesn't say what "reserved", "special", and "translating" mean. This opens up a number of questions including why you need a registry at all. Presumably the "translation" needed is to ensure that the values used in LDP have the same meaning as they do in the IGP. If that is the case, why not simply use exactly the same value? And looking at the registry further, it seems to say that only values allocated by IANA and stored in the registry can be used. That means that an operator that wants to use MT in their network cannot just assign values to the MT-IDs for the topologies because the registry has no space for this to happen. Now, it is possible that you have simply used the wrong words in the registry in section 9, and failed to provide any explanation in the text. Note that "unassigned" means "not yet assigned, but available to be assigned by IANA". And "Reserved" means "Do not assign until a new RFC defines how they should be used." But there are other questions: Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? I guess 16 is convenient to hold either, but how are the top 4 bits to be handled? How do you handle the case where there are multiple instances of an IGP (or different IGPs) running? If you *do* expect there to be a mapping function between IGP MT-ID and LDP MT-ID, how do you ensure the same function is used at both ends of an LDP session? But Section 3.8 really does seem to say that only MT-IDs in the registry are allowed, which seems to make this I-D almost useless because you have only defined "default" (which we have already), "ISIS IPv6", and "all". Isn't an operator allowed to partition their network into topologies? So... I think what you need in Section 9 is... o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. The allocation policies for this registry are: Range Registration Policy ------ ------------------- 0-3995 Expert Review 3996-4095 Private Use 4096-4127 Expert Review 4128-4255 Private Use 4256-4351 Reserved (IANA does not assign) 4352-4511 Expert Review 4512-65535 Private Use IANA is requested to populate this registry as follows: Range/Value Purpose Reference ----------- ------------------------------------- --------- 0 Default/standard topology in IS-IS [This.I-D] 1 IPv4 in-band management in IS-IS [This.I-D] 2 IPv6 routing topology in IS-IS [This.I-D] 3 IPv4 multicast topology in IS-IS [This.I-D] 4 IPv6 multicast topology in IS-IS [This.I-D] 5 IPv6 in-band management in IS-IS [This.I-D] 6-3995 Unassigned (intended to mirror IS-IS) 3996-4095 Reserved for private use (from IS-IS) [This.I-D] 4096 Default/standard topology in OSPF [This.I-D] 4097 Default multicast topology in OSPF [This.I-D] 4098 IPv4 in-band management in OSPF [This.I-D] 4099-4127 Unassigned (intended to mirror OSPF) 4128-4255 Reserved for private use (from OSPF) [This.I-D] 4256-4351 Reserved (IANA does not assign) [This.I-D] 4352-4511 Unassigned 4512-65535 Reserved for Private Use [This.I-D] This would address many of the issues in Sections 3.4 and 3.8, and needs to be discussed in those sections. --- In Section 3.5 o Length: The length (in octets) of TLV. Are you sure it is not just the length in octets of the value? Compare with RFC 5036 Section 3.3 --- Sections 3.5 and 3.6 need to be more closely grouped. Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 --- Section 3.6 To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker MAY send an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker MAY send "MT Capability" with one or more MT Typed FEC elements in it. I don't think this is "MAY" in either case. This *is* how the LDP speaker announces it. There is no other way to announce it. So... To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker sends an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker sends "MT Capability" with one or more MT Typed FEC elements in it. --- Section 3.6 o If an LSR has not advertised MT capability, its peer must not send messages that include MT identifier to this LSR. Isn't that "MUST NOT"? --- Section 3.8 Certain MT topologies are assigned to serve predetermined purposes: It is not the topology that is assigned, but the MT-ID. Should read: Certain MT-ID values are assigned to indicate specific meanings: --- Section 3.8 It is not helpful to "propose" numbers in this section and then to also reference Section 9 for the definitive numbers. I suggest you remove all numbers from this section and simply point at Section 9. --- Section 4.2 This MAY allow an LDP speaker to signal its IP convergence... What does 2119 MAY mean in this context? --- Section 4.3 [RFC4379] defines procedures to detect data-plane failures in MPLS LSPs via LSP ping. The specification defines a "Target FEC Stack" TLV that describes the FEC stack being tested. Ha, ha! You got me :-) s/The specification/That specification/ --- Section 4.3.1 Sub-Type Length Value Field -------- ------ ----------------- TBA5 5 MT LDP IPv4 prefix TBA6 17 MT LDP IPv6 prefix Are you sure you don't mean 8 and 20? --- Section 4.3.4 When detect data plane failures using LSP Ping for a specific topoly, the router will intiate an LSP Ping request with the targer FEC stack I think s/When/To/ s/topoly/topology/ s/intiate/initiate/ s/targer/target/ --- Section 4.3.4 For the case that the LSP ping with return path not specified , the reply packet may go through the default topology instead of the topology where the Echo Request goes through. Is that really "the default" or "any"? If you mean "the default" then I think you need some "MUST NOT" text to talk about other topologies. --- Section 5 The extensions defined in this document utilise the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for an MPLS-MT session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all MT-ID label mappings learned via the session. There is nothing wrong with this text, but it does open a question that is not addressed anywhere in the document: what is the relationship between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? This is somewhat assumable from the discussion of multiple MT-ID wildcard FEC elements in the Multi-Topology Capability TLV, but it is not explicit. --- Shouldn't Section 6 comment on how each of the new protocol elements will not be seen by a legacy implementation because they are only used after successful capability negotiation? But you do need to describe how a legacy node will react to attempted MT capability negotiation. You could also restate the reference to RFC 5036 section 3.4.1.1 since this issue seemed to be a question for you. --- I'm slightly doubtful about the value of Section 7, but I note that the point you are trying to convey is not quite worded correctly. You have: and the specified signaling mechanisms do not provide any way for the data plane to associate a given packet with a context-specific label space. I don't think the signaling mechanism is relevant, and I think "context- specific" hides what you are trying to say. Perhaps you should have: and there is no way for the data plane to associate a received packet with any one topology, meaning that topology-specific label spaces cannot be used. --- Section 9 o New Status Code: "Multi-Topology Capability not supported" (requested code point: TBA2 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is an implementation that does not know the new MT Capability TLV supposed to generate this status code? Or are you referencing an existing error code: in which case it should not appear in this section. o New Status Code: "Unknown Address Family" (requested code point: TBA4 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is a legacy implementation that does not know either of your new MT AFs supposed to generate this status code? But I suspect you are just referencing an existing error code (see Section 3.2) as defined in RFC 5036, and so you should not mention it in this section. Figure 10 does not show either of these status codes. --- Figure 10 shows a specific value for the new status code. Is this a request or demand? I don't think it has already been allocated. --- Section 9 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. This registry is discussed earlier in my notes. but please be aware that you will need to define the allocation policy because it is a new registry. --- Section 9 I want to ask Loa Andersson to look again at the LSP Ping TLV allocations to check that they conform to the work he is currently doing with that registry. --- It would help considerably to add a Manageability Considerations section to this document because the function being added here is not simple to manage or operate, and will have impact on the way that the network is run. Good guidance on such sections can be found in RFC 5706. Appendix A is particularly helpful at summarising things to consider. -------------------- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_00A8_01CE7652.3C71CD50 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I want to try to bring the two threads on the MT = ID ranges for IANA back together to try to understand what is being = proposed and what is possible.

 

First step is to recognise that the OSPF and ISIS = registries exist and already have numbers assigned from them. Thus we = are not going to manage to converge the OSPF and ISIS MT IDs into a = single registry with the same meanings.

 

Alia says "it'd be very useful to have that = range specifically set aside for cases where it matters that it be the = same" but doesn't give a concrete example of such a case. =

 

Furthermore, I am not comfortable with the idea = that both OSPF and ISIS might be running at the same time, as is implied = here, each distributing a different default topology, but with the two = topologies being aggregated for use by LDP. Perhaps I don't see the = network that you are trying to build and deploy, and a picture will help = explain it.

 

My "understanding" of the use case is = that a single instance of a single IGP runs in an area. That IGP may = distribute information about multiple routing topologies, each topology = having an MT ID. LDP is also running in the area and distributes labels = based on the preferred routes in each topology. Thus each label = advertisement includes a FEC and an MT ID.

 

In order to use the labels correctly, there must = be a mapping between the MT IDs used by the IGP, and those used by = LDP.

 

It is also possible that through network-wide = configuration of policy on the LDP implementations, LDP will use the = information from the IGP and the configured policy to formulate new and = different MPLS-only topologies. Thus, LDP might use an MT ID for its own = special topology.

 

There are two options:

 

1. Create a registry that is agnostic to the IGP = in use (i.e. doesn't indicate OSPF or ISIS) and which shows the use of = the topology.

   = 0      =       Default = topology

   = 1     =        IPv4 in-band = management topology

  =  2            IPv6 routing = topology

   = 3      =       IPv4 multicast routing = topology

   = 4     =        IPv6 multicast routing = topology

   = 5            IPv6 in-band management = topology

   = 6 - a    =   Reserved for = future IGP topologies (standards action)

   = a+1 - b Reserved for IGP experimental = topologies

   = b+1 - c Reserved for LDP topologies (standards = action)

   = c+1 - d Reserved for LDP experimental = topologies

 

2. Create a registry that is aware of the IGP in = use and is built on the existing OSPF and ISIS = registries.

This would be modelled on what I suggested before, = but adding allocations for LDP itself...

 

     0       &nbs= p;             &nbs= p; Default/standard = topology in IS-IS

     1        =        &nbs= p;       IPv4 = in-band management in IS-IS     =

     2        =        &nbs= p;       IPv= 6 routing topology in IS-IS   =

     3       &nbs= p;        &nbs= p;      IPv4 = multicast topology in IS-IS  =

     4       &nbs= p;          &nbs= p;    IPv6 multicast = topology in IS-IS   =

     5          &nbs= p;        &nbs= p;   IPv6 in-band management in IS-IS =

     6-3995       &nbs= p;    Unassigned (intended to = mirror IS-IS)

     = 3996-4095     Reserved for = private use (from IS-IS)

     4096       =          Default/standar= d topology in OSPF

     4097                Def= ault multicast topology in OSPF

     4098 =              &nbs= p; IPv4 in-band management in OSPF  

     4099-4127=      Unassigned (intended to mirror = OSPF)

     = 4128-4255   =   Reserved for = private use (from OSPF)

     = 4256-4351   =   Reserved = (IANA does not assign)  =

     4352-4511=      Unassigned=

     = 4512-4607     LDP use = (standards action)

     = 4608-65531   Reserved for Private = Use

     64432-65535 = Experimental use

 

 

In all cases, my concern is what happens when a = new IGP use is defined in an RFC. It would appear that the LDP registry = has to be updated to keep it in synch.

It is also unclear to me how we handle mapping an = IGP private use into the LDP private use.

The intention of the scheme in the second option = is to make that mapping automatic so that when an MT ID is used in an = IGP, we know how to map to the LDP MT ID even if we don't understand the = meaning of the IGP's MT ID.

 

It seems to me that what you might be asking for = in your email is a single MT ID value that is the default topology used = by LDP when it is based on OSPF or ISIS default topology and does not = want to indicate which it comes from. It that is the case, you could = assign 4512 in option 2 for this purpose.

 

I am convinced that the solution to this problem = is to work out what the mapping algorithm is. How does an LDP = implementation decide which MT ID to use in a label advertisement? How = does a packet-classifier decide which label to = use?

 

The answer may be: "It is assumed that this = mapping is manually configured on every = router"

Or it may be: "There is an automatic mapping = between IGP MT IDs and LDP MT IDs"

Or it may be something = else.

 

Once the answer is agreed, making a registry will = be easy.

 

Cheers,

Adrian

 

 

 

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of Quintin Zhao
Sent: 28 June 2013 = 21:41
To: 'Alia Atlas'
Cc: mpls@ietf.org; = draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org
Subject: = Re: [mpls] AD review of = draft-ietf-mpls-ldp-multi-topology

 

Hello Alia,

 

Thanks for your review and = suggestions.

 

Indeed we need to allocate a MT ID range for the applications = such as MRT so that MT ID can be the same for OSPF, ISIS and LDP. =

 

We need decide how big this range should be for the = applications such as MRT. What is your recommendation for this = range?

 

This is what we have now from = ISIS-MT(RFC5120):

 

 

   -  MT ID = #0:          Equivalent to = the "standard" topology.

   -  MT ID = #1:          Reserved for = IPv4 in-band management

          &nb= sp;           &nbs= p; =         purposes.

   -  MT ID = #2:          Reserved for = IPv6 routing topology.

   -  MT ID = #3:          Reserved for = IPv4 multicast routing topology.

   -  MT ID = #4:          Reserved for = IPv6 multicast routing topology.

   -  MT ID = #5:          Reserved for = IPv6 in-band management

          &nb= sp;           &nbs= p; =          purposes.

   -  MT ID #6-#3995:    = Reserved for IETF consensus.

   -  MT ID #3996-#4095: Reserved for = development, experimental and

          &nb= sp;           &nbs= p;  =             &= nbsp;  proprietary features [RFC3692].

 

This is what have now from = OSPF-MT(RFC4915)

 

          &nb= sp; 0      - Reserved for advertising the = metric associated

          &nb= sp;          with the = default topology (see Section 4.2)

          &nb= sp; 1      - Reserved for advertising the = metric associated

          &nb= sp;          with the = default multicast topology

          &nb= sp; 2      - Reserved for IPv4 in-band = management purposes

           = 3-31    - Reserved for assignments by = IANA

           = 32-127  - Reserved for development, experimental = and

          &nb= sp;          proprietary = features [RFC3692]

           = 128-255 - Invalid and SHOULD be ignored

 

The range which is available for us to use is from 6 = -127.

 

Thanks,

Quintin

 

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: = 2013=1B$BG/=1B(B5=1B$B7n=1B(B29=1B$BF|=1B(B 8:52
To: Adrian Farrel
Cc: = draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; = mpls@ietf.org
Subject: Re: [mpls] AD review of = draft-ietf-mpls-ldp-multi-topology

 

Hi Adrian & = authors,

 

=

I have a couple comments on the IANA = registry and number overlapping.

 

=

First, it would be useful to have a = range that is clearly intended to be the same for OSPF, ISIS and LDP. =  Given the

extremely limited range for OSPF = multi-topology routing (http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of

 

On Wed, May 29, 2013 at 2:18 AM, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi authors,

Thanks for this = document.

I have done my usual AD review which is intended to = catch any issues
that I see, and to smooth out the wrinkles before = the I-D goes to IETF
last call and IESG review.

As you will = see below, I have a number of editorial comments (nits and
larger = changes) and also a few questions/issues.

The biggest issue = concerns the MT-ID and spans sections 3.4, 3.8, and 9.
I suggest you = read the comments against those sections all together.
Note that in = my comment for section 9, I think I have worked out what
you need to = do, and so the resolution to the comments for 3.4 and 3.8
may simply = be documenting this change to the IANA registry.

As usual, all my = comments are up for discussion, so please don't feel
you are required = to make changes if you think there is a good reason why
things are = the way they are.

At the moment it looks like a new revision will = be needed to address the
review, so I have set the flag in the = datatracker. Please work with your
document shepherd to produce and = post a new = revision.

Thanks,
Adrian

=3D=3D=3D

The document = seems to end with a spurious page header.

---

The index = seems to be considerably adrift from reality.
In particular, there is = no Appendix in this document.

---

Why do you say that this = updates RFC 4379? Is it your belief that an
implementation of RFC = 4379 will not be complete/conformant without these
extensions? Or are = you just defining extensions which an implementation
in an MPLS-MT = environment will need to support?

I note that you (in my view, = correctly) do not say that this document
updates RFC 5036, yet it = defines extensions to LDP in a similar way.

---

Please = expand all acronyms on first use unless they show with an
asterisk in = the RFC Editor's list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expans= ion.txt

I = see:
CSP
LSP
QoS

---

Abstract and = Introduction

"IGP protocol" is bad because the = "P" in "IGP" is = "protocol".

---

The RFC Editor prefers documents = to have the Introduction as Section 1.

You may prefer to make = this change yourself, because it will possibly
cause some expansions = of terms and acronyms that the RFC Editor might
so in a way you don't = like.

---

In section 1, the term "MT Topology" = is odd because the "T" of "MT"
stands for = "Topology". Surely you don't mean "Multi Topology = Topology"?

---

Section = 3.1

s/infers/implies/

---

Section 3.2

I = prefer that you don't repeat protocol encodings that are = defined
elsewhere. This can cause nasty problems if you make a = mistake or if
the original definition is updated.

It is enough = for you to write...

   The LDP base specification = [RFC5036] (Section 4.1) defines the
   "Prefix" = FEC Element.  The "Prefix" encoding is defined for a = given
   "Address Family" (AF), and has length = (in bits) specified by the
   "PreLen" = field.

   To extend IP address families for MT, two new = Address Families named
   "MT IP" and "MT = IPv6" are used to specify IPv4 and IPv6 prefixes
  =  within a topology scope.

---

Section 3.2 Figure = 2

This figure gives the impression that both IPv4 and IPv6 = addresses are
four bytes long!

I think you need:

  =     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
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~               =       IP Address           =                     =  ~
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |          Reserved =             |       =  MT-ID                 =  |
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  =  Figure 2: MT IP Address Family = Format

...and...

   Where "IP Address" = is a variable length field padded to a four octet
  =  boundary and containing an IPv4 or IPv6 address/prefix for the = "MT
   IP" and "MT IPv6" AFs = respectively.  The field "MT-ID" corresponds to
  =  the 16-bit Topology ID for given address.

...but you need = to check I got that right!

However, before doing this work, see = my comment on Section 3.3

---

Section 3.2

  =  The proposed FEC Elements with "MT IP" Address Family = can be used in

You are not proposing any more, you are = defining!

See also section 3.6, 3.8, 4.1, 4.3, and = 8

---

Section 3.2

   [RFC5036] does not = specify the handling of "Unknown" Address
  =  Families.  Therefore, [RFC5036] will need to be updated to = include
   the handling procedure for unknown address = families.

Ouch!

This had me really worried because it = implied that you are breaking
existing LDP deployments. But I = discussed it with Loa, and he pointed me
at Section 3.4.1.1 of RFC = 5036

   "If in decoding a FEC TLV an LSR = encounters a FEC Element with an
    Address Family it does = not support, it SHOULD stop decoding the FEC
    TLV, abort = processing the message containing the TLV, and send an
    = "Unsupported Address Family" Notification message to its LDP = peer
    signaling an error.

    If it = encounters a FEC Element type it cannot decode, it SHOULD stop
  =   decoding the FEC TLV, abort processing the message containing = the
    TLV, and send an "Unknown FEC" = Notification message to its LDP peer
    signaling an = error."

So I think you can just delete this = paragraph.

Furthermore, Section 3.5 defines a capability = advertisement that enables
you to know whether it is safe to use one = of the new AFs.  So surely you
should also say "MUST NOT = send an MT AF unless the peer has said it can
handle = it."

See my re-write in the next = comment.

---

Section 3.3 appears to be repeating a lot of = Section 3.2, but in a
better and more concise way. For example, = Figure 3 nicely shows how the
Prefix FEC element works with the new = AFs.

This leads me to think that Section 3.2 could be reduced to = just a few
lines that say...

   The LDP base = specification [RFC5036] (Section 4.1) defines the
   the = use of an "Address Family" (AF) field in FEC Elements to = indicate
   the encoding of the "Prefix" or = "Address" that follows, and to
   indicate how = the FEC should be interpreted.

   This document defines = two new AF values named "MT IP" and "MT = IPv6"
   that are used to specify the use of IPv4 or = IPv6 within a topology
   scope.  The data associated = with these new AFs includes an "MT-ID"
   field = that carries the 16-bit Topology ID for a topology.

  =  The value of MT-ID=3D0 corresponds to default topology and MUST = be
   ignored on receipt so as to not cause any = conflict/confusion with
   existing non-MT = procedures.

   FEC Elements with the new AFs can be = used in any LDP message and
   procedures that currently = specify and allow the use of FEC Elements
   with the IP or = IPv6 AFs, but MUST NOT be used unless the peer has
  =  indicated it can handle them as described in Section 3.5. =  Note that
   behavior by an LDP speaker that receives = a FEC element containing an
   unknown AF is described in = Section 3.4.1.1 of [RFC5036].

---

Section 3.4 is perfectly = clear except it doesn't say what = "reserved",
"special", and = "translating" mean.

This opens up a number of questions = including why you need a registry
at all.  Presumably the = "translation" needed is to ensure that the
values used in = LDP have the same meaning as they do in the IGP. If that
is the case, = why not simply use exactly the same value?

And looking at the = registry further, it seems to say that only values
allocated by IANA = and stored in the registry can be used. That means
that an operator = that wants to use MT in their network cannot just
assign values to = the MT-IDs for the topologies because the registry
has no space for = this to happen.

Now, it is possible that you have simply used the = wrong words in the
registry in section 9, and failed to provide any = explanation in the
text.  Note that "unassigned" means = "not yet assigned, but available
to be assigned by IANA". =  And "Reserved" means "Do not assign until
a new = RFC defines how they should be used."

But there are other = questions:

Why do you need 16 bits when ISIS has only 12 bits and = OSPF only 8 bits?
I guess 16 is convenient to hold either, but how = are the top 4 bits to
be handled?

How do you handle the case = where there are multiple instances of an IGP
(or different IGPs) = running?

If you *do* expect there to be a mapping function = between IGP MT-ID and
LDP MT-ID, how do you ensure the same function = is used at both ends of
an LDP session?

But Section 3.8 really = does seem to say that only MT-IDs in the registry
are allowed, which = seems to make this I-D almost useless because you
have only defined = "default" (which we have already), "ISIS IPv6", = and
"all". Isn't an operator allowed to partition their = network into
topologies?

So...

I think what you need in = Section 9 is...

   o  New registry "LDP = Multi-Topology (MT) ID Name Space" under "LDP
    =   Parameter" namespace.  The allocation policies for this = registry
      are:

      Range =           Registration Policy
    =   ------         =  -------------------
      0-3995     =      Expert Review
      3996-4095 =       Private Use
      4096-4127 =       Expert Review
      4128-4255 =       Private Use
      4256-4351 =       Reserved (IANA does not assign)
    =   4352-4511       Expert Review
    =   4512-65535      Private Use

    =   IANA is requested to populate this registry as = follows:


      Range/Value   =  Purpose                 =                 = Reference
      -----------   =  -------------------------------------   ---------
  =     0             =  Default/standard topology in IS-IS     =  [This.I-D]
      1         =      IPv4 in-band management in IS-IS     =    [This.I-D]
      2       =        IPv6 routing topology in IS-IS     =      [This.I-D]
      3     =          IPv4 multicast topology in IS-IS =        [This.I-D]
      4   =            IPv6 multicast topology in = IS-IS        [This.I-D]
      5 =              IPv6 in-band management = in IS-IS        [This.I-D]
      = 6-3995         Unassigned (intended to mirror = IS-IS)
      3996-4095      Reserved = for private use (from IS-IS)   [This.I-D]
      = 4096           Default/standard topology in = OSPF       [This.I-D]
      4097   =         Default multicast topology in OSPF   =    [This.I-D]
      4098     =       IPv4 in-band management in OSPF     =     [This.I-D]
      4099-4127     =  Unassigned (intended to mirror OSPF)
      = 4128-4255      Reserved for private use (from OSPF) =    [This.I-D]
      4256-4351     =  Reserved (IANA does not assign)         = [This.I-D]
      4352-4511     =  Unassigned
      4512-65535     = Reserved for Private Use             =    [This.I-D]

This would address many of the issues in = Sections 3.4 and 3.8, and needs
to be discussed in those = sections.

---

In Section 3.5

   o =  Length: The length (in octets) of TLV.

Are you sure it is = not just the length in octets of the value?
Compare with RFC 5036 = Section 3.3

---

Sections 3.5 and 3.6 need to be more = closely grouped.

Suggest moving most of 3.5 into 3.5.1 and moving = 3.6 into 3.5.2

---

Section 3.6

   To = announce its MT capability for an IP address family, LDP FEC = type,
   and Multi Topology, an LDP speaker MAY send an = "MT Capability"
   including the exact Typed = Wildcard FEC element with corresponding
  =  "AddressFamily" field (i.e., set to "MT IP" = for IPv4 and set to "MT
   IPv6" for IPv6 address = family), corresponding "FEC Type" field (i.e.,
  =  set to "P2P", "P2MP", "MP2MP"), and = corresponding "MT-ID".  To
   announce its = MT capability for both IPv4 and IPv6 address family, or
  =  for multiple FEC types, or for multiple Multi Topologies, an = LDP
   speaker MAY send "MT Capability" with one = or more MT Typed FEC
   elements in it.

I don't = think this is "MAY" in either case. This *is* how the = LDP
speaker announces it. There is no other way to announce it. = So...

   To announce its MT capability for an IP = address family, LDP FEC type,
   and Multi Topology, an LDP = speaker sends an "MT Capability" including
   the = exact Typed Wildcard FEC element with corresponding
  =  "AddressFamily" field (i.e., set to "MT IP" = for IPv4 and set to "MT
   IPv6" for IPv6 address = family), corresponding "FEC Type" field (i.e.,
  =  set to "P2P", "P2MP", "MP2MP"), and = corresponding "MT-ID".  To
   announce its = MT capability for both IPv4 and IPv6 address family, or
  =  for multiple FEC types, or for multiple Multi Topologies, an = LDP
   speaker sends "MT Capability" with one or = more MT Typed FEC elements
   in = it.

---

Section 3.6

   o  If an LSR = has not advertised MT capability, its peer must not send
  =     messages that include MT identifier to this = LSR.

Isn't that "MUST NOT"?

---

Section = 3.8

   Certain MT topologies are assigned to serve = predetermined purposes:

It is not the topology that is assigned, = but the MT-ID. Should read:

   Certain MT-ID values are = assigned to indicate specific meanings:

---

Section = 3.8

It is not helpful to "propose" numbers in this = section and then to
also reference Section 9 for the definitive = numbers.  I suggest you
remove all numbers from this section and = simply point at Section 9.

---

Section 4.2

  =  This MAY allow an LDP speaker to signal its IP = convergence...

What does 2119 MAY mean in this = context?

---

Section 4.3

   [RFC4379] = defines procedures to detect data-plane failures in MPLS
  =  LSPs via LSP ping.  The specification defines a "Target = FEC Stack"
   TLV that describes the FEC stack being = tested.

Ha, ha! You got me :-)
s/The specification/That = specification/

---

Section 4.3.1

    =      Sub-Type       Length     =        Value Field
        =  --------       ------         =    -----------------
          =    TBA5            5   =          MT LDP IPv4 prefix
    =          TBA6         =   17            MT LDP IPv6 = prefix

Are you sure you don't mean 8 and = 20?

---

Section 4.3.4

   When detect data = plane failures using LSP Ping for a specific topoly,
   the = router will intiate an LSP Ping request with the targer FEC = stack

I = think

s/When/To/

s/topoly/topology/

s/intiate/initia= te/

s/targer/target/

---

Section = 4.3.4

   For the case that the LSP ping with return = path not specified , the
   reply packet may go through the = default topology instead of the
   topology where the Echo = Request goes through.

Is that really "the default" or = "any"?
If you mean "the default" then I think you = need some "MUST NOT" text to
talk about other = topologies.

---

Section 5

   The = extensions defined in this document utilise the existing LDP
  =  error handling defined in [RFC5036].  If an LSR receives an = error
   notification from a peer for an MPLS-MT session, = it terminates the
   LDP session by closing the TCP = transport connection for the session
   and discarding all = MT-ID label mappings learned via the session.

There is nothing = wrong with this text, but it does open a question that
is not = addressed anywhere in the document: what is the relationship
between = LDP sessions and MT-IDs?  1:1, 1:n, n:1, n:m?

This is = somewhat assumable from the discussion of multiple MT-ID
wildcard FEC = elements in the Multi-Topology Capability TLV, but it is
not = explicit.

---

Shouldn't Section 6 comment on how each of = the new protocol elements
will not be seen by a legacy implementation = because they are only used
after successful capability = negotiation?

But you do need to describe how a legacy node will = react to attempted
MT capability negotiation.

You could also = restate the reference to RFC 5036 section 3.4.1.1 since
this issue = seemed to be a question for you.

---

I'm slightly doubtful = about the value of Section 7, but I note that the
point you are = trying to convey is not quite worded correctly. You have:

  =  and the specified
   signaling mechanisms do not = provide any way for the data plane to
   associate a given = packet with a context-specific label space.

I don't think the = signaling mechanism is relevant, and I think = "context-
specific" hides what you are trying to say. =  Perhaps you should have:

   and there is no = way
   for the data plane to associate a received packet = with any one
   topology, meaning that topology-specific = label spaces cannot be used.

---

Section 9

  =  o  New Status Code: "Multi-Topology Capability not = supported"
      (requested code point: TBA2 from = LDP registry "Status Code Name
      = Space").

This status code does not appear to be mentioned in = the draft. How is
it used? Is an implementation that does not know = the new MT Capability
TLV supposed to generate this status code? Or = are you referencing an
existing error code: in which case it should = not appear in this section.

   o  New Status Code: = "Unknown Address Family" (requested code point:
  =     TBA4 from LDP registry "Status Code Name = Space").

This status code does not appear to be mentioned in = the draft. How is
it used? Is a legacy implementation that does not = know either of your
new MT AFs supposed to generate this status code? = But I suspect you are
just referencing an existing error code (see = Section 3.2) as defined in
RFC 5036, and so you should not mention it = in this section.

Figure 10 does not show either of these status = codes.

---

Figure 10 shows a specific value for the new = status code. Is this a
request or demand? I don't think it has = already been allocated.

---

Section 9

  =  o  New registry "LDP Multi-Topology (MT) ID Name = Space" under "LDP
      Parameter" = namespace.

This registry is discussed earlier in my notes. but = please be aware that
you will need to define the allocation policy = because it is a new
registry.

---

Section 9

I = want to ask Loa Andersson to look again at the LSP Ping = TLV
allocations to check that they conform to the work he is = currently
doing with that registry.

---

It would help = considerably to add a Manageability Considerations section
to this = document because the function being added here is not simple = to
manage or operate, and will have impact on the way that the = network is
run. Good guidance on such sections can be found in RFC = 5706. Appendix A
is particularly helpful at summarising things to = consider.

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

____________________________= ___________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 

------=_NextPart_000_00A8_01CE7652.3C71CD50-- From adrian@olddog.co.uk Mon Jul 1 04:08:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5453021F844E for ; Mon, 1 Jul 2013 04:08:55 -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=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmV5SLERzOVb for ; Mon, 1 Jul 2013 04:08:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id F163B21F8900 for ; Mon, 1 Jul 2013 04:08:38 -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 r61B8R3e029643; Mon, 1 Jul 2013 12:08:27 +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 r61B8PU7029583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 12:08:27 +0100 From: "Adrian Farrel" To: "'Quintin Zhao'" , Date: Mon, 1 Jul 2013 12:08:25 +0100 Message-ID: <00b801ce764b$4fb7bf70$ef273e50$@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: Ac52SrgNeAtL295CTbClsSx9rdbdlw== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] Management considerations in draft-ietf-mpls-ldp-multi-topology 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, 01 Jul 2013 11:08:55 -0000 Hi, > (2) Regarding to the Manageability Considerations, it is indeed as what you > suggested here that the function being added here is not simple to manage or > operate, and will have impact on the way that the network is run. We are > thinking to have a separate document to detail these considerations late. > Will this be OK? It is possible that you will get away with a pointer to another document, but I think this would only work if that document really exists and has content. The IESG has (by now) got used to the trick of pointing at another document that is never written :-) The purpose of pushing for management considerations at this stage is that there may be elements of the manageability that require rethinking of how the protocol works. Frankly, I think that the discussion of the IANA registry is one such example. How do I, as an operator trying to debug my network, make the association between the LDP label advertisement, and the IGP routing advertisement if I don't know the mapping that has been used to convert the IGP MT ID into the LDP MT ID? Thus, I think it worth taking the time to at least set out the management problems. Some may require additional protocol development in BFD or somesuch, and you don't need to do those developments up front. But you should identify what work is needed. Adrian From amalis@gmail.com Fri Jun 28 05:36:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D921F9D5B; Fri, 28 Jun 2013 05:36:44 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaWnEWNaYqdl; Fri, 28 Jun 2013 05:36:38 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3221F9F08; Fri, 28 Jun 2013 05:34:48 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so1896017obc.10 for ; Fri, 28 Jun 2013 05:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vwedOUcpIJdS1x5KkWVyaADfzQIweQuLgWLsrI9EV+E=; b=CkBwN6kPRItgJ9mBO+0XiCYwDsgBzvqCKSb67gMfouTBGiXeRgB/d866wYWC3R9rTf dRysr+l3JBsBwJ0xnkWc20e33NJeQwJUDQN3ug4U+KrroCcqnp9KH4Weo6UUaSGQ3Vaz IQzfVuGrYwRrugHz9crQ5INOBPzxHI1XBDLLDDKrj8anWJK3MZ10qbagisVRZwjYwh56 iw96DwVUHNIY//ma9rJlRzGRyWWCbDZM1eHmjor6peKkJJeQBYqBBTzhiJ6Ofd/LqDPI k3l3aJbTXGNwA+JtRxdVAebi8YJ9LFKpgghO8LKHUqCpMZbrdFJUspnYacOgs3HS3XjW hGlA== X-Received: by 10.182.27.102 with SMTP id s6mr6163772obg.42.1372422887795; Fri, 28 Jun 2013 05:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.144.65 with HTTP; Fri, 28 Jun 2013 05:34:27 -0700 (PDT) In-Reply-To: <001401ce73fa$8f45d620$add18260$@olddog.co.uk> References: <51B9BE97.2090103@pi.nu> <51CD64A1.4010408@pi.nu> <001401ce73fa$8f45d620$add18260$@olddog.co.uk> From: "Andrew G. Malis" Date: Fri, 28 Jun 2013 08:34:27 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e01184c8cb5773304e0361afe X-Mailman-Approved-At: Mon, 01 Jul 2013 05:25:09 -0700 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "pwe3@ietf.org" , "pwe3-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] [PWE3] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 28 Jun 2013 12:36:44 -0000 --089e01184c8cb5773304e0361afe Content-Type: text/plain; charset=ISO-8859-1 Adrian, Looks good to me. Just from an English language aspect (here I am lecturing a Brit about English :-) I suggest either removing the final comma from your text or alternatively adding a comma after "ACH messages". Cheers, Andy On Fri, Jun 28, 2013 at 8:25 AM, Adrian Farrel wrote: > > However TLVs might be carried in the GACh messages, the disticnction > > is not entirely clear in the draft, can the authors please make > > this clear. > > Happily. > > The current version defines "ACH TLV" as "TLV constructs that can be > carried in > messages on the G-ACh by placing them in the ACH between the fixed header > fields > and the G-ACh message." > > Thus, retiring ACH TLVs, obviously means only removing this concept and > not any > other TLV-related concept. > > I would propose to change the last sentence of Section 1 as follows: > > OLD > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. > NEW > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. This document makes no comment about the > use of TLVs in other places. In particular, proposals to use TLVs > within ACH messages, or as an appendage to ACH messages are not in > scope of this document. > END > > Does that work? > > Thanks, > Adrian > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --089e01184c8cb5773304e0361afe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian,

Looks good to me.= Just from an English language aspect (here I am lecturing a Brit about Eng= lish :-) I suggest either removing the final comma from your text or altern= atively adding a comma after
"ACH messages".

Cheers,
Andy


On Fri, Jun = 28, 2013 at 8:25 AM, Adrian Farrel <adrian@olddog.co.uk> w= rote:
> However TLVs might be= carried in the GACh messages, the disticnction
> is not entirely clear in the draft, can the authors please make
> this clear.

Happily.

The current version defines "ACH TLV" as "TLV constructs tha= t can be carried in
messages on the G-ACh by placing them in the ACH between the fixed header f= ields
and the G-ACh message."

Thus, retiring ACH TLVs, obviously means only removing this concept and not= any
other TLV-related concept.

I would propose to change the last sentence of Section 1 as follows:

OLD
=A0 =A0This document states that ACH TLVs as specified in RFC 5586 are not<= br> =A0 =A0useful and might be harmful. =A0It updates RFC 5586 by deprecating t= he
=A0 =A0ACH TLV and updating the associated IANA registries as described in<= br> =A0 =A0Section 4 of this document.
NEW
=A0 =A0This document states that ACH TLVs as specified in RFC 5586 are not<= br> =A0 =A0useful and might be harmful. =A0It updates RFC 5586 by deprecating t= he
=A0 =A0ACH TLV and updating the associated IANA registries as described in<= br> =A0 =A0Section 4 of this document. =A0This document makes no comment about = the
=A0 =A0use of TLVs in other places. =A0In particular, proposals to use TLVs=
=A0 =A0within ACH messages, or as an appendage to ACH messages are not in =A0 =A0scope of this document.
END

Does that work?

Thanks,
Adrian

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

--089e01184c8cb5773304e0361afe-- From josh.rogers@twcable.com Mon Jul 1 06:19:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C356911E83EA for ; Mon, 1 Jul 2013 06:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du8pi1hahq4g for ; Mon, 1 Jul 2013 06:19:04 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 017BF11E81C5 for ; Mon, 1 Jul 2013 06:17:12 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,974,1363147200"; d="scan'208";a="101355090" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2013 09:15:12 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 1 Jul 2013 09:16:59 -0400 From: "Rogers, Josh" To: "Will Liu (Shucheng)" , "mpls@ietf.org" Date: Mon, 1 Jul 2013 09:16:57 -0400 Thread-Topic: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt Thread-Index: Ac52XUOvYRZ5yH6VRwOOT7aZdQPZkg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 13:19:08 -0000 RE: MplsNewExtendedTunnelId >For IPv6 this represents an IPv4 address of the ingress or >egress LSR for the tunnel for an IPv6 network. We've been interested in changing a couple of private networks to v6 only, but are waiting for feature in code and maturity of v6 MPLS, so may still be a while before we can do it. I noticed that the language about the Extended TunnelID uses words like 'suggests' and 'should' when speaking about using a v4 loopback address as the TunnelId for a 'IPv6 network'. If there is no v4 address because the network is v6 only, what should be used instead? Are we setting the expectation that everything will be dual stacked forever? Thanks for your response and insight, Josh On 6/27/13 11:58 PM, "Will Liu (Shucheng)" wrote: >Hi Folks, > >We uploaded a new version to address the comments about MplsLSPID >description as below. We are looking forward to your further comments. >Thanks. > >Cheers, >Will > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Friday, June 28, 2013 12:54 PM >To: Tina TSOU; Will Liu (Shucheng); Francesco Fondelli; Vishwas Manral; >Will Liu (Shucheng) >Subject: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt > > >A new version of I-D, draft-manral-mpls-rfc3811bis-03.txt >has been successfully submitted by Vishwas Manral and posted to the >IETF repository. > >Filename: draft-manral-mpls-rfc3811bis >Revision: 03 >Title: Definitions of Textual Conventions (TCs) for Multiprotocol= Label >Switching (MPLS) Management >Creation date: 2013-06-28 >Group: Individual Submission >Number of pages: 22 >URL: >http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-03.txt >Status: >http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis >Htmlized: >http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-03 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-manral-mpls-rfc3811bis-03 > >Abstract: > This memo defines a Management Information Base (MIB) module which > contains Textual Conventions to represent commonly used Multiprotocol > Label Switching (MPLS) management information. The intent is that > these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS > related MIB modules that would otherwise define their own > representations. > > This document obsoletes RFC3811 as it addresses the need to support > IPv6 extended TunnelID's by defining a new TC- > MplsNewExtendedTunnelID which suggests using IPv4 address of the > ingress or egress LSR for the tunnel for an IPv6 network. Changes > from RFC3811 and the effect of the new TC to other related documents > are summarized in Section 4 and 5, respectively. > > > > > >The IETF Secretariat > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Mon Jul 1 06:43:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8072921F9F47; Mon, 1 Jul 2013 06:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qOMcm+LDKsU; Mon, 1 Jul 2013 06:43:22 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 150BB21F9F44; Mon, 1 Jul 2013 06:43:21 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,974,1363147200"; d="scan'208";a="98170762" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2013 09:40:59 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 1 Jul 2013 09:42:53 -0400 From: "George, Wes" To: "mpls@ietf.org" Date: Mon, 1 Jul 2013 09:42:50 -0400 Thread-Topic: IPv6-only MPLS gap analysis Thread-Index: Ac52YN0rty2KcGKdS1SHtmzwtosE3w== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230435B0ECC4@PRVPEXVS15.corp.twcable.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-Mailman-Approved-At: Mon, 01 Jul 2013 06:46:12 -0700 Cc: "l2vpn@ietf.org" , "draft-ietf-l2vpn-evpn@tools.ietf.org" , "l3vpn@ietf.org" , "draft-mpls-ipv6-only-gap@tools.ietf.org" Subject: [mpls] IPv6-only MPLS gap analysis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 01 Jul 2013 13:43:26 -0000 QXMgZGlzY3Vzc2VkIGluIE9ybGFuZG8gaW4gdGhlIE1QTFMgV0csIHdlIGhhdmUgYmVndW4gd29y ayBvbiBhIEdhcCBBbmFseXNpcyBmb3IgTVBMUyBvcGVyYXRpb24gb24gYW4gSVB2Ni1vbmx5IG5l dHdvcmsuIEkgYW0gY29weWluZyB0aGUgTDJWUE4gYW5kIEwzVlBOIFdHcywgYXMgdGhlIGF1dGhv cnMgd291bGQgY2VydGFpbmx5IHZhbHVlIHRoZWlyIHJldmlldyBhbmQgaW5wdXQsIGFuZCB3ZSBh bHNvIHdhbnRlZCB0byBtYWtlIHRob3NlIFdHcyBhd2FyZSBvZiB0aGUgbmVlZCB0byBiZWdpbiBj b25zaWRlcmluZyBJUHY2LW9ubHkgb3BlcmF0aW9uIGluIGFueSBuZXcgc3RhbmRhcmRzIHdvcmsg dGhhdCB0aGV5IG1pZ2h0IHVuZGVydGFrZSwgZS5nLiBFVlBOLiBUaGlzIG1heSB0YWtlIHRoZSBm b3JtIG9mIHJlZmVycmluZyB0byBleGlzdGluZyBnYXBzIGZyb20gdGhpcyBkb2N1bWVudCB0aGF0 IG11c3QgYmUgYWRkcmVzc2VkIGJlZm9yZSB0aGUgZGVwZW5kZW5jeSBpcyByZXNvbHZlZCwgb3Ig aXQgbWF5IHRha2UgdGhlIGZvcm0gb2YgY2hhbmdlcyB0byB0aGUgZHJhZnQgdG8gZXhwbGljaXRs eSBhbGxvdyBJUHY2LW9ubHkgb3BlcmF0aW9uLCBidXQgd2UgbGltaXRlZCBvdXIgc2NvcGUgdG8g ZXhpc3RpbmcgUkZDcyBpbiBvcmRlciB0byBrZWVwIHdoYXQgaXMgYWxyZWFkeSBhIGZhaXJseSBs YXJnZSB1bmRlcnRha2luZyBtYW5hZ2VhYmxlLg0KDQpUaGlzIGlzIHN0aWxsIHZlcnkgbXVjaCBh IHdvcmsgaW4gcHJvZ3Jlc3MuIFdlJ3JlIGVzcGVjaWFsbHkgaW50ZXJlc3RlZCBpbiBmZWVkYmFj ayBvbiB0aGUgc3RydWN0dXJlIG9mIHRoZSBkb2N1bWVudCAoZG8gdGhlIGNhdGVnb3JpZXMgbWFr ZSBzZW5zZSkgYW5kIHdoZXRoZXIgd2UgYXJlIG1pc3NpbmcgbWFqb3IgaXRlbXMgdG8gaW5jbHVk ZSBpbiB0aGUgZ2FwIGFuYWx5c2lzLCBhY3Jvc3MgY29udHJvbCBwbGFuZSwgYXBwbGljYXRpb25z LCBvciBPQU0uDQoNClRoYW5rcywNCg0KV2VzIEdlb3JnZSwgb24gYmVoYWxmIG9mIHRoZSBvdGhl ciBhdXRob3JzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBN b25kYXksIEp1bHkgMDEsIDIwMTMgOToyMyBBTQ0KVG86IFJvbiBCb25pY2E7IFJhaml2IFBhcG5l amE7IERocnV2IERob2R5OyBHZW9yZ2UsIFdlczsgQ2FybG9zIFBpZ25hdGFybzsgS2FtcmFuIFJh emE7IFJvbmFsZCBCb25pY2E7IFZpc2h3YXMgTWFucmFsOyBSYWppdiBBc2F0aQ0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tcGxzLWlwdjYtb25seS1nYXAtMDAu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1wbHMtaXB2Ni1vbmx5LWdhcC0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VzbGV5IEdlb3JnZSBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRy YWZ0LW1wbHMtaXB2Ni1vbmx5LWdhcA0KUmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAg ICAgICBHYXAgQW5hbHlzaXMgZm9yIE9wZXJhdGluZyBJUHY2LW9ubHkgTVBMUyBOZXR3b3Jrcw0K Q3JlYXRpb24gZGF0ZTogICAyMDEzLTA3LTAxDQpHcm91cDogICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tcGxzLWlwdjYtb25seS1nYXAtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbXBscy1pcHY2LW9ubHktZ2FwDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW1wbHMtaXB2Ni1vbmx5LWdhcC0wMA0KDQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCByZXZpZXdzIHRoZSBNUExTIHByb3RvY29sIHN1aXRlIGluIHRoZSBjb250 ZXh0IG9mIElQdjYNCiAgIGFuZCBpZGVudGlmaWVzIGdhcHMgdGhhdCBtdXN0IGJlIGFkZHJlc3Nl ZCBpbiBvcmRlciB0byBhbGxvdyBNUExTLQ0KICAgcmVsYXRlZCBwcm90b2NvbHMgYW5kIGFwcGxp Y2F0aW9ucyB0byBiZSB1c2VkIHdpdGggSVB2Ni1vbmx5DQogICBuZXR3b3Jrcy4gIFRoaXMgZG9j dW1lbnQgaXMgbm90IGludGVuZGVkIHRvIGhpZ2hsaWdodCBhIHBhcnRpY3VsYXINCiAgIHZlbmRv cidzIGltcGxlbWVudGF0aW9uIChvciBsYWNrIHRoZXJlb2YpIGluIHRoZSBjb250ZXh0IG9mIElQ djYtb25seQ0KICAgTVBMUyBmdW5jdGlvbmFsaXR5LCBidXQgcmF0aGVyIHRvIGZvY3VzIG9uIGdh cHMgaW4gdGhlIHN0YW5kYXJkcw0KICAgZGVmaW5pbmcgdGhlIE1QTFMgc3VpdGUuDQoNCg0KDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBj b3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVs YXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5 IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From vishwas.ietf@gmail.com Mon Jul 1 08:49:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E57011E8248 for ; Mon, 1 Jul 2013 08:49:19 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWoBrto2RzS7 for ; Mon, 1 Jul 2013 08:49:18 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D11BE11E8242 for ; Mon, 1 Jul 2013 08:49:16 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so9696666iej.1 for ; Mon, 01 Jul 2013 08:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ihOnzWBeruyg4F5kn6RilTdhgG1Y6h6TxPOXxGb16T4=; b=oJLwc6jMmUHl5OidJmbohGsGjk0HixqJOTOZpVNekzqe4xKDN3XWjSXX5eYF4dNLDD /a729FAWsnXDrOgqQwx27Y8bXxTCsrVwVPvWJ5280P+4I0W4O0i0FYbipd7hza0zVenT gVwtdFy6ZOvNZ985ltkiQRlJZT6eyx8MbtgsrqppXYMzz/AA6BiJtHMV8ECBzZSgy6aJ faMgIlAgrdNg+uEeBcljKFFmqDWD0QbRHqOzgHAxkr336Tu7t25P3W2UWc4yaHDFgQw/ Y1WP3S6dyKP22Cgn4naebjD05xqjtCFv3moAzgwalMcPo4FazkMlye0yrPsmBa0AWfuw i2cA== MIME-Version: 1.0 X-Received: by 10.50.22.72 with SMTP id b8mr16148022igf.17.1372693753553; Mon, 01 Jul 2013 08:49:13 -0700 (PDT) Received: by 10.50.11.115 with HTTP; Mon, 1 Jul 2013 08:49:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jul 2013 08:49:13 -0700 Message-ID: From: Vishwas Manral To: "Rogers, Josh" Content-Type: multipart/alternative; boundary=047d7b10c94791778904e0752b4d Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 15:49:19 -0000 --047d7b10c94791778904e0752b4d Content-Type: text/plain; charset=ISO-8859-1 Hi Josh, Good point. I read the words and they did sound very confusing. As a format its an OCTET STRING, we however need to clarify the definition of the TC MplsNewExtendedTunnelId. We will update that text across. Thanks, Vishwas On Mon, Jul 1, 2013 at 6:16 AM, Rogers, Josh wrote: > RE: MplsNewExtendedTunnelId > >For IPv6 this represents an IPv4 address of the ingress or > >egress LSR for the tunnel for an IPv6 network. > > > We've been interested in changing a couple of private networks to v6 only, > but are waiting for feature in code and maturity of v6 MPLS, so may still > be a while before we can do it. I noticed that the language about the > Extended TunnelID uses words like 'suggests' and 'should' when speaking > about using a v4 loopback address as the TunnelId for a 'IPv6 network'. > If there is no v4 address because the network is v6 only, what should be > used instead? Are we setting the expectation that everything will be dual > stacked forever? > > Thanks for your response and insight, > Josh > > > On 6/27/13 11:58 PM, "Will Liu (Shucheng)" wrote: > > >Hi Folks, > > > >We uploaded a new version to address the comments about MplsLSPID > >description as below. We are looking forward to your further comments. > >Thanks. > > > >Cheers, > >Will > > > >-----Original Message----- > >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >Sent: Friday, June 28, 2013 12:54 PM > >To: Tina TSOU; Will Liu (Shucheng); Francesco Fondelli; Vishwas Manral; > >Will Liu (Shucheng) > >Subject: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt > > > > > >A new version of I-D, draft-manral-mpls-rfc3811bis-03.txt > >has been successfully submitted by Vishwas Manral and posted to the > >IETF repository. > > > >Filename: draft-manral-mpls-rfc3811bis > >Revision: 03 > >Title: Definitions of Textual Conventions (TCs) for > Multiprotocol Label > >Switching (MPLS) Management > >Creation date: 2013-06-28 > >Group: Individual Submission > >Number of pages: 22 > >URL: > >http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-03.txt > >Status: > >http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis > >Htmlized: > >http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-03 > >Diff: > >http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-03 > > > >Abstract: > > This memo defines a Management Information Base (MIB) module which > > contains Textual Conventions to represent commonly used Multiprotocol > > Label Switching (MPLS) management information. The intent is that > > these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS > > related MIB modules that would otherwise define their own > > representations. > > > > This document obsoletes RFC3811 as it addresses the need to support > > IPv6 extended TunnelID's by defining a new TC- > > MplsNewExtendedTunnelID which suggests using IPv4 address of the > > ingress or egress LSR for the tunnel for an IPv6 network. Changes > > from RFC3811 and the effect of the new TC to other related documents > > are summarized in Section 4 and 5, respectively. > > > > > > > > > > > >The IETF Secretariat > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b10c94791778904e0752b4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Josh,
=A0
Good point. I read t= he words and they did sound very confusing.
=A0
As a fo= rmat its an OCTET STRING, we however need to clarify the definition of the = TC MplsNewExtendedTunnelId. We will update that text across.
=A0
Thanks,
Vishwas


On Mon, Jul 1, 2013 at 6:16 AM, = Rogers, Josh <josh.rogers@twcable.com> wrote:
RE: MplsNewExtendedTunnelId
>For IPv6 this represents an IPv4 address of the ingress or
>egress LSR for the tunnel for an IPv6 network.


We've been interested in changing a couple of private networks to v6 on= ly,
but are waiting for feature in code and maturity of v6 MPLS, so may still be a while before we can do it. =A0I noticed that the language about the Extended TunnelID uses words like 'suggests' and 'should' w= hen speaking
about using a v4 loopback address as the TunnelId for a 'IPv6 network&#= 39;.
If there is no v4 address because the network is v6 only, what should be used instead? =A0Are we setting the expectation that everything will be dua= l
stacked forever?

Thanks for your response and insight,
Josh


On 6/27/13 11:58 PM, "Will Liu (Shucheng)" <liushucheng@huawei.com> wrote:

>Hi Folks,
>
>We uploaded a new version to address the comments about MplsLSPID
>description as below. We are looking forward to your further comments.<= br> >Thanks.
>
>Cheers,
>Will
>
>-----Original Message-----
>From: internet-drafts@ietf.= org [mailto:internet-drafts= @ietf.org]
>Sent: Friday, June 28, 2013 12:54 PM
>To: Tina TSOU; Will Liu (Shucheng); Francesco Fondelli; Vishwas Manral;=
>Will Liu (Shucheng)
>Subject: New Version Notification for draft-manral-mpls-rfc3811bis-03.t= xt
>
>
>A new version of I-D, draft-manral-mpls-rfc3811bis-03.txt
>has been successfully submitted by Vishwas Manral and posted to the
>IETF repository.
>
>Filename: =A0 =A0 =A0 draft-manral-mpls-rfc3811bis
>Revision: =A0 =A0 =A0 03
>Title: =A0 =A0 =A0 =A0 =A0Definitions of Textual Conventions (TCs) for = Multiprotocol Label
>Switching (MPLS) Management
>Creation date: =A02013-06-28
>Group: =A0 =A0 =A0 =A0 =A0Individual Submission
>Number of pages: 22
>URL:
>http://www.ietf.org/internet-drafts/draft-ma= nral-mpls-rfc3811bis-03.txt
>Status:
>http://datatracker.ietf.org/doc/draft-manral-mpls-rfc38= 11bis
>Htmlized:
>http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-0= 3
>Diff:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-manral-m= pls-rfc3811bis-03
>
>Abstract:
> =A0 This memo defines a Management Information Base (MIB) module which=
> =A0 contains Textual Conventions to represent commonly used Multiproto= col
> =A0 Label Switching (MPLS) management information. =A0The intent is th= at
> =A0 these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS<= br> > =A0 related MIB modules that would otherwise define their own
> =A0 representations.
>
> =A0 This document obsoletes RFC3811 as it addresses the need to suppor= t
> =A0 IPv6 extended TunnelID's by defining a new TC-
> =A0 MplsNewExtendedTunnelID which suggests using IPv4 address of the > =A0 ingress or egress LSR for the tunnel for an IPv6 network. =A0Chang= es
> =A0 from RFC3811 and the effect of the new TC to other related documen= ts
> =A0 are summarized in Section 4 and 5, respectively.
>
>
>
>
>
>The IETF Secretariat
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b10c94791778904e0752b4d-- From ietf-ipr@ietf.org Mon Jul 1 09:53:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74C811E81DC; Mon, 1 Jul 2013 09:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faYjDHauh5PF; Mon, 1 Jul 2013 09:53:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAE511E8171; Mon, 1 Jul 2013 09:53:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ice@cisco.com, erosen@cisco.com, skraza@cisco.com, jeff.tantsura@ericsson.com, akatlas@juniper.net, quintin.zhao@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701165319.9553.47059.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 09:53:19 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org, loa@pi.nu Subject: [mpls] IPR Disclosure: Juniper's Statement of IPR related to draft-wijnands-mpls-mldp-node-protection-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: Mon, 01 Jul 2013 16:53:25 -0000 Dear IJsbrand Wijnands, Eric Rosen, Kamran Raza, Jeff Tantsura, Alia Atlas,= Quintin Zhao: An IPR disclosure that pertains to your Internet-Draft entitled "mLDP Node Protection" (draft-wijnands-mpls-mldp-node-protection) was submitted to the= IETF Secretariat on 2013-06-29 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2116/). The = title of the IPR disclosure is "Juniper's Statement of IPR related to draft-wijna= nds- mpls-mldp-node-protection-04.""); The IETF Secretariat From huaimo.chen@huawei.com Mon Jul 1 20:28:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28AF21F9B9D for ; Mon, 1 Jul 2013 20:28:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmhgGiLoUsoi for ; Mon, 1 Jul 2013 20:28:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDBE21F9A87 for ; Mon, 1 Jul 2013 20:28:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA66049; Tue, 02 Jul 2013 03:28:23 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 04:28:08 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 04:28:16 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Mon, 1 Jul 2013 20:28:13 -0700 From: Huaimo Chen To: Lizhong Jin Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHOcB28thOt3kgIPkCotNKnZ4jMnZlEyj7wgAI3KICAAteHsIAB4qgAgAT1W9A= Date: Tue, 2 Jul 2013 03:28:12 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451E1A3C@dfweml509-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.29] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4451E1A3Cdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-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: Tue, 02 Jul 2013 03:28:38 -0000 --_000_5316A0AB3C851246A7CA5758973207D4451E1A3Cdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks much for your third round comments! My answers/explanations are inline below. Best Regards, Huaimo From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Friday, June 28, 2013 11:22 AM To: Huaimo Chen Cc: Ross Callon; mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egres= s-protection@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Huaimo, Thank you for the detail discussion. See inline below. Regards Lizhong On Fri, Jun 28, 2013 at 7:31 AM, Huaimo Chen > wrote: Hi Lizhong, Thanks much for your second round comments! My responses are inline below. Best Regards, Huaimo From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Lizhong Jin Sent: Sunday, June 23, 2013 10:27 AM To: Ross Callon Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p= 2mp-egress-protection@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi authors, I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. Over= ally, there are some points that need to be discussed before WG adoption. A= nd I would appreciate if the authors could help to clarify. 1. If I understand the draft correctly, the primary and backup egress node = address should be two different address. But actually, the egress node is c= losely related with many customer service configurations (e.g, mvpn and p2m= p pw). Anycast address based protection has been proved to be an efficient = way for MVPN and other service over RSVP-TE P2MP. Then if anycast address i= s applied for egress node protection, FRR defined in RFC4090 could be reuse= d, right? Huaimo: It seems that anycast address based protection depends on IP routin= g. Thus the traffic interruption (or switch over) time will be much longer= when the primary egress fails since it relies on the IP routing convergenc= e. If it is applied for egress node protection, both the primary egress and= the backup egress should have a same anycast IP address, a CE should conne= ct to these two egresses and have a routing table entry with two items. One= item for the route (i.e., the anycast IP address) to the primary egress w= ith a smaller metric, the other for the route to the backup egress with a b= igger metric. Thus, the CE receives the traffic from the primary egress in = normal operations. When the primary egress fails, the route to the backup = egress becomes the best one after IP routing convergence and the CE switche= s to receive the traffic from the backup egress. In order for the CE to ge= t the traffic from the backup egress after the primary egress fails, the tr= affic should be sent to the backup egress before or when the primary egress= fails. A P2MP LSP with these two egresses (i.e., the primary egress and th= e backup egress as its normal two egresses) can send the traffic to both th= e primary egress and the backup egress at the same time. It seems that FRR = defined in RFC 4090 can not be reused directly here to switch the traffic t= o the backup egress from the primary egress when the primary egress fails. = Using the egress node protection proposed in the draft have two advantages = over the anycast address based protection. One is that the traffic interrup= tion (or switch over) time will be much shorter (tens of ms) when the prim= ary egress fails; the other is that the bandwidth used for sending the traf= fic to the backup egress is saved. Is my understanding of anycast based pr= otection consistent with yours? [Lizhong] After more consideration, let me explain my understanding in deta= il. The previous node will see the primary and backup egress as one egress = node with the anycast address. Since there is one egress node for the previ= ous node, then FRR defined in RFC4090 could be reused. But there should be = some synchronization mechanism between primary and backup egress, to negoti= ate a common label that could be used by both primary and backup egress. Th= at could be potentially achieved by MP-BGP. The switching time and BW usage= would be the same as FRR. Using anycast address would ease the implementat= ion of the client service (e.g mvpn). [Huaimo] Physically the primary egress node and the backup egress node are = two different nodes even though they have a same anycast address. To protec= t the primary egress node of a primary (P2MP or P2P) LSP, the previous hop = (or upstream) node of the primary egress node needs to create a backup LSP = to the backup egress node (i.e., the physical backup egress node, which is = different from the physical primary egress node). Since there is not any p= rimary LSP path segment after the primary egress node, the FRR defined in R= FC4090 could not be reused directly. In order to use the FRR defined in RFC= 4090 for protecting a node B, the previous hop (or upstream) node (say node= A) of the node B needs to create a backup LSP that intersects the primary = LSP somewhere downstream of the node B. See the following descriptions from= RFC4090: In section 3.1 One-to-One Backup, "In the one-to-one backup method, a l= abel-switched path is established that intersects the original LSP somewher= e downstream of the point of link or node failure. ... " In section 3.2 Facility Backup, the second paragraph: "The bypass tunnel mu= st intersect the path of the original LSP(s) somewhere downstream of the PL= R. ... " In the case that the node B is the primary egress node, node A (i.e., the p= revious hop/upstream node of the primary egress node) can not create any ba= ckup LSP intersecting the primary LSP somewhere downstream of the node B (i= .e., the primary egress node). There is not any primary LSP after the node = B (i.e., the primary egress node). To protect the primary egress node of a primary LSP, some special protocol = extensions are needed. The objective of this draft is to define these speci= al extensions. [Lizhong] It seems we are not aligned yet here. Let's say node C as the bac= kup node. Since node A and C has same anycast address, node B will see the = two nodes as one in its TE-DB (a virtual node). Then B will have a backup p= ath to this virtual node (node C), which is the end-point of the primary LS= P. And as I said in previous email, there should be a synchronization mecha= nism existed between A and C. [Huaimo 3] Regarding to the synchronization between the primary egress node= such as A and the backup egress node such as C, do you mean the synchroniz= ation about the service label used by the primary egress (e.g., A) and the = backup egress (e.g., C)? For a service carried by a P2MP LSP, the service labels should be the same = for all the primary egresses and backup egresses. When the ingress of the L= SP allocates an upstream assignment label for the service, it sends this se= rvice label to all the primary egresses and the backup egresses of the LSP = for the service to be carried by the LSP. When a primary egress fails, the = previous hop of the primary egress switches the traffic to the backup egres= s through a backup LSP to the backup egress. The service label in the traff= ic stays unchanged. Thus we may not need any synchronization about the serv= ice label between a primary egress and its backup egress. For a service carried by a P2P LSP, the synchronization about the service l= abel between a primary egress and its backup egress is required. The objec= tive of the synchronization should be to make the backup egress to send th= e same service traffic to the same receiver as the primary egress (through = using a backup service label, which may not be the same as the primary serv= ice label used by the primary egress. These two labels indicate the same se= rvice and the same service traffic receiver). There are a few of ways to ac= hieve this. One way is that the backup egress allocates a backup service label and send= s the ingress this label with the service identification information (note = that primary egress and backup egress have the same service identification = information for a same service) in a similar way as the primary egress. The= ingress sends the backup service label paired with the primary service lab= el (i.e., the service label allocated by the primary egress for the same se= rvice and receiver) to the previous hop of the primary egress in a PATH mes= sage. When the primary egress fails, the previous hop switches the traffic = to the backup egress through a backup LSP to the backup egress. The primary= service label in a packet to be sent to the primary egress is replaced wit= h the backup service label when the packet is switched to the backup egress= , which sends the traffic to the same receiver as the primary egress throug= h using the backup service label. Regarding to the service label, it seems out scope of this draft. The servi= ce label such as VPN label should be handled by others such as BGP. We will= provide some descriptions about this in details in the next version of the= draft. In the client side, using anycast address may be easier. The egress node p= rotection in the core side should work with the anycast address protection = in the client side. We will address this in the next version of the draft. 2. section 7.2.2. I doubt if the facility proction could work in the egress= protection. The backup egress node does not know the P2MP lable allocated = by the primary egress node. And it is very likely that the P2MP lable recei= ved by backup egress node has already been allocated for other purpose. Or = is there any sychronization mechanism between primary and backup node. Huaimo: In some cases, there is no need for any label. For example, if the = second last hop label pop is enabled, the previous hop (or upstream) node o= f the primary egress does not need any P2MP LSP label from the backup egres= s. In the case that the previous hop (or upstream) node of the primary egre= ss needs a P2MP LSP label from the backup egress, there are a few of ways t= o get the label. One way is to let the previous hop (or upstream) node send= the object containing the backup egress to the primary egress, which "ext= ends" the P2MP LSP to the backup egress. It sends a path message to the bac= kup egress, gets a resv message with a P2MP LSP label from the backup egres= s and then sends a resv message with this label to the previous hop (or ups= tream) node. Note that the primary egress will not create any forwarding e= ntry with this label for sending the traffic to the backup egress. The prev= ious hop (or upstream) node can provide the primary egress node protection = using this label in a way similar to the one that it provides an intermedia= te node protection. We will address this in the next version of the draft. [Lizhong] But why do you think there is a link between the primary and back= up egress? What if there is no directly connection between the two? [Huaimo] We can have another way for the previous hop (or upstream) node of= the primary egress to get the label from the backup egress node. The previ= ous hop (or upstream) node may "extend" the P2MP LSP to the backup egress. = It sends a path message to the backup egress, gets a resv message with a P2= MP LSP label from the backup egress and then provides the primary egress no= de protection using this label. Note that the previous hop (or upstream) n= ode will not create any forwarding entry with this label for sending the tr= affic to the backup egress. We may call the LSP (segment) extended from the= primary LSP an empty primary LSP since it will not transport any traffic. The first way requires that there be a link between the primary egress and = the backup egress. The second way does not have this requirement. The first= way may reuse the existing FRR procedures more. The figures below show som= e details about these two ways. The first way: Link **** Primary LSP $ ---- Backup LSP $ [R2]****[R3]*****[L1] Empty Primary LSP $ * \ *)$ $ *) * \ *)$ $[CE1] *) * \ *)$ $ *) * \__[La] * [R1]****[R4]***[R5]*****[L2] $ \ *)$ $ $ \ *)$ $[CE2] [S] \ *)$ $ \__[Lb] Link between primary egress (L1) and backup egress (La) is required Primary egress (L1) signals empty primary LSP to backup egress (La) Previous hop (R3) reuses FRR to protect primary egress (L1) [Lizhong] My concern for the empty LSP is the waste of signaling resources = in the network. The RSVP is a soft-state protocol hop by hop and relies on = the refresh of signaling message. We could investigate it in more detail to= see if any better solution exists. [Huaimo 3] You are right. We can investigate more to get a better solution. The second way: Link **** Primary LSP $ ---- Backup LSP $ [R2]****[R3]*****[L1] Empty Primary LSP $ * *)\ $ *) * *)\ $[CE1] *) * *)\ $ *) * *)\__[La] * [R1]****[R4]***[R5]*****[L2] $ *)\ $ $ *)\ $[CE2] [S] *)\ $ *)\__[Lb] Previous hop (R3) signals empty primary LSP to backup egress (La) Previous hop (R3) uses a bypass LSP to protect primary egress (L1) Regards Lizhong On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon > wrote: Ravi, Eric, Tarek, Lizhong; You have been selected as MPLS Review team reviewers for draft-chen-mpls-p2mp-egress-protection-09. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? Also, is the text and grammar understandable (it doesn't need to be perfect at this point, but should be reasonably clear). We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, Comments may be sent privately to only the WG chairs. Are you able to review this draft by June 26, 2013? Thanks, Ross (as MPLS WG chair) --_000_5316A0AB3C851246A7CA5758973207D4451E1A3Cdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

 <= /p>

Thanks much for your third round comments!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Lizhong = Jin [mailto:lizho.jin@gmail.com]
Sent: Friday, June 28, 2013 11:22 AM
To: Huaimo Chen
Cc: Ross Callon; mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2m= p-egress-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Huaimo,

Thank you for the detail discussion. See inline belo= w.

 

Regards

Lizhong

 

On Fri, Jun 28, 2013 at 7:31 AM, Huaimo Chen <huaimo.chen@huawei= .com> wrote:

Hi Lizhong,

 

    Thanks much for your= second round comments!

My responses are inline below.=

 

Best Regards,

Huaimo

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: mpls@ietf.org= ; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi authors,

I have been asked to review draft-chen-mpls-p2mp-egress-protection= -09. Overally, there are some points that need to be discussed before WG ad= option. And I would appreciate if the authors could help to clarify.

 

1. If I understand the draft correctly, the primary and backup egress n= ode address should be two different address. But actually, the eg= ress node is closely related with many customer service configurations= (e.g, mvpn and p2mp pw). Anycast address based protection has been proved to be an efficient way for MVPN and other servi= ce over RSVP-TE P2MP. Then if anycast address is applied for egress node pr= otection, FRR defined in RFC4090 could be reused, right?

 

Huaimo: It seems that anycast address b= ased protection depends on IP routing. Thus the traffic interruption (or switch over)  time will be much longer when the primary egress fa= ils since it relies on the IP routing convergence. If it is applied for egr= ess node protection, both the primary egress and the backup egress should h= ave a same anycast IP address, a CE should connect to these two egresses and have a routing table entry with two item= s. One item for the route (i.e., the anycast IP address) to the primary egr= ess  with a smaller metric, the other for the route to the backup egre= ss with a bigger metric. Thus, the CE receives the traffic from the primary egress in normal operations.  W= hen the primary egress fails, the route to the backup egress becomes the be= st one after IP routing convergence and the CE switches to receive the traf= fic from the backup egress.  In order for the CE to get the traffic from the backup egress after the primary egr= ess fails, the traffic should be sent to the backup egress before or when t= he primary egress fails. A P2MP LSP with these two egresses (i.e., the prim= ary egress and the backup egress as its normal two egresses) can send the traffic to both the primary egres= s and the backup egress at the same time. It seems that FRR defined in RFC = 4090 can not be reused directly here to switch the traffic to the backup eg= ress from the primary egress when the primary egress fails. Using the egress node protection proposed in the= draft have two advantages over the anycast address based protection. One i= s that the traffic interruption (or switch over)  time will be much sh= orter (tens of ms) when the primary egress fails; the other is that the bandwidth used for sending the traffic to the= backup egress is saved.  Is my understanding of anycast based protect= ion consistent with yours?

[Lizhong] After more consideration, let me explain my understandin= g in detail. The previous node will see the primary and backup egress as on= e egress node with the anycast address. Since there is one egress node for the previous node, then FRR defined in = RFC4090 could be reused. But there should be some synchronization mech= anism between primary and backup egress, to negotiate a common label t= hat could be used by both primary and backup egress. That could be potentially achieved by MP-BGP. The switching time a= nd BW usage would be the same as FRR. Using anycast address would ease the = implementation of the client service (e.g mvpn).

 

[Huaimo] Physically the primary egress = node and the backup egress node are two different nodes even though they have a same anycast address. To protect the primary egress nod= e of a primary (P2MP or P2P) LSP, the previous hop (or upstream) node of th= e primary egress node needs to create a backup LSP to the backup egress nod= e (i.e., the physical backup egress node, which is different from the physical primary egress node).  Sin= ce there is not any primary LSP path segment after the primary egress node,= the FRR defined in RFC4090 could not be reused directly. In order to use t= he FRR defined in RFC4090 for protecting a node B, the previous hop (or upstream) node (say node A) of the node B n= eeds to create a backup LSP that intersects the primary LSP somewhere downstream of the node B. See the foll= owing descriptions from RFC4090:

    In section 3.1 One-t= o-One Backup, “In the one-to-one backup method, a label-switched path= is established that intersects the original LSP somewhere downstream of the p= oint of link or node failure. … “

In section 3.2 Facility Backup, the second parag= raph: “The bypass tunnel must intersect the path of the original LSP(= s) somewhere downstream of the PLR. … “

In the case that the node B is the primary egres= s node, node A (i.e., the previous hop/upstream node of the primary egress = node) can not create any backup LSP intersecting the primary LSP somewhere downstream of the node B (i.e., the primary egress node). Th= ere is not any primary LSP after the node B (i.e., the primary egress node)= .

To protect the primary egress node of a primary = LSP, some special protocol extensions are needed. The objective of this dra= ft is to define these special extensions.

[Lizhong] It seems we are not aligned yet here. Let'= s say node C as the backup node. Since node A and C has same anycast addres= s, node B will see the two nodes as one in its TE-DB (a virtual node). Then= B will have a backup path to this virtual node (node C), which is the end-point of the primary LSP. And as I= said in previous email, there should be a synchronization mechanism existe= d between A and C. 

 

[Huaimo 3] Regarding to t= he synchronization between the primary egress node such as A and the backup= egress node such as C, do you mean the synchronization about the service label used by the primary egress (e.g., A) and the backu= p egress (e.g., C)?

For a service carried by a P2MP LSP, the service labels should be the sa= me for all the primary egresses and backup egresses. When the ingress of the LSP allocates an upstream assignment label for the serv= ice, it sends this service label to all the primary egresses and the backup= egresses of the LSP for the service to be carried by the LSP. When a prima= ry egress fails, the previous hop of the primary egress switches the traffic to the backup egress through a = backup LSP to the backup egress. The service label in the traffic stays unc= hanged. Thus we may not need any synchronization about the service label be= tween a primary egress and its backup egress.

For a service carried by a P2P LSP, the synchronization about the servic= e label between a primary egress and its backup egress is required.  The objective of the synchronization should be to make &nb= sp;the backup egress to send the same service traffic to the same receiver = as the primary egress (through using a backup service label, which may not = be the same as the primary service label used by the primary egress. These two labels indicate the same service and the = same service traffic receiver). There are a few of ways to achieve this.

One way is that the backup egress allocates a backup service label and s= ends the ingress this label with the service identification information (note that primary egress and backup egress have the same serv= ice identification information for a same service) in a similar way as the = primary egress. The ingress sends the backup service label paired with the = primary service label (i.e., the service label allocated by the primary egress for the same service and rec= eiver) to the previous hop of the primary egress in a PATH message. When th= e primary egress fails, the previous hop switches the traffic to the backup= egress through a backup LSP to the backup egress. The primary service label in a packet to be sent to the= primary egress is replaced with the backup service label when the packet i= s switched to the backup egress, which sends the traffic to the same receiv= er as the primary egress through using the backup service label.

Regarding to the service label, it seems out sco= pe of this draft. The service label such as VPN label should be handled by = others such as BGP. We will provide some descriptions about this in details in the next version of the draft.<= /p>

In the client side, using anycast address may be= easier.  The egress node protection in the core side should work with= the anycast address protection in the client side. We will address this in the next version of the draft.

 

2. section 7.2.2. I doubt if the facility proction could work in t= he egress protection. The backup egress node does not know the P2MP lable a= llocated by the primary egress node. And it is very likely that the P2MP lable received by backup egress node h= as already been allocated for other purpose. Or is there any sychronization= mechanism between primary and backup node.

 

Huaimo: In some cases, there is no need= for any label. For example, if the second last hop label pop is enabled, the previous hop (or upstream) node of the primary egress = does not need any P2MP LSP label from the backup egress. In the case that t= he previous hop (or upstream) node of the primary egress needs a P2MP LSP l= abel from the backup egress, there are a few of ways to get the label. One way is to let the previous hop (or= upstream) node send the object containing the backup egress to the primary= egress,  which “extends” the P2MP LSP to the backup egres= s. It sends a path message to the backup egress, gets a resv message with a P2MP LSP label from the backup egress and then = sends a resv message with this label to the previous hop (or upstream) node= .  Note that the primary egress will not create any forwarding entry w= ith this label for sending the traffic to the backup egress. The previous hop (or upstream) node can provide the = primary egress node protection using this label in a way similar to the one= that it provides an intermediate node protection. We will address this in = the next version of the draft.

[Lizhong] But why do you think there is a link between the primary= and backup egress? What if there is no directly connection between the two= ?

 

[Huaimo] We can have another way for th= e previous hop (or upstream) node of the primary egress to get the label from the backup egress node. The previous hop (or upstream) = node may "extend" the P2MP LSP to the backup egress. It sends a p= ath message to the backup egress, gets a resv message with a P2MP LSP label= from the backup egress and then provides the primary egress node protection using this label.  Note that the p= revious hop (or upstream) node will not create any forwarding entry with th= is label for sending the traffic to the backup egress. We may call the LSP = (segment) extended from the primary LSP an empty primary LSP since it will not transport any traffic.<= /o:p>

The first way requires that there be a = link between the primary egress and the backup egress. The second way does not have this requirement. The first way may reuse the exi= sting FRR procedures more. The figures below show some details about these = two ways.

 

The first way:

 

     Link &= nbsp;           &nbs= p;            &= nbsp;            ***= * Primary LSP

   &n= bsp; $           &nb= sp;            =             &nb= sp;     ---- Backup LSP

    $=          [R2]****[R3]*****[L1] = ;            Empty P= rimary LSP

   $ =          *    &= nbsp;     \     *)$  $ &n= bsp;          *)

   &n= bsp;         *   &nb= sp;        \    *)$&= nbsp;   $[CE1]     *)

   &n= bsp;        *    &nb= sp;         \   *)$ = $            *)

   &n= bsp;       *     &nb= sp;          \__[La]

   &n= bsp;      *

   &n= bsp;   [R1]****[R4]***[R5]*****[L2]

   &n= bsp;  $         &nbs= p;        \     *)$&= nbsp; $   

   &n= bsp; $          &nbs= p;         \    *)$&= nbsp;   $[CE2]

  [S] &nbs= p;            &= nbsp;       \   *)$  $

   &n= bsp;            = ;            \_= _[Lb]

 

Link between primary= egress (L1) and backup egress (La) is required

Primary egress (L1) = signals empty primary LSP to backup egress (La)

Previous hop (R3) re= uses FRR to protect primary egress (L1)

[Lizhong] My concern for the empty LSP is the waste = of signaling resources in the network. The RSVP is a soft-state protocol ho= p by hop and relies on the refresh of signaling message. We could investiga= te it in more detail to see if any better solution exists.

 <= /p>

[Huaimo 3] You are right.= We can investigate more to get a better solution.

 

 

The second way:

 

   &n= bsp; Link           =             &nb= sp;            =    **** Primary LSP

   &n= bsp; $           &nb= sp;            =             &nb= sp;     ---- Backup LSP

    $=          [R2]****[R3]*****[L1] = ;            Empty P= rimary LSP

   $&= nbsp;         *   &n= bsp;    *)\        &= nbsp; $            *= )

   &n= bsp;         *  &nbs= p;       *)\     &nb= sp;     $[CE1]     *)

   &n= bsp;        *    &nb= sp;       *)\     &n= bsp;  $          &nb= sp; *)

   &n= bsp;       *     &nb= sp;        *)\__[La]

   &n= bsp;      *

   &n= bsp;   [R1]****[R4]***[R5]*****[L2]

   &n= bsp;  $         &nbs= p;      *)\      &nb= sp;   $   

   &n= bsp; $          &nbs= p;       *)\     &nb= sp;     $[CE2]

  [S] &nbs= p;            &= nbsp;     *)\        = ;$

   &n= bsp;            = ;          *)\__[Lb]

 

 

Previous hop (R3) si= gnals empty primary LSP to backup egress (La)

Previous hop (R3) us= es a bypass LSP to protect primary egress (L1)

    

 

Regards

Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net> wrote:=

Ravi, Eric, Tarek, Lizhong;

You have been selected as MPLS Review team reviewers for
draft-chen-mpls-p2mp-egress-protection-09.

Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own
document.

Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound?  Also, is the text and grammar understandable (it doesn't need to be perfect at this
point, but should be reasonably clear). We are interested in knowing
whether the document is ready to be considered for WG adoption (ie,
it doesn't have to be perfect at this point, but should be a good
start).

Reviews should be sent to the document authors, WG co-chairs and
WG secretary, and CC'd to the MPLS WG email list. If necessary,
Comments may be sent privately to only the WG chairs.

Are you able to review this draft by June 26, 2013?

Thanks, Ross
(as MPLS WG chair)

 

 

 

--_000_5316A0AB3C851246A7CA5758973207D4451E1A3Cdfweml509mbxchi_-- From vero.zheng@huawei.com Tue Jul 2 01:20:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B731E11E8414 for ; Tue, 2 Jul 2013 01:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ4HjwzdJ5CA for ; Tue, 2 Jul 2013 01:20:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB9B11E8426 for ; Tue, 2 Jul 2013 01:20:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA88301; Tue, 02 Jul 2013 08:20:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 09:19:38 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 09:20:36 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.94]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Tue, 2 Jul 2013 16:20:29 +0800 From: Vero Zheng To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group lst call on draft-ietf-mpls-targeted-mldp Thread-Index: AQHOcZEYH3AF1ttYP0SDU+t4YWziD5lRFADw Date: Tue, 2 Jul 2013 08:20:29 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C4C0DD693@SZXEML552-MBS.china.huawei.com> References: <51C9748A.30802@pi.nu> In-Reply-To: <51C9748A.30802@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-targeted-mldp@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIHdvcmtpbmcgZ3JvdXAgbHN0IGNhbGwgb24g?= =?gb2312?b?ZHJhZnQtaWV0Zi1tcGxzLXRhcmdldGVkLW1sZHA=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:20:59 -0000 WWVzL1N1cHBvcnQNCg0KVGhpcyBkcmFmdCBiYXNpY2FsbHkgZXh0ZW50IHRoZSBtTERQIG92ZXIg VGFyZ2V0IExEUCBTZXNzaW9uLiBBY2NvcmRpbmcgdG8gdGhpcyBkcmFmdCwgdGhlIFVwc3RyZWFt IExTUiBjb3VsZCBlaXRoZXIgYmUgYSBCR1AgbmV4dC1ob3Agb3IgYSBSU1ZQLVRFIHR1bm5lbCBl bmRwb2ludC4gTm8gcHJvdG9jb2wgZXh0ZW5zaW9uIG5lZWRlZC4NCkkgZmVlbCB0aGlzIGlzIHVz ZWZ1bCBpbiBvcGVyYXRpb24gbmV0d29ya3MuDQoNCk5pdHM6DQpCb3RoIHNlY3Rpb24gMS4zIGFu ZCBzZWN0aW9uIDIgaGFzIHJlZmVyZW5jZSB0byBzZWN0aW9uIDEuMy4xIHdoaWNoIHNob3VsZCBi ZSBzZWN0aW9uIDEuMi4xDQoNCkNoZWVycywgVmVybw0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiC3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBMb2ENCj4gQW5kZXJzc29uDQo+ILeiy83KsbzkOiAyMDEzxOo21MIyNcjVIDE4 OjQ0DQo+IMrVvP7IyzogbXBsc0BpZXRmLm9yZw0KPiCzrcvNOiBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRhcmdldGVkLW1sZHBAdG9vbHMuaWV0Zi5vcmcNCj4g 1vfM4jogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbHN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRh cmdldGVkLW1sZHANCj4gDQo+IFdvcmtpbmcgR3JvdXBzLA0KPiANCj4gUFdFMyB3b3JraW5nIGdy b3VwLA0KPiBXb3JraW5nIEdyb3VwLA0KPiANCj4gdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVr IFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9uDQo+IGRyYWZ0LWlldGYtbXBscy10YXJnZXRlZC1t bGRwLTAyLnR4dC4NCj4gDQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMg d29ya2luZyBncm91cA0KPiBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLg0KPiANCj4gUGxl YXNlIHNlbmQgYm90aCB0ZWNobmljYWwgY29tbWVudHMsIGFuZCBpZiB5b3UgYXJlIGhhcHB5DQo+ IHdpdGggdGhlIGRvY3VtZW50IGFzIGlzIGFsc28gaW5kaWNhdGlvbnMgb2Ygc3VwcG9ydC4NCj4g DQo+IFRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWluc3QgdGhpcyBkcmFmdC4NCj4gDQo+IFRo ZSBjby1hdXRob3JzIGhhdmUgZWFybGllciBzdGF0ZWQgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUN Cj4gb2YgYW55IElQUnMgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0Lg0KPiANCj4gSWYgYW55b25l IGVsc2UgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgYXJlIGF3YXJlIG9mIElQUnMgY2xhaW1zIGFnYWlu c3QNCj4gdGhpcyBkcmFmdCwgdGhlIHRpbWUgdG8gZGlzY2xvc2UgdGhhdCBpcyBub3cuDQo+IA0K PiBUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHdpbGwgZW5kIG9uIEp1bHkgOSwgMjAxMy4N Cj4gDQo+IC9Mb2ENCj4gZm9yIHRoZSB3ZyBjby1jaGFpcnMNCj4gLS0NCj4gDQo+IA0KPiBMb2Eg QW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2Vp LmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBw aS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3 MzkgODEgMjEgNjQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From adrian@olddog.co.uk Tue Jul 2 02:25:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D7711E8459 for ; Tue, 2 Jul 2013 02:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcyZr6MIBqEv for ; Tue, 2 Jul 2013 02:25:42 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4A611E8449 for ; Tue, 2 Jul 2013 02:25:40 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r629Pcfu011220 for ; Tue, 2 Jul 2013 10:25:38 +0100 Received: from 950129200 (host-54-196-68-109.spectrum1.uk.sharedband.net [109.68.196.54]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r629PNxb010948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jul 2013 10:25:38 +0100 From: "Adrian Farrel" To: References: <20130702063022.15833.61412.idtracker@ietfa.amsl.com> In-Reply-To: <20130702063022.15833.61412.idtracker@ietfa.amsl.com> Date: Tue, 2 Jul 2013 10:25:22 +0100 Message-ID: <009801ce7706$1cf3ec60$56dbc520$@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: AQIL5Q4v2vmrUDTHU3rhBNy+NymVHpjWQagw Content-Language: en-gb Subject: [mpls] FW: I-D Action: draft-parise-ldp-convergence-term-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 09:25:47 -0000 FYI I guess discussion goes on in bmwg Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 02 July 2013 07:30 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-parise-ldp-convergence-term-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Terminology for Benchmarking LDP Data Plane Convergence > Author(s) : Bhavani Parise > Rajiv Papneja > Filename : draft-parise-ldp-convergence-term-00.txt > Pages : 18 > Date : 2013-07-01 > > Abstract: > This document defines new terms for benchmarking of LDP convergence. > These terms are to be used in future methodology documents for > benchmarking LDP Convergence. Existing BMWG terminology documents > such as IGP Convergence Benchmarking [RFC 6412] provide useful terms > for LDP Convergence benchmarking. These terms are discussed in this > document. Applicable terminology for MPLS and LDP defined in MPLS WG > RFCs [RFC 3031] and [RFC 5036] are also discussed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-parise-ldp-convergence-term > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-parise-ldp-convergence-term-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 From ietf-secretariat-reply@ietf.org Tue Jul 2 09:14:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DC521F8700 for ; Tue, 2 Jul 2013 09:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMKe5EOo+Vwc for ; Tue, 2 Jul 2013 09:14:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1752121F99A5 for ; Tue, 2 Jul 2013 09:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702161428.2042.84541.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 09:14:28 -0700 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:14:28 -0000 Changed milestone "Submit draft-ietf-mpls-tp-mip-mep-map for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-rosetta-stone for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-ipv6 for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-applicability-label-adv = for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-dod for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication", set due date to December 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-targeted-mldp for publication", set due date to December 2013 from June 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From akatlas@juniper.net Tue Jul 2 12:07:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5960D21F9C05 for ; Tue, 2 Jul 2013 12:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=-1.480, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7mbMApuQA1I for ; Tue, 2 Jul 2013 12:07:45 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15E21F9BF0 for ; Tue, 2 Jul 2013 12:07:45 -0700 (PDT) Received: from mail50-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 19:07:44 +0000 Received: from mail50-db8 (localhost [127.0.0.1]) by mail50-db8-R.bigfish.com (Postfix) with ESMTP id 2DE003200EB for ; Tue, 2 Jul 2013 19:07:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zzzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail50-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail50-db8 (localhost.localdomain [127.0.0.1]) by mail50-db8 (MessageSwitch) id 1372792061745476_10152; Tue, 2 Jul 2013 19:07:41 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.240]) by mail50-db8.bigfish.com (Postfix) with ESMTP id A8229CC004A for ; Tue, 2 Jul 2013 19:07:41 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 2 Jul 2013 19:07:40 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Jul 2013 12:07:06 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 2 Jul 2013 12:07:06 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.250) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Jul 2013 12:18:54 -0700 Received: from mail45-db9-R.bigfish.com (10.174.16.241) by DB9EHSOBE012.bigfish.com (10.174.14.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 19:07:04 +0000 Received: from mail45-db9 (localhost [127.0.0.1]) by mail45-db9-R.bigfish.com (Postfix) with ESMTP id 51B5F480180 for ; Tue, 2 Jul 2013 19:07:04 +0000 (UTC) Received: from mail45-db9 (localhost.localdomain [127.0.0.1]) by mail45-db9 (MessageSwitch) id 1372792021924440_10198; Tue, 2 Jul 2013 19:07:01 +0000 (UTC) Received: from DB9EHSMHS020.bigfish.com (unknown [10.174.16.231]) by mail45-db9.bigfish.com (Postfix) with ESMTP id DBCC6780031; Tue, 2 Jul 2013 19:07:01 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by DB9EHSMHS020.bigfish.com (10.174.14.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 2 Jul 2013 19:07:00 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0324.000; Tue, 2 Jul 2013 19:06:56 +0000 From: Alia Atlas To: IJsbrand Wijnands , Loa Andersson Thread-Topic: IPR Poll on draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOcA+K4uSNSo3rfESrXwTrV559eZlDQPAAgA6K6UA= Date: Tue, 2 Jul 2013 19:06:55 +0000 Message-ID: References: <51C6EDCD.6000403@pi.nu> <94816208-E748-46D9-B7EE-8BD1AD8B59B6@cisco.com> In-Reply-To: <94816208-E748-46D9-B7EE-8BD1AD8B59B6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PI.NU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-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: Tue, 02 Jul 2013 19:07:51 -0000 Hi Loa, > Are you aware of any IPR that applies to draft-wijnands-mpls-mldp-node-pr= otection? Yes. > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). Yes, please see https://datatracker.ietf.org/ipr/2116/ Thanks and sorry for the delay, Alia From loa@pi.nu Tue Jul 2 23:47:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09DD21F9D24 for ; Tue, 2 Jul 2013 23:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS2rI4tEUN0n for ; Tue, 2 Jul 2013 23:47:48 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E968F21F9CCA for ; Tue, 2 Jul 2013 23:47:47 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EE7EA180110A; Wed, 3 Jul 2013 08:41:21 +0200 (CEST) Message-ID: <51D3C795.2000609@pi.nu> Date: Wed, 03 Jul 2013 08:41:25 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: Draft submission deadlines change X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 06:47:54 -0000 Working Group, Please note this change to the draft submission deadlines. /Loa for the wg chairs -------- Original Message -------- Subject: Draft submission deadlines change Date: Tue, 02 Jul 2013 22:17:01 -0700 From: IETF Chair Reply-To: ietf@ietf.org To: IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From lizhenbin@huawei.com Wed Jul 3 00:14:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09C21F99EE for ; Wed, 3 Jul 2013 00:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBO84aqtxmDl for ; Wed, 3 Jul 2013 00:14:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7521F99F8 for ; Wed, 3 Jul 2013 00:14:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUP99616; Wed, 03 Jul 2013 07:14:22 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 08:12:58 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 08:13:58 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 3 Jul 2013 15:13:53 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group lst call on draft-ietf-mpls-targeted-mldp Thread-Index: AQHOcZEQB/X+btIsrESHKxWUy4r80JlSku0Q Date: Wed, 3 Jul 2013 07:13:52 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08187790@nkgeml506-mbx.china.huawei.com> References: <51C9748A.30802@pi.nu> In-Reply-To: <51C9748A.30802@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.196] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-targeted-mldp@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIHdvcmtpbmcgZ3JvdXAgbHN0IGNhbGwgb24g?= =?gb2312?b?ZHJhZnQtaWV0Zi1tcGxzLXRhcmdldGVkLW1sZHA=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 07:14:32 -0000 V2UgdGhpbmsgdGhlIHRhcmdldGVkIG1sZHAgc2NlbmFyaW8gaXMgbmVjZXNzYXJ5LiBBZnRlciBy ZXZpZXcsIGZvbGxvdyBjb21tZW50cyBhcmUgcHJvcG9zZWQ6DQoxLiBTaW5jZSB1c2luZyB1bmlj YXN0IG9yIG11bHRpY2FzdCB0dW5uZWwgaXMgZGVjaWRlZCBieSBkb3duc3RyZWFtIG5vZGUsIGlm IG5vZGUgVSBoYXMgc2V2ZXJhbCBkb3duc3RyZWFtIG5vZGVzLCBzb21lIGRvd25zdHJlYW0gbm9k ZXMgY2hvb3NlIHVuaWNhc3QgYW5kIG90aGVycyBjaG9vc2UgbXVsdGljYXN0LCB0aGVuIHdoYXQg aXMgVSdzIGNob2ljZT8gTWF5YmUgaXQgY2FuIHRyZWF0IHRoZSBtdWx0aWNhc3QgdHVubmVsIGFz IG9uZSBicmFuY2ggd2l0aCBvdGhlciB1bmljYXN0IHR1bm5lbCBvciBjYW4gdXNlIG9uZSBuZXcg Y2FwYWJpbGl0eSB0byBuZWdvdGlhdGUgdGhpcyBiZWZvcmUgTVAtTFNQIHNldHRpbmcgdXAuDQoN CjIuIE1heWJlIHRoZSBwcm9jZWR1cmUgZm9yIHRoZSB1bnN5bW1ldHJpY2FsIG5ldHdvcmsgY2Fu IGJlIGltcHJvdmVkLiBGb3IgZXhhbXBsZSwgdGhlIG5leHQgaG9wIGludGVyZmFjZSBmcm9tIEQg dG8gdGhlIHJvb3QgaXMgYSBwaHlzaWNhbCBpbnRlcmZhY2UgYnV0IGZyb20gVSB0byBEIGlzIGFu IFJTVlAtVEUgdHVubmVsICwgc28gRCBzZW5kIG9uZSBsYWJlbCBtYXBwaW5nIGJ1dCBtYXliZSBV IGlzIHdhaXRpbmcgZm9yIG9uZSB1cHN0cmVhbSBsYWJlbCByZXF1ZXN0LiANCg0KMy4gSW4gc2Vj dGlvbiAzKFRhcmdldGVkIG1MRFAgd2l0aCBNdWx0aWNhc3QgVHVubmVsaW5nKSwgaWYgVSBjaG9v c2UgdXNpbmcgZGlmZmVyZW50IG11bHRpY2FzdCB0dW5uZWwgZm9yIGRpZmZlcmVudCBNUC1MU1Bz LCBtYXliZSBpdCBjYW4gdHJ5IG90aGVyIG1ldGhvZHMgdG8gYXZvaWQgdXBzdHJlYW0gbGFiZWwg YWxsb2NhdGlvbi4gRm9yIGV4YW1wbGUsIHVzaW5nIG9uZSAnUmVjdXJzaXZlIE9wYXF1ZSBUTFYn IGluIFJGQzY1MTIsIHdlIGNhbiByZWRpcmVjdCB0aGUgcm9vdCB0byB0aGUgVSwgYW5kIHRyaWdn ZXIgb25lIG11bHRpY2FzdCB0dW5uZWwgc2V0dXAgYmV0d2VlbiBVIGFuZCBELiBFdmVuIHdlIGNh biBhdm9pZCB0dW5uZWxpbmcgc2luY2Ugbm9kZSBEIGtub3dzIHRoZSBpbi1sYWJlbCBzaG91bGQg bWFwIHRvIHdoaWNoIE1QLUxTUC4gDQoNCjQuIFRoZSB1bmljYXN0IHR1bm5lbGluZyBtZXRob2Qg aXMgc3RpbGwgdW5zYXRpc2ZhY3Rvcnkgc2luY2UgaXQgbWF5IGNhdXNlIHRyYWZmaWMgY29uZ2Vz dGlvbiBpZiBzb21lIG9mIHRoZSB1bmljYXN0IHR1bm5lbHMgc2hhcmVzIG9uZSBsaW5rIGFuZCB0 aGlzIGlzIGEgdmVyeSBwb3NzaWJsZSBjYXNlIHVuZGVyIGN1cnJlbnQgYmFja2JvbmUgbmV0d29y ayBkZXBsb3ltZW50Lg0KDQoNClJlZ2FyZHMsDQpSb2Jpbg0KDQoNCg0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBMb2EgQW5kZXJzc29uDQq3osvNyrG85DogMjAxM8TqNtTCMjXI1SAxODo0 NA0KytW8/sjLOiBtcGxzQGlldGYub3JnDQqzrcvNOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZzsgZHJhZnQtaWV0Zi1tcGxzLXRhcmdldGVkLW1sZHBAdG9vbHMuaWV0Zi5vcmcNCtb3zOI6IFtt cGxzXSB3b3JraW5nIGdyb3VwIGxzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10YXJnZXRlZC1t bGRwDQoNCldvcmtpbmcgR3JvdXBzLA0KDQpQV0UzIHdvcmtpbmcgZ3JvdXAsDQpXb3JraW5nIEdy b3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgV29ya2luZyBHcm91cCBsYXN0IGNh bGwgb24NCmRyYWZ0LWlldGYtbXBscy10YXJnZXRlZC1tbGRwLTAyLnR4dC4NCg0KUGxlYXNlIHNl bmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQptYWlsaW5nIGxpc3Qg KG1wbHNAaWV0Zi5vcmcpLg0KDQpQbGVhc2Ugc2VuZCBib3RoIHRlY2huaWNhbCBjb21tZW50cywg YW5kIGlmIHlvdSBhcmUgaGFwcHkNCndpdGggdGhlIGRvY3VtZW50IGFzIGlzIGFsc28gaW5kaWNh dGlvbnMgb2Ygc3VwcG9ydC4NCg0KVGhlcmUgYXJlIG5vIElQUiBjbGFpbXMgYWdhaW5zdCB0aGlz IGRyYWZ0Lg0KDQpUaGUgY28tYXV0aG9ycyBoYXZlIGVhcmxpZXIgc3RhdGVkIHRoYXQgdGhleSBh cmUgbm90IGF3YXJlDQpvZiBhbnkgSVBScyBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQuDQoNCklm IGFueW9uZSBlbHNlIGluIHRoZSB3b3JraW5nIGdyb3VwIGFyZSBhd2FyZSBvZiBJUFJzIGNsYWlt cyBhZ2FpbnN0DQp0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZSB0aGF0IGlzIG5vdy4N Cg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB3aWxsIGVuZCBvbiBKdWx5IDksIDIwMTMu DQoNCi9Mb2ENCmZvciB0aGUgd2cgY28tY2hhaXJzDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9y IE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1YXdlaSBU ZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg== From loa@pi.nu Wed Jul 3 04:22:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4832B11E819E for ; Wed, 3 Jul 2013 04:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saZiIKskP-dt for ; Wed, 3 Jul 2013 04:22:44 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8172D11E819A for ; Wed, 3 Jul 2013 04:22:44 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1A03F180110A; Wed, 3 Jul 2013 13:22:43 +0200 (CEST) Message-ID: <51D40986.1040709@pi.nu> Date: Wed, 03 Jul 2013 13:22:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel , "VIGOUREUX, MARTIN (MARTIN)" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 11:22:49 -0000 Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-node-protection as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends July 17, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/1727/ https://datatracker.ietf.org/ipr/2116/ The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jeff.tantsura@ericsson.com Wed Jul 3 04:33:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2D21F9C20 for ; Wed, 3 Jul 2013 04:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSGSaWuTRRjV for ; Wed, 3 Jul 2013 04:33:03 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3FE121F9BB2 for ; Wed, 3 Jul 2013 04:33:02 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-d1-51d40bed06b1 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B6.EE.13034.DEB04D15; Wed, 3 Jul 2013 13:33:02 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 07:32:55 -0400 From: Jeff Tantsura To: Loa Andersson Thread-Topic: draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOd9+rubVB+8rRX0uPRZdCA2a1C5lS0l/+ Date: Wed, 3 Jul 2013 11:32:54 +0000 Message-ID: <10C19E96-D02E-4655-AE33-613364B09093@ericsson.com> References: <51D40986.1040709@pi.nu> In-Reply-To: <51D40986.1040709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPiO477iuBBst+Mlr86LnBbPFzuq/F v7lzmC3u7PrCavH90hIWi1tLV7I6sHm0PtvL6rFkyU8mjxWbVzJ6zJrexubx5fJntgDWKC6b lNSczLLUIn27BK6Mqx0TWAr+cVb07VRqYLzO3sXIySEhYCLx/No1ZghbTOLCvfVsXYxcHEIC Rxklft36yAjhLGOU2Nw4EayDTcBA4v+34ywgtoiArMS1bT+ZQIqYBY4wSTz6ux0sISxgKnHp 9yugURxARWYSHxozIeqNJCYsmMUEYrMIqEjs+zKHCaSEV8Be4mKvA0hYCCh8fH8L2CpOAVWJ la/+soHYjEDHfT+1BqyVWUBc4taT+UwQRwtILNlzHuoBUYmXj/+xQtToSCzY/YkNwtaWWLbw NVgNr4CgxMmZT1gmMIrOQjJqFpKWWUhaZiFpWcDIsoqRo7Q4tSw33chgEyMwno5JsOnuYNzz 0vIQozQHi5I47yq9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGHsEZ7ZsEdnTv+nBqZ8x ezzSnhiG7ZBa7nnN1OGb2aSwxatFrv75Lhex47/6Zd/qXy/nB288wXT86uGpP2fk7M2z5eif kzWrb8a6Qkn7U22xyiu3luTNP/el/dxWEcfTEzm2fZxheWJhN8uaqCdLMldeP8RncWBpj7o9 V4H3iSPC3vxXk42ig18qsRRnJBpqMRcVJwIAquVlK3UCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 11:33:08 -0000 Support, as co-author Regards, Jeff On Jul 3, 2013, at 1:22 PM, "Loa Andersson" wrote: > Working Group, >=20 > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-node-protection as an MPLS working > group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends July 17, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/1727/ > https://datatracker.ietf.org/ipr/2116/ >=20 >=20 > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. >=20 > /Loa > (mpls wg co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From naikumar@cisco.com Wed Jul 3 04:46:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6FE21F9CAD for ; Wed, 3 Jul 2013 04:46:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjZqhLJm3HqK for ; Wed, 3 Jul 2013 04:46:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7F69C21F9CAF for ; Wed, 3 Jul 2013 04:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1372851966; x=1374061566; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CjCO067OUGEPkz37Yzhz18QcHaoS842FVzpdkAa11dI=; b=Qw8GwqTqagj8ITaxWUeCYhdwN7RyyqBAl4n0M0/TeI6LyDQy/9AVwGxR P9fuKjK+uYbR0VlNViyDlrjtZdc8AV8q7N+jB+UVbD/vcQObgL96nQwu0 1X5ySWdiWhz2Kz08kO1kWQhiKo1lLqTyL7xzj8n+5WcBzQh3e00yCBLHo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAFoO1FGtJXG//2dsb2JhbABagwkyScAxgQIWdIIjAQEBBAEBATcxAxcCAgIBCBEEAQELFAkHGwwLFAkIAgQBEgiIBwy6ZAQEjiWBETgGgn5pA6kOgxGBcTc X-IronPort-AV: E=Sophos;i="4.87,987,1363132800"; d="scan'208";a="230487710" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jul 2013 11:46:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r63Bk5J9007989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 11:46:05 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 06:46:04 -0500 From: "Nagendra Kumar (naikumar)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel , "VIGOUREUX, MARTIN (MARTIN)" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Thread-Topic: [mpls] draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOd9+tfVPj7r/8cUGaQOu6l33qMplS1fUQ Date: Wed, 3 Jul 2013 11:46:03 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C4610249CA3@xmb-rcd-x03.cisco.com> References: <51D40986.1040709@pi.nu> In-Reply-To: <51D40986.1040709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 11:46:11 -0000 Support Regards, Nagendra -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, July 03, 2013 4:53 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; Adrian Farrel; VIGOUREUX, MA= RTIN (MARTIN); draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: [mpls] draft-wijnands-mpls-mldp-node-protection Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-node-= protection as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at ietf.org). Please give a technical motivation for your= support/not support, especially if you think that the document should not = be adopted as a working group document. This poll ends July 17, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/1727/ https://datatracker.ietf.org/ipr/2116/ The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mehmet_toy@cable.comcast.com Tue Jul 2 18:02:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543421F9AA7 for ; Tue, 2 Jul 2013 18:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDTfPoqS8aaq for ; Tue, 2 Jul 2013 18:02:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD7721F9AA0 for ; Tue, 2 Jul 2013 18:02:37 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.80654679; Tue, 02 Jul 2013 19:01:10 -0600 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.141]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Tue, 2 Jul 2013 21:02:26 -0400 From: "Toy, Mehmet" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac53iPXu/akGdIv9Q12kGd+6DmcIow== Date: Wed, 3 Jul 2013 01:02:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.248] Content-Type: multipart/alternative; boundary="_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F2E14PACDCEXMB13cabl_" MIME-Version: 1.0 To: "rtorvi@juniper.net" , "Huaimo Chen (huaimo.chen@huawei.com)" , Ross Callon X-Mailman-Approved-At: Wed, 03 Jul 2013 06:26:32 -0700 Cc: "mpls@ietf.org" , "boris.zhang@telus.com" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , Ning So , "mpls-chairs@tools.ietf.org" , "Xu, Fengman" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 01:02:43 -0000 --_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F2E14PACDCEXMB13cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Locally protecting egress nodes of a P2MP LSP reduces the time for protecti= on switching and resources required for the protection. The proposal has be= en verified in a prototype. As one of the authors of this draft, I support = its adaptation. Thanks Mehmet From: Huaimo Chen Sent: Thursday, June 27, 2013 9:58 PM To: 'Raveendra Torvi'; Ross Callon Cc: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protec= tion@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Ravi, Thanks much for your very helpful comments! My responses are inline below. Best Regards, Huaimo From: Raveendra Torvi [mailto:rtorvi@juniper.net] Sent: Monday, June 24, 2013 5:57 PM To: Huaimo Chen; Lizhong Jin; Ross Callon Cc: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protec= tion@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n I have finished first round of review of this draft. In short, WG should ex= plore use cases and see whether signaling procedure mentioned in the draft = are applicable in real world, before accepting this as WG draft. I do not= think this draft is readily usable. [Huaimo] This draft is initially written for a real use case, which has bee= n presented in the WG meetings. A prototype has been developed to verify so= me of the ideas in the draft. The running results have showed that they wor= k as expected. Following are some issues with draft: [1] Unlike other local protection this is an ingress driven, not PLR. In i= nter-domain scenario, ingress may not have the visibility of entire network= to figure out the complete primary path, not to mention the bypass path. [Huaimo] Can we focus on one domain scenario for our discussions first? Oth= er local protection and the egress node protection may need help from other= s such as PCE in inter-domain scenarios. The ingress of an LSP just provides the minimum amount of information for p= rotecting primary egress nodes. The protection for every primary egress nod= e is then driven by the PLR (i.e., the previous hop node of the primary egr= ess node). For facility backup protection, the ingress of the LSP just needs to give a= backup egress node for every primary egress node to be protected (plus som= e constraints if needed, which are the same as other local protection defin= ed in RFC4090). The previous hop node (i.e., PLR) selects or creates a bypa= ss backup tunnel from itself to the backup egress node for protecting the p= rimary egress node. If there is a bypass backup tunnel from the PLR to the = backup egress node that satisfies the constraints, then this tunnel is sele= cted; otherwise, a new bypass backup tunnel to the backup egress node will = be created. A path for the backup bypass tunnel will be computed by the PLR= and then the backup bypass is signaled along the path computed. If a backup S2L sub LSP is used to protect a primary egress node of a P2MP = LSP, the ingress of the LSP needs to provide a path from the previous hop o= f the primary egress to the backup egress node. In one domain scenario, the= re is no issue for the ingress to provide this path. [2] In the presence of loose-hops, this may also yield to wrong selection o= f PLR by ingress, as one may have several hops between ingress designated P= LR and protected PE. There is no indication from Egress to ingress that egr= ess is protected. [Huaimo] The ingress of an LSP does not select any PLR (i.e., the previous = hop node of the primary egress node) for protecting the primary egress node= . In order to protect a primary egress node of the LSP, the ingress just gi= ves the backup egress (designated to protect the primary egress). When a no= de determines that it is the previous hop node of the primary egress node, = it will act as the PLR to provide protection for the primary egress node. The status of the egress node protection is sent to the ingress in the RRO = of the RESV message. There are some descriptions about this in the draft (s= ee the paragraph below). "The previous hop node of the primary egress node sets the protection flags= in the RRO IPv4/IPv6 Sub-object for the primary egress node according to t= he status of the primary egress node and the backup LSP protecting the prim= ary egress node. For example, it will set the node protection bit to one in= dicating that the primary egress node is protected when the backup LSP to t= he backup egress node is set up for protecting the primary egress node." [3] 1:1 relationship between primary egress and backup egress. This will be= scalability issues especially with ring topologies. This solution is NOT extensible to 1:N protection. [Huaimo] It seems typical that one primary egress (PE) pairs with a backup = egress (PE) and a CE is dual home to two egresses (PEs). I do not see any s= calability issue here. Can you give more details about the scalability issu= es regarding to the 1:1 relationship between primary egress and backup egre= ss? The facility backup protection proposed in the draft can provide 1:N protec= tion. Multiple (N) LSPs going through the previous hop node to the primary = egress node can be protected for their primary egress node failure at the s= ame time by one (1) bypass tunnel from the previous hop node to the backup = egress node. Does this address the issue "This solution is NOT extensible t= o 1:N protection."? [4] This draft does not address interoperability with 1:N protection.. [Huaimo] Can you give some more details about "interoperability with 1:N pr= otection"? [5] Local reversion does not work Consider following example: S2L 1 : I - PH1-PE- Primary S2L 1 Backup: I - PH3 - PE-Backup S2L 2: I - PH2 - PE-Other I----PH1--------PE-Primary || PH2--------PE-Other | PH3---------- PE Backup PH - PE link comes back, PH1 sends traffic PE Primary and how & when does P= H2 stop sending traffic to PH3? [Huaimo] For using backup S2L sub LSP to protect the primary egress node, t= he path from the previous hop node of the primary egress node to the backup= egress node will not intersect with the path of the LSP. For the example a= bove, S2L 1 Backup will not go through PH2 (see figure below). Thus local r= eversion may work. S2L 1: I -- PH1 -- PE-Primary S2L 1 Backup: I -- PH1 -- PH3 -- PE-Backup S2L 2: I -- PH1 -- PH2 -- PE-Other I----PH1--------PE-Primary | \ | PH2--------PE-Other \__ PH3---------- PE-Backup When PE-Primary (i.e., the primary egress node) fails, PH1 switches the tra= ffic to the PE-Backup (i.e., the backup egress node). When PE-Primary comes back, PH1 may switch the traffic back to PE-Primary a= fter re-signaling S2L 1 if the local revertive mode is used. [6] According to Section 4.4, in order to detect PE-CE link down, this sol= ution needs a BFD session from a P router to CE device, which is a non-star= ter as P router may not have any state to reach CE, at least draft does not= go deep enough to explain this point. [Huaimo] We will focus on detecting the failure of the primary egress node = in the next version of the draft. [7] This solution addresses P2MP LSPs only. The approach cannot be extended= to apply for P2P LSPs, in which case it must be ensured that the back egre= ss know how to handle inner label (i.e. service label). [Huaimo] The following is a possible approach in which the solution propose= d in the draft is "extended" to protect the egress of a P2P LSP. To protect the primary egress node of a P2P LSP, the ingress of the LSP add= s the object containing the primary egress and the backup egress in the PAT= H message. This object has the same format as the object EGRESS_BACKUP_SUB_= LSP used for protecting a primary egress node of a P2MP LSP. If one-to-one backup is used, the previous hop node of the primary egress n= ode creates a backup LSP from itself to the backup egress for protecting th= e primary egress of the P2P LSP in a way similar to the one for creating a = backup sub LSP to protect a primary egress of a P2MP LSP. If facility backup is used, the previous hop node of the primary egress nod= e selects or creates a backup bypass tunnel from itself to the backup egres= s for protecting the primary egress. In the case that the previous hop (or upstream) node of the primary egress = needs a P2P LSP label from the backup egress (i.e., the inner label used by= the PLR to put into the bypass tunnel), there are a few of ways to get the= label. One way is that the previous hop (or upstream) node "extends" the P= 2P LSP to the backup egress. It sends a path message towards the backup egr= ess along the path computed and gets a resv message with a P2P LSP label fr= om the backup egress. Note that the previous hop (or upstream) node will n= ot create any forwarding entry with this label for sending the traffic to t= he backup egress. The previous hop (or upstream) node can provide the prima= ry egress node protection using this label in a way similar to the one that= it provides an intermediate node protection. Regarding to the service label, it seems that it is out scope of this draft= . The service label such as VPN label should be handled by others such as B= GP. Regards Ravi --_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F2E14PACDCEXMB13cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Locally protecting egress= nodes of a P2MP LSP reduces the time for protection switching and resource= s required for the protection. The proposal has been verified in a prototype. As one of the authors of this draft, I support its adaptat= ion.

Thanks<= /p>

Mehmet

 

 

From: Huaimo C= hen
Sent: Thursday, June 27, 2013 9:58 PM
To: 'Raveendra Torvi'; Ross Callon
Cc: mpls@ietf.or= g; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chair= s@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Ravi,

 

     Tha= nks much for your very helpful comments!

     My = responses are inline below.

 

Best Regards,

Huaimo

 <= /p>

From: Raveendr= a Torvi [mailto:rt= orvi@juniper.net]
Sent: Monday, June 24, 2013 5:57 PM
To: Huaimo Chen; Lizhong Jin; Ross Callon
Cc: mpls@ietf.or= g; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chair= s@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

I have finished first rou= nd of review of this draft. In short, WG should explore use cases and see w= hether signaling procedure mentioned in the draft are applicable in real world, before accepting this as WG draft.   I do not thi= nk this draft is readily usable.

 <= /p>

[Huaimo] This draft is initi= ally written for a real use case, which has been presented in the WG meetin= gs. A prototype has been developed to verify some of the ideas in the draft. The running results have showed that they work as expe= cted.

 <= /p>

Following are some issues= with draft:

 

[1] Unlike other local protection this is an ingress= driven, not PLR.  In inter-domain scenario, ingress may not have the = visibility of entire network to figure out the complete primary path, not t= o mention the bypass path.

 <= /p>

[Huaimo] Can we focus on one= domain scenario for our discussions first? Other local protection and the = egress node protection may need help from others such as PCE in inter-domain scenarios.  

The ingress of an LSP just p= rovides the minimum amount of information for protecting primary egress nod= es. The protection for every primary egress node is then driven by the PLR (i.e., the previous hop node of the primary egress node)= .

For facility backup protecti= on, the ingress of the LSP just needs to give a backup egress node for ever= y primary egress node to be protected (plus some constraints if needed, which are the same as other local protection defined in RFC4090= ). The previous hop node (i.e., PLR) selects or creates a bypass backup tun= nel from itself to the backup egress node for protecting the primary egress= node. If there is a bypass backup tunnel from the PLR to the backup egress node that satisfies the constrain= ts, then this tunnel is selected; otherwise, a new bypass backup tunnel to = the backup egress node will be created. A path for the backup bypass tunnel= will be computed by the PLR and then the backup bypass is signaled along the path computed.

If a backup S2L sub LSP is u= sed to protect a primary egress node of a P2MP LSP, the ingress of the LSP = needs to provide a path from the previous hop of the primary egress to the backup egress node. In one domain scenario, there is no issu= e for the ingress to provide this path.

 <= /p>

 

[2] In the presence of loose-hops, this may also yie= ld to wrong selection of PLR by ingress, as one may have several hops betwe= en ingress designated PLR and protected PE. There is no indication from Egr= ess to ingress that egress is protected.

 <= /p>

[Huaimo] The ingress of an L= SP does not select any PLR (i.e., the previous hop node of the primary egre= ss node) for protecting the primary egress node. In order to protect a primary egress node of the LSP, the ingress just gives the ba= ckup egress (designated to protect the primary egress). When a node determi= nes that it is the previous hop node of the primary egress node, it will ac= t as the PLR to provide protection for the primary egress node.

The status of the egress nod= e protection is sent to the ingress in the RRO of the RESV message. There a= re some descriptions about this in the draft (see the paragraph below).

 

“The previous hop node of the primary egress node se= ts the protection flags in the RRO IPv4/IPv6 Sub-object for the primary egr= ess node according to the status of the primary egress node and the backup LSP protecting the primary egress node. For example, i= t will set the node protection bit to one indicating that the primary egres= s node is protected when the backup LSP to the backup egress node is set up= for protecting the primary egress node.”

 <= /p>

 

[3] 1:1 relationship between primary egress and back= up egress. This will be scalability issues especially with ring topologies.=  

   This solution is NOT extensible to= 1:N protection.

 

[Huaimo] It seems typical th= at one primary egress (PE) pairs with a backup egress (PE) and a CE is dual= home to two egresses (PEs). I do not see any scalability issue here. Can you give more details about the scalability issues regardi= ng to the 1:1 relationship between primary egress and backup egress?

The facility backup protecti= on proposed in the draft can provide 1:N protection. Multiple (N) LSPs goin= g through the previous hop node to the primary egress node can be protected for their primary egress node failure at the same time by= one (1) bypass tunnel from the previous hop node to the backup egress node= . Does this address the issue “This solution is NOT extensible to 1:N= protection.”?

 <= /p>

 <= /p>

[4] This draft does not address interoperability wit= h 1:N protection..

 

[Huaimo] Can you give some m= ore details about “interoperability with 1:N protection”?<= /o:p>

 <= /p>

 <= /p>

[5] Local reversion does not work

  

 Consider following example:

 

S2L 1 :  I – PH1—PE- Primary

S2L 1 Backup:  I – PH3 – PE-Backup<= o:p>

S2L 2: I – PH2 – PE-Other

  

      I----PH1--------= PE-Primary

        &nbs= p;       ||

        &nbs= p;      PH2--------PE-Other

         &nb= sp;      |

        &nbs= p;      PH3---------- PE Backup

 

PH – PE link comes back, PH1 sends traffic PE = Primary and how & when does PH2 stop sending traffic to PH3?

 <= /p>

[Huaimo] For using backup S2= L sub LSP to protect the primary egress node, the path from the previous ho= p node of the primary egress node to the backup egress node will not intersect with the path of the LSP. For the example above, S2L 1 = Backup will not go through PH2 (see figure below). Thus local reversion may= work.

 

S2L 1:  I –- PH1 -— PE-Primary

S2L 1 Backup:  I -– PH1 -- PH3 -– PE-Backup<= /span>

S2L 2: I –- PH1 -- PH2 -– PE-Other

 

      I----PH1--------PE-Primary

           |  \ <= o:p>

           | = ;  PH2--------PE-Other

            \__&n= bsp;  

            =    PH3---------- PE-Backup

 

When PE-Primary (i.e., the p= rimary egress node) fails, PH1 switches the traffic to the PE-Backup (i.e.,= the backup egress node).

When PE-Primary comes back, = PH1 may switch the traffic back to PE-Primary after re-signaling S2L 1 if t= he local revertive mode is used. 

 <= /p>

 

[6] According to Section 4.4,  in order to dete= ct PE-CE link down, this solution needs a BFD session from a P router to CE= device, which is a non-starter as P router may not have any state to reach= CE, at least draft does not go deep enough to explain this point.

 <= /p>

[Huaimo] We will focus on de= tecting the failure of the primary egress node in the next version of the d= raft.

 <= /p>

 <= /p>

[7] This solution addresses P2MP LSPs only. The appr= oach cannot be extended to apply for P2P LSPs, in which case it must be ens= ured that the back egress know how to handle inner label (i.e. service labe= l).

 

[Huaimo] The following is a = possible approach in which the solution proposed in the draft is “ext= ended” to protect the egress of a P2P LSP.

To protect the primary egres= s node of a P2P LSP, the ingress of the LSP adds the object containing the = primary egress and the backup egress in the PATH message. This object has the same format as the object EGRESS_BACKUP_SUB_LSP used f= or protecting a primary egress node of a P2MP LSP.

If one-to-one backup is used= , the previous hop node of the primary egress node creates a backup LSP fro= m itself to the backup egress for protecting the primary egress of the P2P LSP in a way similar to the one for creating a backup su= b LSP to protect a primary egress of a P2MP LSP.

If facility backup is used, = the previous hop node of the primary egress node selects or creates a backu= p bypass tunnel from itself to the backup egress for protecting the primary egress.

In the case that the previou= s hop (or upstream) node of the primary egress needs a P2P LSP label from t= he backup egress (i.e., the inner label used by the PLR to put into the bypass tunnel), there are a few of ways to get the label. = One way is that the previous hop (or upstream) node “extends” t= he P2P LSP to the backup egress. It sends a path message towards the backup= egress along the path computed and gets a resv message with a P2P LSP label from the backup egress.  Note that the p= revious hop (or upstream) node will not create any forwarding entry with th= is label for sending the traffic to the backup egress. The previous hop (or= upstream) node can provide the primary egress node protection using this label in a way similar to the one that i= t provides an intermediate node protection.

Regarding to the service lab= el, it seems that it is out scope of this draft. The service label such as = VPN label should be handled by others such as BGP.

 <= /p>

 <= /p>

 <= /p>

Regards

Ravi=

--_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F2E14PACDCEXMB13cabl_-- From mehmet_toy@cable.comcast.com Wed Jul 3 06:32:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEFB11E81AC for ; Wed, 3 Jul 2013 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ44UXsX4E6u for ; Wed, 3 Jul 2013 06:32:22 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 398B011E8145 for ; Wed, 3 Jul 2013 06:32:14 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.80712608; Wed, 03 Jul 2013 07:30:39 -0600 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Wed, 3 Jul 2013 09:31:58 -0400 From: "Toy, Mehmet" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac53iPXu/akGdIv9Q12kGd+6DmcIowAaGwmA Date: Wed, 3 Jul 2013 13:31:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.248] Content-Type: multipart/alternative; boundary="_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F30E3PACDCEXMB13cabl_" MIME-Version: 1.0 To: "rtorvi@juniper.net" , "Huaimo Chen (huaimo.chen@huawei.com)" , Ross Callon X-Mailman-Approved-At: Wed, 03 Jul 2013 06:56:10 -0700 Cc: "mpls@ietf.org" , "boris.zhang@telus.com" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , Ning So , "mpls-chairs@tools.ietf.org" , "Xu, Fengman" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:32:28 -0000 --_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F30E3PACDCEXMB13cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The word "adaptation" should be "adoption". Sorry for the typo. Mehmet From: Toy, Mehmet Sent: Tuesday, July 02, 2013 9:02 PM To: 'rtorvi@juniper.net'; Huaimo Chen (huaimo.chen@huawei.com); 'Ross Callo= n' Cc: 'mpls@ietf.org'; 'draft-chen-mpls-p2mp-egress-protection@tools.ietf.org= '; 'mpls-chairs@tools.ietf.org'; Ning So; autumn.liu@ericsson.com; Xu, Feng= man; LEI LIU; Boris.Zhang@telus.com Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Locally protecting egress nodes of a P2MP LSP reduces the time for protecti= on switching and resources required for the protection. The proposal has be= en verified in a prototype. As one of the authors of this draft, I support = its adaptation. Thanks Mehmet From: Huaimo Chen Sent: Thursday, June 27, 2013 9:58 PM To: 'Raveendra Torvi'; Ross Callon Cc: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protec= tion@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Ravi, Thanks much for your very helpful comments! My responses are inline below. Best Regards, Huaimo From: Raveendra Torvi [mailto:rtorvi@juniper.net] Sent: Monday, June 24, 2013 5:57 PM To: Huaimo Chen; Lizhong Jin; Ross Callon Cc: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protec= tion@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n I have finished first round of review of this draft. In short, WG should ex= plore use cases and see whether signaling procedure mentioned in the draft = are applicable in real world, before accepting this as WG draft. I do not= think this draft is readily usable. [Huaimo] This draft is initially written for a real use case, which has bee= n presented in the WG meetings. A prototype has been developed to verify so= me of the ideas in the draft. The running results have showed that they wor= k as expected. Following are some issues with draft: [1] Unlike other local protection this is an ingress driven, not PLR. In i= nter-domain scenario, ingress may not have the visibility of entire network= to figure out the complete primary path, not to mention the bypass path. [Huaimo] Can we focus on one domain scenario for our discussions first? Oth= er local protection and the egress node protection may need help from other= s such as PCE in inter-domain scenarios. The ingress of an LSP just provides the minimum amount of information for p= rotecting primary egress nodes. The protection for every primary egress nod= e is then driven by the PLR (i.e., the previous hop node of the primary egr= ess node). For facility backup protection, the ingress of the LSP just needs to give a= backup egress node for every primary egress node to be protected (plus som= e constraints if needed, which are the same as other local protection defin= ed in RFC4090). The previous hop node (i.e., PLR) selects or creates a bypa= ss backup tunnel from itself to the backup egress node for protecting the p= rimary egress node. If there is a bypass backup tunnel from the PLR to the = backup egress node that satisfies the constraints, then this tunnel is sele= cted; otherwise, a new bypass backup tunnel to the backup egress node will = be created. A path for the backup bypass tunnel will be computed by the PLR= and then the backup bypass is signaled along the path computed. If a backup S2L sub LSP is used to protect a primary egress node of a P2MP = LSP, the ingress of the LSP needs to provide a path from the previous hop o= f the primary egress to the backup egress node. In one domain scenario, the= re is no issue for the ingress to provide this path. [2] In the presence of loose-hops, this may also yield to wrong selection o= f PLR by ingress, as one may have several hops between ingress designated P= LR and protected PE. There is no indication from Egress to ingress that egr= ess is protected. [Huaimo] The ingress of an LSP does not select any PLR (i.e., the previous = hop node of the primary egress node) for protecting the primary egress node= . In order to protect a primary egress node of the LSP, the ingress just gi= ves the backup egress (designated to protect the primary egress). When a no= de determines that it is the previous hop node of the primary egress node, = it will act as the PLR to provide protection for the primary egress node. The status of the egress node protection is sent to the ingress in the RRO = of the RESV message. There are some descriptions about this in the draft (s= ee the paragraph below). "The previous hop node of the primary egress node sets the protection flags= in the RRO IPv4/IPv6 Sub-object for the primary egress node according to t= he status of the primary egress node and the backup LSP protecting the prim= ary egress node. For example, it will set the node protection bit to one in= dicating that the primary egress node is protected when the backup LSP to t= he backup egress node is set up for protecting the primary egress node." [3] 1:1 relationship between primary egress and backup egress. This will be= scalability issues especially with ring topologies. This solution is NOT extensible to 1:N protection. [Huaimo] It seems typical that one primary egress (PE) pairs with a backup = egress (PE) and a CE is dual home to two egresses (PEs). I do not see any s= calability issue here. Can you give more details about the scalability issu= es regarding to the 1:1 relationship between primary egress and backup egre= ss? The facility backup protection proposed in the draft can provide 1:N protec= tion. Multiple (N) LSPs going through the previous hop node to the primary = egress node can be protected for their primary egress node failure at the s= ame time by one (1) bypass tunnel from the previous hop node to the backup = egress node. Does this address the issue "This solution is NOT extensible t= o 1:N protection."? [4] This draft does not address interoperability with 1:N protection.. [Huaimo] Can you give some more details about "interoperability with 1:N pr= otection"? [5] Local reversion does not work Consider following example: S2L 1 : I - PH1-PE- Primary S2L 1 Backup: I - PH3 - PE-Backup S2L 2: I - PH2 - PE-Other I----PH1--------PE-Primary || PH2--------PE-Other | PH3---------- PE Backup PH - PE link comes back, PH1 sends traffic PE Primary and how & when does P= H2 stop sending traffic to PH3? [Huaimo] For using backup S2L sub LSP to protect the primary egress node, t= he path from the previous hop node of the primary egress node to the backup= egress node will not intersect with the path of the LSP. For the example a= bove, S2L 1 Backup will not go through PH2 (see figure below). Thus local r= eversion may work. S2L 1: I -- PH1 -- PE-Primary S2L 1 Backup: I -- PH1 -- PH3 -- PE-Backup S2L 2: I -- PH1 -- PH2 -- PE-Other I----PH1--------PE-Primary | \ | PH2--------PE-Other \__ PH3---------- PE-Backup When PE-Primary (i.e., the primary egress node) fails, PH1 switches the tra= ffic to the PE-Backup (i.e., the backup egress node). When PE-Primary comes back, PH1 may switch the traffic back to PE-Primary a= fter re-signaling S2L 1 if the local revertive mode is used. [6] According to Section 4.4, in order to detect PE-CE link down, this sol= ution needs a BFD session from a P router to CE device, which is a non-star= ter as P router may not have any state to reach CE, at least draft does not= go deep enough to explain this point. [Huaimo] We will focus on detecting the failure of the primary egress node = in the next version of the draft. [7] This solution addresses P2MP LSPs only. The approach cannot be extended= to apply for P2P LSPs, in which case it must be ensured that the back egre= ss know how to handle inner label (i.e. service label). [Huaimo] The following is a possible approach in which the solution propose= d in the draft is "extended" to protect the egress of a P2P LSP. To protect the primary egress node of a P2P LSP, the ingress of the LSP add= s the object containing the primary egress and the backup egress in the PAT= H message. This object has the same format as the object EGRESS_BACKUP_SUB_= LSP used for protecting a primary egress node of a P2MP LSP. If one-to-one backup is used, the previous hop node of the primary egress n= ode creates a backup LSP from itself to the backup egress for protecting th= e primary egress of the P2P LSP in a way similar to the one for creating a = backup sub LSP to protect a primary egress of a P2MP LSP. If facility backup is used, the previous hop node of the primary egress nod= e selects or creates a backup bypass tunnel from itself to the backup egres= s for protecting the primary egress. In the case that the previous hop (or upstream) node of the primary egress = needs a P2P LSP label from the backup egress (i.e., the inner label used by= the PLR to put into the bypass tunnel), there are a few of ways to get the= label. One way is that the previous hop (or upstream) node "extends" the P= 2P LSP to the backup egress. It sends a path message towards the backup egr= ess along the path computed and gets a resv message with a P2P LSP label fr= om the backup egress. Note that the previous hop (or upstream) node will n= ot create any forwarding entry with this label for sending the traffic to t= he backup egress. The previous hop (or upstream) node can provide the prima= ry egress node protection using this label in a way similar to the one that= it provides an intermediate node protection. Regarding to the service label, it seems that it is out scope of this draft= . The service label such as VPN label should be handled by others such as B= GP. Regards Ravi --_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F30E3PACDCEXMB13cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The word “adaptatio= n” should be “adoption”.

Sorry for the typo.<= /o:p>

Mehmet<= /p>

 <= /p>

From: Toy, Meh= met
Sent: Tuesday, July 02, 2013 9:02 PM
To: 'rtorvi@juniper.net'; Huaimo Chen (huaimo.chen@huawei.com); 'Ros= s Callon'
Cc: 'mpls@ietf.org'; 'draft-chen-mpls-p2mp-egress-protection@tools.i= etf.org'; 'mpls-chairs@tools.ietf.org'; Ning So; autumn.liu@ericsson.com; X= u, Fengman; LEI LIU; Boris.Zhang@telus.com
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Locally protecting egress= nodes of a P2MP LSP reduces the time for protection switching and resource= s required for the protection. The proposal has been verified in a prototype. As one of the authors of this draft, I support its adaptat= ion.

Thanks<= /p>

Mehmet

 

 

From: Huaimo C= hen
Sent: Thursday, June 27, 2013 9:58 PM
To: 'Raveendra Torvi'; Ross Callon
Cc: mpls@ietf.or= g; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chair= s@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Ravi,

 

     Tha= nks much for your very helpful comments!

     My = responses are inline below.

 

Best Regards,

Huaimo

 <= /p>

From: Raveendr= a Torvi [mailto:rt= orvi@juniper.net]
Sent: Monday, June 24, 2013 5:57 PM
To: Huaimo Chen; Lizhong Jin; Ross Callon
Cc: mpls@ietf.or= g; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chair= s@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

I have finished first rou= nd of review of this draft. In short, WG should explore use cases and see w= hether signaling procedure mentioned in the draft are applicable in real world, before accepting this as WG draft.   I do not thi= nk this draft is readily usable.

 <= /p>

[Huaimo] This draft is initi= ally written for a real use case, which has been presented in the WG meetin= gs. A prototype has been developed to verify some of the ideas in the draft. The running results have showed that they work as expe= cted.

 <= /p>

Following are some issues= with draft:

 

[1] Unlike other local protection this is an ingress= driven, not PLR.  In inter-domain scenario, ingress may not have the = visibility of entire network to figure out the complete primary path, not t= o mention the bypass path.

 <= /p>

[Huaimo] Can we focus on one= domain scenario for our discussions first? Other local protection and the = egress node protection may need help from others such as PCE in inter-domain scenarios.  

The ingress of an LSP just p= rovides the minimum amount of information for protecting primary egress nod= es. The protection for every primary egress node is then driven by the PLR (i.e., the previous hop node of the primary egress node)= .

For facility backup protecti= on, the ingress of the LSP just needs to give a backup egress node for ever= y primary egress node to be protected (plus some constraints if needed, which are the same as other local protection defined in RFC4090= ). The previous hop node (i.e., PLR) selects or creates a bypass backup tun= nel from itself to the backup egress node for protecting the primary egress= node. If there is a bypass backup tunnel from the PLR to the backup egress node that satisfies the constrain= ts, then this tunnel is selected; otherwise, a new bypass backup tunnel to = the backup egress node will be created. A path for the backup bypass tunnel= will be computed by the PLR and then the backup bypass is signaled along the path computed.

If a backup S2L sub LSP is u= sed to protect a primary egress node of a P2MP LSP, the ingress of the LSP = needs to provide a path from the previous hop of the primary egress to the backup egress node. In one domain scenario, there is no issu= e for the ingress to provide this path.

 <= /p>

 

[2] In the presence of loose-hops, this may also yie= ld to wrong selection of PLR by ingress, as one may have several hops betwe= en ingress designated PLR and protected PE. There is no indication from Egr= ess to ingress that egress is protected.

 <= /p>

[Huaimo] The ingress of an L= SP does not select any PLR (i.e., the previous hop node of the primary egre= ss node) for protecting the primary egress node. In order to protect a primary egress node of the LSP, the ingress just gives the ba= ckup egress (designated to protect the primary egress). When a node determi= nes that it is the previous hop node of the primary egress node, it will ac= t as the PLR to provide protection for the primary egress node.

The status of the egress nod= e protection is sent to the ingress in the RRO of the RESV message. There a= re some descriptions about this in the draft (see the paragraph below).

 

“The previous hop node of the primary egress node se= ts the protection flags in the RRO IPv4/IPv6 Sub-object for the primary egr= ess node according to the status of the primary egress node and the backup LSP protecting the primary egress node. For example, i= t will set the node protection bit to one indicating that the primary egres= s node is protected when the backup LSP to the backup egress node is set up= for protecting the primary egress node.”

 <= /p>

 

[3] 1:1 relationship between primary egress and back= up egress. This will be scalability issues especially with ring topologies.=  

   This solution is NOT extensible to= 1:N protection.

 

[Huaimo] It seems typical th= at one primary egress (PE) pairs with a backup egress (PE) and a CE is dual= home to two egresses (PEs). I do not see any scalability issue here. Can you give more details about the scalability issues regardi= ng to the 1:1 relationship between primary egress and backup egress?

The facility backup protecti= on proposed in the draft can provide 1:N protection. Multiple (N) LSPs goin= g through the previous hop node to the primary egress node can be protected for their primary egress node failure at the same time by= one (1) bypass tunnel from the previous hop node to the backup egress node= . Does this address the issue “This solution is NOT extensible to 1:N= protection.”?

 <= /p>

 <= /p>

[4] This draft does not address interoperability wit= h 1:N protection..

 

[Huaimo] Can you give some m= ore details about “interoperability with 1:N protection”?<= /o:p>

 <= /p>

 <= /p>

[5] Local reversion does not work

  

 Consider following example:

 

S2L 1 :  I – PH1—PE- Primary

S2L 1 Backup:  I – PH3 – PE-Backup<= o:p>

S2L 2: I – PH2 – PE-Other

  

      I----PH1--------= PE-Primary

        &nbs= p;       ||

        &nbs= p;      PH2--------PE-Other

         &nb= sp;      |

        &nbs= p;      PH3---------- PE Backup

 

PH – PE link comes back, PH1 sends traffic PE = Primary and how & when does PH2 stop sending traffic to PH3?

 <= /p>

[Huaimo] For using backup S2= L sub LSP to protect the primary egress node, the path from the previous ho= p node of the primary egress node to the backup egress node will not intersect with the path of the LSP. For the example above, S2L 1 = Backup will not go through PH2 (see figure below). Thus local reversion may= work.

 

S2L 1:  I –- PH1 -— PE-Primary

S2L 1 Backup:  I -– PH1 -- PH3 -– PE-Backup<= /span>

S2L 2: I –- PH1 -- PH2 -– PE-Other

 

      I----PH1--------PE-Primary

           |  \ <= o:p>

           | = ;  PH2--------PE-Other

            \__&n= bsp;  

            =    PH3---------- PE-Backup

 

When PE-Primary (i.e., the p= rimary egress node) fails, PH1 switches the traffic to the PE-Backup (i.e.,= the backup egress node).

When PE-Primary comes back, = PH1 may switch the traffic back to PE-Primary after re-signaling S2L 1 if t= he local revertive mode is used. 

 <= /p>

 

[6] According to Section 4.4,  in order to dete= ct PE-CE link down, this solution needs a BFD session from a P router to CE= device, which is a non-starter as P router may not have any state to reach= CE, at least draft does not go deep enough to explain this point.

 <= /p>

[Huaimo] We will focus on de= tecting the failure of the primary egress node in the next version of the d= raft.

 <= /p>

 <= /p>

[7] This solution addresses P2MP LSPs only. The appr= oach cannot be extended to apply for P2P LSPs, in which case it must be ens= ured that the back egress know how to handle inner label (i.e. service labe= l).

 

[Huaimo] The following is a = possible approach in which the solution proposed in the draft is “ext= ended” to protect the egress of a P2P LSP.

To protect the primary egres= s node of a P2P LSP, the ingress of the LSP adds the object containing the = primary egress and the backup egress in the PATH message. This object has the same format as the object EGRESS_BACKUP_SUB_LSP used f= or protecting a primary egress node of a P2MP LSP.

If one-to-one backup is used= , the previous hop node of the primary egress node creates a backup LSP fro= m itself to the backup egress for protecting the primary egress of the P2P LSP in a way similar to the one for creating a backup su= b LSP to protect a primary egress of a P2MP LSP.

If facility backup is used, = the previous hop node of the primary egress node selects or creates a backu= p bypass tunnel from itself to the backup egress for protecting the primary egress.

In the case that the previou= s hop (or upstream) node of the primary egress needs a P2P LSP label from t= he backup egress (i.e., the inner label used by the PLR to put into the bypass tunnel), there are a few of ways to get the label. = One way is that the previous hop (or upstream) node “extends” t= he P2P LSP to the backup egress. It sends a path message towards the backup= egress along the path computed and gets a resv message with a P2P LSP label from the backup egress.  Note that the p= revious hop (or upstream) node will not create any forwarding entry with th= is label for sending the traffic to the backup egress. The previous hop (or= upstream) node can provide the primary egress node protection using this label in a way similar to the one that i= t provides an intermediate node protection.

Regarding to the service lab= el, it seems that it is out scope of this draft. The service label such as = VPN label should be handled by others such as BGP.

 <= /p>

 <= /p>

 <= /p>

Regards

Ravi=

--_000_E0CCE9D2B396674BABDD84B7C422BE1C3C4F30E3PACDCEXMB13cabl_-- From daniele.ceccarelli@ericsson.com Wed Jul 3 07:18:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023CC21F9D53; Wed, 3 Jul 2013 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVChNqp0iKXZ; Wed, 3 Jul 2013 07:18:40 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4021F9D50; Wed, 3 Jul 2013 07:18:39 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-19-51d432bd7c97 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 35.74.11907.DB234D15; Wed, 3 Jul 2013 16:18:38 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 16:18:37 +0200 From: Daniele Ceccarelli To: "mpls-bounces@ietf.org" Thread-Topic: [mpls] draft-wijnands-mpls-mldp-node-protection Thread-Index: Ac53+DVoDjsaJc0gLEmkXXMyj4uf5g== Date: Wed, 3 Jul 2013 14:18:37 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480FC99F@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre4+oyuBBsfucFj86LnBbPFzuq/F nV1fWC1277/CbvH90hIWi1tLV7I6sHm0PtvL6rFkyU8mjxWbVzJ6fLn8mS2AJYrLJiU1J7Ms tUjfLoEr4/2+ooItfBUn1rA2MP7g7mLk5JAQMJG4+u0RM4QtJnHh3nq2LkYuDiGBo4wSB3Y8 Z4RwFjFKzDywjamLkYODTcBK4skhH5AGEQFjid7nG8EamAWuMkn0LN3MDpIQFrCROH1xFTNE ka3E5puvGSFsPYmF+5aygcxhEVCR2LXXACTMK+At8eTEXLByRgFZiQm7F4GVMwuIS9x6Mp8J 4jgBiSV7zkMdKirx8vE/VghbSWLF9ktQ9ToSC3Z/YoOwtSWWLXzNDDFfUOLkzCcsExhFZiEZ OwtJyywkLbOQtCxgZFnFyFGcWpyUm25ksIkRGCsHt/y22MF4+a/NIUZpDhYlcd4temcChQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTAqHDubVtLx4XKB1fq5Cnk6IrInt5zeb69s3HJ45V69 tcecHH/ucX9QkP+DyefD3oWib/oPRvw97rA6wHTPdYUpWz5/fFse6Rvz+Fnvd4trh/sz79aX rp99XsZI/5btBeP7y+XfPKgT0U4TbLq4O/L6Iu3Jd+SmHyrlkD7eF6Bzde0LX+ae94/ylFiK MxINtZiLihMBhhaskmMCAAA= Cc: "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 14:18:45 -0000 =0A= Support=0A= =0A= Br=0A= Daniele=0A= =0A= *** E-mail via DME powered by mobile broadband ***=0A= =0A= =0A= --Original message---=0A= Sender: "mpls-bounces@ietf.org" =0A= Time: Wed Jul 03 13:22:00 CEST 2013=0A= To: mpls@ietf.org, mpls-chairs@tools.ietf.org, adrian@olddog.co.uk, martin.= vigoureux@alcatel-lucent.com, draft-wijnands-mpls-mldp-node-protection@tool= s.ietf.org, =0A= Subject: [mpls] draft-wijnands-mpls-mldp-node-protection=0A= =0A= Working Group,=0A= =0A= This is to start a two week poll on adopting=0A= draft-wijnands-mpls-mldp-node-protection as an MPLS working=0A= group document.=0A= =0A= Please send your comments (support/not support) to the mpls working=0A= group mailing list (mpls at ietf.org). Please give a technical=0A= motivation for your support/not support, especially if you think that=0A= the document should not be adopted as a working group document.=0A= =0A= This poll ends July 17, 2013.=0A= =0A= There are two IPR claims against this document:=0A= =0A= https://datatracker.ietf.org/ipr/1727/=0A= https://datatracker.ietf.org/ipr/2116/=0A= =0A= =0A= The authors has stated on the working group mailing list=0A= that they are not aware of any other IPR claims against this draft.=0A= =0A= However if you are on the the mpls working group mailing list and=0A= aware of IPR that relates to this draft, the time to disclose=0A= this is now.=0A= =0A= /Loa=0A= (mpls wg co-chair)=0A= -- =0A= =0A= =0A= Loa Andersson email: loa@mail01.huawei.com=0A= Senior MPLS Expert loa@pi.nu=0A= Huawei Technologies (consultant) phone: +46 739 81 21 64=0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls= From skraza@cisco.com Wed Jul 3 07:49:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB55B11E8181 for ; Wed, 3 Jul 2013 07:49:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ5RQXzVVev1 for ; Wed, 3 Jul 2013 07:49:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 919D121F99F7 for ; Wed, 3 Jul 2013 07:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1549; q=dns/txt; s=iport; t=1372862982; x=1374072582; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8GA5EDlYg9D52Qo/aP/Fyk0bEnUkmOAAQFzKIZuzex0=; b=eYIZmiXdsVDxno/YhkHOYqOHjM5ktZhYBxCbMRVeJSi6atWqlVyQMAkH 7ck6BlSZX13rbFvlSKgh4VdsS9Qpdp2zokTe3RLWuikU6kbq2J+ZcxB4Z 6PlzFm1Ef1KCAFDU1OcCWxbND1cAVK9UnILr4550G81X65Qitqk76V8dF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAA851FGtJXHA/2dsb2JhbABagwkyScAygQMWdIIjAQEBBAEBATcxAwsOBAEIGAoUKwwLJQIEAQ0FCIgHDLsBBASOJYERMQeDBGkDqQ6DEYFxNw X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="230623393" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2013 14:49:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r63Enf9c013068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 14:49:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 09:49:41 -0500 From: "Kamran Raza (skraza)" To: Jeff Tantsura , Loa Andersson Thread-Topic: [mpls] draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOd+EacD1ahP7x2UeiY4svjFqyWJlTGhEA Date: Wed, 3 Jul 2013 14:49:39 +0000 Message-ID: In-Reply-To: <10C19E96-D02E-4655-AE33-613364B09093@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [161.44.213.24] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 14:49:47 -0000 +1 (as co-author) On 2013-07-03 7:32 AM, "Jeff Tantsura" wrote: >Support, as co-author > >Regards, >Jeff > >On Jul 3, 2013, at 1:22 PM, "Loa Andersson" wrote: > >> Working Group, >>=20 >> This is to start a two week poll on adopting >> draft-wijnands-mpls-mldp-node-protection as an MPLS working >> group document. >>=20 >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls at ietf.org). Please give a technical >> motivation for your support/not support, especially if you think that >> the document should not be adopted as a working group document. >>=20 >> This poll ends July 17, 2013. >>=20 >> There are two IPR claims against this document: >>=20 >> https://datatracker.ietf.org/ipr/1727/ >> https://datatracker.ietf.org/ipr/2116/ >>=20 >>=20 >> The authors has stated on the working group mailing list >> that they are not aware of any other IPR claims against this draft. >>=20 >> However if you are on the the mpls working group mailing list and >> aware of IPR that relates to this draft, the time to disclose >> this is now. >>=20 >> /Loa >> (mpls wg co-chair) >> --=20 >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From akatlas@gmail.com Wed Jul 3 08:54:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A32521F9700 for ; Wed, 3 Jul 2013 08:54:45 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qli6hvXVJC1V for ; Wed, 3 Jul 2013 08:54:44 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DF70621F91C4 for ; Wed, 3 Jul 2013 08:54:39 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so764943iec.8 for ; Wed, 03 Jul 2013 08:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wlQP4j/J1D5Yo5n7+0VkAUJp7y8VnrPnQ78vk3/8hYo=; b=ExBiw1hvAf+9q7dwT3K9Sw2Vt66h1oU1I7eIKXBR+DP+ITgMgz7paMzE3XydrwLLLU Ty+UALy6C2lt+2K0LFBeCeS9BM7MvDzCJDckv7BM32eAsVnQKde8L3bb80+BP6LuDUUp d99nHAd6zKuIu1vt5H47gBSSCGwK93mziEH76TdzQyEznhU8LiZMnNIPv62/ma36TfQ4 r2EiZkzkZA4ZQjBU2LgqEJzlks2isZ52rT9SUNHHP1HgKWMcTqiL8+Kknw+++RcyHZwL txYMp0iOshYw+It/SO2BM3E3KlTB2/tGqCIOFRysJiA9nMS4lwfefwPhQGRZNOLJJdxT Pt3Q== MIME-Version: 1.0 X-Received: by 10.50.67.111 with SMTP id m15mr981274igt.54.1372866879421; Wed, 03 Jul 2013 08:54:39 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Wed, 3 Jul 2013 08:54:39 -0700 (PDT) Date: Wed, 3 Jul 2013 11:54:39 -0400 Message-ID: From: Alia Atlas To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=047d7bd75244ac03f804e09d7a3e Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 15:54:46 -0000 --047d7bd75244ac03f804e09d7a3e Content-Type: text/plain; charset=ISO-8859-1 Support (as co-author) Alia >On Jul 3, 2013, at 1:22 PM, "Loa Andersson" wrote: > > > >> Working Group, > >> > >> This is to start a two week poll on adopting > >> draft-wijnands-mpls-mldp-node-protection as an MPLS working > >> group document. > >> > >> Please send your comments (support/not support) to the mpls working > >> group mailing list (mpls at ietf.org). Please give a technical > >> motivation for your support/not support, especially if you think that > >> the document should not be adopted as a working group document. > >> > >> This poll ends July 17, 2013. > >> > >> There are two IPR claims against this document: > >> > >> https://datatracker.ietf.org/ipr/1727/ > >> https://datatracker.ietf.org/ipr/2116/ > >> > >> > >> The authors has stated on the working group mailing list > >> that they are not aware of any other IPR claims against this draft. > >> > >> However if you are on the the mpls working group mailing list and > >> aware of IPR that relates to this draft, the time to disclose > >> this is now. > >> > >> /Loa > >> (mpls wg co-chair) > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ > >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 > --047d7bd75244ac03f804e09d7a3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support (as co-author)

Alia


>On Jul 3, 2013, at 1:22 PM, &qu= ot;Loa Andersson" <loa@pi.nu> w= rote:
>
>> Working Group,
>>
>> This is to start a two week poll on adopting
>> draft-wijnands-mpls-mldp-node-protection as an MPLS working
>> group document.
>>
>> Please send your comments (support/not support) to the mpls workin= g
>> group mailing list (mpls at ietf.org). Please give a technical
>> motivation for your support/not support, especially if you think t= hat
>> the document should not be adopted as a working group document. >>
>> This poll ends July 17, 2013.
>>
>> There are two IPR claims against this document:
>>
>> https://datatracker.ietf.org/ipr/1727/
>> https://datatracker.ietf.org/ipr/2116/
>>
>>
>> The authors has stated on the working group mailing list
>> that they are not aware of any other IPR claims against this draft= .
>>
>> However if you are on the the mpls working group mailing list and<= br> >> aware of IPR that relates to this draft, the time to disclose
>> this is now.
>>
>> /Loa
>> (mpls wg co-chair)
>> --
>>
>>
>> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email= : loa@mail01.huawei.com
>> Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0loa@pi.nu
>> Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

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

--047d7bd75244ac03f804e09d7a3e-- From akatlas@gmail.com Wed Jul 3 11:12:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8192B21F9DC2 for ; Wed, 3 Jul 2013 11:12:43 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBLDCXU6DkSc for ; Wed, 3 Jul 2013 11:12:40 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9A00921F9C3E for ; Wed, 3 Jul 2013 11:12:39 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so1211806iej.1 for ; Wed, 03 Jul 2013 11:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NMbWWI17aTBzoT2/ZPf9PJlkaxtOZj9mmMMw7i5jhoY=; b=Zw+XXRuFuDmvhNPziUBz8Z7nwFjqylMOxzARUaQKErxmXlBClbyrVr6bfa/XqeGNCI HCJr2OYyuN1Kv0hleJj9VpxqwUvuLoWFZpPO/SkmzRs2RxZgkNBfwH/BIt6AuAjvNZTp EK/Khu4TI+L1aKQMK/LeVFYUkbXno9MRXNipGvRhWoX7LUmGS+rVleWXGr7eAjTzYUU9 LTKXuKWutxfjDeEKyemtV2CczPWFlRW7uVjDB/Ejvih0en70drY9Ly+NDj75BLhRJxkc OtroFPbbTCbjc0JC2V6/7fbMfu9nPMTjFeDkEs6AI0EBbgOzNN+0TaOTLvHvhKEq/Gx6 3tew== MIME-Version: 1.0 X-Received: by 10.50.67.111 with SMTP id m15mr1381685igt.54.1372875157566; Wed, 03 Jul 2013 11:12:37 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Wed, 3 Jul 2013 11:12:37 -0700 (PDT) In-Reply-To: <51cdf4db.a7fe420a.49c5.22e6SMTPIN_ADDED_BROKEN@mx.google.com> References: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> <51cdf4db.a7fe420a.49c5.22e6SMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 3 Jul 2013 14:12:37 -0400 Message-ID: From: Alia Atlas To: Quintin Zhao Content-Type: multipart/alternative; boundary=047d7bd75244167ba804e09f6856 Cc: "mpls@ietf.org" , draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 18:12:43 -0000 --047d7bd75244167ba804e09f6856 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Quintin, I think it is useful to have a range of MT-IDs which is the same for OSPF, IS-IS, and LDP. I do not personally know of a specific use where this is required. Given that the OSPF range is only 7 bits long, I'd suggest no more than 16 for this purpose - and reserve another 32 just in case. For MRT, the only protocol in which the MT-IDs are actually signaled is LDP (and possibly PIM). Both of those have a range of 4096 for the signaling. I think it would be useful to have many of these available (up to 16 even) - but that's to more easily support different MRT Profiles for different purposes on the same network at the same time. Alia On Fri, Jun 28, 2013 at 4:40 PM, Quintin Zhao wrot= e: > Hello Alia,**** > > ** ** > > Thanks for your review and suggestions.**** > > ** ** > > Indeed we need to allocate a MT ID range for the applications such as MRT > so that MT ID can be the same for OSPF, ISIS and LDP. **** > > ** ** > > We need decide how big this range should be for the applications such as > MRT. What is your recommendation for this range?**** > > ** ** > > This is what we have now from ISIS-MT(RFC5120):**** > > ** ** > > ** ** > > - MT ID #0: Equivalent to the "standard" topology.**** > > - MT ID #1: Reserved for IPv4 in-band management**** > > purposes.**** > > - MT ID #2: Reserved for IPv6 routing topology.**** > > - MT ID #3: Reserved for IPv4 multicast routing topology.***= * > > - MT ID #4: Reserved for IPv6 multicast routing topology.***= * > > - MT ID #5: Reserved for IPv6 in-band management**** > > purposes.**** > > - MT ID #6-#3995: Reserved for IETF consensus.**** > > - MT ID #3996-#4095: Reserved for development, experimental and**** > > proprietary features [RFC3692].**= * > * > > ** ** > > This is what have now from OSPF-MT(RFC4915)**** > > ** ** > > 0 - Reserved for advertising the metric associated**** > > with the default topology (see Section 4.2)**** > > 1 - Reserved for advertising the metric associated**** > > with the default multicast topology**** > > 2 - Reserved for IPv4 in-band management purposes**** > > 3-31 - Reserved for assignments by IANA**** > > 32-127 - Reserved for development, experimental and**** > > proprietary features [RFC3692]**** > > 128-255 - Invalid and SHOULD be ignored**** > > ** ** > > The range which is available for us to use is from 6 -127.**** > > ** ** > > Thanks,**** > > Quintin**** > > ** ** > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* 2013=E5=B9=B45=E6=9C=8829=E6=97=A5 8:52 > *To:* Adrian Farrel > *Cc:* draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; mpls@ietf.or= g > *Subject:* Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology**** > > ** ** > > Hi Adrian & authors,**** > > ** ** > > I have a couple comments on the IANA registry and number overlapping.**** > > ** ** > > First, it would be useful to have a range that is clearly intended to be > the same for OSPF, ISIS and LDP. Given the**** > > extremely limited range for OSPF multi-topology routing ( > http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of**= * > * > > 3-127, it'd be very useful to have that range specifically set aside for > cases where it matters that it be the same. **** > > ** ** > > One use that I see for this draft is for MRT, which is doing > multi-topology forwarding but not multi-topology routing. This means**** > > that the MT-IDs used do not need to overlap with those in OSPF or ISIS. > It would be good to ensure that there's a reasonable**** > > range in LDP for such purposes. LDP is one of the few mechanisms that > easily lends itself to multi-topology forwarding.**** > > ** ** > > Alia**** > > ** ** > > P.S. Having the same values for mLDP and PIM may also be very useful for > interworking. PIM doesn't actually have an IANA**** > > registry for MT-ID and leaves the meaning of the values up to the network > operator.**** > > ** ** > > On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel > wrote:**** > > Hi authors, > > Thanks for this document. > > I have done my usual AD review which is intended to catch any issues > that I see, and to smooth out the wrinkles before the I-D goes to IETF > last call and IESG review. > > As you will see below, I have a number of editorial comments (nits and > larger changes) and also a few questions/issues. > > The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. > I suggest you read the comments against those sections all together. > Note that in my comment for section 9, I think I have worked out what > you need to do, and so the resolution to the comments for 3.4 and 3.8 > may simply be documenting this change to the IANA registry. > > As usual, all my comments are up for discussion, so please don't feel > you are required to make changes if you think there is a good reason why > things are the way they are. > > At the moment it looks like a new revision will be needed to address the > review, so I have set the flag in the datatracker. Please work with your > document shepherd to produce and post a new revision. > > Thanks, > Adrian > > =3D=3D=3D > > The document seems to end with a spurious page header. > > --- > > The index seems to be considerably adrift from reality. > In particular, there is no Appendix in this document. > > --- > > Why do you say that this updates RFC 4379? Is it your belief that an > implementation of RFC 4379 will not be complete/conformant without these > extensions? Or are you just defining extensions which an implementation > in an MPLS-MT environment will need to support? > > I note that you (in my view, correctly) do not say that this document > updates RFC 5036, yet it defines extensions to LDP in a similar way. > > --- > > Please expand all acronyms on first use unless they show with an > asterisk in the RFC Editor's list at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > I see: > CSP > LSP > QoS > > --- > > Abstract and Introduction > > "IGP protocol" is bad because the "P" in "IGP" is "protocol". > > --- > > The RFC Editor prefers documents to have the Introduction as Section 1. > > You may prefer to make this change yourself, because it will possibly > cause some expansions of terms and acronyms that the RFC Editor might > so in a way you don't like. > > --- > > In section 1, the term "MT Topology" is odd because the "T" of "MT" > stands for "Topology". Surely you don't mean "Multi Topology Topology"? > > --- > > Section 3.1 > > s/infers/implies/ > > --- > > Section 3.2 > > I prefer that you don't repeat protocol encodings that are defined > elsewhere. This can cause nasty problems if you make a mistake or if > the original definition is updated. > > It is enough for you to write... > > The LDP base specification [RFC5036] (Section 4.1) defines the > "Prefix" FEC Element. The "Prefix" encoding is defined for a given > "Address Family" (AF), and has length (in bits) specified by the > "PreLen" field. > > To extend IP address families for MT, two new Address Families named > "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes > within a topology scope. > > --- > > Section 3.2 Figure 2 > > This figure gives the impression that both IPv4 and IPv6 addresses are > four bytes long! > > I think you need: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ IP Address ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | MT-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: MT IP Address Family Format > > ...and... > > Where "IP Address" is a variable length field padded to a four octet > boundary and containing an IPv4 or IPv6 address/prefix for the "MT > IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to > the 16-bit Topology ID for given address. > > ...but you need to check I got that right! > > However, before doing this work, see my comment on Section 3.3 > > --- > > Section 3.2 > > The proposed FEC Elements with "MT IP" Address Family can be used in > > You are not proposing any more, you are defining! > > See also section 3.6, 3.8, 4.1, 4.3, and 8 > > --- > > Section 3.2 > > [RFC5036] does not specify the handling of "Unknown" Address > Families. Therefore, [RFC5036] will need to be updated to include > the handling procedure for unknown address families. > > Ouch! > > This had me really worried because it implied that you are breaking > existing LDP deployments. But I discussed it with Loa, and he pointed me > at Section 3.4.1.1 of RFC 5036 > > "If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address Family it does not support, it SHOULD stop decoding the FEC > TLV, abort processing the message containing the TLV, and send an > "Unsupported Address Family" Notification message to its LDP peer > signaling an error. > > If it encounters a FEC Element type it cannot decode, it SHOULD stop > decoding the FEC TLV, abort processing the message containing the > TLV, and send an "Unknown FEC" Notification message to its LDP peer > signaling an error." > > So I think you can just delete this paragraph. > > Furthermore, Section 3.5 defines a capability advertisement that enables > you to know whether it is safe to use one of the new AFs. So surely you > should also say "MUST NOT send an MT AF unless the peer has said it can > handle it." > > See my re-write in the next comment. > > --- > > Section 3.3 appears to be repeating a lot of Section 3.2, but in a > better and more concise way. For example, Figure 3 nicely shows how the > Prefix FEC element works with the new AFs. > > This leads me to think that Section 3.2 could be reduced to just a few > lines that say... > > The LDP base specification [RFC5036] (Section 4.1) defines the > the use of an "Address Family" (AF) field in FEC Elements to indicate > the encoding of the "Prefix" or "Address" that follows, and to > indicate how the FEC should be interpreted. > > This document defines two new AF values named "MT IP" and "MT IPv6" > that are used to specify the use of IPv4 or IPv6 within a topology > scope. The data associated with these new AFs includes an "MT-ID" > field that carries the 16-bit Topology ID for a topology. > > The value of MT-ID=3D0 corresponds to default topology and MUST be > ignored on receipt so as to not cause any conflict/confusion with > existing non-MT procedures. > > FEC Elements with the new AFs can be used in any LDP message and > procedures that currently specify and allow the use of FEC Elements > with the IP or IPv6 AFs, but MUST NOT be used unless the peer has > indicated it can handle them as described in Section 3.5. Note that > behavior by an LDP speaker that receives a FEC element containing an > unknown AF is described in Section 3.4.1.1 of [RFC5036]. > > --- > > Section 3.4 is perfectly clear except it doesn't say what "reserved", > "special", and "translating" mean. > > This opens up a number of questions including why you need a registry > at all. Presumably the "translation" needed is to ensure that the > values used in LDP have the same meaning as they do in the IGP. If that > is the case, why not simply use exactly the same value? > > And looking at the registry further, it seems to say that only values > allocated by IANA and stored in the registry can be used. That means > that an operator that wants to use MT in their network cannot just > assign values to the MT-IDs for the topologies because the registry > has no space for this to happen. > > Now, it is possible that you have simply used the wrong words in the > registry in section 9, and failed to provide any explanation in the > text. Note that "unassigned" means "not yet assigned, but available > to be assigned by IANA". And "Reserved" means "Do not assign until > a new RFC defines how they should be used." > > But there are other questions: > > Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? > I guess 16 is convenient to hold either, but how are the top 4 bits to > be handled? > > How do you handle the case where there are multiple instances of an IGP > (or different IGPs) running? > > If you *do* expect there to be a mapping function between IGP MT-ID and > LDP MT-ID, how do you ensure the same function is used at both ends of > an LDP session? > > But Section 3.8 really does seem to say that only MT-IDs in the registry > are allowed, which seems to make this I-D almost useless because you > have only defined "default" (which we have already), "ISIS IPv6", and > "all". Isn't an operator allowed to partition their network into > topologies? > > So... > > I think what you need in Section 9 is... > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. The allocation policies for this registry > are: > > Range Registration Policy > ------ ------------------- > 0-3995 Expert Review > 3996-4095 Private Use > 4096-4127 Expert Review > 4128-4255 Private Use > 4256-4351 Reserved (IANA does not assign) > 4352-4511 Expert Review > 4512-65535 Private Use > > IANA is requested to populate this registry as follows: > > > Range/Value Purpose Reference > ----------- ------------------------------------- --------- > 0 Default/standard topology in IS-IS [This.I-D] > 1 IPv4 in-band management in IS-IS [This.I-D] > 2 IPv6 routing topology in IS-IS [This.I-D] > 3 IPv4 multicast topology in IS-IS [This.I-D] > 4 IPv6 multicast topology in IS-IS [This.I-D] > 5 IPv6 in-band management in IS-IS [This.I-D] > 6-3995 Unassigned (intended to mirror IS-IS) > 3996-4095 Reserved for private use (from IS-IS) [This.I-D] > 4096 Default/standard topology in OSPF [This.I-D] > 4097 Default multicast topology in OSPF [This.I-D] > 4098 IPv4 in-band management in OSPF [This.I-D] > 4099-4127 Unassigned (intended to mirror OSPF) > 4128-4255 Reserved for private use (from OSPF) [This.I-D] > 4256-4351 Reserved (IANA does not assign) [This.I-D] > 4352-4511 Unassigned > 4512-65535 Reserved for Private Use [This.I-D] > > This would address many of the issues in Sections 3.4 and 3.8, and needs > to be discussed in those sections. > > --- > > In Section 3.5 > > o Length: The length (in octets) of TLV. > > Are you sure it is not just the length in octets of the value? > Compare with RFC 5036 Section 3.3 > > --- > > Sections 3.5 and 3.6 need to be more closely grouped. > > Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 > > --- > > Section 3.6 > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker MAY send an "MT Capability" > including the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker MAY send "MT Capability" with one or more MT Typed FEC > elements in it. > > I don't think this is "MAY" in either case. This *is* how the LDP > speaker announces it. There is no other way to announce it. So... > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker sends an "MT Capability" including > the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker sends "MT Capability" with one or more MT Typed FEC elements > in it. > > --- > > Section 3.6 > > o If an LSR has not advertised MT capability, its peer must not send > messages that include MT identifier to this LSR. > > Isn't that "MUST NOT"? > > --- > > Section 3.8 > > Certain MT topologies are assigned to serve predetermined purposes: > > It is not the topology that is assigned, but the MT-ID. Should read: > > Certain MT-ID values are assigned to indicate specific meanings: > > --- > > Section 3.8 > > It is not helpful to "propose" numbers in this section and then to > also reference Section 9 for the definitive numbers. I suggest you > remove all numbers from this section and simply point at Section 9. > > --- > > Section 4.2 > > This MAY allow an LDP speaker to signal its IP convergence... > > What does 2119 MAY mean in this context? > > --- > > Section 4.3 > > [RFC4379] defines procedures to detect data-plane failures in MPLS > LSPs via LSP ping. The specification defines a "Target FEC Stack" > TLV that describes the FEC stack being tested. > > Ha, ha! You got me :-) > s/The specification/That specification/ > > --- > > Section 4.3.1 > > Sub-Type Length Value Field > -------- ------ ----------------- > TBA5 5 MT LDP IPv4 prefix > TBA6 17 MT LDP IPv6 prefix > > Are you sure you don't mean 8 and 20? > > --- > > Section 4.3.4 > > When detect data plane failures using LSP Ping for a specific topoly, > the router will intiate an LSP Ping request with the targer FEC stack > > I think > > s/When/To/ > > s/topoly/topology/ > > s/intiate/initiate/ > > s/targer/target/ > > --- > > Section 4.3.4 > > For the case that the LSP ping with return path not specified , the > reply packet may go through the default topology instead of the > topology where the Echo Request goes through. > > Is that really "the default" or "any"? > If you mean "the default" then I think you need some "MUST NOT" text to > talk about other topologies. > > --- > > Section 5 > > The extensions defined in this document utilise the existing LDP > error handling defined in [RFC5036]. If an LSR receives an error > notification from a peer for an MPLS-MT session, it terminates the > LDP session by closing the TCP transport connection for the session > and discarding all MT-ID label mappings learned via the session. > > There is nothing wrong with this text, but it does open a question that > is not addressed anywhere in the document: what is the relationship > between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? > > This is somewhat assumable from the discussion of multiple MT-ID > wildcard FEC elements in the Multi-Topology Capability TLV, but it is > not explicit. > > --- > > Shouldn't Section 6 comment on how each of the new protocol elements > will not be seen by a legacy implementation because they are only used > after successful capability negotiation? > > But you do need to describe how a legacy node will react to attempted > MT capability negotiation. > > You could also restate the reference to RFC 5036 section 3.4.1.1 since > this issue seemed to be a question for you. > > --- > > I'm slightly doubtful about the value of Section 7, but I note that the > point you are trying to convey is not quite worded correctly. You have: > > and the specified > signaling mechanisms do not provide any way for the data plane to > associate a given packet with a context-specific label space. > > I don't think the signaling mechanism is relevant, and I think "context- > specific" hides what you are trying to say. Perhaps you should have: > > and there is no way > for the data plane to associate a received packet with any one > topology, meaning that topology-specific label spaces cannot be used. > > --- > > Section 9 > > o New Status Code: "Multi-Topology Capability not supported" > (requested code point: TBA2 from LDP registry "Status Code Name > Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is an implementation that does not know the new MT Capability > TLV supposed to generate this status code? Or are you referencing an > existing error code: in which case it should not appear in this section. > > o New Status Code: "Unknown Address Family" (requested code point: > TBA4 from LDP registry "Status Code Name Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is a legacy implementation that does not know either of your > new MT AFs supposed to generate this status code? But I suspect you are > just referencing an existing error code (see Section 3.2) as defined in > RFC 5036, and so you should not mention it in this section. > > Figure 10 does not show either of these status codes. > > --- > > Figure 10 shows a specific value for the new status code. Is this a > request or demand? I don't think it has already been allocated. > > --- > > Section 9 > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. > > This registry is discussed earlier in my notes. but please be aware that > you will need to define the allocation policy because it is a new > registry. > > --- > > Section 9 > > I want to ask Loa Andersson to look again at the LSP Ping TLV > allocations to check that they conform to the work he is currently > doing with that registry. > > --- > > It would help considerably to add a Manageability Considerations section > to this document because the function being added here is not simple to > manage or operate, and will have impact on the way that the network is > run. Good guidance on such sections can be found in RFC 5706. Appendix A > is particularly helpful at summarising things to consider. > > -------------------- > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > --047d7bd75244167ba804e09f6856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Quintin,

I think it is useful to hav= e a range of MT-IDs which is the same for OSPF, IS-IS, and LDP. =C2=A0I do = not personally know of a specific use where this is required. =C2=A0Given t= hat the OSPF range is only 7 bits long, I'd suggest no more than 16 for= this purpose - and reserve another 32 just in case.
=C2=A0
For MRT, the only protocol in which the MT-IDs are ac= tually signaled is LDP (and possibly PIM). =C2=A0Both of those have a range= of 4096 for the signaling. =C2=A0 I think it would be useful to have many = of these available (up to 16 even) - but that's to more easily support = different MRT Profiles for different purposes on the same network at the sa= me time.

Alia


On Fri, Jun 28, 2013 at 4:40 PM, Quintin Zhao <quintin.zhao@huawei.com> wrote:

Hello Alia,

=C2=A0

Thanks for your review and suggestions.=

=C2=A0=

Indeed we need to alloc= ate a MT ID range for the applications such as MRT so that MT ID can be the= same for OSPF, ISIS and LDP.

=C2=A0=

We need decide how big = this range should be for the applications such as MRT. What is your recomme= ndation for this range?

=C2=A0=

This is what we have no= w from ISIS-MT(RFC5120):

=C2=A0=

=C2=A0

=C2=A0=C2=A0 -=C2=A0 MT ID = #0:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Equivalent to the= "standard" topology.

=C2=A0=C2=A0 -=C2=A0 MT ID #1:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv4 in-band management

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0purposes.

=C2=A0=C2=A0 -=C2=A0 MT ID = #2:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv6= routing topology.

=C2=A0=C2=A0 -=C2=A0 MT ID #3:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv4 multicast routing to= pology.

=C2=A0=C2=A0 -=C2=A0 MT ID #4:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Reserved for IPv6 multicast routing topology.=

=C2=A0=C2=A0 -=C2=A0 MT ID = #5:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv6= in-band management

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0purpo= ses.

=C2=A0=C2=A0 -=C2=A0 MT ID #6-#3995:=C2=A0=C2=A0=C2=A0 Reserved for IETF = consensus.

=C2=A0=C2=A0 -=C2=A0 MT ID = #3996-#4095: Reserved for development, experimental and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0proprietary features [RFC3692].

= =C2=A0

This is what have now from = OSPF-MT(RFC4915)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - R= eserved for advertising the metric associated

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wi= th the default topology (see Section 4.2)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Reserve= d for advertising the metric associated

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 with the default multicast topology=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - Reserved for IPv4 in-band management purposes

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3-31=C2=A0=C2=A0=C2=A0 - Reserved for ass= ignments by IANA

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 32-127=C2=A0 - Reserved for development, experimental and

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 proprietary features [RFC3692]

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 128-255 - Invalid and SHOULD be ignored

=C2=A0=

The range which is avai= lable for us to use is from 6 -127.

=C2=A0

Thanks,=

Quintin

=C2=A0

From:<= /b> Alia Atlas [mailto:akatlas@gmail.com]
Sent: 2013=E5=B9=B45=E6=9C=8829<= /span>=E6=97=A5<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif""> 8:52
To: Adrian Farrel
Cc: draft-ietf-mpls-ldp-= multi-topology.all@tools.ietf.org; mpls@ietf.org
Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology<= u>

=C2=A0

Hi Adrian & authors,

=C2=A0

I have a couple= comments on the IANA registry and number overlapping.=

=C2=A0

First, it would= be useful to have a range that is clearly intended to be the same for OSPF= , ISIS and LDP. =C2=A0Given the

extremely limited ra= nge for OSPF multi-topology routing (http://www.iana= .org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of<= /span>

3-127, it'd be v= ery useful to have that range specifically set aside for cases where it mat= ters that it be the same.=C2=A0

=C2=A0

One use that I see for this draft is for MR= T, which is doing multi-topology forwarding but not multi-topology routing.= =C2=A0This means

that the MT-IDs used= do not need to overlap with those in OSPF or ISIS. =C2=A0It would be good = to ensure that there's a reasonable

=

range in LDP for such purposes. =C2=A0LDP is one of th= e few mechanisms that easily lends itself to multi-topology forwarding.<= /u>

=C2=A0

Alia

=C2= =A0

P.S. =C2=A0Having the same values for mLDP and PIM may also be very useful= for interworking. =C2=A0PIM doesn't actually have an IANA

registry for MT-ID a= nd leaves the meaning of the values up to the network operator.

=C2=A0

On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel &l= t;adrian@olddog.co= .uk> wrote:

Hi authors,

Thanks for t= his document.

I have done my usual AD review which is intended to ca= tch any issues
that I see, and to smooth out the wrinkles before the I-D= goes to IETF
last call and IESG review.

As you will see below, I have a number of= editorial comments (nits and
larger changes) and also a few questions/i= ssues.

The biggest issue concerns the MT-ID and spans sections 3.4, = 3.8, and 9.
I suggest you read the comments against those sections all together.
Not= e that in my comment for section 9, I think I have worked out what
you n= eed to do, and so the resolution to the comments for 3.4 and 3.8
may sim= ply be documenting this change to the IANA registry.

As usual, all my comments are up for discussion, so please don't fe= el
you are required to make changes if you think there is a good reason = why
things are the way they are.

At the moment it looks like a ne= w revision will be needed to address the
review, so I have set the flag in the datatracker. Please work with yourdocument shepherd to produce and post a new revision.

Thanks,
Ad= rian

=3D=3D=3D

The document seems to end with a spurious page= header.

---

The index seems to be considerably adrift from reality.
I= n particular, there is no Appendix in this document.

---

Why = do you say that this updates RFC 4379? Is it your belief that an
impleme= ntation of RFC 4379 will not be complete/conformant without these
extensions? Or are you just defining extensions which an implementation
= in an MPLS-MT environment will need to support?

I note that you (in = my view, correctly) do not say that this document
updates RFC 5036, yet = it defines extensions to LDP in a similar way.

---

Please expand all acronyms on first use unless they show wit= h an
asterisk in the RFC Editor's list at
http:= //www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

I see:
CSP
LSP
QoS

---

Abstract and Introduction=

"IGP protocol" is bad because the "P" in "= IGP" is "protocol".

---

The RFC Editor prefers= documents to have the Introduction as Section 1.

You may prefer to make this change yourself, because it will possiblycause some expansions of terms and acronyms that the RFC Editor might
= so in a way you don't like.

---

In section 1, the term &q= uot;MT Topology" is odd because the "T" of "MT" stands for "Topology". Surely you don't mean "Multi Topo= logy Topology"?

---

Section 3.1

s/infers/implies/=

---

Section 3.2

I prefer that you don't repeat pr= otocol encodings that are defined
elsewhere. This can cause nasty problems if you make a mistake or if
the= original definition is updated.

It is enough for you to write...
=C2=A0 =C2=A0The LDP base specification [RFC5036] (Section 4.1) define= s the
=C2=A0 =C2=A0"Prefix" FEC Element. =C2=A0The "Prefix" e= ncoding is defined for a given
=C2=A0 =C2=A0"Address Family" (= AF), and has length (in bits) specified by the
=C2=A0 =C2=A0"PreLen= " field.

=C2=A0 =C2=A0To extend IP address families for MT, two= new Address Families named
=C2=A0 =C2=A0"MT IP" and "MT IPv6" are used to specify = IPv4 and IPv6 prefixes
=C2=A0 =C2=A0within a topology scope.

---<= br>
Section 3.2 Figure 2

This figure gives the impression that bo= th IPv4 and IPv6 addresses are
four bytes long!

I think you need:

=C2=A0 =C2=A0 =C2=A0 0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A0 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
=C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0~ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0~
=C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reserved =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0MT-ID =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 = =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fi= gure 2: MT IP Address Family Format

...and...

=C2=A0 =C2=A0Where "IP Address" is a variable length field pa= dded to a four octet
=C2=A0 =C2=A0boundary and containing an IPv4 or IPv= 6 address/prefix for the "MT
=C2=A0 =C2=A0IP" and "MT IPv= 6" AFs respectively. =C2=A0The field "MT-ID" corresponds to<= br> =C2=A0 =C2=A0the 16-bit Topology ID for given address.

...but you ne= ed to check I got that right!

However, before doing this work, see m= y comment on Section 3.3

---

Section 3.2

=C2=A0 =C2=A0= The proposed FEC Elements with "MT IP" Address Family can be used= in

You are not proposing any more, you are defining!

See also secti= on 3.6, 3.8, 4.1, 4.3, and 8

---

Section 3.2

=C2=A0 = =C2=A0[RFC5036] does not specify the handling of "Unknown" Addres= s
=C2=A0 =C2=A0Families. =C2=A0Therefore, [RFC5036] will need to be upda= ted to include
=C2=A0 =C2=A0the handling procedure for unknown address families.

Ou= ch!

This had me really worried because it implied that you are break= ing
existing LDP deployments. But I discussed it with Loa, and he pointe= d me
at Section 3.4.1.1 of RFC 5036

=C2=A0 =C2=A0"If in decoding a F= EC TLV an LSR encounters a FEC Element with an
=C2=A0 =C2=A0 Address Fam= ily it does not support, it SHOULD stop decoding the FEC
=C2=A0 =C2=A0 T= LV, abort processing the message containing the TLV, and send an
=C2=A0 =C2=A0 "Unsupported Address Family" Notification message t= o its LDP peer
=C2=A0 =C2=A0 signaling an error.

=C2=A0 =C2=A0 If= it encounters a FEC Element type it cannot decode, it SHOULD stop
=C2= =A0 =C2=A0 decoding the FEC TLV, abort processing the message containing th= e
=C2=A0 =C2=A0 TLV, and send an "Unknown FEC" Notification message= to its LDP peer
=C2=A0 =C2=A0 signaling an error."

So I thi= nk you can just delete this paragraph.

Furthermore, Section 3.5 defi= nes a capability advertisement that enables
you to know whether it is safe to use one of the new AFs. =C2=A0So surely y= ou
should also say "MUST NOT send an MT AF unless the peer has said= it can
handle it."

See my re-write in the next comment.
=
---

Section 3.3 appears to be repeating a lot of Section 3.2, but in= a
better and more concise way. For example, Figure 3 nicely shows how t= he
Prefix FEC element works with the new AFs.

This leads me to th= ink that Section 3.2 could be reduced to just a few
lines that say...

=C2=A0 =C2=A0The LDP base specification [RFC5036] = (Section 4.1) defines the
=C2=A0 =C2=A0the use of an "Address Famil= y" (AF) field in FEC Elements to indicate
=C2=A0 =C2=A0the encoding= of the "Prefix" or "Address" that follows, and to
=C2=A0 =C2=A0indicate how the FEC should be interpreted.

=C2=A0 =C2= =A0This document defines two new AF values named "MT IP" and &quo= t;MT IPv6"
=C2=A0 =C2=A0that are used to specify the use of IPv4 or= IPv6 within a topology
=C2=A0 =C2=A0scope. =C2=A0The data associated with these new AFs includes a= n "MT-ID"
=C2=A0 =C2=A0field that carries the 16-bit Topology = ID for a topology.

=C2=A0 =C2=A0The value of MT-ID=3D0 corresponds t= o default topology and MUST be
=C2=A0 =C2=A0ignored on receipt so as to not cause any conflict/confusion w= ith
=C2=A0 =C2=A0existing non-MT procedures.

=C2=A0 =C2=A0FEC Ele= ments with the new AFs can be used in any LDP message and
=C2=A0 =C2=A0p= rocedures that currently specify and allow the use of FEC Elements
=C2=A0 =C2=A0with the IP or IPv6 AFs, but MUST NOT be used unless the peer = has
=C2=A0 =C2=A0indicated it can handle them as described in Section 3.= 5. =C2=A0Note that
=C2=A0 =C2=A0behavior by an LDP speaker that receives= a FEC element containing an
=C2=A0 =C2=A0unknown AF is described in Section 3.4.1.1 of [RFC5036].
---

Section 3.4 is perfectly clear except it doesn't say what = "reserved",
"special", and "translating" m= ean.

This opens up a number of questions including why you need a registryat all. =C2=A0Presumably the "translation" needed is to ensure = that the
values used in LDP have the same meaning as they do in the IGP.= If that
is the case, why not simply use exactly the same value?

And looking = at the registry further, it seems to say that only values
allocated by I= ANA and stored in the registry can be used. That means
that an operator = that wants to use MT in their network cannot just
assign values to the MT-IDs for the topologies because the registry
has = no space for this to happen.

Now, it is possible that you have simpl= y used the wrong words in the
registry in section 9, and failed to provi= de any explanation in the
text. =C2=A0Note that "unassigned" means "not yet assigned, = but available
to be assigned by IANA". =C2=A0And "Reserved&quo= t; means "Do not assign until
a new RFC defines how they should be = used."

But there are other questions:

Why do you need 16 bits when ISIS= has only 12 bits and OSPF only 8 bits?
I guess 16 is convenient to hold= either, but how are the top 4 bits to
be handled?

How do you han= dle the case where there are multiple instances of an IGP
(or different IGPs) running?

If you *do* expect there to be a mappin= g function between IGP MT-ID and
LDP MT-ID, how do you ensure the same f= unction is used at both ends of
an LDP session?

But Section 3.8 r= eally does seem to say that only MT-IDs in the registry
are allowed, which seems to make this I-D almost useless because you
hav= e only defined "default" (which we have already), "ISIS IPv6= ", and
"all". Isn't an operator allowed to partition = their network into
topologies?

So...

I think what you need in Section 9 is...
=C2=A0 =C2=A0o =C2=A0New registry "LDP Multi-Topology (MT) ID Nam= e Space" under "LDP
=C2=A0 =C2=A0 =C2=A0 Parameter" names= pace. =C2=A0The allocation policies for this registry
=C2=A0 =C2=A0 =C2=A0 are:

=C2=A0 =C2=A0 =C2=A0 Range =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Registration Policy
=C2=A0 =C2=A0 =C2=A0 ------ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------
=C2=A0 =C2=A0 =C2=A0 = 0-3995 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expert Review
=C2=A0 =C2=A0 =C2= =A0 3996-4095 =C2=A0 =C2=A0 =C2=A0 Private Use
=C2=A0 =C2=A0 =C2=A0 4096= -4127 =C2=A0 =C2=A0 =C2=A0 Expert Review
=C2=A0 =C2=A0 =C2=A0 4128-4255 =C2=A0 =C2=A0 =C2=A0 Private Use
=C2=A0 = =C2=A0 =C2=A0 4256-4351 =C2=A0 =C2=A0 =C2=A0 Reserved (IANA does not assign= )
=C2=A0 =C2=A0 =C2=A0 4352-4511 =C2=A0 =C2=A0 =C2=A0 Expert Review
= =C2=A0 =C2=A0 =C2=A0 4512-65535 =C2=A0 =C2=A0 =C2=A0Private Use

=C2= =A0 =C2=A0 =C2=A0 IANA is requested to populate this registry as follows:

=C2=A0 =C2=A0 =C2=A0 Range/Value =C2=A0 =C2=A0Purpose =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 ----------- =C2= =A0 =C2=A0------------------------------------- =C2=A0 ---------
=C2=A0 = =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Default/sta= ndard topology in IS-IS =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4= in-band management in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2= =A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 ro= uting topology in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2= =A0 =C2=A0 =C2=A0 3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 mu= lticast topology in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2=A0 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6= multicast topology in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2= =A0 =C2=A0 =C2=A0 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 in= -band management in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 = =C2=A0 =C2=A0 6-3995 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unassigned (intended to mi= rror IS-IS)
=C2=A0 =C2=A0 =C2=A0 3996-4095 =C2=A0 =C2=A0 =C2=A0Reserved = for private use (from IS-IS) =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0 4096 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Default/standa= rd topology in OSPF =C2=A0 =C2=A0 =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0= 4097 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Default multicast topology in OSPF= =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2=A0 4098 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 IPv4 in-band management in OSPF =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0 4099-4127 =C2=A0 =C2=A0 =C2=A0Unassigned (intended to = mirror OSPF)
=C2=A0 =C2=A0 =C2=A0 4128-4255 =C2=A0 =C2=A0 =C2=A0Reserved= for private use (from OSPF) =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2= =A0 4256-4351 =C2=A0 =C2=A0 =C2=A0Reserved (IANA does not assign) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0 4352-4511 =C2=A0 = =C2=A0 =C2=A0Unassigned
=C2=A0 =C2=A0 =C2=A0 4512-65535 =C2=A0 =C2=A0 Reserved for Private Use =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]

This = would address many of the issues in Sections 3.4 and 3.8, and needs
to b= e discussed in those sections.

---

In Section 3.5

=C2=A0 =C2=A0o =C2=A0Length: The length (in octets) of TLV.

Are = you sure it is not just the length in octets of the value?
Compare with = RFC 5036 Section 3.3

---

Sections 3.5 and 3.6 need to be more= closely grouped.

Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2

= ---

Section 3.6

=C2=A0 =C2=A0To announce its MT capability fo= r an IP address family, LDP FEC type,
=C2=A0 =C2=A0and Multi Topology, a= n LDP speaker MAY send an "MT Capability"
=C2=A0 =C2=A0including the exact Typed Wildcard FEC element with correspond= ing
=C2=A0 =C2=A0"AddressFamily" field (i.e., set to "MT = IP" for IPv4 and set to "MT
=C2=A0 =C2=A0IPv6" for IPv6 a= ddress family), corresponding "FEC Type" field (i.e.,
=C2=A0 =C2=A0set to "P2P", "P2MP", "MP2MP"), = and corresponding "MT-ID". =C2=A0To
=C2=A0 =C2=A0announce its = MT capability for both IPv4 and IPv6 address family, or
=C2=A0 =C2=A0for= multiple FEC types, or for multiple Multi Topologies, an LDP
=C2=A0 =C2=A0speaker MAY send "MT Capability" with one or more MT= Typed FEC
=C2=A0 =C2=A0elements in it.

I don't think this is= "MAY" in either case. This *is* how the LDP
speaker announces= it. There is no other way to announce it. So...

=C2=A0 =C2=A0To announce its MT capability for an IP address family, LD= P FEC type,
=C2=A0 =C2=A0and Multi Topology, an LDP speaker sends an &qu= ot;MT Capability" including
=C2=A0 =C2=A0the exact Typed Wildcard F= EC element with corresponding
=C2=A0 =C2=A0"AddressFamily" field (i.e., set to "MT IP"= ; for IPv4 and set to "MT
=C2=A0 =C2=A0IPv6" for IPv6 address = family), corresponding "FEC Type" field (i.e.,
=C2=A0 =C2=A0se= t to "P2P", "P2MP", "MP2MP"), and correspondi= ng "MT-ID". =C2=A0To
=C2=A0 =C2=A0announce its MT capability for both IPv4 and IPv6 address fami= ly, or
=C2=A0 =C2=A0for multiple FEC types, or for multiple Multi Topolo= gies, an LDP
=C2=A0 =C2=A0speaker sends "MT Capability" with o= ne or more MT Typed FEC elements
=C2=A0 =C2=A0in it.

---

Section 3.6

=C2=A0 =C2=A0o =C2= =A0If an LSR has not advertised MT capability, its peer must not send
= =C2=A0 =C2=A0 =C2=A0 messages that include MT identifier to this LSR.
Isn't that "MUST NOT"?

---

Section 3.8

=C2=A0 =C2=A0Certain MT topologies are as= signed to serve predetermined purposes:

It is not the topology that = is assigned, but the MT-ID. Should read:

=C2=A0 =C2=A0Certain MT-ID = values are assigned to indicate specific meanings:

---

Section 3.8

It is not helpful to "propose" = numbers in this section and then to
also reference Section 9 for the def= initive numbers. =C2=A0I suggest you
remove all numbers from this sectio= n and simply point at Section 9.

---

Section 4.2

=C2=A0 =C2=A0This MAY allow an LDP speake= r to signal its IP convergence...

What does 2119 MAY mean in this co= ntext?

---

Section 4.3

=C2=A0 =C2=A0[RFC4379] defines = procedures to detect data-plane failures in MPLS
=C2=A0 =C2=A0LSPs via LSP ping. =C2=A0The specification defines a "Tar= get FEC Stack"
=C2=A0 =C2=A0TLV that describes the FEC stack being = tested.

Ha, ha! You got me :-)
s/The specification/That specifica= tion/

---

Section 4.3.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sub-Type =C2=A0 =C2= =A0 =C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Value Field
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------- =C2=A0 =C2=A0 =C2=A0 ------ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBA5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A05 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MT LDP IPv4 prefix
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBA6 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 17 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MT LDP IPv6 prefix
Are you sure you don't mean 8 and 20?

---

Section 4.3= .4

=C2=A0 =C2=A0When detect data plane failures using LSP Ping for a= specific topoly,
=C2=A0 =C2=A0the router will intiate an LSP Ping reque= st with the targer FEC stack

I think

s/When/To/

s/topoly/topology/

s/intiate/in= itiate/

s/targer/target/

---

Section 4.3.4

=C2= =A0 =C2=A0For the case that the LSP ping with return path not specified , t= he
=C2=A0 =C2=A0reply packet may go through the default topology instead= of the
=C2=A0 =C2=A0topology where the Echo Request goes through.

Is that r= eally "the default" or "any"?
If you mean "the = default" then I think you need some "MUST NOT" text to
ta= lk about other topologies.

---

Section 5

=C2=A0 =C2=A0The extensions defined in this= document utilise the existing LDP
=C2=A0 =C2=A0error handling defined i= n [RFC5036]. =C2=A0If an LSR receives an error
=C2=A0 =C2=A0notification= from a peer for an MPLS-MT session, it terminates the
=C2=A0 =C2=A0LDP session by closing the TCP transport connection for the se= ssion
=C2=A0 =C2=A0and discarding all MT-ID label mappings learned via t= he session.

There is nothing wrong with this text, but it does open = a question that
is not addressed anywhere in the document: what is the relationship
betw= een LDP sessions and MT-IDs? =C2=A01:1, 1:n, n:1, n:m?

This is somew= hat assumable from the discussion of multiple MT-ID
wildcard FEC element= s in the Multi-Topology Capability TLV, but it is
not explicit.

---

Shouldn't Section 6 comment on how each= of the new protocol elements
will not be seen by a legacy implementatio= n because they are only used
after successful capability negotiation?
But you do need to describe how a legacy node will react to attemptedMT capability negotiation.

You could also restate the reference to= RFC 5036 section 3.4.1.1 since
this issue seemed to be a question for y= ou.

---

I'm slightly doubtful about the value of Section 7, but = I note that the
point you are trying to convey is not quite worded corre= ctly. You have:

=C2=A0 =C2=A0and the specified
=C2=A0 =C2=A0signa= ling mechanisms do not provide any way for the data plane to
=C2=A0 =C2=A0associate a given packet with a context-specific label space.<= br>
I don't think the signaling mechanism is relevant, and I think &= quot;context-
specific" hides what you are trying to say. =C2=A0Per= haps you should have:

=C2=A0 =C2=A0and there is no way
=C2=A0 =C2=A0for the data plane to = associate a received packet with any one
=C2=A0 =C2=A0topology, meaning = that topology-specific label spaces cannot be used.

---

Secti= on 9

=C2=A0 =C2=A0o =C2=A0New Status Code: "Multi-Topology Capa= bility not supported"
=C2=A0 =C2=A0 =C2=A0 (requested code point: TBA2 from LDP registry "St= atus Code Name
=C2=A0 =C2=A0 =C2=A0 Space").

This status cod= e does not appear to be mentioned in the draft. How is
it used? Is an im= plementation that does not know the new MT Capability
TLV supposed to generate this status code? Or are you referencing an
exi= sting error code: in which case it should not appear in this section.
=C2=A0 =C2=A0o =C2=A0New Status Code: "Unknown Address Family" = (requested code point:
=C2=A0 =C2=A0 =C2=A0 TBA4 from LDP registry "Status Code Name Space&qu= ot;).

This status code does not appear to be mentioned in the draft.= How is
it used? Is a legacy implementation that does not know either of= your
new MT AFs supposed to generate this status code? But I suspect yo= u are
just referencing an existing error code (see Section 3.2) as defined in
= RFC 5036, and so you should not mention it in this section.

Figure 1= 0 does not show either of these status codes.

---

Figure 10 s= hows a specific value for the new status code. Is this a
request or demand? I don't think it has already been allocated.

= ---

Section 9

=C2=A0 =C2=A0o =C2=A0New registry "LDP Mul= ti-Topology (MT) ID Name Space" under "LDP
=C2=A0 =C2=A0 =C2= =A0 Parameter" namespace.

This registry is discussed earlier in my notes. but please be aware tha= t
you will need to define the allocation policy because it is a new
r= egistry.

---

Section 9

I want to ask Loa Andersson to = look again at the LSP Ping TLV
allocations to check that they conform to the work he is currently
doing= with that registry.

---

It would help considerably to add a = Manageability Considerations section
to this document because the functi= on being added here is not simple to
manage or operate, and will have impact on the way that the network is
r= un. Good guidance on such sections can be found in RFC 5706. Appendix A
= is particularly helpful at summarising things to consider.

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

_______________________________________________
mpls mailing listmpls@ietf.org
http= s://www.ietf.org/mailman/listinfo/mpls

=C2=A0


--047d7bd75244167ba804e09f6856-- From akatlas@gmail.com Wed Jul 3 11:35:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F111E81C5 for ; Wed, 3 Jul 2013 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFI0n2QCkWS4 for ; Wed, 3 Jul 2013 11:35:47 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF821F9D1E for ; Wed, 3 Jul 2013 11:35:46 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so1189336ief.26 for ; Wed, 03 Jul 2013 11:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b1cAD9dI5UnGw4gX3wfgp0tyfHRKS+Qic9nEeUO2+as=; b=BbdyYXVk+m8dQB8A5uzYWJC0WGwJFbIB33RRhGH3M1tYy9xyHzpiiLSqxX4hfPF74/ 6jvVqZ/2e7KGUtARE5lAcVwq37/rUq2nBfoXeEotu+7bLZZr5pgA/rVWRyYzr8L10Ly3 S0yyEjCPlEIXHgtB1v9fRcGWDdCPlExty2+F0ozc93ez89S3r0GgFXTjor3VPopeoNqA XRnmivVplYbkeQ9mjt1mIWU3PsLT/NCTY303sNnUki1L3zwBipSljtK+FjDd9HSSv4iU BJFpqcdUCD/cOIQvfUjbKIByAgQ8GMMehDYhyyo7jNb4DGtDZcnIIgvDW8PBYTEO1nEC eUCg== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr1298103icb.2.1372876545308; Wed, 03 Jul 2013 11:35:45 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Wed, 3 Jul 2013 11:35:45 -0700 (PDT) In-Reply-To: <00a701ce7649$da9bd920$8fd38b60$@olddog.co.uk> References: <00a701ce7649$da9bd920$8fd38b60$@olddog.co.uk> Date: Wed, 3 Jul 2013 14:35:45 -0400 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=bcaec511e1b6cdbde204e09fbac0 Cc: "mpls@ietf.org" , draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org, Quintin Zhao Subject: Re: [mpls] MT ID registry in draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 18:35:51 -0000 --bcaec511e1b6cdbde204e09fbac0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, I think, in general, that automatic mapping is quite reasonable. This makes even more sense given that the LDP range is 16 bits long, the OSPF range is 7 bits long, and the IS-IS and PIM ones are 4096 bits long. I have heard of networks running both IS-IS and OSPF on overlapping routers - and LDP would take from both. I don't have the use-case to hand (this was a while ago) - but I don't think it is extremely uncommon. Just consider merger cases... (though that's not where I heard of it). Alia On Mon, Jul 1, 2013 at 6:57 AM, Adrian Farrel wrote: > Hi all,**** > > ** ** > > I want to try to bring the two threads on the MT ID ranges for IANA back > together to try to understand what is being proposed and what is possible= . > **** > > ** ** > > First step is to recognise that the OSPF and ISIS registries exist and > already have numbers assigned from them. Thus we are not going to manage = to > converge the OSPF and ISIS MT IDs into a single registry with the same > meanings.**** > > ** ** > > Alia says "it'd be very useful to have that range specifically set aside > for cases where it matters that it be the same" but doesn't give a concre= te > example of such a case. **** > > ** ** > > Furthermore, I am not comfortable with the idea that both OSPF and ISIS > might be running at the same time, as is implied here, each distributing = a > different default topology, but with the two topologies being aggregated > for use by LDP. Perhaps I don't see the network that you are trying to > build and deploy, and a picture will help explain it.**** > > ** ** > > My "understanding" of the use case is that a single instance of a single > IGP runs in an area. That IGP may distribute information about multiple > routing topologies, each topology having an MT ID. LDP is also running in > the area and distributes labels based on the preferred routes in each > topology. Thus each label advertisement includes a FEC and an MT ID.**** > > ** ** > > In order to use the labels correctly, there must be a mapping between the > MT IDs used by the IGP, and those used by LDP.**** > > ** ** > > It is also possible that through network-wide configuration of policy on > the LDP implementations, LDP will use the information from the IGP and th= e > configured policy to formulate new and different MPLS-only topologies. > Thus, LDP might use an MT ID for its own special topology.**** > > ** ** > > There are two options:**** > > ** ** > > 1. Create a registry that is agnostic to the IGP in use (i.e. doesn't > indicate OSPF or ISIS) and which shows the use of the topology.**** > > 0 Default topology**** > > 1 IPv4 in-band management topology**** > > 2 IPv6 routing topology**** > > 3 IPv4 multicast routing topology**** > > 4 IPv6 multicast routing topology**** > > 5 IPv6 in-band management topology**** > > 6 - a Reserved for future IGP topologies (standards action)**** > > a+1 - b Reserved for IGP experimental topologies**** > > b+1 - c Reserved for LDP topologies (standards action)**** > > c+1 - d Reserved for LDP experimental topologies**** > > ** ** > > 2. Create a registry that is aware of the IGP in use and is built on the > existing OSPF and ISIS registries.**** > > This would be modelled on what I suggested before, but adding allocations > for LDP itself...**** > > ** ** > > 0 Default/standard topology in IS-IS**** > > 1 IPv4 in-band management in IS-IS **** > > 2 IPv6 routing topology in IS-IS **** > > 3 IPv4 multicast topology in IS-IS **** > > 4 IPv6 multicast topology in IS-IS **** > > 5 IPv6 in-band management in IS-IS **** > > 6-3995 Unassigned (intended to mirror IS-IS)**** > > 3996-4095 Reserved for private use (from IS-IS) **** > > 4096 Default/standard topology in OSPF **** > > 4097 Default multicast topology in OSPF **** > > 4098 IPv4 in-band management in OSPF **** > > 4099-4127 Unassigned (intended to mirror OSPF)**** > > 4128-4255 Reserved for private use (from OSPF)**** > > 4256-4351 Reserved (IANA does not assign) **** > > 4352-4511 Unassigned**** > > 4512-4607 LDP use (standards action)**** > > 4608-65531 Reserved for Private Use**** > > 64432-65535 Experimental use**** > > ** ** > > ** ** > > In all cases, my concern is what happens when a new IGP use is defined in > an RFC. It would appear that the LDP registry has to be updated to keep i= t > in synch.**** > > It is also unclear to me how we handle mapping an IGP private use into th= e > LDP private use.**** > > The intention of the scheme in the second option is to make that mapping > automatic so that when an MT ID is used in an IGP, we know how to map to > the LDP MT ID even if we don't understand the meaning of the IGP's MT ID.= * > *** > > ** ** > > It seems to me that what you might be asking for in your email is a singl= e > MT ID value that is the default topology used by LDP when it is based on > OSPF or ISIS default topology and does not want to indicate which it come= s > from. It that is the case, you could assign 4512 in option 2 for this > purpose.**** > > ** ** > > I am convinced that the solution to this problem is to work out what the > mapping algorithm is. How does an LDP implementation decide which MT ID t= o > use in a label advertisement? How does a packet-classifier decide which > label to use?**** > > ** ** > > The answer may be: "It is assumed that this mapping is manually configure= d > on every router"**** > > Or it may be: "There is an automatic mapping between IGP MT IDs and LDP M= T > IDs"**** > > Or it may be something else.**** > > ** ** > > Once the answer is agreed, making a registry will be easy.**** > > ** ** > > Cheers,**** > > Adrian**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Quintin Zhao > *Sent:* 28 June 2013 21:41 > *To:* 'Alia Atlas' > *Cc:* mpls@ietf.org; draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.or= g > *Subject:* Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology**** > > ** ** > > Hello Alia,**** > > ** ** > > Thanks for your review and suggestions.**** > > ** ** > > Indeed we need to allocate a MT ID range for the applications such as MRT > so that MT ID can be the same for OSPF, ISIS and LDP. **** > > ** ** > > We need decide how big this range should be for the applications such as > MRT. What is your recommendation for this range?**** > > ** ** > > This is what we have now from ISIS-MT(RFC5120):**** > > ** ** > > ** ** > > - MT ID #0: Equivalent to the "standard" topology.**** > > - MT ID #1: Reserved for IPv4 in-band management**** > > purposes.**** > > - MT ID #2: Reserved for IPv6 routing topology.**** > > - MT ID #3: Reserved for IPv4 multicast routing topology.***= * > > - MT ID #4: Reserved for IPv6 multicast routing topology.***= * > > - MT ID #5: Reserved for IPv6 in-band management**** > > purposes.**** > > - MT ID #6-#3995: Reserved for IETF consensus.**** > > - MT ID #3996-#4095: Reserved for development, experimental and**** > > proprietary features [RFC3692].**= * > * > > ** ** > > This is what have now from OSPF-MT(RFC4915)**** > > ** ** > > 0 - Reserved for advertising the metric associated**** > > with the default topology (see Section 4.2)**** > > 1 - Reserved for advertising the metric associated**** > > with the default multicast topology**** > > 2 - Reserved for IPv4 in-band management purposes**** > > 3-31 - Reserved for assignments by IANA**** > > 32-127 - Reserved for development, experimental and**** > > proprietary features [RFC3692]**** > > 128-255 - Invalid and SHOULD be ignored**** > > ** ** > > The range which is available for us to use is from 6 -127.**** > > ** ** > > Thanks,**** > > Quintin**** > > ** ** > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* 2013=E5=B9=B45=E6=9C=8829=E6=97=A5 8:52 > *To:* Adrian Farrel > *Cc:* draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; mpls@ietf.or= g > *Subject:* Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology**** > > ** ** > > Hi Adrian & authors,**** > > ** ** > > I have a couple comments on the IANA registry and number overlapping.**** > > ** ** > > First, it would be useful to have a range that is clearly intended to be > the same for OSPF, ISIS and LDP. Given the**** > > extremely limited range for OSPF multi-topology routing ( > http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of**= * > * > > 3-127, it'd be very useful to have that range specifically set aside for > cases where it matters that it be the same. **** > > ** ** > > One use that I see for this draft is for MRT, which is doing > multi-topology forwarding but not multi-topology routing. This means**** > > that the MT-IDs used do not need to overlap with those in OSPF or ISIS. > It would be good to ensure that there's a reasonable**** > > range in LDP for such purposes. LDP is one of the few mechanisms that > easily lends itself to multi-topology forwarding.**** > > ** ** > > Alia**** > > ** ** > > P.S. Having the same values for mLDP and PIM may also be very useful for > interworking. PIM doesn't actually have an IANA**** > > registry for MT-ID and leaves the meaning of the values up to the network > operator.**** > > ** ** > > On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel > wrote:**** > > Hi authors, > > Thanks for this document. > > I have done my usual AD review which is intended to catch any issues > that I see, and to smooth out the wrinkles before the I-D goes to IETF > last call and IESG review. > > As you will see below, I have a number of editorial comments (nits and > larger changes) and also a few questions/issues. > > The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. > I suggest you read the comments against those sections all together. > Note that in my comment for section 9, I think I have worked out what > you need to do, and so the resolution to the comments for 3.4 and 3.8 > may simply be documenting this change to the IANA registry. > > As usual, all my comments are up for discussion, so please don't feel > you are required to make changes if you think there is a good reason why > things are the way they are. > > At the moment it looks like a new revision will be needed to address the > review, so I have set the flag in the datatracker. Please work with your > document shepherd to produce and post a new revision. > > Thanks, > Adrian > > =3D=3D=3D > > The document seems to end with a spurious page header. > > --- > > The index seems to be considerably adrift from reality. > In particular, there is no Appendix in this document. > > --- > > Why do you say that this updates RFC 4379? Is it your belief that an > implementation of RFC 4379 will not be complete/conformant without these > extensions? Or are you just defining extensions which an implementation > in an MPLS-MT environment will need to support? > > I note that you (in my view, correctly) do not say that this document > updates RFC 5036, yet it defines extensions to LDP in a similar way. > > --- > > Please expand all acronyms on first use unless they show with an > asterisk in the RFC Editor's list at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > I see: > CSP > LSP > QoS > > --- > > Abstract and Introduction > > "IGP protocol" is bad because the "P" in "IGP" is "protocol". > > --- > > The RFC Editor prefers documents to have the Introduction as Section 1. > > You may prefer to make this change yourself, because it will possibly > cause some expansions of terms and acronyms that the RFC Editor might > so in a way you don't like. > > --- > > In section 1, the term "MT Topology" is odd because the "T" of "MT" > stands for "Topology". Surely you don't mean "Multi Topology Topology"? > > --- > > Section 3.1 > > s/infers/implies/ > > --- > > Section 3.2 > > I prefer that you don't repeat protocol encodings that are defined > elsewhere. This can cause nasty problems if you make a mistake or if > the original definition is updated. > > It is enough for you to write... > > The LDP base specification [RFC5036] (Section 4.1) defines the > "Prefix" FEC Element. The "Prefix" encoding is defined for a given > "Address Family" (AF), and has length (in bits) specified by the > "PreLen" field. > > To extend IP address families for MT, two new Address Families named > "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes > within a topology scope. > > --- > > Section 3.2 Figure 2 > > This figure gives the impression that both IPv4 and IPv6 addresses are > four bytes long! > > I think you need: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ IP Address ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | MT-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: MT IP Address Family Format > > ...and... > > Where "IP Address" is a variable length field padded to a four octet > boundary and containing an IPv4 or IPv6 address/prefix for the "MT > IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to > the 16-bit Topology ID for given address. > > ...but you need to check I got that right! > > However, before doing this work, see my comment on Section 3.3 > > --- > > Section 3.2 > > The proposed FEC Elements with "MT IP" Address Family can be used in > > You are not proposing any more, you are defining! > > See also section 3.6, 3.8, 4.1, 4.3, and 8 > > --- > > Section 3.2 > > [RFC5036] does not specify the handling of "Unknown" Address > Families. Therefore, [RFC5036] will need to be updated to include > the handling procedure for unknown address families. > > Ouch! > > This had me really worried because it implied that you are breaking > existing LDP deployments. But I discussed it with Loa, and he pointed me > at Section 3.4.1.1 of RFC 5036 > > "If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address Family it does not support, it SHOULD stop decoding the FEC > TLV, abort processing the message containing the TLV, and send an > "Unsupported Address Family" Notification message to its LDP peer > signaling an error. > > If it encounters a FEC Element type it cannot decode, it SHOULD stop > decoding the FEC TLV, abort processing the message containing the > TLV, and send an "Unknown FEC" Notification message to its LDP peer > signaling an error." > > So I think you can just delete this paragraph. > > Furthermore, Section 3.5 defines a capability advertisement that enables > you to know whether it is safe to use one of the new AFs. So surely you > should also say "MUST NOT send an MT AF unless the peer has said it can > handle it." > > See my re-write in the next comment. > > --- > > Section 3.3 appears to be repeating a lot of Section 3.2, but in a > better and more concise way. For example, Figure 3 nicely shows how the > Prefix FEC element works with the new AFs. > > This leads me to think that Section 3.2 could be reduced to just a few > lines that say... > > The LDP base specification [RFC5036] (Section 4.1) defines the > the use of an "Address Family" (AF) field in FEC Elements to indicate > the encoding of the "Prefix" or "Address" that follows, and to > indicate how the FEC should be interpreted. > > This document defines two new AF values named "MT IP" and "MT IPv6" > that are used to specify the use of IPv4 or IPv6 within a topology > scope. The data associated with these new AFs includes an "MT-ID" > field that carries the 16-bit Topology ID for a topology. > > The value of MT-ID=3D0 corresponds to default topology and MUST be > ignored on receipt so as to not cause any conflict/confusion with > existing non-MT procedures. > > FEC Elements with the new AFs can be used in any LDP message and > procedures that currently specify and allow the use of FEC Elements > with the IP or IPv6 AFs, but MUST NOT be used unless the peer has > indicated it can handle them as described in Section 3.5. Note that > behavior by an LDP speaker that receives a FEC element containing an > unknown AF is described in Section 3.4.1.1 of [RFC5036]. > > --- > > Section 3.4 is perfectly clear except it doesn't say what "reserved", > "special", and "translating" mean. > > This opens up a number of questions including why you need a registry > at all. Presumably the "translation" needed is to ensure that the > values used in LDP have the same meaning as they do in the IGP. If that > is the case, why not simply use exactly the same value? > > And looking at the registry further, it seems to say that only values > allocated by IANA and stored in the registry can be used. That means > that an operator that wants to use MT in their network cannot just > assign values to the MT-IDs for the topologies because the registry > has no space for this to happen. > > Now, it is possible that you have simply used the wrong words in the > registry in section 9, and failed to provide any explanation in the > text. Note that "unassigned" means "not yet assigned, but available > to be assigned by IANA". And "Reserved" means "Do not assign until > a new RFC defines how they should be used." > > But there are other questions: > > Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? > I guess 16 is convenient to hold either, but how are the top 4 bits to > be handled? > > How do you handle the case where there are multiple instances of an IGP > (or different IGPs) running? > > If you *do* expect there to be a mapping function between IGP MT-ID and > LDP MT-ID, how do you ensure the same function is used at both ends of > an LDP session? > > But Section 3.8 really does seem to say that only MT-IDs in the registry > are allowed, which seems to make this I-D almost useless because you > have only defined "default" (which we have already), "ISIS IPv6", and > "all". Isn't an operator allowed to partition their network into > topologies? > > So... > > I think what you need in Section 9 is... > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. The allocation policies for this registry > are: > > Range Registration Policy > ------ ------------------- > 0-3995 Expert Review > 3996-4095 Private Use > 4096-4127 Expert Review > 4128-4255 Private Use > 4256-4351 Reserved (IANA does not assign) > 4352-4511 Expert Review > 4512-65535 Private Use > > IANA is requested to populate this registry as follows: > > > Range/Value Purpose Reference > ----------- ------------------------------------- --------- > 0 Default/standard topology in IS-IS [This.I-D] > 1 IPv4 in-band management in IS-IS [This.I-D] > 2 IPv6 routing topology in IS-IS [This.I-D] > 3 IPv4 multicast topology in IS-IS [This.I-D] > 4 IPv6 multicast topology in IS-IS [This.I-D] > 5 IPv6 in-band management in IS-IS [This.I-D] > 6-3995 Unassigned (intended to mirror IS-IS) > 3996-4095 Reserved for private use (from IS-IS) [This.I-D] > 4096 Default/standard topology in OSPF [This.I-D] > 4097 Default multicast topology in OSPF [This.I-D] > 4098 IPv4 in-band management in OSPF [This.I-D] > 4099-4127 Unassigned (intended to mirror OSPF) > 4128-4255 Reserved for private use (from OSPF) [This.I-D] > 4256-4351 Reserved (IANA does not assign) [This.I-D] > 4352-4511 Unassigned > 4512-65535 Reserved for Private Use [This.I-D] > > This would address many of the issues in Sections 3.4 and 3.8, and needs > to be discussed in those sections. > > --- > > In Section 3.5 > > o Length: The length (in octets) of TLV. > > Are you sure it is not just the length in octets of the value? > Compare with RFC 5036 Section 3.3 > > --- > > Sections 3.5 and 3.6 need to be more closely grouped. > > Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 > > --- > > Section 3.6 > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker MAY send an "MT Capability" > including the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker MAY send "MT Capability" with one or more MT Typed FEC > elements in it. > > I don't think this is "MAY" in either case. This *is* how the LDP > speaker announces it. There is no other way to announce it. So... > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker sends an "MT Capability" including > the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker sends "MT Capability" with one or more MT Typed FEC elements > in it. > > --- > > Section 3.6 > > o If an LSR has not advertised MT capability, its peer must not send > messages that include MT identifier to this LSR. > > Isn't that "MUST NOT"? > > --- > > Section 3.8 > > Certain MT topologies are assigned to serve predetermined purposes: > > It is not the topology that is assigned, but the MT-ID. Should read: > > Certain MT-ID values are assigned to indicate specific meanings: > > --- > > Section 3.8 > > It is not helpful to "propose" numbers in this section and then to > also reference Section 9 for the definitive numbers. I suggest you > remove all numbers from this section and simply point at Section 9. > > --- > > Section 4.2 > > This MAY allow an LDP speaker to signal its IP convergence... > > What does 2119 MAY mean in this context? > > --- > > Section 4.3 > > [RFC4379] defines procedures to detect data-plane failures in MPLS > LSPs via LSP ping. The specification defines a "Target FEC Stack" > TLV that describes the FEC stack being tested. > > Ha, ha! You got me :-) > s/The specification/That specification/ > > --- > > Section 4.3.1 > > Sub-Type Length Value Field > -------- ------ ----------------- > TBA5 5 MT LDP IPv4 prefix > TBA6 17 MT LDP IPv6 prefix > > Are you sure you don't mean 8 and 20? > > --- > > Section 4.3.4 > > When detect data plane failures using LSP Ping for a specific topoly, > the router will intiate an LSP Ping request with the targer FEC stack > > I think > > s/When/To/ > > s/topoly/topology/ > > s/intiate/initiate/ > > s/targer/target/ > > --- > > Section 4.3.4 > > For the case that the LSP ping with return path not specified , the > reply packet may go through the default topology instead of the > topology where the Echo Request goes through. > > Is that really "the default" or "any"? > If you mean "the default" then I think you need some "MUST NOT" text to > talk about other topologies. > > --- > > Section 5 > > The extensions defined in this document utilise the existing LDP > error handling defined in [RFC5036]. If an LSR receives an error > notification from a peer for an MPLS-MT session, it terminates the > LDP session by closing the TCP transport connection for the session > and discarding all MT-ID label mappings learned via the session. > > There is nothing wrong with this text, but it does open a question that > is not addressed anywhere in the document: what is the relationship > between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? > > This is somewhat assumable from the discussion of multiple MT-ID > wildcard FEC elements in the Multi-Topology Capability TLV, but it is > not explicit. > > --- > > Shouldn't Section 6 comment on how each of the new protocol elements > will not be seen by a legacy implementation because they are only used > after successful capability negotiation? > > But you do need to describe how a legacy node will react to attempted > MT capability negotiation. > > You could also restate the reference to RFC 5036 section 3.4.1.1 since > this issue seemed to be a question for you. > > --- > > I'm slightly doubtful about the value of Section 7, but I note that the > point you are trying to convey is not quite worded correctly. You have: > > and the specified > signaling mechanisms do not provide any way for the data plane to > associate a given packet with a context-specific label space. > > I don't think the signaling mechanism is relevant, and I think "context- > specific" hides what you are trying to say. Perhaps you should have: > > and there is no way > for the data plane to associate a received packet with any one > topology, meaning that topology-specific label spaces cannot be used. > > --- > > Section 9 > > o New Status Code: "Multi-Topology Capability not supported" > (requested code point: TBA2 from LDP registry "Status Code Name > Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is an implementation that does not know the new MT Capability > TLV supposed to generate this status code? Or are you referencing an > existing error code: in which case it should not appear in this section. > > o New Status Code: "Unknown Address Family" (requested code point: > TBA4 from LDP registry "Status Code Name Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is a legacy implementation that does not know either of your > new MT AFs supposed to generate this status code? But I suspect you are > just referencing an existing error code (see Section 3.2) as defined in > RFC 5036, and so you should not mention it in this section. > > Figure 10 does not show either of these status codes. > > --- > > Figure 10 shows a specific value for the new status code. Is this a > request or demand? I don't think it has already been allocated. > > --- > > Section 9 > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. > > This registry is discussed earlier in my notes. but please be aware that > you will need to define the allocation policy because it is a new > registry. > > --- > > Section 9 > > I want to ask Loa Andersson to look again at the LSP Ping TLV > allocations to check that they conform to the work he is currently > doing with that registry. > > --- > > It would help considerably to add a Manageability Considerations section > to this document because the function being added here is not simple to > manage or operate, and will have impact on the way that the network is > run. Good guidance on such sections can be found in RFC 5706. Appendix A > is particularly helpful at summarising things to consider. > > -------------------- > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > --bcaec511e1b6cdbde204e09fbac0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

I think, in general, that au= tomatic mapping is quite reasonable. =C2=A0This makes even more sense given= that the LDP range is 16 bits long, the OSPF range is 7 bits long, and the= IS-IS and PIM ones are 4096 bits long.

I have heard of networks running both IS-IS and OSPF on= overlapping routers - and LDP would take from both. =C2=A0I don't have= the use-case to hand (this was a while ago) - but I don't think it is = extremely uncommon. =C2=A0Just consider merger cases... (though that's = not where I heard of it).

Alia
On Mon, Jul 1, 2013 at 6:57 AM, Adrian Farrel <= span dir=3D"ltr"><adrian@olddog.c= o.uk> wrote:

Hi all,

=C2=A0

I want to try to br= ing the two threads on the MT ID ranges for IANA back together to try to un= derstand what is being proposed and what is possible.<= /p>

=C2=A0

First step is to re= cognise that the OSPF and ISIS registries exist and already have numbers as= signed from them. Thus we are not going to manage to converge the OSPF and = ISIS MT IDs into a single registry with the same meanings.

=C2=A0

Alia says "it&= #39;d be very useful to have that range specifically set aside for cases wh= ere it matters that it be the same" but doesn't give a concrete ex= ample of such a case.

=C2=A0

Furthermore, I am n= ot comfortable with the idea that both OSPF and ISIS might be running at th= e same time, as is implied here, each distributing a different default topo= logy, but with the two topologies being aggregated for use by LDP. Perhaps = I don't see the network that you are trying to build and deploy, and a = picture will help explain it.

=C2=A0

My "understand= ing" of the use case is that a single instance of a single IGP runs in= an area. That IGP may distribute information about multiple routing topolo= gies, each topology having an MT ID. LDP is also running in the area and di= stributes labels based on the preferred routes in each topology. Thus each = label advertisement includes a FEC and an MT ID.

=C2=A0

In order to use the= labels correctly, there must be a mapping between the MT IDs used by the I= GP, and those used by LDP.

=C2=A0

It is also possible= that through network-wide configuration of policy on the LDP implementatio= ns, LDP will use the information from the IGP and the configured policy to = formulate new and different MPLS-only topologies. Thus, LDP might use an MT= ID for its own special topology.

=C2=A0

There are two optio= ns:

=C2=A0

1. Create a registr= y that is agnostic to the IGP in use (i.e. doesn't indicate OSPF or ISI= S) and which shows the use of the topology.

=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Default topology

=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0IPv4 in-band management topo= logy

=C2=A0 =C2=A02=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IPv6 routing top= ology

=C2=A0=C2=A0 3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0IPv4 multicast routing topol= ogy

=C2=A0=C2=A0 4=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0IPv6 multicast routing topol= ogy

=C2=A0=C2=A0 5=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0IPv6 in-band management topo= logy

=C2=A0=C2=A0 6 - a=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0Reserved for= future IGP topologies (standards action)

=C2=A0=C2=A0 a+1 - b Reserved for IGP experimental topologies

<= p class=3D"MsoNormal"> =C2=A0=C2=A0 b+1 - c Reserved for L= DP topologies (standards action)

=C2=A0=C2=A0 c+1 - d Reserved = for LDP experimental topologies

=C2=A0

2. Create a registr= y that is aware of the IGP in use and is built on the existing OSPF and ISI= S registries.

This would be modelled on= what I suggested before, but adding allocations for LDP itself...

=C2=A0

=C2=A0=C2=A0= =C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Default/standard topology in IS= -IS

=C2=A0=C2=A0=C2=A0= =C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IPv4 in-band management in IS-IS= =C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A02=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IPv6 routing topology in IS-IS=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A03=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IPv4 multicast topology in IS-IS<= span>=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A04=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0IPv6 multicast topology in IS-I= S=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A05=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IPv6 in-band management in IS= -IS

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A06-3995=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0Unassigned (inten= ded to mirror IS-IS)

=C2=A0=C2=A0=C2=A0= =C2=A0 3996-4095=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for p= rivate use (from IS-IS)

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A04096=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Default/standard topology in OSPF

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A04097=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Default multicast topology in OSPF

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A04098 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0IPv4 in-ba= nd management in OSPF=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A04099-4127=C2=A0=C2=A0=C2=A0 =C2=A0Unassigned (intended to mirror OSPF)

=C2=A0=C2=A0=C2=A0= =C2=A0 4128-4255=C2=A0=C2=A0 =C2=A0=C2=A0R= eserved for private use (from OSPF)

=C2=A0=C2=A0=C2=A0= =C2=A0 4256-4351=C2=A0=C2=A0 =C2=A0=C2=A0R= eserved (IANA does not assign)=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A04352-4511=C2=A0 =C2=A0=C2=A0=C2=A0Unassigned

=C2=A0=C2=A0=C2=A0=C2=A0 4512-4607<= span>=C2=A0=C2=A0=C2=A0=C2=A0 LDP use (standards action)

=C2=A0= =C2=A0=C2=A0=C2=A0 4608-65531=C2=A0 =C2=A0= Reserved for Private Use

=C2=A0=C2=A0=C2=A0= =C2=A0 64432-65535 Experimental use

=C2=A0

=C2=A0

In all cases, my co= ncern is what happens when a new IGP use is defined in an RFC. It would app= ear that the LDP registry has to be updated to keep it in synch.<= /u>

It is also unclear to me = how we handle mapping an IGP private use into the LDP private use.

The intention of the sche= me in the second option is to make that mapping automatic so that when an M= T ID is used in an IGP, we know how to map to the LDP MT ID even if we don&= #39;t understand the meaning of the IGP's MT ID.

=C2=A0

It seems to me that= what you might be asking for in your email is a single MT ID value that is= the default topology used by LDP when it is based on OSPF or ISIS default = topology and does not want to indicate which it comes from. It that is the = case, you could assign 4512 in option 2 for this purpose.

=C2=A0

I am convinced that= the solution to this problem is to work out what the mapping algorithm is.= How does an LDP implementation decide which MT ID to use in a label advert= isement? How does a packet-classifier decide which label to use?<= /u>

=C2=A0

The answer may be: = "It is assumed that this mapping is manually configured on every route= r"

Or it may be: "There= is an automatic mapping between IGP MT IDs and LDP MT IDs"<= /u>

Or it may be something el= se.

=C2=A0

Once the answer is agreed= , making a registry will be easy.

=C2=A0

Cheers,

Adrian

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Quintin Zhao
Sent: 28 June 2013 21:41
To: 'Alia Atlas'
Cc= : mpls@ietf.org; draft-ietf-mpls-ldp= -multi-topology.all@tools.ietf.org
Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology<= u>

=C2=A0=

Hello Alia,<= u>

=C2=A0=

Thanks for your review = and suggestions.

=C2=A0=

Indeed we need to alloc= ate a MT ID range for the applications such as MRT so that MT ID can be the= same for OSPF, ISIS and LDP.

=C2=A0=

We need decide how big = this range should be for the applications such as MRT. What is your recomme= ndation for this range?

=C2=A0=

This is what we have no= w from ISIS-MT(RFC5120):

=C2=A0=

=C2=A0

=C2=A0=C2=A0 -=C2=A0 MT ID = #0:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Equivalent to the= "standard" topology.

=C2=A0=C2=A0 -=C2=A0 MT ID #1:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv4 in-band management

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0purposes.

=C2=A0=C2=A0 -=C2=A0 MT ID = #2:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv6= routing topology.

=C2=A0=C2=A0 -=C2=A0 MT ID #3:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv4 multicast routing to= pology.

=C2=A0=C2=A0 -=C2=A0 MT ID #4:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Reserved for IPv6 multicast routing topology.=

=C2=A0=C2=A0 -=C2=A0 MT ID = #5:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved for IPv6= in-band management

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0purpo= ses.

=C2=A0=C2=A0 -=C2=A0 MT ID #6-#3995:=C2=A0=C2=A0=C2=A0 Reserved for IETF = consensus.

=C2=A0=C2=A0 -=C2=A0 MT ID = #3996-#4095: Reserved for development, experimental and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0proprietary features [RFC3692].

= =C2=A0

This is what have now from = OSPF-MT(RFC4915)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - R= eserved for advertising the metric associated

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wi= th the default topology (see Section 4.2)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Reserve= d for advertising the metric associated

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 with the default multicast topology=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - Reserved for IPv4 in-band management purposes

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3-31=C2=A0=C2=A0=C2=A0 - Reserved for ass= ignments by IANA

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 32-127=C2=A0 - Reserved for development, experimental and

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 proprietary features [RFC3692]

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 128-255 - Invalid and SHOULD be ignored

=C2=A0=

The range which is avai= lable for us to use is from 6 -127.

=C2=A0

Thanks,=

Quintin

=C2=A0

From:<= /b> Alia Atlas [mailto:akatlas@gmail.com]
Sent: 2013=E5=B9=B45=E6=9C=88= 29=E6=97=A5 8:5= 2
To: Adrian Farrel
Cc: draft-ietf-mpls-ldp-multi-topology.all= @tools.ietf.org; mpls@ietf.org
Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology<= u>

<= u>=C2=A0

Hi Adrian & authors,

=C2=A0

I have a couple= comments on the IANA registry and number overlapping.=

=C2=A0

First, it would= be useful to have a range that is clearly intended to be the same for OSPF= , ISIS and LDP. =C2=A0Given the

extremely limited ra= nge for OSPF multi-topology routing (http://www.iana.org/assignments/o= spf-mt-routing/ospf-mt-routing.xml) of

3-127, it'd be v= ery useful to have that range specifically set aside for cases where it mat= ters that it be the same.=C2=A0

=C2=A0

One use that I see for this draft is for MR= T, which is doing multi-topology forwarding but not multi-topology routing.= =C2=A0This means

that the MT-IDs used= do not need to overlap with those in OSPF or ISIS. =C2=A0It would be good = to ensure that there's a reasonable

=

range in LDP for such purposes. =C2=A0LDP is one of th= e few mechanisms that easily lends itself to multi-topology forwarding.<= /u>

=C2=A0

Alia

=C2= =A0

P.S. =C2=A0Having the same values for mLDP and PIM may also be very useful= for interworking. =C2=A0PIM doesn't actually have an IANA

registry for MT-ID a= nd leaves the meaning of the values up to the network operator.

=C2=A0

On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel &l= t;adrian@olddog.co.uk> wrote:=

Hi authors,

Thanks for t= his document.

I have done my usual AD review which is intended to ca= tch any issues
that I see, and to smooth out the wrinkles before the I-D= goes to IETF
last call and IESG review.

As you will see below, I have a number of= editorial comments (nits and
larger changes) and also a few questions/i= ssues.

The biggest issue concerns the MT-ID and spans sections 3.4, = 3.8, and 9.
I suggest you read the comments against those sections all together.
Not= e that in my comment for section 9, I think I have worked out what
you n= eed to do, and so the resolution to the comments for 3.4 and 3.8
may sim= ply be documenting this change to the IANA registry.

As usual, all my comments are up for discussion, so please don't fe= el
you are required to make changes if you think there is a good reason = why
things are the way they are.

At the moment it looks like a ne= w revision will be needed to address the
review, so I have set the flag in the datatracker. Please work with yourdocument shepherd to produce and post a new revision.

Thanks,
Ad= rian

=3D=3D=3D

The document seems to end with a spurious page= header.

---

The index seems to be considerably adrift from reality.
I= n particular, there is no Appendix in this document.

---

Why = do you say that this updates RFC 4379? Is it your belief that an
impleme= ntation of RFC 4379 will not be complete/conformant without these
extensions? Or are you just defining extensions which an implementation
= in an MPLS-MT environment will need to support?

I note that you (in = my view, correctly) do not say that this document
updates RFC 5036, yet = it defines extensions to LDP in a similar way.

---

Please expand all acronyms on first use unless they show wit= h an
asterisk in the RFC Editor's list at
http://www.rfc-editor.o= rg/rfc-style-guide/abbrev.expansion.txt

I see:
CSP
LSP
QoS

---

Abstract and Introduction=

"IGP protocol" is bad because the "P" in "= IGP" is "protocol".

---

The RFC Editor prefers= documents to have the Introduction as Section 1.

You may prefer to make this change yourself, because it will possiblycause some expansions of terms and acronyms that the RFC Editor might
= so in a way you don't like.

---

In section 1, the term &q= uot;MT Topology" is odd because the "T" of "MT" stands for "Topology". Surely you don't mean "Multi Topo= logy Topology"?

---

Section 3.1

s/infers/implies/=

---

Section 3.2

I prefer that you don't repeat pr= otocol encodings that are defined
elsewhere. This can cause nasty problems if you make a mistake or if
the= original definition is updated.

It is enough for you to write...
=C2=A0 =C2=A0The LDP base specification [RFC5036] (Section 4.1) define= s the
=C2=A0 =C2=A0"Prefix" FEC Element. =C2=A0The "Prefix" e= ncoding is defined for a given
=C2=A0 =C2=A0"Address Family" (= AF), and has length (in bits) specified by the
=C2=A0 =C2=A0"PreLen= " field.

=C2=A0 =C2=A0To extend IP address families for MT, two= new Address Families named
=C2=A0 =C2=A0"MT IP" and "MT IPv6" are used to specify = IPv4 and IPv6 prefixes
=C2=A0 =C2=A0within a topology scope.

---<= br>
Section 3.2 Figure 2

This figure gives the impression that bo= th IPv4 and IPv6 addresses are
four bytes long!

I think you need:

=C2=A0 =C2=A0 =C2=A0 0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A0 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
=C2=A0 =C2=A0 = =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0~ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 IP Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0~
=C2= =A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reserved= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0MT-= ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Figure 2: MT IP Address Family Format

...and...

= =C2=A0 =C2=A0Where "IP Address" is a variable length field padded= to a four octet
=C2=A0 =C2=A0boundary and containing an IPv4 or IPv6 address/prefix for the= "MT
=C2=A0 =C2=A0IP" and "MT IPv6" AFs respectively= . =C2=A0The field "MT-ID" corresponds to
=C2=A0 =C2=A0the 16-b= it Topology ID for given address.

...but you need to check I got that right!

However, before doing= this work, see my comment on Section 3.3

---

Section 3.2
=
=C2=A0 =C2=A0The proposed FEC Elements with "MT IP" Address F= amily can be used in

You are not proposing any more, you are defining!

See also secti= on 3.6, 3.8, 4.1, 4.3, and 8

---

Section 3.2

=C2=A0 = =C2=A0[RFC5036] does not specify the handling of "Unknown" Addres= s
=C2=A0 =C2=A0Families. =C2=A0Therefore, [RFC5036] will need to be upda= ted to include
=C2=A0 =C2=A0the handling procedure for unknown address families.

Ou= ch!

This had me really worried because it implied that you are break= ing
existing LDP deployments. But I discussed it with Loa, and he pointe= d me
at Section 3.4.1.1 of RFC 5036

=C2=A0 =C2=A0"If in decoding a F= EC TLV an LSR encounters a FEC Element with an
=C2=A0 =C2=A0 Address Fam= ily it does not support, it SHOULD stop decoding the FEC
=C2=A0 =C2=A0 T= LV, abort processing the message containing the TLV, and send an
=C2=A0 =C2=A0 "Unsupported Address Family" Notification message t= o its LDP peer
=C2=A0 =C2=A0 signaling an error.

=C2=A0 =C2=A0 If= it encounters a FEC Element type it cannot decode, it SHOULD stop
=C2= =A0 =C2=A0 decoding the FEC TLV, abort processing the message containing th= e
=C2=A0 =C2=A0 TLV, and send an "Unknown FEC" Notification message= to its LDP peer
=C2=A0 =C2=A0 signaling an error."

So I thi= nk you can just delete this paragraph.

Furthermore, Section 3.5 defi= nes a capability advertisement that enables
you to know whether it is safe to use one of the new AFs. =C2=A0So surely y= ou
should also say "MUST NOT send an MT AF unless the peer has said= it can
handle it."

See my re-write in the next comment.
=
---

Section 3.3 appears to be repeating a lot of Section 3.2, but in= a
better and more concise way. For example, Figure 3 nicely shows how t= he
Prefix FEC element works with the new AFs.

This leads me to th= ink that Section 3.2 could be reduced to just a few
lines that say...

=C2=A0 =C2=A0The LDP base specification [RFC5036] = (Section 4.1) defines the
=C2=A0 =C2=A0the use of an "Address Famil= y" (AF) field in FEC Elements to indicate
=C2=A0 =C2=A0the encoding= of the "Prefix" or "Address" that follows, and to
=C2=A0 =C2=A0indicate how the FEC should be interpreted.

=C2=A0 =C2= =A0This document defines two new AF values named "MT IP" and &quo= t;MT IPv6"
=C2=A0 =C2=A0that are used to specify the use of IPv4 or= IPv6 within a topology
=C2=A0 =C2=A0scope. =C2=A0The data associated with these new AFs includes a= n "MT-ID"
=C2=A0 =C2=A0field that carries the 16-bit Topology = ID for a topology.

=C2=A0 =C2=A0The value of MT-ID=3D0 corresponds t= o default topology and MUST be
=C2=A0 =C2=A0ignored on receipt so as to not cause any conflict/confusion w= ith
=C2=A0 =C2=A0existing non-MT procedures.

=C2=A0 =C2=A0FEC Ele= ments with the new AFs can be used in any LDP message and
=C2=A0 =C2=A0p= rocedures that currently specify and allow the use of FEC Elements
=C2=A0 =C2=A0with the IP or IPv6 AFs, but MUST NOT be used unless the peer = has
=C2=A0 =C2=A0indicated it can handle them as described in Section 3.= 5. =C2=A0Note that
=C2=A0 =C2=A0behavior by an LDP speaker that receives= a FEC element containing an
=C2=A0 =C2=A0unknown AF is described in Section 3.4.1.1 of [RFC5036].
---

Section 3.4 is perfectly clear except it doesn't say what = "reserved",
"special", and "translating" m= ean.

This opens up a number of questions including why you need a registryat all. =C2=A0Presumably the "translation" needed is to ensure = that the
values used in LDP have the same meaning as they do in the IGP.= If that
is the case, why not simply use exactly the same value?

And looking = at the registry further, it seems to say that only values
allocated by I= ANA and stored in the registry can be used. That means
that an operator = that wants to use MT in their network cannot just
assign values to the MT-IDs for the topologies because the registry
has = no space for this to happen.

Now, it is possible that you have simpl= y used the wrong words in the
registry in section 9, and failed to provi= de any explanation in the
text. =C2=A0Note that "unassigned" means "not yet assigned, = but available
to be assigned by IANA". =C2=A0And "Reserved&quo= t; means "Do not assign until
a new RFC defines how they should be = used."

But there are other questions:

Why do you need 16 bits when ISIS= has only 12 bits and OSPF only 8 bits?
I guess 16 is convenient to hold= either, but how are the top 4 bits to
be handled?

How do you han= dle the case where there are multiple instances of an IGP
(or different IGPs) running?

If you *do* expect there to be a mappin= g function between IGP MT-ID and
LDP MT-ID, how do you ensure the same f= unction is used at both ends of
an LDP session?

But Section 3.8 r= eally does seem to say that only MT-IDs in the registry
are allowed, which seems to make this I-D almost useless because you
hav= e only defined "default" (which we have already), "ISIS IPv6= ", and
"all". Isn't an operator allowed to partition = their network into
topologies?

So...

I think what you need in Section 9 is...
=C2=A0 =C2=A0o =C2=A0New registry "LDP Multi-Topology (MT) ID Nam= e Space" under "LDP
=C2=A0 =C2=A0 =C2=A0 Parameter" names= pace. =C2=A0The allocation policies for this registry
=C2=A0 =C2=A0 =C2=A0 are:

=C2=A0 =C2=A0 =C2=A0 Range =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Registration Policy
=C2=A0 =C2=A0 =C2=A0 ------ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------
=C2=A0 =C2=A0 =C2=A0 = 0-3995 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expert Review
=C2=A0 =C2=A0 =C2= =A0 3996-4095 =C2=A0 =C2=A0 =C2=A0 Private Use
=C2=A0 =C2=A0 =C2=A0 4096= -4127 =C2=A0 =C2=A0 =C2=A0 Expert Review
=C2=A0 =C2=A0 =C2=A0 4128-4255 =C2=A0 =C2=A0 =C2=A0 Private Use
=C2=A0 = =C2=A0 =C2=A0 4256-4351 =C2=A0 =C2=A0 =C2=A0 Reserved (IANA does not assign= )
=C2=A0 =C2=A0 =C2=A0 4352-4511 =C2=A0 =C2=A0 =C2=A0 Expert Review
= =C2=A0 =C2=A0 =C2=A0 4512-65535 =C2=A0 =C2=A0 =C2=A0Private Use

=C2= =A0 =C2=A0 =C2=A0 IANA is requested to populate this registry as follows:

=C2=A0 =C2=A0 =C2=A0 Range/Value =C2=A0 =C2=A0Purpose =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 ----------- =C2= =A0 =C2=A0------------------------------------- =C2=A0 ---------
=C2=A0 = =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Default/sta= ndard topology in IS-IS =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4= in-band management in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2= =A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 ro= uting topology in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2= =A0 =C2=A0 =C2=A0 3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 mu= lticast topology in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2=A0 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6= multicast topology in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2= =A0 =C2=A0 =C2=A0 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 in= -band management in IS-IS =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 = =C2=A0 =C2=A0 6-3995 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unassigned (intended to mi= rror IS-IS)
=C2=A0 =C2=A0 =C2=A0 3996-4095 =C2=A0 =C2=A0 =C2=A0Reserved = for private use (from IS-IS) =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0 4096 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Default/standa= rd topology in OSPF =C2=A0 =C2=A0 =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0= 4097 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Default multicast topology in OSPF= =C2=A0 =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2=A0 4098 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 IPv4 in-band management in OSPF =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0 4099-4127 =C2=A0 =C2=A0 =C2=A0Unassigned (intended to = mirror OSPF)
=C2=A0 =C2=A0 =C2=A0 4128-4255 =C2=A0 =C2=A0 =C2=A0Reserved= for private use (from OSPF) =C2=A0 =C2=A0[This.I-D]
=C2=A0 =C2=A0 =C2= =A0 4256-4351 =C2=A0 =C2=A0 =C2=A0Reserved (IANA does not assign) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [This.I-D]
=C2=A0 =C2=A0 =C2=A0 4352-4511 =C2=A0 = =C2=A0 =C2=A0Unassigned
=C2=A0 =C2=A0 =C2=A0 4512-65535 =C2=A0 =C2=A0 Reserved for Private Use =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[This.I-D]

This = would address many of the issues in Sections 3.4 and 3.8, and needs
to b= e discussed in those sections.

---

In Section 3.5

=C2=A0 =C2=A0o =C2=A0Length: The length (in octets) of TLV.

Are = you sure it is not just the length in octets of the value?
Compare with = RFC 5036 Section 3.3

---

Sections 3.5 and 3.6 need to be more= closely grouped.

Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2

= ---

Section 3.6

=C2=A0 =C2=A0To announce its MT capability fo= r an IP address family, LDP FEC type,
=C2=A0 =C2=A0and Multi Topology, a= n LDP speaker MAY send an "MT Capability"
=C2=A0 =C2=A0including the exact Typed Wildcard FEC element with correspond= ing
=C2=A0 =C2=A0"AddressFamily" field (i.e., set to "MT = IP" for IPv4 and set to "MT
=C2=A0 =C2=A0IPv6" for IPv6 a= ddress family), corresponding "FEC Type" field (i.e.,
=C2=A0 =C2=A0set to "P2P", "P2MP", "MP2MP"), = and corresponding "MT-ID". =C2=A0To
=C2=A0 =C2=A0announce its = MT capability for both IPv4 and IPv6 address family, or
=C2=A0 =C2=A0for= multiple FEC types, or for multiple Multi Topologies, an LDP
=C2=A0 =C2=A0speaker MAY send "MT Capability" with one or more MT= Typed FEC
=C2=A0 =C2=A0elements in it.

I don't think this is= "MAY" in either case. This *is* how the LDP
speaker announces= it. There is no other way to announce it. So...

=C2=A0 =C2=A0To announce its MT capability for an IP address family, LD= P FEC type,
=C2=A0 =C2=A0and Multi Topology, an LDP speaker sends an &qu= ot;MT Capability" including
=C2=A0 =C2=A0the exact Typed Wildcard F= EC element with corresponding
=C2=A0 =C2=A0"AddressFamily" field (i.e., set to "MT IP"= ; for IPv4 and set to "MT
=C2=A0 =C2=A0IPv6" for IPv6 address = family), corresponding "FEC Type" field (i.e.,
=C2=A0 =C2=A0se= t to "P2P", "P2MP", "MP2MP"), and correspondi= ng "MT-ID". =C2=A0To
=C2=A0 =C2=A0announce its MT capability for both IPv4 and IPv6 address fami= ly, or
=C2=A0 =C2=A0for multiple FEC types, or for multiple Multi Topolo= gies, an LDP
=C2=A0 =C2=A0speaker sends "MT Capability" with o= ne or more MT Typed FEC elements
=C2=A0 =C2=A0in it.

---

Section 3.6

=C2=A0 =C2=A0o =C2= =A0If an LSR has not advertised MT capability, its peer must not send
= =C2=A0 =C2=A0 =C2=A0 messages that include MT identifier to this LSR.
Isn't that "MUST NOT"?

---

Section 3.8

=C2=A0 =C2=A0Certain MT topologies are as= signed to serve predetermined purposes:

It is not the topology that = is assigned, but the MT-ID. Should read:

=C2=A0 =C2=A0Certain MT-ID = values are assigned to indicate specific meanings:

---

Section 3.8

It is not helpful to "propose" = numbers in this section and then to
also reference Section 9 for the def= initive numbers. =C2=A0I suggest you
remove all numbers from this sectio= n and simply point at Section 9.

---

Section 4.2

=C2=A0 =C2=A0This MAY allow an LDP speake= r to signal its IP convergence...

What does 2119 MAY mean in this co= ntext?

---

Section 4.3

=C2=A0 =C2=A0[RFC4379] defines = procedures to detect data-plane failures in MPLS
=C2=A0 =C2=A0LSPs via LSP ping. =C2=A0The specification defines a "Tar= get FEC Stack"
=C2=A0 =C2=A0TLV that describes the FEC stack being = tested.

Ha, ha! You got me :-)
s/The specification/That specifica= tion/

---

Section 4.3.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sub-Type =C2=A0 =C2= =A0 =C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Value Field
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------- =C2=A0 =C2=A0 =C2=A0 ------ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBA5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A05 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MT LDP IPv4 prefix
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBA6 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 17 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MT LDP IPv6 prefix
Are you sure you don't mean 8 and 20?

---

Section 4.3= .4

=C2=A0 =C2=A0When detect data plane failures using LSP Ping for a= specific topoly,
=C2=A0 =C2=A0the router will intiate an LSP Ping reque= st with the targer FEC stack

I think

s/When/To/

s/topoly/topology/

s/intiate/in= itiate/

s/targer/target/

---

Section 4.3.4

=C2= =A0 =C2=A0For the case that the LSP ping with return path not specified , t= he
=C2=A0 =C2=A0reply packet may go through the default topology instead= of the
=C2=A0 =C2=A0topology where the Echo Request goes through.

Is that r= eally "the default" or "any"?
If you mean "the = default" then I think you need some "MUST NOT" text to
ta= lk about other topologies.

---

Section 5

=C2=A0 =C2=A0The extensions defined in this= document utilise the existing LDP
=C2=A0 =C2=A0error handling defined i= n [RFC5036]. =C2=A0If an LSR receives an error
=C2=A0 =C2=A0notification= from a peer for an MPLS-MT session, it terminates the
=C2=A0 =C2=A0LDP session by closing the TCP transport connection for the se= ssion
=C2=A0 =C2=A0and discarding all MT-ID label mappings learned via t= he session.

There is nothing wrong with this text, but it does open = a question that
is not addressed anywhere in the document: what is the relationship
betw= een LDP sessions and MT-IDs? =C2=A01:1, 1:n, n:1, n:m?

This is somew= hat assumable from the discussion of multiple MT-ID
wildcard FEC element= s in the Multi-Topology Capability TLV, but it is
not explicit.

---

Shouldn't Section 6 comment on how each= of the new protocol elements
will not be seen by a legacy implementatio= n because they are only used
after successful capability negotiation?
But you do need to describe how a legacy node will react to attemptedMT capability negotiation.

You could also restate the reference to= RFC 5036 section 3.4.1.1 since
this issue seemed to be a question for y= ou.

---

I'm slightly doubtful about the value of Section 7, but = I note that the
point you are trying to convey is not quite worded corre= ctly. You have:

=C2=A0 =C2=A0and the specified
=C2=A0 =C2=A0signa= ling mechanisms do not provide any way for the data plane to
=C2=A0 =C2=A0associate a given packet with a context-specific label space.<= br>
I don't think the signaling mechanism is relevant, and I think &= quot;context-
specific" hides what you are trying to say. =C2=A0Per= haps you should have:

=C2=A0 =C2=A0and there is no way
=C2=A0 =C2=A0for the data plane to = associate a received packet with any one
=C2=A0 =C2=A0topology, meaning = that topology-specific label spaces cannot be used.

---

Secti= on 9

=C2=A0 =C2=A0o =C2=A0New Status Code: "Multi-Topology Capa= bility not supported"
=C2=A0 =C2=A0 =C2=A0 (requested code point: TBA2 from LDP registry "St= atus Code Name
=C2=A0 =C2=A0 =C2=A0 Space").

This status cod= e does not appear to be mentioned in the draft. How is
it used? Is an im= plementation that does not know the new MT Capability
TLV supposed to generate this status code? Or are you referencing an
exi= sting error code: in which case it should not appear in this section.
=C2=A0 =C2=A0o =C2=A0New Status Code: "Unknown Address Family" = (requested code point:
=C2=A0 =C2=A0 =C2=A0 TBA4 from LDP registry "Status Code Name Space&qu= ot;).

This status code does not appear to be mentioned in the draft.= How is
it used? Is a legacy implementation that does not know either of= your
new MT AFs supposed to generate this status code? But I suspect yo= u are
just referencing an existing error code (see Section 3.2) as defined in
= RFC 5036, and so you should not mention it in this section.

Figure 1= 0 does not show either of these status codes.

---

Figure 10 s= hows a specific value for the new status code. Is this a
request or demand? I don't think it has already been allocated.

= ---

Section 9

=C2=A0 =C2=A0o =C2=A0New registry "LDP Mul= ti-Topology (MT) ID Name Space" under "LDP
=C2=A0 =C2=A0 =C2= =A0 Parameter" namespace.

This registry is discussed earlier in my notes. but please be aware tha= t
you will need to define the allocation policy because it is a new
r= egistry.

---

Section 9

I want to ask Loa Andersson to = look again at the LSP Ping TLV
allocations to check that they conform to the work he is currently
doing= with that registry.

---

It would help considerably to add a = Manageability Considerations section
to this document because the functi= on being added here is not simple to
manage or operate, and will have impact on the way that the network is
r= un. Good guidance on such sections can be found in RFC 5706. Appendix A
= is particularly helpful at summarising things to consider.

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

_______________________________________________
mpls mailing listmpls@ietf.org
https://www.ietf.org/mailman/listinfo/mp= ls

=C2=A0


--bcaec511e1b6cdbde204e09fbac0-- From Jonathan.Hardwick@metaswitch.com Thu Jul 4 01:45:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB6F21F9ECF for ; Thu, 4 Jul 2013 01:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeMWDsfGbDYK for ; Thu, 4 Jul 2013 01:45:24 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2B39921F9EC0 for ; Thu, 4 Jul 2013 01:45:24 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 4 Jul 2013 09:45:05 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0342.003; Thu, 4 Jul 2013 09:45:17 +0100 From: Jonathan Hardwick To: "mpls@ietf.org" , "draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: Thoughts on draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: Ac54ks5TH5p4mgC5Rsa9vhvU3WoQtw== Date: Thu, 4 Jul 2013 08:45:17 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10E98C1@ENFICSMBX1.datcon.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.153] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10E98C1ENFICSMBX1datco_" MIME-Version: 1.0 Subject: [mpls] Thoughts on draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 08:45:30 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10E98C1ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there Here are my thoughts on this draft. My apologies if this duplicates what a= nyone else has already said, I have not read all the other comments. Regards Jon 1. Applicability of this solution As I think has been mentioned elsewhere, PCE provides a superior solution t= o this problem since it can produce an end-to-end optimized tree without th= e need for guesswork and crankback. I assume you believe that there are sc= enarios that the PCE solution is not applicable to. Please could the draft= explain what those scenarios are? 2. Comments on proposed mechanism Some of the recommendations made by the draft seem to me to be counter-prod= uctive. In section 3.1 "It is RECOMMENDED that the ingress node of a P2MP LSP selec= ts the same ingress border node in the loose hop ERO for all sibling S2L su= b-LSPs that transit through a given domain." By doing this you can elimina= te from consideration more preferable S2L paths by forcing them all through= a single border node. Even if this recommendation is followed, there is n= o guarantee that you have eliminated or even reduced the potential number o= f merge points. I don't think this behaviour should be recommended. In section 3.2 "If an ingress border node on the path of the P2MP LSP is un= able to find a route that can supply the required resources or that is re-m= erge free, it MUST generate a PathErr message for the subset of the S2L sub= -LSPs which it is not able to route." The implication is that the border = node's first priority is to find any remerge-free route, no matter how sub-= optimal. Only if no such route can be found, should it crank back. This s= eems wrong. In fact I think the border node's priorities should be inverte= d. Each detected remerge is an opportunity to optimize the data plane so t= hat more leaf nodes are reached via a common path. Rather than avoiding a = remerge at all costs (by maximising the number of paths) we should aim to f= ind remerges so that we can prune unnecessary paths. * If the most preferable path for an S2L LSP involves a remerge the= n the leaf nodes that are involved in the merge should be moved onto a comm= on path. I can see no advantage to looking for a less-preferable path with= out a remerge in this scenario. * If the most preferable path for an S2L LSP does not involve a rem= erge, but there is a less-preferred path that does involve a remerge, then = the domain's operator may still (by policy) choose to move all the leaf nod= es onto a common path through the remerge node, for example if they are par= ticularly concerned about carrying each packet twice, or if by doing so it = leads to a lower overall cumulative TE metric for the tree. In section 3.2 "For this purpose the ingress border node SHOULD try to find= a minimum subset of S2L sub-LSPs for which the PathErr needs to be generat= ed towards the ingress node." This is saying that if a remerge cannot be a= voided then two paths should be merged by rejecting the path with the small= est number of leaf nodes and moving all of those leaf nodes onto the other = path. That is maximally conservative of signalling plane resources but the= priority is usually to optimize the network. Say the root of the tree is = R and the two merging paths pass through border nodes A and B before mergin= g at node M. If the cost of path RA + AM is less than the cost of path RB = + BM then the network is optimized by moving leaf nodes onto the path throu= gh A, irrespective of how many leaf nodes you are moving. The costs of AM = and BM are known to node M from its TE database; the costs of RA and RB cou= ld be signalled to node M. 3. Minor / editorial comments Section 1 para 5 "when P2MP LSP spans" -> "when the P2MP LSP spans" Section 1 para 6 "However this can lead to a deadlock..." - I couldn't foll= ow the example given, please could you explain or add a reference? Section 1 para 8 "individual the destinatyions" - typo Section 1 para 8 "it can lead to data duplication inside the backbone" - ho= w? Section 1.1 para 4 "entire or part" -> "all or part" Section 1.1 para 4 "by expanding EROs in Path messages of the destinations"= - doesn't make sense Section 1.1 para 4 "Border node does not know" -> "The border node does not= know" Section 1.1 para 4 "Signaling extension and procedure" -> "Signaling extens= ions and procedures" Section 1.2 para 2 "do not guarantee" -> "does not guarantee" Section 3.2 para 3 "that has less number of" -> "that has the fewest" Section 3.2 para 3 "These are the S2L sub-LSPs on an incoming interface tha= t has less number of S2L sub-LSPs compared to the second incoming interface= that is causing the re-merge condition." - I don't understand this sentenc= e Section 3.2 para 9 "in history table" -> "in a history table" Section 3.2 para 9 "until local timer expires" -> "until a local timer expi= res" Section 4.3 para 1 "operator may have disabled" -> "the operator has disabl= ed" Section 4.3 para 1 "the the" - typo. --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10E98C1ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there

 

Here are my thoughts on this draft.  My apologi= es if this duplicates what anyone else has already said, I have not read al= l the other comments.

 

Regards

Jon

 

 

1. Applicability of this solution<= /p>

As I think has been mentioned elsewhere, PCE provide= s a superior solution to this problem since it can produce an end-to-end op= timized tree without the need for guesswork and crankback.  I assume y= ou believe that there are scenarios that the PCE solution is not applicable to.  Please could the draft explai= n what those scenarios are?

 

2. Comments on proposed mechanism<= /p>

Some of the recommendations made by the draft seem t= o me to be counter-productive.

 

In section 3.1 “It is RECOMMENDED that the ingress n= ode of a P2MP LSP selects the same ingress border node in the loose hop ERO= for all sibling S2L sub-LSPs that transit through a given domain.”  By doing this you can eliminate from con= sideration more preferable S2L paths by forcing them all through a single b= order node.  Even if this recommendation is followed, there is no guar= antee that you have eliminated or even reduced the potential number of merge points.  I don’t think this behaviour= should be recommended.

 

In section 3.2 “If an ingress border node on the pat= h of the P2MP LSP is unable to find a route that can supply the required re= sources or that is re-merge free, it MUST generate a PathErr message for the subset of the S2L sub-LSPs which it is not able to= route.”   The implication is that the border node&#= 8217;s first priority is to find any remerge-free route, no matter how sub-= optimal.  Only if no such route can be found, should it crank back.  This seems wrong.  In fact I think the border node&= #8217;s priorities should be inverted.  Each detected remerge is an op= portunity to optimize the data plane so that more leaf nodes are reached vi= a a common path.  Rather than avoiding a remerge at all costs (by maximising the number of paths) we should aim to find remerges s= o that we can prune unnecessary paths.

 

·         If the most preferable path for an S2L LSP i= nvolves a remerge then the leaf nodes that are involved in the merge should= be moved onto a common path.  I can see no advantage to looking for a= less-preferable path without a remerge in this scenario.

 

·         If the most preferable path for an S2L LSP d= oes not involve a remerge, but there is a less-preferred path that does inv= olve a remerge, then the domain’s operator may still (by policy) choo= se to move all the leaf nodes onto a common path through the remerge node, for example if they are particularly concer= ned about carrying each packet twice, or if by doing so it leads to a lower= overall cumulative TE metric for the tree.

 

In section 3.2 “For this purpose the ingress border = node SHOULD try to find a minimum subset of S2L sub-LSPs for which the Path= Err needs to be generated towards the ingress node.”  This is saying that if a remerge cannot be avoided then two paths should b= e merged by rejecting the path with the smallest number of leaf nodes and m= oving all of those leaf nodes onto the other path.  That is maximally = conservative of signalling plane resources but the priority is usually to optimize the network.  Say the root of= the tree is R and the two merging paths pass through border nodes A and B = before merging at node M.  If the cost of path RA + AM is less tha= n the cost of path RB + BM then the network is optimized by moving leaf nodes onto the path through A, irrespective of ho= w many leaf nodes you are moving.  The costs of AM and BM are known to= node M from its TE database; the costs of RA and RB could be signalled to = node M.

 

3. Minor / editorial comments

Section 1 para 5 “when P2MP LSP spans” -= > “when the P2MP LSP spans”

Section 1 para 6 “However this can lead to a d= eadlock...” – I couldn’t follow the example given, please= could you explain or add a reference?

Section 1 para 8 “individual the destinatyions= ” – typo

Section 1 para 8 “it can lead to data duplicat= ion inside the backbone” – how?

Section 1.1 para 4 “entire or part” ->= ; “all or part”

Section 1.1 para 4 “by expanding EROs in Path = messages of the destinations” – doesn’t make sense

Section 1.1 para 4 “Border node does not know&= #8221; -> “The border node does not know”

Section 1.1 para 4 “Signaling extension and pr= ocedure” -> “Signaling extensions and procedures”=

Section 1.2 para 2 “do not guarantee” -&= gt; “does not guarantee”

Section 3.2 para 3 “that has less number of= 221; -> “that has the fewest”

Section 3.2 para 3 “These are the S2L sub-LSPs= on an incoming interface that has less number of S2L sub-LSPs compared to = the second incoming interface that is causing the re-merge condition.”= ; – I don’t understand this sentence

Section 3.2 para 9 “in history table” -&= gt; “in a history table”

Section 3.2 para 9 “until local timer expires&= #8221; -> “until a local timer expires”

Section 4.3 para 1 “operator may have disabled= ” -> “the operator has disabled”

Section 4.3 para 1 “the  the” ̵= 1; typo.

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10E98C1ENFICSMBX1datco_-- From yaakov_s@rad.com Thu Jul 4 02:21:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C7821F9F49 for ; Thu, 4 Jul 2013 02:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AILUt-RNjSOU for ; Thu, 4 Jul 2013 02:21:33 -0700 (PDT) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF821F9ECB for ; Thu, 4 Jul 2013 02:21:28 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 4 Jul 2013 12:12:02 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.03.0146.000; Thu, 4 Jul 2013 12:21:13 +0300 From: Yaakov Stein To: "tictoc@ietf.org" Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32g== Date: Thu, 4 Jul 2013 09:21:13 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090209.51D53E8A.019E,ss=1,fgs=0 Cc: "mpls@ietf.org" Subject: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 09:21:38 -0000 We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). Please send indications of support, as well as any remaining technical comm= ents, to the list. Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG, but please conduct all discussion on the TICTOC working group mailing list. This working group last call will end on July 19, 2013. Y(J)S=20 From talmi@marvell.com Thu Jul 4 03:20:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330B521F9E6A; Thu, 4 Jul 2013 03:20:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9vv0DmHicml; Thu, 4 Jul 2013 03:20:33 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9076321F9E63; Thu, 4 Jul 2013 03:20:29 -0700 (PDT) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUdVMbCinPd3g7Cer5jI1UeC3vEEunFz/@postini.com; Thu, 04 Jul 2013 03:20:33 PDT Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 4 Jul 2013 03:18:20 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Thu, 4 Jul 2013 13:18:16 +0300 From: Tal Mizrahi To: Yaakov Stein , "tictoc@ietf.org" Date: Thu, 4 Jul 2013 13:18:12 +0300 Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gAB+kVw Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9F14FED@IL-MB01.marvell.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> 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: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 10:20:40 -0000 Support. Tal. -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Yaakov Stein Sent: Thursday, July 04, 2013 12:21 PM To: tictoc@ietf.org Cc: mpls@ietf.org Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-= 05). Please send indications of support, as well as any remaining technical comm= ents, to the list. Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG, but please conduct all discussion on the TICTOC working group mail= ing list. This working group last call will end on July 19, 2013. Y(J)S=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From internet-drafts@ietf.org Thu Jul 4 20:40:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9B611E810D; Thu, 4 Jul 2013 20:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk+DiZO41Gst; Thu, 4 Jul 2013 20:40:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26211E80AD; Thu, 4 Jul 2013 20:40:16 -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: 4.51.p2 Message-ID: <20130705034015.30638.13765.idtracker@ietfa.amsl.com> Date: Thu, 04 Jul 2013 20:40:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-lim-mpls-proxy-lsp-ping-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: Fri, 05 Jul 2013 03:40:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Proxy MPLS Echo Request Author(s) : George Swallow Vanson Lim Sam Aldrin Filename : draft-lim-mpls-proxy-lsp-ping-03.txt Pages : 24 Date : 2013-07-04 Abstract: This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ root tracing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lim-mpls-proxy-lsp-ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-lim-mpls-proxy-lsp-ping-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-lim-mpls-proxy-lsp-ping-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 5 00:25:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FFF21F9E2E; Fri, 5 Jul 2013 00:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAFJQ4C80+Su; Fri, 5 Jul 2013 00:25:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF23821F999C; Fri, 5 Jul 2013 00:25: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: 4.51.p2 Message-ID: <20130705072543.23258.87224.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2013 00:25:43 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-special-purpose-labels-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, 05 Jul 2013 07:25:44 -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 Gro= up of the IETF. Title : Allocating and Retiring Special Purpose MPLS Labels Author(s) : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-ietf-mpls-special-purpose-labels-00.txt Pages : 13 Date : 2013-07-04 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Fri Jul 5 00:46:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDC11E8262 for ; Fri, 5 Jul 2013 00:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCARu0IGgiF6 for ; Fri, 5 Jul 2013 00:46:05 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4111E825C for ; Fri, 5 Jul 2013 00:46:02 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 676FA1800820; Fri, 5 Jul 2013 09:46:01 +0200 (CEST) Message-ID: <51D679B9.5020204@pi.nu> Date: Fri, 05 Jul 2013 09:46:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 References: <20130705034015.30638.13765.idtracker@ietfa.amsl.com> In-Reply-To: <20130705034015.30638.13765.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-lim-mpls-proxy-lsp-ping-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: Fri, 05 Jul 2013 07:46:10 -0000 Working Group, The mpls wg co-chairs have decided to accept draft-lim-mpls-proxy-lsp-ping as a MPLS working group document. Can the authors please re-post the draft as draft-ietf-mpls-proxy-lsp-ping, without any other changes than the filename and other administrativia. /Loa for the MPLS co-chairs On 2013-07-05 05:40, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Proxy MPLS Echo Request > Author(s) : George Swallow > Vanson Lim > Sam Aldrin > Filename : draft-lim-mpls-proxy-lsp-ping-03.txt > Pages : 24 > Date : 2013-07-04 > > Abstract: > This document defines a means of remotely initiating Multiprotocol > Label Switched Protocol Pings on Label Switched Paths. A proxy ping > request is sent to any Label Switching Routers along a Label Switched > Path. The primary motivations for this facility are first to limit > the number of messages and related processing when using LSP Ping in > large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ > root tracing. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lim-mpls-proxy-lsp-ping > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lim-mpls-proxy-lsp-ping-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-lim-mpls-proxy-lsp-ping-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From william.mccall@gmail.com Fri Jul 5 03:06:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD23D11E8276 for ; Fri, 5 Jul 2013 03:06:08 -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_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPEp-x0DNWOZ for ; Fri, 5 Jul 2013 03:06:08 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 54C7E21F9C79 for ; Fri, 5 Jul 2013 03:06:08 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so3103351oag.5 for ; Fri, 05 Jul 2013 03:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Cz4zvwPqk2sR1pTyF8KvTMDM0vXP8/sxQqpCnIHGSmQ=; b=cbtHG/LDSw+LT2+fOMTHQUTvp+WnQn+eCKZozf5vXvPs0pJP6FOMA30GUeX3GFYUiC pg1wd52agfCvlSNHxxqh4JEud9jnScMzf4zz8FPfIohgbsg2JwVM7UuzujA3QzR0keBE PXUzcbLM1NsgNxYs6vHjMh8xejJAhEEgyUaMJxhdz88KTrcc3XMHo8JpQtZeRLBTb9LA XG8aAci+NOMy8r6RdaZhD3izRfpKTavGoGZX+RmFgXsCweVDAFpxSMPPSAGgsN7DtTXk Un26ZTEShgLkG8Waryor5E5xcPdIfOPehWFlOIyA+R/fMFJ/p/wQYAZLL4fd04MYJ6o6 A/tg== X-Received: by 10.182.55.72 with SMTP id q8mr10078697obp.96.1373018767874; Fri, 05 Jul 2013 03:06:07 -0700 (PDT) Received: from [10.10.0.56] (cpe-66-25-3-111.tx.res.rr.com. [66.25.3.111]) by mx.google.com with ESMTPSA id q4sm13346313obl.1.2013.07.05.03.06.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 03:06:07 -0700 (PDT) Message-ID: <51D69A90.1070908@gmail.com> Date: Fri, 05 Jul 2013 05:06:08 -0500 From: William McCall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: mpls@ietf.org, renwei.li@huawei.com, mli@huawei.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Review of draft-renwei-mpls-bgp-big-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 10:06:08 -0000 This is my first review, so please feel free to correct me on procedure, etc. In the introduction, the problem statement revolves around L3VPNs and large numbers of labels needed in an environment with ~16 million virtual networks in conjunction with work in VXLAN, NVGRE and NVO3. In it, the proposal is to extend the MPLS label size by assigning a reserved label to indicate that a 32 bit label immediately follows. Among my observations are the following-- [technical] 1) BGP/MPLS L3VPNs can convey label stacks per rfc3107. What would this change alleviate that could not already be solved by adding another label to the stack? 2) If the label size is to be extended in this manner, would it be expected to create a separate label space for 32-bit values? If not, would the 20-bit label range be excluded from use in the 32-bit labels? This should be clarified. The only statement regarding this from the doc is: " When an MPLS LSR receivs an MPLS packet, it reads out the MPLS label. If the MPLS label is a Big Label Indicator, it will use the subsequent 32-bit value as the MPLS label for the forwarding purpose." [editorial] 3) Obsolete RFC 2547 is referenced. 4) A few miscellaneous wording changes could be used. I can discuss in private to avoid spamming the list. Thanks, --WM From william.mccall@gmail.com Fri Jul 5 03:34:04 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C563E11E8289 for ; Fri, 5 Jul 2013 03:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2tNp1gV0oVx for ; Fri, 5 Jul 2013 03:34:04 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5939711E827C for ; Fri, 5 Jul 2013 03:34:04 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so3183763oag.15 for ; Fri, 05 Jul 2013 03:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=omo8oAeRMsuCbt4OCCBmtgWmhYubB2EaKGl1TyIDkr8=; b=PYcvQjdgFyJcpIwwZkblay0ekI93+xka4eQR2bQWUwnwdLJZgKiK7ZjsK+1cuwKnBh eVriZg8xEyEmrIwDtkRpH7VBGNd0ZXapvuxhL4kV1NEvmusiW9D2hXgpcygaClie4+li aX1vRBss7bVQUtK+4JghDVachGJbs0oMusdk5C0iwEC2BBJCrMUHHS7ynB28VVbmdX9I nEL0MSg0W5KqGDEzAbbbwAiez+ZkmgH5zGl8dvOjv0SDsAzI91wHg24rHPiUmwiUZmbv oyoLqzRbA23elWvXCww0kUsVJr6v8OpQCBY2A/Vau4Cvugsv4DePQ/Uzzk6NntMRBhXp lwYA== X-Received: by 10.182.125.1 with SMTP id mm1mr10035912obb.47.1373020442893; Fri, 05 Jul 2013 03:34:02 -0700 (PDT) Received: from [10.10.0.56] (cpe-66-25-3-111.tx.res.rr.com. [66.25.3.111]) by mx.google.com with ESMTPSA id hm1sm13348586obb.9.2013.07.05.03.34.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 03:34:02 -0700 (PDT) Message-ID: <51D6A11B.2010708@gmail.com> Date: Fri, 05 Jul 2013 05:34:03 -0500 From: William McCall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: mpls@ietf.org, renwei.li@huawei.com, mli@huawei.com References: <51D69A90.1070908@gmail.com> In-Reply-To: <51D69A90.1070908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 10:34:04 -0000 So sorry, but I referenced the wrong draft. On 07/05/2013 05:06 AM, William McCall wrote: > This is my first review, so please feel free to correct me on > procedure, etc. > > In the introduction, the problem statement revolves around L3VPNs and > large numbers of labels needed in an environment with ~16 million > virtual networks in conjunction with work in VXLAN, NVGRE and NVO3. In > it, the proposal is to extend the MPLS label size by assigning a > reserved label to indicate that a 32 bit label immediately follows. > > Among my observations are the following-- > > [technical] > > 1) BGP/MPLS L3VPNs can convey label stacks per rfc3107. What would > this change alleviate that could not already be solved by adding > another label to the stack? > > 2) If the label size is to be extended in this manner, would it be > expected to create a separate label space for 32-bit values? If not, > would the 20-bit label range be excluded from use in the 32-bit > labels? This should be clarified. The only statement regarding this > from the doc is: > > " When an MPLS LSR receivs an MPLS packet, it reads out the MPLS > label. If the MPLS label is a Big Label Indicator, it will use the > subsequent 32-bit value as the MPLS label for the forwarding purpose." > > [editorial] > > 3) Obsolete RFC 2547 is referenced. > > 4) A few miscellaneous wording changes could be used. I can discuss in > private to avoid spamming the list. > > Thanks, > > --WM > From internet-drafts@ietf.org Fri Jul 5 05:37:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC911E82C2; Fri, 5 Jul 2013 05:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcc9CTJjPAFE; Fri, 5 Jul 2013 05:37:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAE611E82BF; Fri, 5 Jul 2013 05:37:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130705123756.12691.19867.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2013 05:37:56 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-proxy-lsp-ping-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, 05 Jul 2013 12:37: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 Gro= up of the IETF. Title : Proxy MPLS Echo Request Author(s) : George Swallow Vanson Lim Sam Aldrin Filename : draft-ietf-mpls-proxy-lsp-ping-00.txt Pages : 24 Date : 2013-07-05 Abstract: This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ root tracing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-proxy-lsp-ping-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From erosen@cisco.com Fri Jul 5 08:50:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD4B21F9BDB for ; Fri, 5 Jul 2013 08:50:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H41qufaBP4ge for ; Fri, 5 Jul 2013 08:50:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5788921F9BF0 for ; Fri, 5 Jul 2013 08:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=730; q=dns/txt; s=iport; t=1373039407; x=1374249007; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=fcDZjuWoj7gdjTldZBPMLDR0/S5DlHHAMpMsHzoFYtI=; b=HE5pAivkIHMShDLLDeVoHhpnRiLLp+ERRPhAXMorh7BQiNf+lFK6cbwp vECO5XnmGJOKeBMXUIKBs2W7Qs1fXA22qvsCBcpbCrbWzCsAzoEXRE0/w 7bo5EM75iTnPdmFl+rENwLTOo2DUKa1S3kaQRkr7xTl+6mXVcbUpdfAvQ Q=; X-IronPort-AV: E=Sophos;i="4.87,1002,1363132800"; d="scan'208";a="231339961" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jul 2013 15:50:07 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r65Fo6Lg024287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 15:50:06 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 r65Fo50d030678; Fri, 5 Jul 2013 11:50:05 -0400 From: Eric Rosen To: William McCall In-reply-to: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> Date: Fri, 05 Jul 2013 11:50:05 -0400 Message-ID: <30677.1373039405@erosen-linux> Cc: mli@huawei.com, mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:50:13 -0000 > What would this change alleviate that could not already be solved by > adding another label to the stack? Excellent point. Please see also section 3 (especially the last paragraph) of RFC 5331 on "context labels". By using one label as a "context label" identifying a context in which the subsequent label is interpreted, one gets the effect of a 40-bit label space, and the same mechanism can also be used to support upstream-assigned labels. It's also worth noting that the "big label" proposal would probably end up using three label stack entries per big label: special purpose label indicator, big label indicator, big label value. The use of context labels will require only two label stack entries. From gregory.mirsky@ericsson.com Fri Jul 5 09:46:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A977F11E8134; Fri, 5 Jul 2013 09:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XklP6VgFQDsE; Fri, 5 Jul 2013 09:46:39 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7926D11E80A2; Fri, 5 Jul 2013 09:46:39 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-ce-51d6f86daff9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AF.E6.31362.D68F6D15; Fri, 5 Jul 2013 18:46:38 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 5 Jul 2013 12:46:37 -0400 From: Gregory Mirsky To: Yaakov Stein , "tictoc@ietf.org" Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gBBhpew Date: Fri, 5 Jul 2013 16:46:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyuXSPn27ej2uBBrPXcljcWrqS1eJvcw+7 xYeuH6wOzB5Llvxk8pi0Ni2AKYrLJiU1J7MstUjfLoEr4+LVzWwFD7gqXjSsY2lg/MHRxcjJ ISFgInH+xUtmCFtM4sK99WxdjFwcQgJHGSUOb7jACOEsY5To2bySEaSKTcBI4sXGHnYQW0TA Q+LqpAlMXYwcHMwCyhKn7sqAhIUFbCRmr1zGAlFiK/Gr6yUjhG0kMXXGJLBlLAIqEk/PPgQb wyvgK/Hi4lKwGiEBL4nOruWsIDangLfEy3VTmEBsRqDjvp9aA2YzC4hL3HoynwniaAGJJXvO Qz0gKvHy8T9WCFtZ4vucRywQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJyywk LbOQtCxgZFnFyFFanFqWm25kuIkRGC3HJNgcdzAu+GR5iFGag0VJnHeD3plAIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYxpD+UU34vPn3hlbu3O89/LPW9u9rs6u1tQrMfG+nPtzgNPm278 7T+x7Ne8W2FBLJams3iu3XKKKlN1/frk5IzkGR8kTPNFSzTcNFfK/so77DTv92Ldle8Stk/J fRRqEskXeklv4UWes79E9hV/+Mu1xj1fIGTWy3WbW/o2fmRQ9ltQtPy08fcEJZbijERDLeai 4kQApHQWaWQCAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 16:46:47 -0000 Do not support - As document describing Transporting Timing messages over MPLS Networks it= comes short in justification of complexity of PTP LSP for non-1588 protoco= ls; - I do believe that even for IEEE 1588 distribution through MPLS-TP domain = PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnecti= ng ports that support IEEE 1588 (new capability advertised in IGP-TE) is ar= chitectually clean and sufficient. Regards, Greg -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Yaakov Stein Sent: Thursday, July 04, 2013 2:21 AM To: tictoc@ietf.org Cc: mpls@ietf.org Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-= 05). Please send indications of support, as well as any remaining technical comm= ents, to the list. Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG, but please conduct all discussion on the TICTOC working group mail= ing list. This working group last call will end on July 19, 2013. Y(J)S=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From internet-drafts@ietf.org Sun Jul 7 11:46:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D3F21F9F2D; Sun, 7 Jul 2013 11:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fy0MyVWVLCy; Sun, 7 Jul 2013 11:46:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 225DE21F9F28; Sun, 7 Jul 2013 11:46: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: 4.51.p2 Message-ID: <20130707184650.15093.76476.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2013 11:46:50 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-special-purpose-labels-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, 07 Jul 2013 18:46:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Allocating and Retiring Special Purpose MPLS Labels Author(s) : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-ietf-mpls-special-purpose-labels-01.txt Pages : 13 Date : 2013-07-07 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-special-purpose-labels-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kireeti.kompella@gmail.com Sun Jul 7 11:51:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B399B21F9A59 for ; Sun, 7 Jul 2013 11:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS8rhOXiiURX for ; Sun, 7 Jul 2013 11:51:31 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29921F9A57 for ; Sun, 7 Jul 2013 11:51:31 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so3382374pdd.34 for ; Sun, 07 Jul 2013 11:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=XJevbOOXEoQ95oyU6fULZOp9YwwGrV+1mw4Z3edQp/8=; b=TQjew8ZDKI779B43GfPdINvnDuDPsCGRKaaB8H1yXpzcu/Lw/Uiw/blVrrZ8sAX80L aXtYD4BLLJajjWQcRVXFahykj6jy47mPKjiglNgrE+Z35Y80Hlj8lit6TJOj7R/cLIwl y3rF7XFuYMB63KmvTt8TDVQENRsTZ7fhOktruZJOc0wn4S8Ri3Lq3Gy00r/NQ6YfF5EG Hf1EF4bYLQ1hffNVBnkRyCequWn6p46uIMWSDAPW+THSSkpdQyhYtqAZnp1Jo1DbOHC0 2znbd3CCry6MXPnD+EA6HJcNOfk/OgWajjUotvleuTR55wsMXCoqCI2vJNEihvO69+Rp OX8Q== X-Received: by 10.68.12.165 with SMTP id z5mr17857803pbb.172.1373223090965; Sun, 07 Jul 2013 11:51:30 -0700 (PDT) Received: from [192.168.1.78] (75-37-192-227.lightspeed.lsatca.sbcglobal.net. [75.37.192.227]) by mx.google.com with ESMTPSA id bn10sm19715453pad.9.2013.07.07.11.51.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 11:51:30 -0700 (PDT) From: Kireeti Kompella Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE29B91-00EF-4ACD-BB85-7F9C8911076C" Date: Sun, 7 Jul 2013 11:51:28 -0700 Message-Id: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> To: MPLS Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Ross Callon , Loa Andersson Subject: [mpls] draft-ietf-mpls-special-purpose-labels-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: Sun, 07 Jul 2013 18:51:31 -0000 --Apple-Mail=_FBE29B91-00EF-4ACD-BB85-7F9C8911076C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I have updated this document with the following: a) the range of Standards Action extended special purpose labels is = 16-239; experimental is 240-255. The rest are reserved for now. b) I've added a question/answer on whether to use extended special = purpose labels in load balancing -- saying MUST NOT. c) Clarified text regarding a label following an extended special = purpose (Xuxiaohu's comment). Finally, I note Lizhong's comment regarding label 7. The goal in = allowing label 7 as either a regular special purpose label or an = extended special purpose label is to simplify parsing when searching for = an entropy label. I added text around this, but did not change SHOULD = NOT to MUST NOT. WG chairs, I believe this doc is ready for WG LC. Kireeti.= --Apple-Mail=_FBE29B91-00EF-4ACD-BB85-7F9C8911076C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

I have updated this document with the = following:
a) the range of Standards Action extended special = purpose labels is 16-239; experimental is 240-255.  The rest are = reserved for now.
b) I've added a question/answer on whether = to use extended special purpose labels in load balancing -- saying MUST = NOT.
c) Clarified text regarding a label following an extended = special purpose (Xuxiaohu's = comment).

Finally, I note Lizhong's comment regarding label 7.  The goal in = allowing label 7 as either a regular special purpose label or = an extended special purpose label is to simplify parsing when searching = for an entropy label.  I added text around this, but did not change = SHOULD NOT to MUST NOT.

WG chairs, I = believe this doc is ready for WG LC.

Kireeti.
= --Apple-Mail=_FBE29B91-00EF-4ACD-BB85-7F9C8911076C-- From william.mccall@gmail.com Sun Jul 7 12:25:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BE821F9A50 for ; Sun, 7 Jul 2013 12:25:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-7F03mbcYf6 for ; Sun, 7 Jul 2013 12:25:08 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id B210121F9A4B for ; Sun, 7 Jul 2013 12:25:08 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so5484998oag.14 for ; Sun, 07 Jul 2013 12:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1PZZUNOtqlTIZAsLzF2zTl+CUbtSGsETcDDNPreLM+c=; b=j33MsRcGQw7wIIgNMT0BdkjLlPM7EoRzaAi0j5xzZSbkd6bBaz2H33b0z7cIJxTarw bicSXDma3VacONJhc6KQ1WY7x085Ybz22g7YTzIrN9PRKtgOVy+LhZvMoIPh3hixC1KL FG1YqYAu8Oooybl5QVlk9R+3gN1yodXMradTahMSV2c4uV5b/RMBuEmGqKJ5BZEKbjBT ccY+FeDkUYE20zHbDnFLt6VzpkztyqnACi6BLeXfWnIFlOVDZNjWwfrTxSWLWCJ7C4mb 3QcCDLsX2bcacwpBkJNNyZI38xMV9bZwOIb9AffMGvpo2PwYX90eUT4WoaCyn9Kjvh8K z3dg== X-Received: by 10.182.215.193 with SMTP id ok1mr18173865obc.78.1373225108299; Sun, 07 Jul 2013 12:25:08 -0700 (PDT) Received: from [10.10.0.56] (cpe-66-25-3-111.tx.res.rr.com. [66.25.3.111]) by mx.google.com with ESMTPSA id i9sm29291026oem.7.2013.07.07.12.25.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 12:25:07 -0700 (PDT) Message-ID: <51D9C095.6060606@gmail.com> Date: Sun, 07 Jul 2013 14:25:09 -0500 From: William McCall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kireeti Kompella References: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> In-Reply-To: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , MPLS , Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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: Sun, 07 Jul 2013 19:25:09 -0000 [editorial stuff] Section 3, list element #4 says: " [...]If this decision is revisited later, an accompanying Standards Track RFC that details the use of the label, a discussion of possible sources of confusion between signaling and data plane, and mitigation thereof." Should say: Sentence is incomplete. I think you're looking for something like "[...] thereof shall be required". Section 3, list element #6 says: " [...]these packets be re-ordered." Should say: "[...]these packets may be re-ordered." Section 3.2 sub-part a says: "[...]not to include deprecated value[...]" Should say: "[...]not to include the deprecated value[...]" Section 5, list element #3 says: "[...]registry must be also say[...]" Should say: "[...]registry must also say[...]" --WM From lizho.jin@gmail.com Mon Jul 8 06:56:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3727421F9C4A for ; Mon, 8 Jul 2013 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHLUZjbJYtYN for ; Mon, 8 Jul 2013 06:56:45 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5797C21F9C49 for ; Mon, 8 Jul 2013 06:56:45 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so2261538qaj.13 for ; Mon, 08 Jul 2013 06:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ssCqPQxQPRzWFcnAvMBc1mCiwCKwVglQpamdWLDQxyk=; b=z8LdTFLkQVlqlsNV4Vb/C8+6vdacHLoamiOwv7+iZU6AnykBSTndcDKgMczcWxQCDz oUZwoJwqfdA4rkTdHN5Qt5Q9neIr/9ks2TdGR6QD9yRsBJNm02ZnPuNVQxJf2riKzJl5 ufrkmDq0nMvIeiUn9K1Dh40J/Pplnr0Hw0YShg6fEGh+Zej8bSgvGmKpvZXESjKnDbXC VnBeAOa22dcoPvSDmgWaVy8V0bmdOKKNvRZ4m5K1WKJ3HKmZh67HS8b8RGB7whYd74VC UcYSzoMZTbBnAkPygJ9Jeg337lVijXwsB0E5PNN23wCbG3/opgXWwc/wgw+6JpLrZVKi 9Keg== MIME-Version: 1.0 X-Received: by 10.229.56.67 with SMTP id x3mr3838946qcg.112.1373291803685; Mon, 08 Jul 2013 06:56:43 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Mon, 8 Jul 2013 06:56:43 -0700 (PDT) Date: Mon, 8 Jul 2013 21:56:43 +0800 Message-ID: From: Lizhong Jin To: Kireeti Kompella Content-Type: multipart/alternative; boundary=001a1133069021b89204e1006acd Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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, 08 Jul 2013 13:56:46 -0000 --001a1133069021b89204e1006acd Content-Type: text/plain; charset=ISO-8859-1 Hi Kireeti, I do not quite understand why having two entropy label possibilities would simplify the parsing. From my knowledge of the switching asic, the asic would always parse all the MPLS labels, and check each MPLS reserve label by indexing (not hashing) to a content register which indicates the entropy label property. If we have two possibilities for entropy label, then we have to use two registers in hardware for the same purpose. I do not see the benefit yet. Could you please indicate a bit? Regards Lizhong > > Message: 2 > Date: Sun, 7 Jul 2013 11:51:28 -0700 > From: Kireeti Kompella > To: MPLS > Cc: Ross Callon , Loa Andersson > Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01 > Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> > Content-Type: text/plain; charset="us-ascii" > > Hi All, > > I have updated this document with the following: > a) the range of Standards Action extended special purpose labels is > 16-239; experimental is 240-255. The rest are reserved for now. > b) I've added a question/answer on whether to use extended special purpose > labels in load balancing -- saying MUST NOT. > c) Clarified text regarding a label following an extended special purpose > (Xuxiaohu's comment). > > Finally, I note Lizhong's comment regarding label 7. The goal in allowing > label 7 as either a regular special purpose label or an extended special > purpose label is to simplify parsing when searching for an entropy label. > I added text around this, but did not change SHOULD NOT to MUST NOT. > > WG chairs, I believe this doc is ready for WG LC. > > Kireeti. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm > > > > ------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > End of mpls Digest, Vol 111, Issue 13 > ************************************* > --001a1133069021b89204e1006acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kireeti,
I do not quite understand why having two= entropy label possibilities would simplify the parsing. From my knowledge = of the switching asic, the asic would always parse all the MPLS labels, and= check each MPLS reserve label by indexing (not hashing) to a content regis= ter which indicates the entropy label property. If we have two possibilitie= s for entropy label, then we have to use two registers in hardware for the = same purpose. I do not see the benefit yet. Could you please indicate a bit= ?

Regards
Lizhong


=A0

Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <ki= reeti.kompella@gmail.com>
To: MPLS <mpls@ietf.org>
Cc: Ross Callon <rcallon@juniper.= net>, Loa Andersson <loa@pi.nu&g= t;
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255. =A0The rest are reserved for now.
b) I've added a question/answer on whether to use extended special purp= ose labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7. =A0The goal in all= owing label 7 as either a regular special purpose label or an extended spec= ial purpose label is to simplify parsing when searching for an entropy labe= l. =A0I added text around this, but did not change SHOULD NOT to MUST NOT.<= br>
WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>

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

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


End of mpls Digest, Vol 111, Issue 13
*************************************

--001a1133069021b89204e1006acd-- From kireeti.kompella@gmail.com Mon Jul 8 08:32:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C43F21F9CFB for ; Mon, 8 Jul 2013 08:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFiBCSJyte5P for ; Mon, 8 Jul 2013 08:32:14 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8B21F9CF7 for ; Mon, 8 Jul 2013 08:32:14 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so10143655ief.40 for ; Mon, 08 Jul 2013 08:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nYWJR2+bMo7emjzhZF0fYd2+MpVMjkuSou7NEp2Vd48=; b=tUO7tFT28qeAgtDLOZnZNWX4BxxARpRMaOr5Lk3CSBH28iNtn37AXEiyAP6H3O/ITB bkZ5eHwm6i7y5myMOHeAA6o1WajQ7nRHaBqyLkBghNP3a56HG2tmc/cZCGrlmbkLtWjQ HCso3tuQ21oItqztzygfdV03Tc6bKYu6fLiB8DMn2wnTNAL4KXbQkhtf3G+dztlD1RAU YP0Yum/EJgTWMnd8y123jiZGcY2rUSPlTPlET46Dblddtys057+O4uWfkCUFLJIu/P6G 8+XG8xqe9CAA+CpgFxIWPi3rd2G4VGUDjc6M2DuOeegETUBeLa4+1amWgH/TfoLM4vsw Ciyw== MIME-Version: 1.0 X-Received: by 10.50.124.1 with SMTP id me1mr8757772igb.45.1373297533084; Mon, 08 Jul 2013 08:32:13 -0700 (PDT) Received: by 10.64.10.71 with HTTP; Mon, 8 Jul 2013 08:32:13 -0700 (PDT) In-Reply-To: <51D9C095.6060606@gmail.com> References: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> <51D9C095.6060606@gmail.com> Date: Mon, 8 Jul 2013 08:32:13 -0700 Message-ID: From: Kireeti Kompella To: William McCall Content-Type: multipart/alternative; boundary=089e01182722a16d5504e101bf68 Cc: Ross Callon , MPLS , Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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, 08 Jul 2013 15:32:15 -0000 --089e01182722a16d5504e101bf68 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 12:25 PM, William McCall wrote: > [editorial stuff] > > Section 3, list element #4 says: > " [...]If this decision is revisited later, an accompanying Standards > Track RFC that details the use of the label, a discussion of possible > sources of confusion between signaling and data plane, and mitigation > thereof." > Should say: > Sentence is incomplete. I think you're looking for something like "[...] > thereof shall be required". > Sentence, spelled out, is: "... an accompanying Standards Track RFC that details a) the use of the label, b) a discussion of possible sources of confusion between signaling and data plane, and c) mitigation thereof." Seems complete to me. Section 3, list element #6 says: > " [...]these packets be re-ordered." > Should say: > "[...]these packets may be re-ordered." > Thanks, will fix. > Section 3.2 sub-part a says: > "[...]not to include deprecated value[...]" > Should say: > "[...]not to include the deprecated value[...]" > Ditto. > Section 5, list element #3 says: > "[...]registry must be also say[...]" > Should say: > "[...]registry must also say[...]" Ditto. Thanks, Kireeti. > --WM > -- Kireeti --089e01182722a16d5504e101bf68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 7, 2013 at 12:25 PM= , William McCall <william.mccall@gmail.com> wrote:
[editorial stuff]

Section 3, list element #4 says:
" [...]If this decision is revisited later, an accompanying Standards = Track RFC that details the use of the label, a discussion of possible sourc= es of confusion between signaling and data plane, and mitigation thereof.&q= uot;
Should say:
Sentence is incomplete. I think you're looking for something like "= ;[...] thereof shall be required".

Sentence, spelled out, is:

"...=A0an accompanying Standards Track RFC that details
a)=A0the use of the label,
b)=A0a discussion of possible = sources of confusion between signaling and data plane, and
= c)=A0mitigation thereof."

Seems complete to me.

<= /div>
Section 3, list element #6 says:
" [...]these packets be re-ordered."
Should say:
"[...]these packets may be re-ordered."

=
Thanks, will fix.
=A0
Section 3.2 sub-part a says:
"[...]not to include deprecated value[...]"
Should say:
"[...]not to include the deprecated value[...]"
<= div>
Ditto.
=A0
Section 5, list element #3 says:
"[...]registry must be also say[...]"
Should say:
"[...]registry must also say[...]"

Ditto.

Thanks,
Kireeti.
=A0
--WM



-- Kireeti --089e01182722a16d5504e101bf68-- From internet-drafts@ietf.org Mon Jul 8 21:25:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743AB21F9B9C; Mon, 8 Jul 2013 21:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8sE66PHi8b9; Mon, 8 Jul 2013 21:25:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D408721F9A51; Mon, 8 Jul 2013 21:25:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709042515.11983.18854.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 21:25:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-special-purpose-labels-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 04:25:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Allocating and Retiring Special Purpose MPLS Labels Author(s) : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-ietf-mpls-special-purpose-labels-02.txt Pages : 13 Date : 2013-07-08 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-special-purpose-labels-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 8 22:21:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8931D21F9F42; Mon, 8 Jul 2013 22:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BHJnEkXWuUh; Mon, 8 Jul 2013 22:21:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E590B21F9F3D; Mon, 8 Jul 2013 22:21:52 -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: 4.51.p2 Message-ID: <20130709052152.10184.36171.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 22:21:52 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-special-purpose-labels-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: Tue, 09 Jul 2013 05:21:53 -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 Gro= up of the IETF. Title : Allocating and Retiring Special Purpose MPLS Labels Author(s) : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-ietf-mpls-special-purpose-labels-03.txt Pages : 13 Date : 2013-07-08 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-special-purpose-labels-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kireeti.kompella@gmail.com Mon Jul 8 22:50:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF39A21F9F17 for ; Mon, 8 Jul 2013 22:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhKcmNqvD50m for ; Mon, 8 Jul 2013 22:50:45 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEB921F9F16 for ; Mon, 8 Jul 2013 22:50:45 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so5116390pab.20 for ; Mon, 08 Jul 2013 22:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=yatwNxeHvp1A7TBx3I4ecU7McsOut+lrqmIYTO438HQ=; b=0s0HQDw4ABBbAQ2ZEjKDafI4TtFNK9/wCO+d5HU9nGTBqAEnvsFk4seCGLuFiq/SKI 9xqH9WLdo8qvPwpYIoZWHnWp2ri2M6Y/V575wAxoA2FVh1Itlq6Af3nAwAJ5yCRBJY75 LRHyVY34NLh+w0kFeC+nwuV9BDfAn8QFuyt//7tBdYceY30v3bpQ/c8bS96llpHHM56b dwB49+/CfvDdkRB4v/8RYfPiklV1vbSZP9K4/ATJFj7qGZW6nIwQrszMd/Cr4h5rDoQy 23xzI3JZn71BWGlVSS5dBF9V3umwTN3l8rVVRYBq3vowQDGBzoxyias5djtIBJSiol7y N5eg== X-Received: by 10.66.83.7 with SMTP id m7mr26631537pay.150.1373349044867; Mon, 08 Jul 2013 22:50:44 -0700 (PDT) Received: from mileonard-sslvpn-nc.jnpr.net (natint3.juniper.net. [66.129.224.36]) by mx.google.com with ESMTPSA id y6sm26207903pbl.23.2013.07.08.22.50.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 22:50:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC891678-73B8-4448-9F50-33722A5889F0" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Kireeti Kompella In-Reply-To: Date: Mon, 8 Jul 2013 22:50:40 -0700 Message-Id: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> References: To: Lizhong Jin X-Mailer: Apple Mail (2.1508) Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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, 09 Jul 2013 05:50:48 -0000 --Apple-Mail=_BC891678-73B8-4448-9F50-33722A5889F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Lizhong, In the fast path in a transit LSR, would you prefer: a) look for label 7; then use the label after it as the entropy label; = OR b) look for a two label combination of , then use = the label after it as the entropy label? Let me explain (b). If we are strict about having only one entropy = label possibility, then an implementation _should_ look for a label = sequence of: < =85 !15 7 EL =85 > to truly identify an entropy label., since < =85 15 = 7 L =85 > is illegal, and does not identify L as an entropy label. = (Ignore the special case that the first label is 7.) In other words, if we say "MUST NOT use label 7 as an extended special = purpose label", then in principle, (b) is needed. If we are loose, then an implementation can simply look for < =85 7 EL =85= > without worrying about whether the label before 7 is 15. Of course, = this means that LSRs inserting an entropy label have two choices, but = they can choose just to use one. Senders have an easy time; I want = transit LSRs to have an easy time as well. Of course, receivers will = have to parse both possibilities. I can add: "Receivers processing = label 7 after an extension label MAY drop the packet" to re-emphasize = the "SHOULD NOT", but that seems like an overkill. Does that make sense? (Question to WG at large as well.) Kireeti. On Jul 8, 2013, at 06:56 , Lizhong Jin wrote: > Hi Kireeti, > I do not quite understand why having two entropy label possibilities = would simplify the parsing. =46rom my knowledge of the switching asic, = the asic would always parse all the MPLS labels, and check each MPLS = reserve label by indexing (not hashing) to a content register which = indicates the entropy label property. If we have two possibilities for = entropy label, then we have to use two registers in hardware for the = same purpose. I do not see the benefit yet. Could you please indicate a = bit? >=20 > Regards > Lizhong >=20 >=20 > =20 >=20 > Message: 2 > Date: Sun, 7 Jul 2013 11:51:28 -0700 > From: Kireeti Kompella > To: MPLS > Cc: Ross Callon , Loa Andersson > Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01 > Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi All, >=20 > I have updated this document with the following: > a) the range of Standards Action extended special purpose labels is = 16-239; experimental is 240-255. The rest are reserved for now. > b) I've added a question/answer on whether to use extended special = purpose labels in load balancing -- saying MUST NOT. > c) Clarified text regarding a label following an extended special = purpose (Xuxiaohu's comment). >=20 > Finally, I note Lizhong's comment regarding label 7. The goal in = allowing label 7 as either a regular special purpose label or an = extended special purpose label is to simplify parsing when searching for = an entropy label. I added text around this, but did not change SHOULD = NOT to MUST NOT. >=20 > WG chairs, I believe this doc is ready for WG LC. >=20 > Kireeti. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = >=20 > ------------------------------ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > End of mpls Digest, Vol 111, Issue 13 > ************************************* >=20 --Apple-Mail=_BC891678-73B8-4448-9F50-33722A5889F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Lizhong,

In the fast path in a = transit LSR, would you prefer:
a) look for label 7; then use the = label after it as the entropy label; OR
b) look for a two = label combination of <not label 15, label 7>, then use the label = after it as the entropy label?

Let me = explain (b).  If we are strict about having only one entropy label = possibility, then an implementation _should_ look for a label sequence = of:
< =85 !15 7 EL =85 > to truly = identify an entropy label., since < =85 15 7 L =85 > is illegal, = and does not identify L as an entropy label.  (Ignore the special = case that the first label is 7.)

In other = words, if we say "MUST NOT use label 7 as an extended special purpose = label", then in principle, (b) is needed.

If we are = loose, then an implementation can simply look for < =85 7 = EL =85 > without worrying about whether the label before 7 is 15. =  Of course, this means that LSRs inserting an entropy label have = two choices, but they can choose just to use one.  Senders have an = easy time; I want transit LSRs to have an easy time as well.  Of = course, receivers will have to parse both possibilities.  I can = add: "Receivers processing label 7 after an extension label MAY drop the = packet" to re-emphasize the "SHOULD NOT", but that seems like an = overkill.

Does that make sense?  (Question to WG at = large as well.)

Kireeti.

On Jul 8, 2013, at 06:56 , = Lizhong Jin <lizho.jin@gmail.com> = wrote:

Hi Kireeti,
I = do not quite understand why having two entropy label possibilities would = simplify the parsing. =46rom my knowledge of the switching asic, the = asic would always parse all the MPLS labels, and check each MPLS reserve = label by indexing (not hashing) to a content register which indicates = the entropy label property. If we have two possibilities for entropy = label, then we have to use two registers in hardware for the same = purpose. I do not see the benefit yet. Could you please indicate a = bit?

Regards
Lizhong


 

Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <kireeti.kompella@gmail.com&= gt;
To: MPLS <mpls@ietf.org>
Cc: Ross Callon <rcallon@juniper.net>, Loa = Andersson <loa@pi.nu>
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7A= E6-4739-A30B-838BB08F2F21@gmail.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is = 16-239; experimental is 240-255.  The rest are reserved for = now.
b) I've added a question/answer on whether to use extended special = purpose labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special = purpose (Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7.  The goal in = allowing label 7 as either a regular special purpose label or an = extended special purpose label is to simplify parsing when searching for = an entropy label.  I added text around this, but did not change = SHOULD NOT to MUST NOT.

WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20= 130707/a100d7d4/attachment.htm>

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

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


End of mpls Digest, Vol 111, Issue 13
*************************************


= --Apple-Mail=_BC891678-73B8-4448-9F50-33722A5889F0-- From kvivek@broadcom.com Mon Jul 8 23:20:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7807A21F9EBD for ; Mon, 8 Jul 2013 23:20:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAKTPOOPrnMz for ; Mon, 8 Jul 2013 23:20:50 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4321F9EAE for ; Mon, 8 Jul 2013 23:20:50 -0700 (PDT) Received: from [10.9.208.57] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 08 Jul 2013 23:14:51 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 8 Jul 2013 23:20:45 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Mon, 8 Jul 2013 23:20:45 -0700 From: "Vivek Kumar" To: "Kireeti Kompella" , "Lizhong Jin" Thread-Topic: [mpls] draft-ietf-mpls-special-purpose-labels-01 Thread-Index: AQHOe+L6jfLS1z/kfEi8xxRbcGJZR5lcTg4A//+OCwA= Date: Tue, 9 Jul 2013 06:20:44 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC42ADA7B34@SJEXCHMB09.corp.ad.broadcom.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> In-Reply-To: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DC575D11R042145449-01-01 Content-Type: multipart/alternative; boundary=_000_3C086BA39C55B9418AE8FEA3F3EFDEC42ADA7B34SJEXCHMB09corpa_ Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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, 09 Jul 2013 06:20:54 -0000 --_000_3C086BA39C55B9418AE8FEA3F3EFDEC42ADA7B34SJEXCHMB09corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Kireeti, One question. Why someone want to send label 15 ,label 7, EL when sam= e thing can be achieved by sending label 7,EL . IMHO , label 15 should be used only when someone wants to use extended s= pecial purpose registry . Regards, Vivek From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Tuesday, July 09, 2013 11:21 AM To: Lizhong Jin Cc: Ross Callon; mpls@ietf.org; Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01 Hi Lizhong, In the fast path in a transit LSR, would you prefer: a) look for label 7; then use the label after it as the entropy label; OR b) look for a two label combination of , then use th= e label after it as the entropy label? Let me explain (b). If we are strict about having only one entropy label p= ossibility, then an implementation _should_ look for a label sequence of: < ... !15 7 EL ... > to truly identify an entropy label., since < ... 15 7 = L ... > is illegal, and does not identify L as an entropy label. (Ignore t= he special case that the first label is 7.) In other words, if we say "MUST NOT use label 7 as an extended special purp= ose label", then in principle, (b) is needed. If we are loose, then an implementation can simply look for < ... 7 EL ... = > without worrying about whether the label before 7 is 15. Of course, this= means that LSRs inserting an entropy label have two choices, but they can = choose just to use one. Senders have an easy time; I want transit LSRs to = have an easy time as well. Of course, receivers will have to parse both po= ssibilities. I can add: "Receivers processing label 7 after an extension l= abel MAY drop the packet" to re-emphasize the "SHOULD NOT", but that seems = like an overkill. Does that make sense? (Question to WG at large as well.) Kireeti. On Jul 8, 2013, at 06:56 , Lizhong Jin > wrote: Hi Kireeti, I do not quite understand why having two entropy label possibilities would = simplify the parsing. From my knowledge of the switching asic, the asic wou= ld always parse all the MPLS labels, and check each MPLS reserve label by i= ndexing (not hashing) to a content register which indicates the entropy lab= el property. If we have two possibilities for entropy label, then we have t= o use two registers in hardware for the same purpose. I do not see the bene= fit yet. Could you please indicate a bit? Regards Lizhong Message: 2 Date: Sun, 7 Jul 2013 11:51:28 -0700 From: Kireeti Kompella > To: MPLS > Cc: Ross Callon >, Loa Ande= rsson > Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01 Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> Content-Type: text/plain; charset=3D"us-ascii" Hi All, I have updated this document with the following: a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255. The rest are reserved for now. b) I've added a question/answer on whether to use extended special purpose = labels in load balancing -- saying MUST NOT. c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment). Finally, I note Lizhong's comment regarding label 7. The goal in allowing = label 7 as either a regular special purpose label or an extended special pu= rpose label is to simplify parsing when searching for an entropy label. I = added text around this, but did not change SHOULD NOT to MUST NOT. WG chairs, I believe this doc is ready for WG LC. Kireeti. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 111, Issue 13 ************************************* --_000_3C086BA39C55B9418AE8FEA3F3EFDEC42ADA7B34SJEXCHMB09corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Kireeti,

   One question= . Why someone want to  send  label 15 ,label  7, EL when sam= e thing can be achieved by sending label 7,EL  .

   IMHO , = label 15 should be used only when someone wants to use extended special pur= pose registry .

 <= /p>

Regards,

Vivek

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti Kompella
Sent: Tuesday, July 09, 2013 11:21 AM
To: Lizhong Jin
Cc: Ross Callon; mpls@ietf.org; Loa Andersson
Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01

 

Hi Lizhong,

 

In the fast path in a transit LSR, would you prefer:=

a) look for label 7; then use the label after it as = the entropy label; OR

b) look for a two label combination of <not label= 15, label 7>, then use the label after it as the entropy label?

 

Let me explain (b).  If we are strict about hav= ing only one entropy label possibility, then an implementation _should_ loo= k for a label sequence of:

< … !15 7 EL … > to truly identify= an entropy label., since < … 15 7 L … > is illegal, and = does not identify L as an entropy label.  (Ignore the special case tha= t the first label is 7.)

 

In other words, if we say "MUST NOT use label 7= as an extended special purpose label", then in principle, (b) is need= ed.

 

If we are loose, then an implementation can simply&n= bsp;look for < … 7 EL … > without worrying about whe= ther the label before 7 is 15.  Of course, this means that LSRs insert= ing an entropy label have two choices, but they can choose just to use one.  Senders have an easy time; I want transit LSRs to have an e= asy time as well.  Of course, receivers will have to parse both possib= ilities.  I can add: "Receivers processing label 7 after an exten= sion label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that seems like an overkill.

 

Does that make sense?  (Question to WG at large= as well.)

 

Kireeti.

 

On Jul 8, 2013, at 06:56 , Lizhong Jin <lizho.jin@gmail.com> wrote:



Hi Kireeti,

I do not quite understand why having two entropy lab= el possibilities would simplify the parsing. From my knowledge of the switc= hing asic, the asic would always parse all the MPLS labels, and check each = MPLS reserve label by indexing (not hashing) to a content register which indicates the entropy label property.= If we have two possibilities for entropy label, then we have to use two re= gisters in hardware for the same purpose. I do not see the benefit yet. Cou= ld you please indicate a bit?

 

Regards

Lizhong

 

 

 


Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <ki= reeti.kompella@gmail.com>
To: MPLS <mpls@ietf.org>
Cc: Ross Callon <rcallon@juniper.= net>, Loa Andersson <loa@pi.nu&g= t;
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255.  The rest are reserved for now.
b) I've added a question/answer on whether to use extended special purpose = labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7.  The goal in allo= wing label 7 as either a regular special purpose label or an extended speci= al purpose label is to simplify parsing when searching for an entropy label= .  I added text around this, but did not change SHOULD NOT to MUST NOT.

WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>

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

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


End of mpls Digest, Vol 111, Issue 13
*************************************

 

 

--_000_3C086BA39C55B9418AE8FEA3F3EFDEC42ADA7B34SJEXCHMB09corpa_-- From akatlas@gmail.com Tue Jul 9 05:29:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7DC11E8117 for ; Tue, 9 Jul 2013 05:29:12 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub-4qzQwZ8DP for ; Tue, 9 Jul 2013 05:29:11 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9321F9F9D for ; Tue, 9 Jul 2013 05:29:08 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so12506528iet.37 for ; Tue, 09 Jul 2013 05:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KE7qXhXgDcU6gVyj/nDflHWT6VLcCMbehvdYupwdPFE=; b=o0suQVhw4lp3EOmeStswpLVqztq/88dBqQZGH2IBDC+Wq9BLu0vZJ5tEYZPlN6/ejs STouSoRsgtrtC5jxGMFbIertX74jBOOODxhZxOs0f7q7bTpKB17VsBCV+OkuSczeUPm2 RTvqm5MWVRMbAywneMcNIPU7j3vob3YoOnqOvgoxX7ljpyC/0gJRncb7hj+Bs0CLYuQS JH8TpQkSok/NSwxlxWHXoVzYxPQzDXamfPBiXiFafU3J806dFtctsoNduCAZgP/xiAVZ ktsyyWITnGS0DVXfoOZ3AFpWYdzwvGWdNkRmJf3qXKV46ebH6gWBXkpcXRqv0l/m8RRa Ez5g== MIME-Version: 1.0 X-Received: by 10.50.67.111 with SMTP id m15mr9929641igt.54.1373372946939; Tue, 09 Jul 2013 05:29:06 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 9 Jul 2013 05:29:06 -0700 (PDT) In-Reply-To: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> Date: Tue, 9 Jul 2013 08:29:06 -0400 Message-ID: From: Alia Atlas To: Kireeti Kompella Content-Type: multipart/alternative; boundary=047d7bd75244a5883f04e1134e9b Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson , Lizhong Jin Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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, 09 Jul 2013 12:29:12 -0000 --047d7bd75244a5883f04e1134e9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think it makes sense and helps clarify the reasoning. It would be useful to have a sentence or two in the draft changing: "Label 7 (when received) retains its meaning as ELI whether a regular or an extended special purpose label; this is to simplify the logic for transit LSRs looking for entropy labels." to "Label 7 (when received) retains its meaning as ELI whether a regular or an extended special purpose label; this simplifies a transit LSR's task of looking for entropy labels since it may just look for label 7 and need not verify that the previous label in the stack is not the Extension Label 15. Alia On Tue, Jul 9, 2013 at 1:50 AM, Kireeti Kompella wrote: > Hi Lizhong, > > In the fast path in a transit LSR, would you prefer: > a) look for label 7; then use the label after it as the entropy label; OR > b) look for a two label combination of , then use > the label after it as the entropy label? > > Let me explain (b). If we are strict about having only one entropy label > possibility, then an implementation _should_ look for a label sequence of= : > < =85 !15 7 EL =85 > to truly identify an entropy label., since < =85 15 = 7 L =85 > > is illegal, and does not identify L as an entropy label. (Ignore the > special case that the first label is 7.) > > In other words, if we say "MUST NOT use label 7 as an extended special > purpose label", then in principle, (b) is needed. > > If we are loose, then an implementation can simply look for < =85 7 EL = =85 > > without worrying about whether the label before 7 is 15. Of course, this > means that LSRs inserting an entropy label have two choices, but they can > choose just to use one. Senders have an easy time; I want transit LSRs t= o > have an easy time as well. Of course, receivers will have to parse both > possibilities. I can add: "Receivers processing label 7 after an extensi= on > label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that see= ms > like an overkill. > > Does that make sense? (Question to WG at large as well.) > > Kireeti. > > On Jul 8, 2013, at 06:56 , Lizhong Jin wrote: > > Hi Kireeti, > I do not quite understand why having two entropy label possibilities woul= d > simplify the parsing. From my knowledge of the switching asic, the asic > would always parse all the MPLS labels, and check each MPLS reserve label > by indexing (not hashing) to a content register which indicates the entro= py > label property. If we have two possibilities for entropy label, then we > have to use two registers in hardware for the same purpose. I do not see > the benefit yet. Could you please indicate a bit? > > Regards > Lizhong > > > > >> >> Message: 2 >> Date: Sun, 7 Jul 2013 11:51:28 -0700 >> From: Kireeti Kompella >> To: MPLS >> Cc: Ross Callon , Loa Andersson >> Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01 >> Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi All, >> >> I have updated this document with the following: >> a) the range of Standards Action extended special purpose labels is >> 16-239; experimental is 240-255. The rest are reserved for now. >> b) I've added a question/answer on whether to use extended special >> purpose labels in load balancing -- saying MUST NOT. >> c) Clarified text regarding a label following an extended special purpos= e >> (Xuxiaohu's comment). >> >> Finally, I note Lizhong's comment regarding label 7. The goal in >> allowing label 7 as either a regular special purpose label or an extende= d >> special purpose label is to simplify parsing when searching for an entro= py >> label. I added text around this, but did not change SHOULD NOT to MUST = NOT. >> >> WG chairs, I believe this doc is ready for WG LC. >> >> Kireeti. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://www.ietf.org/mail-archive/web/mpls/attachments/20130707/a100d7d4/= attachment.htm >> > >> >> ------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> End of mpls Digest, Vol 111, Issue 13 >> ************************************* >> > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --047d7bd75244a5883f04e1134e9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think it makes sense and helps clarify the reasoning. = =A0It would be useful to have a sentence or two in the draft changing:
<= br>"Label 7 (when received) retains its meaning as ELI whether a regul= ar
or an extended special purpose label; this is to simplify the logic
for = transit LSRs looking for entropy labels."

to

"Label= 7 (when received) retains its meaning as ELI whether a regular or an exten= ded special purpose label; this simplifies a transit LSR's task of look= ing for entropy labels since it may just look for label 7 and need not veri= fy that the previous label in the stack is not the Extension Label 15.

Alia


On Tue, Jul 9, 2013 at 1:50 AM, Kireeti Kompella <kireeti.kompella@gmail.com> wrote:
Hi Lizho= ng,

In the fast path in a transit LSR, = would you prefer:
a) look for label 7; then use the label after it as the entropy label; OR
b) look for a two label combination of <not label 15, label 7&g= t;, then use the label after it as the entropy label?

Let me explain (b). =A0If we are stric= t about having only one entropy label possibility, then an implementation _= should_ look for a label sequence of:
< = =85 !15 7 EL =85 > to truly identify an entropy label., since < =85 1= 5 7 L =85 > is illegal, and does not identify L as an entropy label. =A0= (Ignore the special case that the first label is 7.)

In other wo= rds, if we say "MUST NOT use label 7 as an extended special purpose la= bel", then in principle, (b) is needed.

If we are loose, then an implementatio= n can simply=A0look=A0for < =85 7 EL =85 > without worrying about whe= ther the label before 7 is 15. =A0Of course, this means that LSRs inserting= an entropy label have two choices, but they can choose just to use one. = =A0Senders have an easy time; I want transit LSRs to have an easy time as w= ell. =A0Of course, receivers will have to parse both possibilities. =A0I ca= n add: "Receivers processing label 7 after an extension label MAY drop= the packet" to re-emphasize the "SHOULD NOT", but that seem= s like an overkill.

Does that m= ake sense? =A0(Question to WG at large as well.)

Kireeti.

On Jul 8, 2013, at 06:56 , Lizhong Jin <lizho.jin@gmail.com> wr= ote:

Hi Kireeti,
I do not quite unders= tand why having two entropy label possibilities would simplify the parsing.= From my knowledge of the switching asic, the asic would always parse all t= he MPLS labels, and check each MPLS reserve label by indexing (not hashing)= to a content register which indicates the entropy label property. If we ha= ve two possibilities for entropy label, then we have to use two registers i= n hardware for the same purpose. I do not see the benefit yet. Could you pl= ease indicate a bit?

Regards
Lizhong


=
=A0

Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <kireeti.kompella@gmail.com>
To: MPLS <mpls@ietf.o= rg>
Cc: Ross Callon <rcallon@juniper.net>, Loa Andersson <loa@pi.nu>
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com= >
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255. =A0The rest are reserved for now.
b) I've added a question/answer on whether to use extended special purp= ose labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7. =A0The goal in all= owing label 7 as either a regular special purpose label or an extended spec= ial purpose label is to simplify parsing when searching for an entropy labe= l. =A0I added text around this, but did not change SHOULD NOT to MUST NOT.<= br>
WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>

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

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


End of mpls Digest, Vol 111, Issue 13
*************************************



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


--047d7bd75244a5883f04e1134e9b-- From lizho.jin@gmail.com Tue Jul 9 07:55:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D821F99F0 for ; Tue, 9 Jul 2013 07:55:51 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW9Kil2km8EE for ; Tue, 9 Jul 2013 07:55:50 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id EA56421F934C for ; Tue, 9 Jul 2013 07:55:46 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so3032933qeb.41 for ; Tue, 09 Jul 2013 07:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TXBeE/LPlTRvqZQkQ072vvbYjd1IPl2BEyKymhxRJIo=; b=OcFErk/q0D7jARvbEZV1NVEVkStzOepQpHbEqCoXZDq3+edfHkEWatn+6RtsWHSxoq arsHs7foCzrriyqyMOa0sIGrwoFO7Bh4TbuFgkOAskl4NezIviJKxrDLWMKkSd6dYwNe Hpd6+c/IjKPMvJaaR79y4VIkuPLQMZqdQdKA2Ax0ntq3VvBCjFdJd+WNd+j/qH1gmwwS 7ERwJ1QvscZQI1H6I02KBXS+p+pvKiUdT9HuDFUIMfBNY1DgmyqBXIa6KrCJBzXReZJc IBxeTbECzWJ1Lp52nv8VO5i1duNVy/p8CtUAQVuF7353JORQoSTc57iyMIhIYkSa63a5 jzNQ== MIME-Version: 1.0 X-Received: by 10.224.151.137 with SMTP id c9mr24162136qaw.107.1373381746424; Tue, 09 Jul 2013 07:55:46 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Tue, 9 Jul 2013 07:55:46 -0700 (PDT) In-Reply-To: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> Date: Tue, 9 Jul 2013 22:55:46 +0800 Message-ID: From: Lizhong Jin To: Kireeti Kompella Content-Type: multipart/alternative; boundary=089e01494bb023000804e1155bb2 Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-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, 09 Jul 2013 14:55:51 -0000 --089e01494bb023000804e1155bb2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kireeti, On Tue, Jul 9, 2013 at 1:50 PM, Kireeti Kompella wrote: > Hi Lizhong, > > In the fast path in a transit LSR, would you prefer: > a) look for label 7; then use the label after it as the entropy label; OR > b) look for a two label combination of , then use > the label after it as the entropy label? > > Let me explain (b). If we are strict about having only one entropy label > possibility, then an implementation _should_ look for a label sequence of= : > < =85 !15 7 EL =85 > to truly identify an entropy label., since < =85 15 = 7 L =85 > > is illegal, and does not identify L as an entropy label. (Ignore the > special case that the first label is 7.) > [Lizhong] I understand your motivation now. But the ASIC will always parse all MPLS labels, and it is not necessary to get the specific EL value by looking up 7, LSR could simply hash all MPLS labels (except RSV label) to do the forwarding. In some implementation, the purpose of label 7 is to get the next service label for forwarding by skipping EL, not to get the EL. I mean two ELI possibilities will not simplify the logic to get EL, hardware will parse every label whatever it is EL or not. Regards Lizhong > In other words, if we say "MUST NOT use label 7 as an extended special > purpose label", then in principle, (b) is needed. > > If we are loose, then an implementation can simply look for < =85 7 EL = =85 > > without worrying about whether the label before 7 is 15. Of course, this > means that LSRs inserting an entropy label have two choices, but they can > choose just to use one. Senders have an easy time; I want transit LSRs t= o > have an easy time as well. Of course, receivers will have to parse both > possibilities. I can add: "Receivers processing label 7 after an extensi= on > label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that see= ms > like an overkill. > > Does that make sense? (Question to WG at large as well.) > > Kireeti. > > On Jul 8, 2013, at 06:56 , Lizhong Jin wrote: > > Hi Kireeti, > I do not quite understand why having two entropy label possibilities woul= d > simplify the parsing. From my knowledge of the switching asic, the asic > would always parse all the MPLS labels, and check each MPLS reserve label > by indexing (not hashing) to a content register which indicates the entro= py > label property. If we have two possibilities for entropy label, then we > have to use two registers in hardware for the same purpose. I do not see > the benefit yet. Could you please indicate a bit? > > Regards > Lizhong > > > > >> >> Message: 2 >> Date: Sun, 7 Jul 2013 11:51:28 -0700 >> From: Kireeti Kompella >> To: MPLS >> Cc: Ross Callon , Loa Andersson >> Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01 >> Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi All, >> >> I have updated this document with the following: >> a) the range of Standards Action extended special purpose labels is >> 16-239; experimental is 240-255. The rest are reserved for now. >> b) I've added a question/answer on whether to use extended special >> purpose labels in load balancing -- saying MUST NOT. >> c) Clarified text regarding a label following an extended special purpos= e >> (Xuxiaohu's comment). >> >> Finally, I note Lizhong's comment regarding label 7. The goal in >> allowing label 7 as either a regular special purpose label or an extende= d >> special purpose label is to simplify parsing when searching for an entro= py >> label. I added text around this, but did not change SHOULD NOT to MUST = NOT. >> >> WG chairs, I believe this doc is ready for WG LC. >> >> Kireeti. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://www.ietf.org/mail-archive/web/mpls/attachments/20130707/a100d7d4/= attachment.htm >> > >> >> ------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> End of mpls Digest, Vol 111, Issue 13 >> ************************************* >> > > > --089e01494bb023000804e1155bb2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Kireeti,


On Tue, Jul 9, 2013 at= 1:50 PM, Kireeti Kompella <kireeti.kompella@gmail.com> wrote:
Hi Lizho= ng,

In the fast path in a transit LSR, = would you prefer:
a) look for label 7; then use the label after it as the entropy label;= OR
b) look for a two label combination of <not label 15, labe= l 7>, then use the label after it as the entropy label?

Let me expl= ain (b). =A0If we are strict about having only one entropy label possibilit= y, then an implementation _should_ look for a label sequence of:
< =85 !15 7 EL =85 > to truly identify an entropy label., since < = =85 15 7 L =85 > is illegal, and does not identify L as an entropy label= . =A0(Ignore the special case that the first label is 7.)
=
[Lizhong] I understand your motivation now. But the ASIC will always p= arse all MPLS labels, and it is not necessary to get the specific EL value = by looking up 7, LSR could simply hash all MPLS labels (except RSV label) t= o do the forwarding. In some implementation, the purpose of label 7 is to g= et the next service label for forwarding by skipping EL, not to get the EL.= I mean two ELI possibilities will not simplify the logic to get EL, hardwa= re will parse every label whatever it is EL or not.

Regards
Lizhong


=

In other wo= rds, if we say "MUST NOT use label 7 as an extended special purpose la= bel", then in principle, (b) is needed.

If we are loose, then an implementatio= n can simply=A0look=A0for < =85 7 EL =85 > without worrying about whe= ther the label before 7 is 15. =A0Of course, this means that LSRs inserting= an entropy label have two choices, but they can choose just to use one. = =A0Senders have an easy time; I want transit LSRs to have an easy time as w= ell. =A0Of course, receivers will have to parse both possibilities. =A0I ca= n add: "Receivers processing label 7 after an extension label MAY drop= the packet" to re-emphasize the "SHOULD NOT", but that seem= s like an overkill.

Does that m= ake sense? =A0(Question to WG at large as well.)

Kireeti.

On Jul 8, 2013, at 06:56 , Lizhong Jin <lizho.jin@gmail.com&g= t; wrote:

<= div class=3D"gmail_quote">
Hi Kireeti,
I do not quite underst= and why having two entropy label possibilities would simplify the parsing. = >From my knowledge of the switching asic, the asic would always parse all th= e MPLS labels, and check each MPLS reserve label by indexing (not hashing) = to a content register which indicates the entropy label property. If we hav= e two possibilities for entropy label, then we have to use two registers in= hardware for the same purpose. I do not see the benefit yet. Could you ple= ase indicate a bit?

Regards
Lizhong


=
=A0

Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <kireeti.kompella@gmail.com>
To: MPLS <mpls@ietf.o= rg>
Cc: Ross Callon <rcallon@juniper.net>, Loa Andersson <loa@pi.nu>
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com= >
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255. =A0The rest are reserved for now.
b) I've added a question/answer on whether to use extended special purp= ose labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7. =A0The goal in all= owing label 7 as either a regular special purpose label or an extended spec= ial purpose label is to simplify parsing when searching for an entropy labe= l. =A0I added text around this, but did not change SHOULD NOT to MUST NOT.<= br>
WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>

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

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


End of mpls Digest, Vol 111, Issue 13
*************************************



--089e01494bb023000804e1155bb2-- From akatlas@gmail.com Tue Jul 9 09:42:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7877F21F8BCE for ; Tue, 9 Jul 2013 09:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.396 X-Spam-Level: ** X-Spam-Status: No, score=2.396 tagged_above=-999 required=5 tests=[AWL=-4.994, BAYES_00=-2.599, CN_BODY_35=0.339, GB_SUMOF=5, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiOG+C1-cqIR for ; Tue, 9 Jul 2013 09:42:08 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 37ED721F9D0F for ; Tue, 9 Jul 2013 09:42:08 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so13390750iec.35 for ; Tue, 09 Jul 2013 09:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zsqrxlii/JaJnyrA9iU4Bj/lNiApBOtaEcOAXslQlPQ=; b=i0cekTw2J6706i1XS05YG4abAmbIEFryvwmL9CPbxLezdK5i+JcnsQF5h+ppe4Gn15 ddrIJddKrPuh/F5KnF/FxLtnPsL+kGn/SaDI6chhOkLKBVip0q/eSRcfSH7RqWquoffQ z6saWzpIcjGXgpcikrTg2hOr/cn1nAgewgOj6HcsLO7qFDsuEODBucvoaaIv6Cr9/kzL IL3Pu54Dkby9vRSdNwsbEGlnrHGq4POVsjJCUoo9Huma3k6NPT9EaSthJ9kvIEoO1e9R ajy2czSkMk+3FGupqHrOcX3SIomnxoATSADq/gvMNq/aplRUYpKLebeFteQZZRPp0z66 ELog== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr8794453icb.2.1373388127760; Tue, 09 Jul 2013 09:42:07 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 9 Jul 2013 09:42:07 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BBD3@NKGEML512-MBS.china.huawei.com> References: <515FA9AF.7080705@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BBD3@NKGEML512-MBS.china.huawei.com> Date: Tue, 9 Jul 2013 12:42:07 -0400 Message-ID: From: Alia Atlas To: Xuxiaohu Content-Type: multipart/alternative; boundary=bcaec511e1b67e7a5804e116d705 Cc: "mpls@ietf.org" , "draft-atlas-mpls-te-express-path@tools.ietf.org" , Loa Andersson , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:42:09 -0000 --bcaec511e1b67e7a5804e116d705 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Xuxiaohu, I apologize for the long delay in responding. On Wed, Apr 10, 2013 at 12:17 AM, Xuxiaohu wrote: > Hi all, > > I have reviewed this doc. I believe this doc is useful, but I have a few > comments as follows for consideration: > > 1. in section 2.1, it said " While it has been possible to compute a CSPF > where the link latency > values are used instead of TE metrics, this results in ignoring the > TE metrics and causing LSPs to prefer the lowest-latency paths. > Instead of this approach to minimize path latency, an end-to-end > latency bound merely requires that the path computed be no more than > that bound without being the minimum. This bound can be used as a > constraint in CSPF to prevent exploring links that would create a > path over the end-to-end latency bound. > > This is illustrated as follows. Let the LSP have an end-to-end > latency bound of 20ms. Assume that the path to node X has been > minimized and its latency is 12ms. When X's links are to be > explored, the link X<->Y has a link latency of 5ms and the link X<->Z > has a link latency of 9ms. The path via X to Y along link X<->Y > would have a path latency of 12ms + 5ms =3D 17ms < 20ms; therefore, th= e > link X<->Y can be explored. In contrast, reaching Z via link X<->Z > would result in a path latency of 12ms + 9ms =3D 21ms > 20ms; therefor= e > the link X<->Z would not be explored in the CSPF." > > Comment: According to an above statement of " an end-to-end latency > bound merely requires that the path computed be no more than that bound > without being the minimum ", it seems that latency is not used as a metri= c > for SPF algorithm but only used as a constraint. If so, how do you decide > which specific link(s) of the first-round calculated SPF path should be > pruned prior to executing the second-round SPF calculation? The same > question exists when considering end-to-end packet loss ratio and latency > variation bounds. The example illustrated in the draft seems not clear to > me. Would any co-author please clarify the above doubt? > I am not sure where the confusion lies. This is known to be a heuristic rather than an optimal algorithm, as is written. I do not know what you precisely mean by a first-round calculated SPF vs. a second-round SPF calculation. I've added the following pseudo-code example: CSPF_with_bound(root, latency_bound) root.distance =3D 0 root.latency =3D 0 fibheap_insert(root, root.distance) while (fibheap_not_empty()) next_rtr =3D fibheap_pop for each link next_link attached to next_rtr if (next_rtr.latency + next_link.latency) < latency_bound explore_link(next_rtr, next_link) Explore_Link(next_rtr, next_link) if (next_rtr.distance + next_link.metric) < next_link->neighbor.distanc= e next_link->neighbor.distance =3D next_rtr.distance + next_link.metri= c next_link->neighbor.latency =3D next_rtr.latency + next_link.latency if (next_rtr.distance + next_link.metric) =3D=3D next_link->neighbor.distance if (next_rtr.latency + next_link.latency) < next_link->neighbor.latency next_link->neighbor.latency =3D next_rtr.latency + next_link.latency > 2. in section 2.1, it said "For link loss, the path loss is not the sum > of the used links' > losses. Instead, the path loss percentage is (100 - loss_L1)*(100 - > loss_L2)*...*(100 - loss_Ln), where the links along the path are L1 > to Ln. The end-to-end link loss bound, computed in this fashion, can > also be used as a constraint in the CSPF on what links to explore". > > Comment: I guess co-authors wanted to say packet loss ratio here. If > so, the formula of packet loss ratio here needs to be correctly expressed= . > This should have had 100 - in front of it - so basically the path loss percentage is (100 - ((100 - loss_L1)*...(100 - loss_Ln)) (100 - loss_L1) is the traffic that makes it to link 2 (L2) and then (100 - loss_L1)*(100 - loss_L2) is the traffic that makes it to L3 and so. ((100 - loss_L1) *... (100 - loss_Ln)) is the percentage of traffic that makes it to the end of the path. > 3. In section 2.2, it said " When computing > the path for a TE tunnel, only links with at least a configurable > amount of Unidirectional Available Bandwidth might be permitted." > > Comment: I wonder whether it is suitable to consider Residual Bandwidt= h > and Unidirectional Available Bandwidth parameters as performance metrics > and therefore discuss them in this doc. Furthermore, whether or not the > measured bandwidth used for the actual forwarding of non- > RSVP-TE LSP packets should be a constraint for CSPF depends on many > factors, such as whether or not this bandwidth can be occupied by future > RSVP-TE LSP traffic. Hence, maybe it's more suitable to discuss in detail= s > the bandwidth constraint related issues in a separate doc. > Does more need to be said about this? It's an ingress decision based on configuration... Thanks for the review! Alia > > Best regards, > Xiaohu > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Loa Andersson [mailto:loa@pi.nu] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA4=D4=C26=C8=D5 12:51 > > =CA=D5=BC=FE=C8=CB: Dutta, Pranjal K (Pranjal); Sriganesh Kini; Rajiv A= sati (rajiva); > Xuxiaohu; > > draft-atlas-mpls-te-express-path@tools.ietf.org; > mpls-chairs@tools.ietf.org > > =D6=F7=CC=E2: MPLS-RT review of draft-atlas-mpls-te-express-path > > > > Xiaohu, Sri, Rajiv and Pranjal, > > > > You have been selected as an MPLS Review team reviewers for > > draft-atlas-mpls-te-express-path-02. > > > > Note to authors: You have been CC'd on this email so that you can know > > that this review is going on. However, please do not review your own > > document. > > > > Reviews should comment on whether the document is coherent, is it > > useful (ie, is it likely to be actually useful in operational > > networks), and is the document technically sound? We are interested > > in knowing whether the document is ready to be considered for WG > > adoption (ie, it doesn't have to be perfect at this point, but should b= e > > a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and > > WG secretary, and CC'd to the MPLS WG email list. If necessary, comment= s > > may be sent privately to only the WG chairs. > > > > Are you able to review this draft by April 20, 2013? > > > > Thanks, Loa > > (as MPLS WG chair) > > > > /Loa > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --bcaec511e1b67e7a5804e116d705 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Xuxiaohu,

I apologize for the long d= elay in responding.

On Wed, Apr 10, 2013 at 12:17 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
Hi all,

I have reviewed this doc. I believe this doc is useful, but I have a few co= mments as follows for consideration:

1. in section 2.1, it said " While it has been possible to compute a C= SPF where the link latency
   values are used instead of TE metrics, this results in ignorin= g the
   TE metrics and causing LSPs to prefer the lowest-latency paths= .
   Instead of this approach to minimize path latency, an end-to-e= nd
   latency bound merely requires that the path computed be no mor= e than
   that bound without being the minimum.  This bound can be = used as a
   constraint in CSPF to prevent exploring links that would creat= e a
   path over the end-to-end latency bound.

   This is illustrated as follows.  Let the LSP have an end-= to-end
   latency bound of 20ms.  Assume that the path to node X ha= s been
   minimized and its latency is 12ms.  When X's links ar= e to be
   explored, the link X<->Y has a link latency of 5ms and t= he link X<->Z
   has a link latency of 9ms.  The path via X to Y along lin= k X<->Y
   would have a path latency of 12ms + 5ms =3D 17ms < 20ms; th= erefore, the
   link X<->Y can be explored.  In contrast, reaching = Z via link X<->Z
   would result in a path latency of 12ms + 9ms =3D 21ms > 20m= s; therefore
   the link X<->Z would not be explored in the CSPF."<= br>
   Comment: According to an above statement of " an end-to-e= nd latency bound merely requires that the path computed be no more than tha= t bound without being the minimum ", it seems that latency is not used= as a metric for SPF algorithm but only used as a constraint. If so, how do= you decide which specific link(s) of the first-round calculated SPF path s= hould be pruned prior to executing the second-round SPF calculation?  = The same question exists when considering end-to-end packet loss ratio and = latency variation bounds. The example illustrated in the draft seems not cl= ear to me. Would any co-author please clarify the above doubt?

I am not sure where the confusion lies. &n= bsp; This is known to be a heuristic rather than an optimal algorithm, as i= s written.

I do not know what you precisely mean b= y a first-round calculated SPF vs. a second-round SPF calculation.

I've added the following pseudo-code example:
=


  CSPF_with_bound(root, latenc= y_bound)
    root.distance =3D 0
   = ; root.latency =3D 0
    fibheap_insert(root, root.distance)
  &nb= sp; while (fibheap_not_empty())
       next_r= tr =3D fibheap_pop
       for each link next_= link attached to next_rtr
          if (= next_rtr.latency + next_link.latency) < latency_bound
              explore_link(next_rtr= , next_link)

  Explore_Link(next_rtr, next_li= nk)
    if (next_rtr.distance + next_link.metric) < = next_link->neighbor.distance
       next_l= ink->neighbor.distance =3D next_rtr.distance + next_link.metric
       next_link->neighbor.latency =3D next_rtr= .latency + next_link.latency
    if (next_rtr.distance = + next_link.metric) =3D=3D next_link->neighbor.distance
 =      if (next_rtr.latency + next_link.latency) < next_li= nk->neighbor.latency
           next_link->neighbor.latenc= y =3D next_rtr.latency + next_link.latency

<= br>
 
2.  in section 2.1, it said "For link loss, the path loss is not = the sum of the used links'
   losses.  Instead, the path loss percentage is (100 - loss= _L1)*(100 -
   loss_L2)*...*(100 - loss_Ln), where the links along the path a= re L1
   to Ln.  The end-to-end link loss bound, computed in this = fashion, can
   also be used as a constraint in the CSPF on what links to expl= ore".

   Comment: I guess co-authors wanted to say packet loss ratio he= re. If so, the formula of packet loss ratio here needs to be correctly expr= essed.

This should have had 100 - in fr= ont of it - so basically
the path loss percentage is (100 - ((100 - loss_L1)*...(100 - loss_Ln)= )

(100 - loss_L1) is the traffic that makes it to = link 2 (L2) and then (100 - loss_L1)*(100 - loss_L2) is the traffic that ma= kes it to L3 and so.
((100 - loss_L1) *... (100 - loss_Ln)) is the percentage of traffic th= at makes it to the end of the path.
  
3.  In section 2.2, it said " When computing
   the path for a TE tunnel, only links with at least a configura= ble
   amount of Unidirectional Available Bandwidth might be permitte= d."

   Comment: I wonder whether it is suitable to consider Residual = Bandwidth and Unidirectional Available Bandwidth parameters as performance = metrics and therefore discuss them in this doc. Furthermore, whether or not= the measured bandwidth used for the actual forwarding of non-
   RSVP-TE LSP packets should be a constraint for CSPF depends on= many factors, such as whether or not this bandwidth can be occupied by fut= ure RSVP-TE LSP traffic. Hence, maybe it's more suitable to discuss in = details the bandwidth constraint related issues in a separate doc.

Does more need to be said about this? &nbs= p;It's an ingress decision based on configuration...

Thanks for the review!
Alia
 

Best regards,
Xiaohu


> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Loa Andersson [mailto:loa@pi.nu]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA4=D4=C26=C8=D5 12:51
> =CA=D5=BC=FE=C8=CB: Dutta, Pranjal K (Pranjal); Sriganesh Kini; Rajiv = Asati (rajiva); Xuxiaohu;
> dra= ft-atlas-mpls-te-express-path@tools.ietf.org; mpls-chairs@tools.ietf.org
> =D6=F7=CC=E2: MPLS-RT review of draft-atlas-mpls-te-express-path
>
> Xiaohu, Sri, Rajiv and Pranjal,
>
> You have been selected as an MPLS Review team reviewers for
> draft-atlas-mpls-te-express-path-02.
>
> Note to authors: You have been CC'd on this email so that you can = know
> that this review is going on. However, please do not review your own > document.
>
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound?  We are interes= ted
> in knowing whether the document is ready to be considered for WG
> adoption (ie, it doesn't have to be perfect at this point, but sho= uld be
> a good start).
>
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary, co= mments
> may be sent privately to only the WG chairs.
>
> Are you able to review this draft by April 20, 2013?
>
> Thanks, Loa
> (as MPLS WG chair)
>
> /Loa
> --
>
>
> Loa Andersson                 =        email: = loa@mail01.huawei.com
> Senior MPLS Expert               &n= bsp;          loa@pi.= nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--bcaec511e1b67e7a5804e116d705-- From akatlas@gmail.com Tue Jul 9 09:50:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E6A21F9D72 for ; Tue, 9 Jul 2013 09:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa3WRVXkW+43 for ; Tue, 9 Jul 2013 09:50:06 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCF521F9D38 for ; Tue, 9 Jul 2013 09:50:06 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a11so6138856iee.20 for ; Tue, 09 Jul 2013 09:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=txIt11EHhwZ2koBgvplsDZSwfgbDjCY2ZODj+hX8gas=; b=kOhrNUj89W/SzOaUs+BYxm/FFh/PU7LudaKDzPdKZP0Shluzo6TxWfeBY9ldKhMooC viebPGtudMDUVtYfcB81kVysP2bHSR1dgBAfzKtw4lXiV6Bg0BKp+ofPFYvMD9zGBmqu a64Jz8kMs0WOWelO+jxBEf4//h17oq4oBLLjTbDjhFFEbgs8GHW/vOi/bnI9zUvc/TW4 0VkGP2qBRj5iaGQdwcBXHLTg+ET/QnWept5+SKuHkSymRhMgnGVM/PIUjEOU+qYz2dMR 87iMBUPihjKYf2qGQlRgYE5vpKFb35xKwGAgQ5AhuGHFtCpSDWv5lMPViazsIHNqk9Cf vDug== MIME-Version: 1.0 X-Received: by 10.43.129.1 with SMTP id hg1mr8780367icc.11.1373388605898; Tue, 09 Jul 2013 09:50:05 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 9 Jul 2013 09:50:05 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5C097@NKGEML512-MBS.china.huawei.com> References: <515FA9AF.7080705@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BBD3@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5C097@NKGEML512-MBS.china.huawei.com> Date: Tue, 9 Jul 2013 12:50:05 -0400 Message-ID: From: Alia Atlas To: Xuxiaohu Content-Type: multipart/alternative; boundary=001a11c236c0fe471104e116f3b4 Cc: "mpls@ietf.org" , "draft-atlas-mpls-te-express-path@tools.ietf.org" , Loa Andersson , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:50:07 -0000 --001a11c236c0fe471104e116f3b4 Content-Type: text/plain; charset=ISO-8859-1 Please see in-line On Thu, Apr 11, 2013 at 2:49 AM, Xuxiaohu wrote: > > > Comment: According to an above statement of " an end-to-end latency > > bound merely requires that the path computed be no more than that bound > > without being the minimum ", it seems that latency is not used as a > metric for > > SPF algorithm but only used as a constraint. If so, how do you decide > which > > specific link(s) of the first-round calculated SPF path should be pruned > prior to > > executing the second-round SPF calculation? The same question exists > when > > considering end-to-end packet loss ratio and latency variation bounds. > The > > example illustrated in the draft seems not clear to me. Would any > co-author > > please clarify the above doubt? > > Here I meant when the first-round calculated SPF path with existing > constraints (e.g., bandwidth, resource color etc) being met can't meet the > end-to-end latency bound constraint, how do you decide which specific > link(s) of that first-round calculated SPF path should be pruned prior to > executing the second-round SPF calculation? In other words, it would be > very hard to use a cumulated value of a given type of link metric (e.g., > end to end path latency, end to end latency variation) as a constraint for > the CSPF algorithm, IMHO. So your concern is what constraint to relax if a path can't be found? I don't think that is something that needs to be standardized... It depends on what you want to trade-off for the various constraints. I can easily see storing the lowest latency over the latency bound that was seen - or other techniques. Alia --001a11c236c0fe471104e116f3b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please see in-line

On Thu, Apr 11, 2013 at 2:49 AM, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:
<cut>
> =A0 =A0Comment: According to an above statement of " an end-to-en= d latency
> bound merely requires that the path computed be no more than that boun= d
> without being the minimum ", it seems that latency is not used as= a metric for
> SPF algorithm but only used as a constraint. If so, how do you decide = which
> specific link(s) of the first-round calculated SPF path should be prun= ed prior to
> executing the second-round SPF calculation? =A0The same question exist= s when
> considering end-to-end packet loss ratio and latency variation bounds.= The
> example illustrated in the draft seems not clear to me. Would any co-a= uthor
> please clarify the above doubt?

Here I meant when the first-round calculated SPF path with exis= ting constraints (e.g., bandwidth, resource color etc) being met can't = meet the end-to-end latency bound constraint, how do you decide which speci= fic link(s) of that first-round calculated SPF path should be pruned prior = to
executing the second-round SPF calculation? In other words, it would be ver= y hard to use a cumulated value of a given type of link metric (e.g., end t= o end path latency, end to end latency variation) as a constraint for the C= SPF algorithm, IMHO.

So your concern is what constraint to relax if a path c= an't be found? =A0I don't think that is something that needs to be = standardized... =A0It depends on what you want to trade-off for the various= constraints. =A0I can easily see storing the lowest latency over the laten= cy bound that was seen - or other techniques.

Alia=A0
--001a11c236c0fe471104e116f3b4-- From akatlas@gmail.com Tue Jul 9 10:45:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5A021F9963 for ; Tue, 9 Jul 2013 10:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C1gyDGQmaZU for ; Tue, 9 Jul 2013 10:45:55 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6E21F9A17 for ; Tue, 9 Jul 2013 10:45:53 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so12634464ief.26 for ; Tue, 09 Jul 2013 10:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JIjKjNpa55JEhREOGCDs3vbVmfzTd/yI+Yeh9W75Kr0=; b=mmpCFl/nlJvLnT3iTwISPntIfUKixXUiGSIAzGl009s7Y4cT9HTNgXP2EpShrfuugN xA9jUlHpJy8dinmd/W3AJ8+kRNcR3VY783aEmzo2u6e5TLcYJbZuEoxaV5pkIhNJGZEk W3bzOHsjw6lURoUWwD+y+KzkjJfhRKjzvAhTFyYeB+m54OheCGmM6b647qBzbC4J3Z8h aGeh17hS3c+J/Qpdq40ZqyRFsJZFV4VsHAsX5HK/cfgXB6uMWozOLTVRkOs0ERKD2Ck5 IswqibCJpVwNxw9nlNdB1SAAW6gLsOR39X1uvoi/qHySgyw2I4F8y2D6YfZAQaXD6bXx z0lA== MIME-Version: 1.0 X-Received: by 10.50.7.1 with SMTP id f1mr10416789iga.48.1373391952699; Tue, 09 Jul 2013 10:45:52 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 9 Jul 2013 10:45:52 -0700 (PDT) In-Reply-To: <95453A37E413464E93B5ABC0F8164C4D06CA10@eusaamb101.ericsson.se> References: <515FA9AF.7080705@pi.nu> <95453A37E413464E93B5ABC0F8164C4D06CA10@eusaamb101.ericsson.se> Date: Tue, 9 Jul 2013 13:45:52 -0400 Message-ID: From: Alia Atlas To: Sriganesh Kini Content-Type: multipart/alternative; boundary=089e0122edb87a66f404e117bbe5 Cc: "mpls@ietf.org" , "draft-atlas-mpls-te-express-path@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:45:58 -0000 --089e0122edb87a66f404e117bbe5 Content-Type: text/plain; charset=ISO-8859-1 Hi Sri, I apologize for the delay in responding. On Mon, Apr 22, 2013 at 4:32 AM, Sriganesh Kini wrote: > Hello Loa, > > Overall I think the document is addressing a useful problem but needs an > update to make it more coherent and sound before going to WG acceptance > call. > > My comments are listed below - > > 1. The filename "mpls-te-express-path" has no correlation to the title and > content of the draft. I would suggest a more appropriate filename such as > "mpls-te-path-selection-mechanism". > This draft is connected to a set of work that was originally termed TE Express Path for the ability to create "express" or low-latency LSPs. The OSPF and IS-IS related work has been renamed. I'd be happy to rename this if/when it becomes a working group draft. I would prefer mpls-te-path-selection-metric-extensions (or something even shorter!) > 2. The "Short Title" should be changed to reflect that this is a path > selection mechanism. Suggest "Simple path selection mechanism". > Changed to "Path Selection with TE Metric Extensions" > 3. Abstract last sentence is better worded as "This document specifies a > computationally simpler mechanism to select performance-constraint-bounded > paths by using performance data advertised via an IGP" > Changed to: "This specification uses network performance data, such as is advertised via the OSPF and ISIS TE metric extensions (defined outside the scope of this document) to perform such path selections." > 4. It is not clear why there is a dependence on the performance data being > advertised via IGP. Can't it come from other sources. E.g. a management > system ? > Yes - as long as we confine the computation to the ingress, network-wide consistency isn't required. I've updated the second sentence in the introduction to be: "Network performance information can be obtained via either the TE Metric Extensions in OSPF or ISIS or via a management system. > 5. The limitations of the path computed due to the scope of link-state > advertisements should be stated. E.g. if the referenced docs for IGP > extensions have area scoped performance-data advertisements, then the > head-end may not be able to compute paths beyond the area. > This is the same as everything else advertised about TE via the IGP... Why does it need to be especially called out? Added " As with other TE information flooded via OSPF or ISIS, the TE metric extensions have a flooding scope limited to the local area or level." > 6. Section 1.1 enum 3 - s/perforance/performance > > 7. Section 1.1 enum 4 suggest s/configuration/constraints > > 8. Section 2.1 - Need a reference for CSPF algorithm being referred to. It > may be of value to write an appendix that gives pseudocode on how the > constraint checking is inserted into the CSPF. > I added some pseudo-code (see email response to Xiaohu). Do you have a suitable reference for a CSPF algorithm? There has been no need to standardize it. > 9. Section 2.1 - In the paragraph starting with "This is illustrated as > follows.". It may be useful to state that there are cases where all the > links of X when explored may violate the bounded constraint the algorithm > should backtrack from the point where the bounded constraint was still > being satisfied. > Please do read the new pseudo-code and example. The link is not explored if it will violate the bounded constraint - that's the point of the modified exploration. > 10. Sec 2.3.3 - Is this an optimization of when to re-optimize ? Because > any link coming out of Anomalous may provide a better path, not just a > link that caused LSPs to change when it went to the Anomalous state. If > so, it may be useful to state it. > Sure - any link changing state might provide better paths - but those that were specifically moved away are more likely to want to move back. I added "This may help optimize when to recompute for a better path." > Also this document should be posted to the PCE WG for comments. > I'm happy to have their comments as well - but I don't think it really applies for PCE. In a PCE scenario, computation is not as much a concern and better algorithms can be used. Thanks, Alia > > > Thanks > -- Sri > > > > > > > On 4/5/13 9:50 PM, "Loa Andersson" wrote: > > >Xiaohu, Sri, Rajiv and Pranjal, > > > >You have been selected as an MPLS Review team reviewers for > >draft-atlas-mpls-te-express-path-02. > > > >Note to authors: You have been CC'd on this email so that you can know > >that this review is going on. However, please do not review your own > >document. > > > >Reviews should comment on whether the document is coherent, is it > >useful (ie, is it likely to be actually useful in operational > >networks), and is the document technically sound? We are interested > >in knowing whether the document is ready to be considered for WG > >adoption (ie, it doesn't have to be perfect at this point, but should be > >a good start). > > > >Reviews should be sent to the document authors, WG co-chairs and > >WG secretary, and CC'd to the MPLS WG email list. If necessary, comments > >may be sent privately to only the WG chairs. > > > >Are you able to review this draft by April 20, 2013? > > > >Thanks, Loa > >(as MPLS WG chair) > > > >/Loa > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --089e0122edb87a66f404e117bbe5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sri,

I apologize for the delay in responding.

On Mon, Apr 22, 2013 at 4:32 AM, Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:
Hello Loa,

Overall I think the document is addressing a useful problem but needs an update to make it more coherent and sound before going to WG acceptance
call.

My comments are listed below -

1. The filename "mpls-te-express-path" has no correlation to the = title and
content of the draft. I would suggest a more appropriate filename such as "mpls-te-path-selection-mechanism".

This draft is connected to a set of work that was originally termed = TE Express Path for the ability to create "express" or low-latenc= y LSPs. =A0 The OSPF and IS-IS related work has been renamed. =A0I'd be= happy to rename this if/when it becomes a working group draft. I would pre= fer mpls-te-path-selection-metric-extensions (or something even shorter!)= =A0

=A0
2. The "Short Title"= ; should be changed to reflect that this is a path
selection mechanism. Suggest "Simple path selection mechanism".

Changed to "Path Selection with TE = Metric Extensions"=A0
=A0
3. Abstract last sentence is better worded as "This document specifies= a
computationally simpler mechanism to select performance-constraint-bounded<= br> paths by using performance data advertised via an IGP"

Changed to:
"This specification us= es network performance data, such
as is advertised via the OSPF a= nd ISIS TE metric extensions (defined
outside the scope of this document) to perform such path selections.&q= uot;

=A0
4. It is not clear why there is a dependence on the performance data being<= br> advertised via IGP. Can't it come from other sources. E.g. a management=
system ?

Yes - as long as we confine th= e computation to the ingress, network-wide consistency isn't required.<= /div>
I've updated the second sentence in the introduction to be:

"Network performance information=A0
can = be obtained via either the TE Metric Extensions in OSPF <xref
= target=3D"I-D.ietf-ospf-te-metric-extensions"/> or ISIS <xr= ef
target=3D"I-D.previdi-isis-te-metric-extensions"/> or via= a management system.
=A0
=A0
5. The limitations of the path computed due to the scope of link-state
advertisements should be stated. E.g. if the referenced docs for IGP
extensions have area scoped performance-data advertisements, then the
head-end may not be able to compute paths beyond the area.
=

This is the same as everything else advertised about TE= via the IGP... =A0Why does it need to=A0
be especially called ou= t?=A0

Added=A0

" As with other = TE information flooded via OSPF or ISIS, the TE
metric extensions= have a flooding scope limited to the local area or level."
=A0
6. Section 1.1 enum 3 - s/perforance/performance

7. Section 1.1 enum 4 suggest s/configuration/constraints

8. Section 2.1 - Need a reference for CSPF algorithm being referred to. It<= br> may be of value to write an appendix that gives pseudocode on how the
constraint checking is inserted into the CSPF.

I added some pseudo-code (see email response to Xiaohu). =A0
<= div>Do you have a suitable reference for a CSPF algorithm? =A0There has bee= n no need=A0
to standardize it.=A0
=A0
9. Section 2.1 - In the paragraph starting with "This is illustrated a= s
follows.". It may be useful to state that there are cases where all th= e
links of X when explored may violate the bounded constraint the algorithm should backtrack from the point where the bounded constraint was still
being satisfied.

Please do read the new= pseudo-code and example. =A0The link is not explored if it
will = violate the bounded constraint - that's the point of the modified explo= ration.=A0
=A0
10. Sec 2.3.3 - Is this an optimization of when to re-optimize ? Because any link coming out of Anomalous may provide a better path, not just a
link that caused LSPs to change when it went to the Anomalous state. If
so, it may be useful to state it.

Sure = - any link changing state might provide better paths - but those that were = specifically moved away
are more likely to want to move back.

I added "This may help optimize when to recompute = for a better path."
=A0
Also this document should be posted to the PCE WG for comments.

I'm happy to have their comments as well - but= I don't think it really applies for PCE.
In a PCE scenario, = computation is not as much a concern and better algorithms can be used.

Thanks,
Alia
=A0


Thanks
-- Sri






On 4/5/13 9:50 PM, "Loa Andersson" <loa@pi.nu> wrote:

>Xiaohu, Sri, Rajiv and Pranjal,
>
>You have been selected as an MPLS Review team reviewers for
>draft-atlas-mpls-te-express-path-02.
>
>Note to authors: You have been CC'd on this email so that you can k= now
>that this review is going on. However, please do not review your own >document.
>
>Reviews should comment on whether the document is coherent, is it
>useful (ie, is it likely to be actually useful in operational
>networks), and is the document technically sound? =A0We are interested<= br> >in knowing whether the document is ready to be considered for WG
>adoption (ie, it doesn't have to be perfect at this point, but shou= ld be
>a good start).
>
>Reviews should be sent to the document authors, WG co-chairs and
>WG secretary, and CC'd to the MPLS WG email list. If necessary, com= ments
>may be sent privately to only the WG chairs.
>
>Are you able to review this draft by April 20, 2013?
>
>Thanks, Loa
>(as MPLS WG chair)
>
>/Loa
>--
>
>
>Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
>Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= a href=3D"mailto:loa@pi.nu">loa@pi.nu
>Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64

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

--089e0122edb87a66f404e117bbe5-- From akatlas@juniper.net Tue Jul 9 11:14:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F0321F9CCA for ; Tue, 9 Jul 2013 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.584 X-Spam-Level: X-Spam-Status: No, score=0.584 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62oLNOmhY4gv for ; Tue, 9 Jul 2013 11:14:05 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9AA21F9A50 for ; Tue, 9 Jul 2013 11:14:05 -0700 (PDT) Received: from mail27-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 18:14:04 +0000 Received: from mail27-co1 (localhost [127.0.0.1]) by mail27-co1-R.bigfish.com (Postfix) with ESMTP id 9702B8E0544 for ; Tue, 9 Jul 2013 18:14:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz9371I542Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail27-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail27-co1 (localhost.localdomain [127.0.0.1]) by mail27-co1 (MessageSwitch) id 1373393643213992_16467; Tue, 9 Jul 2013 18:14:03 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.241]) by mail27-co1.bigfish.com (Postfix) with ESMTP id 318FE8401B8 for ; Tue, 9 Jul 2013 18:14:03 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 18:14:01 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 11:14:01 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 11:14:00 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 11:17:44 -0700 Received: from mail207-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 18:13:59 +0000 Received: from mail207-tx2 (localhost [127.0.0.1]) by mail207-tx2-R.bigfish.com (Postfix) with ESMTP id 4724338011C for ; Tue, 9 Jul 2013 18:13:59 +0000 (UTC) Received: from mail207-tx2 (localhost.localdomain [127.0.0.1]) by mail207-tx2 (MessageSwitch) id 1373393572293446_8913; Tue, 9 Jul 2013 18:12:52 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.247]) by mail207-tx2.bigfish.com (Postfix) with ESMTP id 3B642640043; Tue, 9 Jul 2013 18:12:52 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 18:12:51 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.117]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Tue, 9 Jul 2013 18:12:50 +0000 From: Alia Atlas To: Xuxiaohu , "curtis@ipv6.occnc.com" , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs Thread-Topic: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQI1v7AdXBiEf1kGpZztZc1tuJpldHnDg Date: Tue, 9 Jul 2013 18:12:49 +0000 Message-ID: References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IPV6.OCCNC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:14:12 -0000 Can you clarify why you think constraining the links explored based upon a = latency isn't a practical approach? It is still O(n log n) - granted, it's= a heuristic and may not find a path. Alia -----Original Message----- From: Xuxiaohu [mailto:xuxiaohu@huawei.com]=20 Sent: Tuesday, April 23, 2013 9:44 PM To: curtis@ipv6.occnc.com; MPLS WG Mailing List; draft-atlas-mpls-te-expres= s-path authors; The Great and Mighty MPLS Co-Chairs Subject: re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review= of ...) > s/While it has been possible to compute a CSPF/It is possible to > compute a CSPF/ > s/Instead of this approach to minimize path latency, an/An > alternative to this approach to minimize path latency is an > approach to place a upper bound on path latency. An/ > Note: both approaches are valid. I think the alternative approach (i.e., to compute a CSPF path based on the= TE metric while placing a upper bound on the path latency) is not a practi= cal approach due to computationally complexity. Best regards, Xiaohu From akatlas@juniper.net Tue Jul 9 13:01:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72F11E813A for ; Tue, 9 Jul 2013 13:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxVDH6AkGzOc for ; Tue, 9 Jul 2013 13:01:32 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 46A4D11E8158 for ; Tue, 9 Jul 2013 13:01:32 -0700 (PDT) Received: from mail122-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 20:01:31 +0000 Received: from mail122-co9 (localhost [127.0.0.1]) by mail122-co9-R.bigfish.com (Postfix) with ESMTP id ACABADA03BB for ; Tue, 9 Jul 2013 20:01:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI62a3I98dI9371Ic85fh542Iec9I1432I1418I4015I111aI1447Id79eh15c7mzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail122-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail122-co9 (localhost.localdomain [127.0.0.1]) by mail122-co9 (MessageSwitch) id 1373399993436458_3589; Tue, 9 Jul 2013 19:59:53 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.235]) by mail122-co9.bigfish.com (Postfix) with ESMTP id 5E878B60076 for ; Tue, 9 Jul 2013 19:59:53 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 19:59:52 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 12:59:52 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 12:59:51 -0700 Received: from CO9EHSOBE027.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 13:12:34 -0700 Received: from mail24-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 19:59:50 +0000 Received: from mail24-co9 (localhost [127.0.0.1]) by mail24-co9-R.bigfish.com (Postfix) with ESMTP id D119E980145 for ; Tue, 9 Jul 2013 19:59:50 +0000 (UTC) Received: from mail24-co9 (localhost.localdomain [127.0.0.1]) by mail24-co9 (MessageSwitch) id 1373399986624009_28808; Tue, 9 Jul 2013 19:59:46 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.235]) by mail24-co9.bigfish.com (Postfix) with ESMTP id 911E4C20052; Tue, 9 Jul 2013 19:59:46 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 19:59:45 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.117]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0324.000; Tue, 9 Jul 2013 19:59:45 +0000 From: Alia Atlas To: "curtis@ipv6.occnc.com" , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs Thread-Topic: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQEgkt0dOVDspPkyhTC0TKnb7gpldH2DA Date: Tue, 9 Jul 2013 19:59:44 +0000 Message-ID: References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> In-Reply-To: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B3513CFDFBY2PRD0510MB389_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IPV6.OCCNC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:01:44 -0000 --_000_D1CF735B7C7B744582438550F826E01B3513CFDFBY2PRD0510MB389_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Curtis, Thanks for your detailed comments and suggestions. My responses are in-lin= e, as always. Alia -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] Sent: Tuesday, April 23, 2013 12:59 PM To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Gre= at and Mighty MPLS Co-Chairs Cc: curtis@ipv6.occnc.com Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Loa, authors, et al, So far I have seen two of the four MPLS-RT reviews (maybe I missed the othe= rs). I've commented before on the mailing list about this draft but at thi= s point I would like to provide a detailed review. I think there are very major issues with this document as it now stands. I= MO these issues should be addressed before the draft is even accepted as a = WG document. You can choose to consider this during MPLS-RT review or after. Curtis Major issues: Jitter and loss are very close to meaningless if queueing delays and loss are not considered. Links that are losing packets at the link layer are generally taken down. Oscillations can occur if queueing delay and loss is considered, such as measurements at a low priority and therefore possible to congest or measurements which are otherwise affected by traffic load. Unless there is adequate discussion of stability and mechanisms to insure stability, then jitter and loss should be removed. [Alia] I have changed the second paragraph of the introduction to be: " Queuing latency is specifically excluded to insure freedom from oscillations and stability issues that have plagued prior attempts to use delay as a routing metric. If application traffic which follows path based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing delay or another PHB with potentially very substantial per-hop queuing delay. Only traffic which experiences relatively low congestion, such as Expedited Forwarding traffic, will experience delays very close to the sum of the reported link delays" Removing queuing delay is the agreed result for draft-ietf-ospf-te-metric-e= xtensions. As far as jitter and loss goes, these can still be somewhat meaningful. Fo= r instance, jitter does allow capturing the differences in serialization de= lays - which is relevant in some parts of the network. The acceptable loss= to take a link down may vary. I don't actually see the reasoning or need= to remove jitter and loss from the draft - given that we have constrained = the measurements in the draft-ietf-ospf-te-metric-extensions to not include= queuing delay. General: It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, see nits below) is specific to a link, and not an NPO per LSP. A "non-conformance to NPO" flag in the IGP link advertisement is intractable if there are multiple NPO being applied to the link. [Alia] As you may recall from draft-ietf-ospf-te-metric-extensions, the Ano= malous bit is specified per characteristic advertised per link. This draf= t (draft-atlas-mpls-te-express-path-02) describes the Anomalous bit as clea= rly inside a links' sub-TLV as in Sec 2.3.1: "If the answer to (a) is no for latency SLAs, then any link which has the Anomalous bit set in the Unidirectional Link Delay sub- TLV[I-D.ietf-ospf-te-metric-extensions] [I-D.previdi-isis-te-metric-extensions] should be removed from the topology before a CSPF calculation is used to compute a new path." The use of a "non-conformance to NPO" flag as the only means to alert the set of LSP ingress of a significant change is also at best a poor solution. For example, a change from 2 msec to 15 msec may be a problem for some LSP. That same change may not be a problem for others, such as LSPs where only this one hop is needed. So advertising out of NPO in the IGP doesn't help the second case. LSP ingress must evaluate the path delay constraint, each time a change in IGP link advertised delay is received. [Alia] Sure - different LSPs may have different requirements as to the Anom= alous flag. Using it doesn't replace paying attention to the value that is= advertised. The anomalous flag is reporting that the link is not complyin= g to the expected performance - this can indicate that there is something s= trange going on and some LSPs should avoid using that link due to administr= ative policy. The use of a "non-conformance to NPO" flag solely as a constraint makes sense, where some LSP are configured to exclude links with this flag set. [Alia] Right - case (a) and (c) for Sec 2.3 For path delay computation it would also be useful if the NPO threshhold were advertised. In some cases, it may make sense to minimize or place bounds on the sum of NPO delays. [Alia] I think that should be a comment on draft-ietf-ospf-te-metric-extens= ions. This draft doesn't define what is flooded. A question though is wh= ether in the same network it would make sense to consider both the NPO dela= ys and the actual measured delays? If only one or the other - then that co= uld be a local router's decision as to which is flooded. Specific: Abstract: Remove mention of jitter and loss. [Alia] I am interested in the opinion of the WG on this. In my view, this = draft is describing how the information flooded via the new sub-TLVs in dra= ft-ietf-ospf-te-metric-extensions-04 should be used. Loss and jitter are i= ncluded in that draft; of course, that draft could change as well - but I'd= like to hear stronger arguments for why it is harmful to include them than= that they're only relevant when queuing behavior is included and that can = lead to oscillations. I am, perhaps stubbornly, not convinced that they ar= e irrelevant. 1. Introduction: This sentence is awkward but I think I know what you are trying to say. The method suggested is not optimal for both minimizing path cost and additional constraints, such as latency; optimal solutions are computationally complex. Please consider this replacement. Methods of optimizing path selection for multiple parameters are generally computationally complex. The method proposed here are to make use of either a single metric in path selection, such as minimal path delay, or to make use of another single metric, such as the existing TE metric with additional constraints, such as target link delay bounds and target path delay bounds. [Alia] Thanks for the better text - put in... Please note: The path selection mechanisms described in this document apply to paths that are fully computed by the head-end of the LSP and then signaled in an ERO where every sub-object is strict. This allows the head-end to consider IGP-distributed performance data without requiring the ability to signal the performance constraints in an object of the RSVP Path message. There is work in MPLS or CCAMP by George Swallow and others on cummulative metrics in RSVP-TE with delay as a major motivation. Perhaps that work should be considered. [Alia] I believe you are referring to http://tools.ietf.org/html/draft-iet= f-ccamp-te-metric-recording-01? That draft appears to me to be about how t= o get measurements for latency, jitter, and cost for a given Forwarding Adj= acency or Routing Adjacency so that those values can be advertised into the= IGP. I think this draft is providing a means to collect the data to flood= in draft-ietf-ospf-te-metrics-04. I did add the last sentence in the following: "This document does not specify how a router determines what values to advertise by the IGP; it does assume that the constraints specified in [I-D.ietf-ospf-te-metric-extensions] and [I-D.previdi-isis-te-metric-ext= ensions] are followed. Mechanisms for determining latency and delay variat= ion for Forwarding Adjacencies and Routing Adjacencies are defined in [I-D.ietf-ccamp-te-metri= c-recording]." This paragraph could use rewording: When considering performance-based data, it is obvious that there are additional contributors beyond just the links. Clearly end-to-end latency is a combination of router latency, queuing latency, physical link latency and other factors. However, if application traffic requires paths to be selected based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal queuing delay or another PHB with known maximal per-hop queuing delay. While traversing a router can cause delay, that can be included in the advertised link delay. What you are getting at is that where traffic levels can't possibly have a significant impact the measurements, such as low levels of EF traffic in a WAN with high geographic delays, and delay meansured with EF priority, stability is not impacted if delay measurements are considered. In this case, loss MUST be zero or the EF service is broken (replace routers and try again). OTOH jitter will increase as traffic levels increase, even in such a case where the traffic is only a few percent, potentially causing oscillations and impacting stability. For this reason, jitter and loss should not be considered. I will leave the rewording up to you. I suggest that you create a subsection of "Introduction" which discusses potential oscillations and stability in greater detail. If you like, I will provide some text. [Alia] I do hear your concern that jitter could cause oscillations and impa= ct stability. I am not fully persuaded that this is a practical issue - gi= ven the delays in ingress re-optimization, not trying to minimize the jitte= r, and the ability for an LSP to reserve bandwidth. I would be interested = in what text you might provide and a focused discussion on whether this is = something that needs to have restrictions clearly described to avoid oscill= ations. For now, I have changed this paragraph to: "When considering performance-based data, it is obvious that there are additional contributors beyond just the links. Clearly end-to-end latency is a combination of router latency, queuing latency, physical link latency and other factors. While traversing a router can cause delay, that can be included in the advertised link delay. As described in [I-D.ietf-ospf-te-metric-extensions] and [I-D.previdi-isis-te-metric-extensions], queuing delay should not be included in the measurements advertised by OSPF or ISIS. Queuing latency is specifically excluded to insure freedom from oscillations and stability issues that have plagued prior attempts to use delay as a routing metric. If application traffic which follows path based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing delay or another PHB with potentially very substantial per-hop queuing delay. Only traffic which experiences relatively low congestion, such as Expedited Forwarding traffic, will experience delays very close to the sum of the reported link delays." 1.1. Basic Requirements: Drop "packet loss, jitter" from the first numeric item. Otherwise OK except use of the word SLA. See nits below. [Alia] Changed SLAs to NPO After the list please state that "For existing MPLS constraints, corresponding RSVP-TE signaling allows midpoint LSR to use Path Tear and/or notification and would use this mechanism to accomplish items 3-6. In the absense of RSVP-TE signaling corresponding to these new constraints, new mechanisms at the LSP ingress are needed." Alternately, consider citing the work by George Swallow et al and explain how that solves it in the same way that a change in admin attr of a link would (or should, poor implementations not withstanding). [Alia] Frankly, I'm confused by this. I don't agree that RSVP-TE signaling= extensions would solve, for instance, (3): "3. Ability to periodically verify that a TE tunnel's current LSP complies with its configured end-to-end performance requirements." Even if the ingress signaled the end-to-end performance requirements, I don= 't see how that stops the ingress from verifying compliance? Similarly, only the ingress could do: " 4. Ability to move tunnels, using make-before-break, based upon computed end-to-end performance complying with configuration 5. Ability to move tunnels away from any link that is violating an underlying SLA 6. Ability to optionally avoid setting up tunnels using any link that is violating an SLA, regardless of whether end-to-end performance would still meet requirements." I have looked for the additional work that you are talking about by George = Swallow unsuccessfully. Can you find a pointer to explain what you're talk= ing about? The anomalous bits provide a trigger mechanism that a router ca= n use to tell the ingress to do (5); different admin attributes could do a = similar behavior - and similarly for (6) - but again that is the flooding f= or notification aspect. I think the lack of RSVP-TE extensions doesn't cau= se an issue - these are handled by IGP instead and thus don't have to be si= gnaled per LSP. I am not irrevocably opposed to RSVP-TE extensions - if we really need them= for practical use-cases. This draft was trying to do the minimum that is = sufficient and then, if and when there is a need for more, what extra is ne= eded could be better defined. 2.1. End-to-End Constraints: Note: I've requested that jitter and loss be dropped from draft-ietf-ospf-te-metric-extensions and draft-previdi-isis-te-metric-extensions for the same potential oscillations and stability reasons cited above. [Alia] Yes - I think we clearly need to have a good email discussion with t= hose interested about what oscillations might actually occur and what could= be done to prevent that. s/While it has been possible to compute a CSPF/It is possible to compute a CSPF/ s/Instead of this approach to minimize path latency, an/An alternative to this approach to minimize path latency is an approach to place a upper bound on path latency. An/ Note: both approaches are valid. Delete next paragraph starting with "This is illustrated as follows." This seems to be taken from email and is good email discussion but not needed in the draft. [Alia] I've put in some pseudo-code so I'm ok with taking the example out -= but there does seem to have been confusion even with it in. Delete next paragraph starting with "An end-to-end bound on delay variation". Lets get rid of jitter altogether. (Let the old SNA networks be damned. :) Delete next paragraph starting with "For link loss". Get rid of link loss altogether. [Alia] Not done - discussion is needed. I understand that you really reall= y really don't want to see loss or delay variation in any of these drafts. 2.2. Link Constraints: Drop delay variation and link loss. If we are dealing with EF traffic then using Unidirectional Available Bandwidth and Residual Bandwidth makes no sense. If we are dealing with low priority traffic and we are using Unidirectional Available Bandwidth and Residual Bandwidth in path selection will be prone to oscillations and network instability. Therefore delete the entire second paragraph (the one starting with "When doing path selection for TE tunnels,". [Alia] If we are trying to avoid congesting the link, then Residual Bandwi= dth is important and useful regardless of the LSP traffic class. What is y= our specific concern with oscillation for bandwidth? Why is it different t= han for the bandwidths already advertised and used for TE path computation?= Come on - the Residual Bandwidth is just the Link Capacity minus that re= served by RSVP-TE - so pretty darn similar characteristics to the Unreserve= d Bandwidth per priority... The Unidirectional Available bandwidth does i= nclude an actual traffic measurement - that is averaged over a reasonable i= nterval, that can only change with limited frequency - and then the LSPs ne= ed to be reoptimized to use them. Please explain precisely the oscillation= concern with a clear example. Also delete the entire third paragraph (starting with "Similarly, only links whose loss is"). As stated earlier, use of loss is either a NOOP (low volume of EF traffic) or can lead to oscillations. Get rid of loss entirely. 2.3. Links out of SLA: s/SLA/NPO/g (see nits below). General: A better mechanism than an "Anomalous State" flag is needed to provide notifications of change. One mechanism would be to put the commulative constraint and the cummulative total in the ERO and RRO. A link adding delay can then notify the ingress of any LSP for which the commulative constraint is violated. See work by Swallow et al and perhaps align with that work. [Alia] That could be done as well - but the signaling extensions seem like = overkill for the basic problem of letting the ingress compute a complete ER= O. Carrying both the cumulative constraint and the cumulative total just m= eans that the midpoint detects a changed link and then has to verify the pe= rformance on each LSP and individually signal it. Having an anomalous flag= provides a succinct notification to the ingress which can then do the veri= fication and be known to have the updated information. This solution also = requires that the midpoints all support it before it can be used. An advan= tage of the ingress computation is that only the ingress needs to have upda= ted code. The "Anomalous State" flag is helpful for c in the list, but not for b. The case where a link is out of NPO by 1 msec then changes to out of NPO by 10s of msec is an example. The flag is already set and therefore the trigger is unavailable. [Alia] Right - but LSPs that are particular sensitive (i.e. a or c) can hav= e been moved already. Having the Anomalous flag set is expected to be unu= sual. I agree that it is more a hint for (b) than a full solution. 2.3.1. Use of Anomalous Links for New Paths Delete second paragraph regarding jitter and loss. 2.3.2. Links entering the Anomalous State This section ignores two cases in which the Anomalous State does not change but a change makes the path violate a delay constraint. The first is where all of the links are within NPO but a change to a link has make the path delay sum exceed the path delay constraint. The second is where a link which is already in the Anomalous State by a small margin but the path delay is still within the constraint. A large change in delay at that point will not affect the Anomalous State since it is already set. [Alia] The Anomalous bit is NOT meant to replace reading the actual value = associated with the link and checking each potentially affected LSP. In th= e case of (b), it is a hint to focus on those LSPs first. A better means of handling case (b) in "2.3. Links out of SLA" is needed. [Alia] I've added the following paragraph at the end of 2.3.2: "It is not sufficient to just look at the Anomalous bit in order to determine when TE tunnels must have their compliance verified. When changing to set, the Anomalous bit merely provides a hint that interested TE tunnels for case (b) should have their continued compliance verified." 2.3.3. Links leaving the Anomalous State Same issue as in "2.3.2. Links entering the Anomalous State". A better means of handling case (b) in "2.3. Links out of SLA" is needed. [Alia] I've added the following sentence: "The hint provided by the Anomalous state change may help optimize when to = recompute for a better path." XML version nits: CV: you really should remove the template comments. [Alia] I find them helpful for when I want to do additional things... and = very very few people read the XML. You should also enable strict mode. For example, you have one author too many and strict would catch that. [Alia] So does basic arithmetic :) It will be resolved before the draft = is passed to the RFC editor. Other nits: The "A" in SLA is "Agreement" as in contract. The acronym NPO for network performance objective seems to be in vogue for that reason. IETF since diffserv has wanted to steer clear of making recommendations regarding provider contracts (agreements) with customers, peer, or anyone else. [Alia] True - changed I agree with Sri on the suggestions to change the title, short name and document filename but I'm not fond of his suggested new names. Authors please suggest new title, short name, and filename. [Alia] I did do a new short name and title. As for filename, we'll deal w= ith that if/when the draft is adopted as a WG draft. Thanks again, Alia ------- Forwarded Message On 4/5/13 9:50 PM, "Loa Andersson" > wrote: > >Xiaohu, Sri, Rajiv and Pranjal, > >You have been selected as an MPLS Review team reviewers for >draft-atlas-mpls-te-express-path-02. > >Note to authors: You have been CC'd on this email so that you can know >that this review is going on. However, please do not review your own >document. > >Reviews should comment on whether the document is coherent, is it >useful (ie, is it likely to be actually useful in operational >networks), and is the document technically sound? We are interested in >knowing whether the document is ready to be considered for WG adoption >(ie, it doesn't have to be perfect at this point, but should be a good >start). > >Reviews should be sent to the document authors, WG co-chairs and WG >secretary, and CC'd to the MPLS WG email list. If necessary, comments >may be sent privately to only the WG chairs. > >Are you able to review this draft by April 20, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------- End of Forwarded Message --_000_D1CF735B7C7B744582438550F826E01B3513CFDFBY2PRD0510MB389_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Curtis,

 

Thanks for your det= ailed comments and suggestions.  My responses are in-line, as always.<= o:p>

 

Alia

 

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]
Sent: Tuesday, April 23, 2013 12:59 PM
To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Gre= at and Mighty MPLS Co-Chairs
Cc: curtis@ipv6.occnc.com
Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...)

 

 

Loa, authors, et al,

 

So far I have seen two of the four MPLS-RT review= s (maybe I missed the others).  I've commented before on the mailing l= ist about this draft but at this point I would like to provide a detailed r= eview.

 

I think there are very major issues with this doc= ument as it now stands.  IMO these issues should be addressed before t= he draft is even accepted as a WG document.

 

You can choose to consider this during MPLS-RT re= view or after.

 

Curtis

 

 

 

 

Major issues:

 

  Jitter and loss are very close to meaningl= ess if queueing delays and

  loss are not considered.  Links that = are losing packets at the link

  layer are generally taken down.  Osci= llations can occur if queueing

  delay and loss is considered, such as meas= urements at a low priority

  and therefore possible to congest or measu= rements which are

  otherwise affected by traffic load.  = Unless there is adequate

  discussion of stability and mechanisms to = insure stability, then

  jitter and loss should be removed.

 

[Alia] I have chang= ed the second paragraph of the introduction to be:

 

" Queuing late= ncy is specifically excluded to insure freedom from

   oscill= ations and stability issues that have plagued prior attempts to<= /span>

   use de= lay as a routing metric.  If application traffic which follows

   path b= ased upon latency constraints, the same traffic might be in an

   Expedi= ted Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing

   delay = or another PHB with potentially very substantial per-hop<= /p>

   queuin= g delay.  Only traffic which experiences relatively low

   conges= tion, such as Expedited Forwarding traffic, will experience

   delays= very close to the sum of the reported link delays"<= /p>

 

Removing queuing de= lay is the agreed result for draft-ietf-ospf-te-metric-extensions.

As far as jitter an= d loss goes, these can still be somewhat meaningful.  For instance, ji= tter does allow capturing the differences in serialization delays - which i= s relevant in some parts of the network.  The acceptable loss to take a link down may vary.   I don't actu= ally see the reasoning or need to remove jitter and loss from the draft - g= iven that we have constrained the measurements in the draft-ietf-ospf-te-me= tric-extensions to not include queuing delay.

 

General:

 

  It needs to be much more clearly stated th= at the NPO (s/SLA/NPO/g,

  see nits below) is specific to a link, and= not an NPO per LSP.  A

  "non-conformance to NPO" flag in= the IGP link advertisement is

  intractable if there are multiple NPO bein= g applied to the link.

 

[Alia] As you may r= ecall from draft-ietf-ospf-te-metric-extensions, the Anomalous bit is speci= fied per characteristic advertised per link.   This draft (draft-= atlas-mpls-te-express-path-02) describes the Anomalous bit as clearly inside a links’ sub-TLV as in Sec 2.3.1:

 

“If the answe= r to (a) is no for latency SLAs, then any link which has<= /p>

the Anomalous bit s= et in the Unidirectional Link Delay sub-

TLV[I-D.ietf-ospf-t= e-metric-extensions]

[I-D.previdi-isis-t= e-metric-extensions] should be removed from the

topology before a C= SPF calculation is used to compute a new path.”

 

  The use of a "non-conformance to NPO&= quot; flag as the only means to

  alert the set of LSP ingress of a signific= ant change is also at best

  a poor solution.  For example, a chan= ge from 2 msec to 15 msec may

  be a problem for some LSP.  That same= change may not be a problem

  for others, such as LSPs where only this o= ne hop is needed.  So

  advertising out of NPO in the IGP doesn't = help the second case.  LSP

  ingress must evaluate the path delay const= raint, each time a change

  in IGP link advertised delay is received.<= o:p>

 

[Alia] Sure –= different LSPs may have different requirements as to the Anomalous flag.&n= bsp; Using it doesn’t replace paying attention to the value that is a= dvertised.  The anomalous flag is reporting that the link is not complying to the expected performance – this can indicat= e that there is something strange going on and some LSPs should avoid using= that link due to administrative policy. 

 

  The use of a "non-conformance to NPO&= quot; flag solely as a constraint

  makes sense, where some LSP are configured= to exclude links with

  this flag set.

 

[Alia] Right –= ; case (a) and (c) for Sec 2.3

 

  For path delay computation it would also b= e useful if the NPO

  threshhold were advertised.  In some = cases, it may make sense to

  minimize or place bounds on the sum of NPO= delays.

 

[Alia] I think that= should be a comment on draft-ietf-ospf-te-metric-extensions.  This dr= aft doesn’t define what is flooded.   A question though is = whether in the same network it would make sense to consider both the NPO delays and the actual measured delays?  If only one or t= he other – then that could be a local router’s decision as to w= hich is flooded.

 

Specific:

 

  Abstract:

 

    Remove mention of jitter and l= oss.

 

 

[Alia] I am interes= ted in the opinion of the WG on this.  In my view, this draft is descr= ibing how the information flooded via the new sub-TLVs in draft-ietf-ospf-t= e-metric-extensions-04 should be used.  Loss and jitter are included in that draft; of course, that draft could change = as well – but I’d like to hear stronger arguments for why it is= harmful to include them than that they’re only relevant when queuing= behavior is included and that can lead to oscillations.  I am, perhaps stubbornly, not convinced that they are irrelevant.

 

  1.  Introduction:

 

    This sentence is awkward but I= think I know what you are trying to

    say.

 

      The method suggest= ed is not optimal for both minimizing path

      cost and additiona= l constraints, such as latency; optimal

      solutions are comp= utationally complex.

 

    Please consider this replaceme= nt.

 

      Methods of optimiz= ing path selection for multiple parameters are

      generally computat= ionally complex.  The method proposed here are

      to make use of eit= her a single metric in path selection, such as

      minimal path delay= , or to make use of another single metric,

      such as the existi= ng TE metric with additional constraints, such

      as target link del= ay bounds and target path delay bounds.

 

[Alia] Thanks for t= he better text – put in…

 

    Please note:

 

      The path selection= mechanisms described in this document apply

      to paths that are = fully computed by the head-end of the LSP and

      then signaled in a= n ERO where every sub-object is strict.  This

      allows the head-en= d to consider IGP-distributed performance data

      without requiring = the ability to signal the performance

      constraints in an = object of the RSVP Path message.

 

    There is work in MPLS or CCAMP= by George Swallow and others on

    cummulative metrics in RSVP-TE= with delay as a major motivation.

    Perhaps that work should be co= nsidered.

 

[Alia]  I beli= eve you are referring to http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-= 01?  That draft appears to me to be = about how to get measurements for latency, jitter, and cost for a given Forwarding Adjacency or Routing Adjacency so = that those values can be advertised into the IGP.  I think this draft = is providing a means to collect the data to flood in draft-ietf-ospf-te-met= rics-04. 

 

I did add the last = sentence in the following:

 

“This documen= t does not specify how a router determines what values

to advertise by the= IGP; it does assume that the constraints specified

in [I-D.ietf-ospf-t= e-metric-extensions] and [I-D.previdi-isis-te-metric-extensions] are follow= ed.  Mechanisms for determining latency and delay variation for Forwar= ding

Adjacencies and Rou= ting Adjacencies are defined in [I-D.ietf-ccamp-te-metric-recording].”= ;

 

 

    This paragraph could use rewor= ding:

 

      When considering p= erformance-based data, it is obvious that

      there are addition= al contributors beyond just the links.

      Clearly end-to-end= latency is a combination of router latency,

      queuing latency, p= hysical link latency and other factors.

      However, if applic= ation traffic requires paths to be selected

      based upon latency= constraints, the same traffic might be in an

      Expedited Forwardi= ng Per-Hop- Behavior[RFC3246] with minimal

      queuing delay or a= nother PHB with known maximal per-hop queuing

      delay.  While= traversing a router can cause delay, that can be

      included in the ad= vertised link delay.

 

    What you are getting at is tha= t where traffic levels can't

    possibly have a significant im= pact the measurements, such as low

    levels of EF traffic in a WAN = with high geographic delays, and

    delay meansured with EF priori= ty, stability is not impacted if

    delay measurements are conside= red.  In this case, loss MUST be

    zero or the EF service is brok= en (replace routers and try again).

    OTOH jitter will increase as t= raffic levels increase, even in such

    a case where the traffic is on= ly a few percent, potentially

    causing oscillations and impac= ting stability.  For this reason,

    jitter and loss should not be = considered.

 

    I will leave the rewording up = to you.  I suggest that you create a

    subsection of "Introducti= on" which discusses potential

    oscillations and stability in = greater detail.  If you like, I will

    provide some text.<= /p>

 

[Alia] I do hear yo= ur concern that jitter could cause oscillations and impact stability. = I am not fully persuaded that this is a practical issue – given the = delays in ingress re-optimization, not trying to minimize the jitter, and the ability for an LSP to reserve bandwidth. = ; I would be interested in what text you might provide and a focused discus= sion on whether this is something that needs to have restrictions clearly d= escribed to avoid oscillations.

 

For now, I have cha= nged this paragraph to:

 

“When conside= ring performance-based data, it is obvious that there

are additional cont= ributors beyond just the links. Clearly end-to-end

latency is a combin= ation of router latency, queuing latency, physical

link latency and ot= her factors.  While traversing a router can cause

delay, that can be = included in the advertised link delay.  As

described in [I-D.i= etf-ospf-te-metric-extensions] and

[I-D.previdi-isis-t= e-metric-extensions], queuing delay

should not be inclu= ded in the measurements advertised by OSPF or ISIS.

 

Queuing latency is = specifically excluded to insure freedom from

oscillations and st= ability issues that have plagued prior attempts to

use delay as a rout= ing metric.  If application traffic which follows

path based upon lat= ency constraints, the same traffic might be in an

Expedited Forwardin= g Per-Hop-Behavior [RFC3246] with

minimal queuing del= ay or another PHB with potentially very substantial

per-hop queuing del= ay.  Only traffic which experiences relatively low

congestion, such as= Expedited Forwarding traffic, will experience

delays very close t= o the sum of the reported link delays.”

 

  1.1.  Basic Requirements:<= /p>

 

    Drop "packet loss, jitter= " from the first numeric item.  Otherwise

    OK except use of the word SLA.=   See nits below.

 

[Alia] Changed SLAs= to NPO

 

    After the list please state th= at "For existing MPLS constraints,

    corresponding RSVP-TE signalin= g allows midpoint LSR to use Path

    Tear and/or notification and w= ould use this mechanism to

    accomplish items 3-6.  In= the absense of RSVP-TE signaling

    corresponding to these new con= straints, new mechanisms at the LSP

    ingress are needed." = ; Alternately, consider citing the work by

    George Swallow et al and expla= in how that solves it in the same

    way that a change in admin att= r of a link would (or should, poor

    implementations not withstandi= ng).

 

[Alia] Frankly, I&#= 8217;m confused by this.  I don’t agree that RSVP-TE signaling e= xtensions would solve, for instance, (3):

 

“3. Ability t= o periodically verify that a TE tunnel's current LSP

complies with its c= onfigured end-to-end performance requirements.”

 

Even if the ingress= signaled the end-to-end performance requirements, I don’t see how th= at stops the ingress from verifying compliance?

 

Similarly, only the= ingress could do:

“  = 4.  Ability to move tunnels, using make-before-break, based upon=

   &= nbsp;   computed end-to-end performance complying with configurat= ion

 

   5.&nbs= p; Ability to move tunnels away from any link that is violating an

   &= nbsp;   underlying SLA

 

   6.&nbs= p; Ability to optionally avoid setting up tunnels using any link=

   &= nbsp;   that is violating an SLA, regardless of whether end-to-en= d

   &= nbsp;   performance would still meet requirements.”

 

I have looked for t= he additional work that you are talking about by George Swallow unsuccessfu= lly.  Can you find a pointer to explain what you’re talking abou= t?  The anomalous bits provide a trigger mechanism that a router can use to tell the ingress to do (5); different admin attri= butes could do a similar behavior – and similarly for (6) – but= again that is the flooding for notification aspect.  I think the lack= of RSVP-TE extensions doesn’t cause an issue – these are handled by IGP instead and thus don’t have to be signaled per LS= P.

 

I am not irrevocabl= y opposed to RSVP-TE extensions – if we really need them for practica= l use-cases.  This draft was trying to do the minimum that is sufficie= nt and then, if and when there is a need for more, what extra is needed could be better defined.

 

  2.1.  End-to-End Constraints:

 

    Note: I've requested that jitt= er and loss be dropped from

    draft-ietf-ospf-te-metric-exte= nsions and

    draft-previdi-isis-te-metric-e= xtensions for the same potential

    oscillations and stability rea= sons cited above.

 

[Alia] Yes – = I think we clearly need to have a good email discussion with those interest= ed about what oscillations might actually occur and what could be done to p= revent that.

 

    s/While it has been possible t= o compute a CSPF/It is possible to

    compute a CSPF/

    s/Instead of this approach to = minimize path latency, an/An

    alternative to this approach t= o minimize path latency is an

    approach to place a upper boun= d on path latency.  An/

    Note: both approaches are vali= d.

 

    Delete next paragraph starting= with "This is illustrated as

    follows."  This seem= s to be taken from email and is good email

    discussion but not needed in t= he draft.

 

[Alia] I’ve p= ut in some pseudo-code so I’m ok with taking the example out – = but there does seem to have been confusion even with it in.

 

    Delete next paragraph starting= with "An end-to-end bound on delay

    variation".  Lets ge= t rid of jitter altogether.  (Let the old SNA

    networks be damned. :)

 

    Delete next paragraph starting= with "For link loss".  Get rid of

    link loss altogether.

 

[Alia] Not done = 211; discussion is needed.  I understand that you really really really= don’t want to see loss or delay variation in any of these drafts.

 

  2.2.  Link Constraints:

 

    Drop delay variation and link = loss.

 

    If we are dealing with EF traf= fic then using Unidirectional

    Available Bandwidth and Residu= al Bandwidth makes no sense.  If we

    are dealing with low priority = traffic and we are using

    Unidirectional Available Bandw= idth and Residual Bandwidth in path

    selection will be prone to osc= illations and network instability.

    Therefore delete the entire se= cond paragraph (the one starting

    with "When doing path sel= ection for TE tunnels,".

 

[Alia]  If we = are trying to avoid congesting the link, then Residual Bandwidth is importa= nt and useful regardless of the LSP traffic class.  What is your speci= fic concern with oscillation for bandwidth?  Why is it different than for the bandwidths already advertised and used for TE= path computation?   Come on – the Residual Bandwidth is ju= st the Link Capacity minus that reserved by RSVP-TE – so pretty darn = similar characteristics to the Unreserved Bandwidth per priority…   The Unidirectional Available bandwidth does in= clude an actual traffic measurement – that is averaged over a reasona= ble interval, that can only change with limited frequency – and then = the LSPs need to be reoptimized to use them.  Please explain precisely the oscillation concern with a clear example.<= /p>

 

 

    Also delete the entire third p= aragraph (starting with "Similarly,

    only links whose loss is"= ).  As stated earlier, use of loss is

    either a NOOP (low volume of E= F traffic) or can lead to

    oscillations.  Get rid of= loss entirely.

 

  2.3.  Links out of SLA:

 

    s/SLA/NPO/g (see nits below).<= o:p>

 

    General: A better mechanism th= an an "Anomalous State" flag is

    needed to provide notification= s of change.  One mechanism would be

    to put the commulative constra= int and the cummulative total in the

    ERO and RRO.  A link addi= ng delay can then notify the ingress of

    any LSP for which the commulat= ive constraint is violated.  See

    work by Swallow et al and perh= aps align with that work.

 

[Alia] That could b= e done as well – but the signaling extensions seem like overkill for = the basic problem of letting the ingress compute a complete ERO.  Carr= ying both the cumulative constraint and the cumulative total just means that the midpoint detects a changed link and then has to = verify the performance on each LSP and individually signal it.  Having= an anomalous flag provides a succinct notification to the ingress which ca= n then do the verification and be known to have the updated information.  This solution also requires that th= e midpoints all support it before it can be used.  An advantage of the= ingress computation is that only the ingress needs to have updated code.

 

    The "Anomalous State"= ; flag is helpful for c in the list, but not

    for b.  The case where a = link is out of NPO by 1 msec then changes

    to out of NPO by 10s of msec i= s an example.  The flag is already

    set and therefore the trigger = is unavailable.

 

[Alia] Right –= ; but LSPs that are particular sensitive (i.e. a or c) can have been moved = already.   Having the Anomalous flag set is expected to be unusua= l.  I agree that it is more a hint for (b) than a full solution.

 

  2.3.1.  Use of Anomalous Links for Ne= w Paths

 

    Delete second paragraph regard= ing jitter and loss.

 

  2.3.2.  Links entering the Anomalous = State

 

    This section ignores two cases= in which the Anomalous State does

    not change but a change makes = the path violate a delay

    constraint.  The first is= where all of the links are within NPO

    but a change to a link has mak= e the path delay sum exceed the path

    delay constraint.  The se= cond is where a link which is already in

    the Anomalous State by a small= margin but the path delay is still

    within the constraint.  A= large change in delay at that point will

    not affect the Anomalous State= since it is already set.

 

[Alia]  The An= omalous bit is NOT meant to replace reading the actual value associated wit= h the link and checking each potentially affected LSP.  In the case of= (b), it is a hint to focus on those LSPs first.

 

    A better means of handling cas= e (b) in "2.3.  Links out of SLA" is

    needed.

 

[Alia]  I̵= 7;ve added the following paragraph at the end of 2.3.2:

“It is not su= fficient to just look at the Anomalous bit in order to

determine when TE t= unnels must have their compliance verified.  When

changing to set, th= e Anomalous bit merely provides a hint that

interested TE tunne= ls for case (b) should have their continued

compliance verified= .”

 

  2.3.3.  Links leaving the Anomalous S= tate

 

    Same issue as in "2.3.2.&= nbsp; Links entering the Anomalous State".  A

    better means of handling case = (b) in "2.3.  Links out of SLA" is

    needed.

 

 

[Alia]  I̵= 7;ve added the following sentence:

“The hint pro= vided by the Anomalous state change may help optimize when to recompute for= a better path.”

 

XML version nits:

 

  CV: you really should remove the template = comments.

 

[Alia]  I find= them helpful for when I want to do additional things… and very very = few people read the XML.

 

  You should also enable strict mode.  = For example, you have one

  author too many and strict would catch tha= t.

 

[Alia]  So doe= s basic arithmetic J   It will be resolved before the draft is = passed to the RFC editor.

 

Other nits:

 

  The "A" in SLA is "Agreemen= t" as in contract.  The acronym NPO for

  network performance objective seems to be = in vogue for that reason.

  IETF since diffserv has wanted to steer cl= ear of making

  recommendations regarding provider contrac= ts (agreements) with

  customers, peer, or anyone else.

 

[Alia]  True -= changed

 

  I agree with Sri on the suggestions to cha= nge the title, short name

  and document filename but I'm not fond of = his suggested new names.

  Authors please suggest new title, short na= me, and filename.

 

[Alia]  I did = do a new short name and title.  As for filename, we’ll deal with= that if/when the draft is adopted as a WG draft.

 

Thanks again,<= /o:p>

Alia

 

 

------- Forwarded Message

 

On 4/5/13 9:50 PM, "Loa Andersson" <= loa@pi.nu> wrote:

> 

>Xiaohu, Sri, Rajiv and Pranjal,

> 

>You have been selected as an MPLS Review team= reviewers for

>draft-atlas-mpls-te-express-path-02.

> 

>Note to authors: You have been CC'd on this e= mail so that you can know

>that this review is going on. However, please= do not review your own

>document.

> 

>Reviews should comment on whether the documen= t is coherent, is it

>useful (ie, is it likely to be actually usefu= l in operational

>networks), and is the document technically so= und?  We are interested in

>knowing whether the document is ready to be c= onsidered for WG adoption

>(ie, it doesn't have to be perfect at this po= int, but should be a good

>start).

> 

>Reviews should be sent to the document author= s, WG co-chairs and WG

>secretary, and CC'd to the MPLS WG email list= . If necessary, comments

>may be sent privately to only the WG chairs.<= o:p>

> 

>Are you able to review this draft by April 20= , 2013?

> 

>Thanks, Loa

>(as MPLS WG chair)

> 

>/Loa

>--

> 

> 

>Loa Andersson     &n= bsp;            = ;      email: loa@mail01.huawei.com=

>Senior MPLS Expert    &nb= sp;            =          loa@pi.nu<= o:p>

>Huawei Technologies (consultant)  &= nbsp;  phone: +46 739 81 21 64

 

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.iet= f.org/mailman/listinfo/mpls

 

------- End of Forwarded Message

 

--_000_D1CF735B7C7B744582438550F826E01B3513CFDFBY2PRD0510MB389_-- From loa@pi.nu Wed Jul 10 00:14:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47F21F9F32 for ; Wed, 10 Jul 2013 00:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6te-GjsQCH8f for ; Wed, 10 Jul 2013 00:14:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E14AE21F9F29 for ; Wed, 10 Jul 2013 00:14:40 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 99B851800272; Wed, 10 Jul 2013 09:14:39 +0200 (CEST) Message-ID: <51DD09E2.1020902@pi.nu> Date: Wed, 10 Jul 2013 09:14:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" References: <51C9748A.30802@pi.nu> In-Reply-To: <51C9748A.30802@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-targeted-mldp@tools.ietf.org Subject: [mpls] CLOSED: working group lst call on draft-ietf-mpls-targeted-mldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 07:14:47 -0000 Working Group, This working group last group call has been closed. There has been comments, could the authors please address the comments and re-post a new version of the draft as necessary. /Loa for the wg co-chairs On 2013-06-25 12:44, Loa Andersson wrote: > Working Groups, > > PWE3 working group, > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-targeted-mldp-02.txt. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on July 9, 2013. > > /Loa > for the wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From yaakov_s@rad.com Wed Jul 10 07:54:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538FF21F9DCF for ; Wed, 10 Jul 2013 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24MkFSOqjxdZ for ; Wed, 10 Jul 2013 07:54:12 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC3E21F9C7D for ; Wed, 10 Jul 2013 07:53:39 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 10 Jul 2013 17:53:20 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.03.0146.000; Wed, 10 Jul 2013 17:53:35 +0300 From: Yaakov Stein To: "tictoc@ietf.org" Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gE5BdwQ Date: Wed, 10 Jul 2013 14:53:35 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904E5CC95@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0C0203.51DD7570.014F,ss=1,fgs=0 Cc: "mpls@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:54:17 -0000 I support this draft. I disagree with Greg (which doesn't often happen) in that I don't see this= as adding that much complexity; all that is needed is to associate the desired characteristics with a spec= ific label. I agree that sending 1588 over the GACh DCN would be an alternative mechan= ism that was not discussed in TICTOC; I am far from sure that this would be a better solution that the proposed = one. In particular, by the time an intermediate LSR discovers that this is a 15= 88 packet, it would probably be too late to timestamp it for TC. Y(J)S =20 -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Yaakov Stein Sent: 04 July, 2013 12:21 To: tictoc@ietf.org Cc: mpls@ietf.org Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-= 05). Please send indications of support, as well as any remaining technical comm= ents, to the list. Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG, but please conduct all discussion on the TICTOC working group mail= ing list. This working group last call will end on July 19, 2013. Y(J)S=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From spencer.giacalone@thomsonreuters.com Wed Jul 10 05:42:41 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF4621F9EF1 for ; Wed, 10 Jul 2013 05:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmDQGO8gggeX for ; Wed, 10 Jul 2013 05:42:29 -0700 (PDT) Received: from mailout1-trp.thomsonreuters.com (mailout1-trp.thomsonreuters.com [163.231.6.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1863E21F9F00 for ; Wed, 10 Jul 2013 05:42:28 -0700 (PDT) Received: from trpusmneagrly01.int.westgroup.com (relay1 [163.231.22.97]) by mailout1-trp.thomsonreuters.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6ACgKZe008261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 12:42:20 GMT Received: from EAGE-ERFPHUB12.ERF.thomson.com (EAGE-ERFPHUB12.erf.thomson.com [10.220.31.97]) by trpusmneagrly01.int.westgroup.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6ACgATx026394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 12:42:18 GMT Received: from C111HBREMBX71.ERF.thomson.com ([fe80::592b:dd83:9937:cc0b]) by EAGE-ERFPHUB12.ERF.thomson.com ([fe80::fd21:37:dee1:80cb%12]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 07:42:11 -0500 From: To: , , , , Thread-Topic: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQEgd81DJTuOixUmkYclheypVJZldkPcA///WhhA= Date: Wed, 10 Jul 2013 12:42:11 +0000 Message-ID: References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.30.4] Content-Type: multipart/alternative; boundary="_000_CDFBD39D51B6734A9402D4B52ABDF05901C740C1C111HBREMBX71ER_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Jul 2013 07:55:13 -0700 Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 12:42:41 -0000 --_000_CDFBD39D51B6734A9402D4B52ABDF05901C740C1C111HBREMBX71ER_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to get more feedback on removing jitter and loss from OSPF TE ME b= efore doing so. So far, Curtis, it's only you asking for it (to be removed)= . Also, no one else seems uncomfortable with the A bit.. I am not personall= y in favor of removing them, and I feel the A bit is fine for my use case. From: Alia Atlas [mailto:akatlas@juniper.net] Sent: Tuesday, July 09, 2013 4:00 PM To: curtis@ipv6.occnc.com; MPLS WG Mailing List; draft-atlas-mpls-te-expres= s-path authors; The Great and Mighty MPLS Co-Chairs Subject: RE: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...= ) Hi Curtis, Thanks for your detailed comments and suggestions. My responses are in-lin= e, as always. Alia -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] Sent: Tuesday, April 23, 2013 12:59 PM To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Gre= at and Mighty MPLS Co-Chairs Cc: curtis@ipv6.occnc.com Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Loa, authors, et al, So far I have seen two of the four MPLS-RT reviews (maybe I missed the othe= rs). I've commented before on the mailing list about this draft but at thi= s point I would like to provide a detailed review. I think there are very major issues with this document as it now stands. I= MO these issues should be addressed before the draft is even accepted as a = WG document. You can choose to consider this during MPLS-RT review or after. Curtis Major issues: Jitter and loss are very close to meaningless if queueing delays and loss are not considered. Links that are losing packets at the link layer are generally taken down. Oscillations can occur if queueing delay and loss is considered, such as measurements at a low priority and therefore possible to congest or measurements which are otherwise affected by traffic load. Unless there is adequate discussion of stability and mechanisms to insure stability, then jitter and loss should be removed. [Alia] I have changed the second paragraph of the introduction to be: " Queuing latency is specifically excluded to insure freedom from oscillations and stability issues that have plagued prior attempts to use delay as a routing metric. If application traffic which follows path based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing delay or another PHB with potentially very substantial per-hop queuing delay. Only traffic which experiences relatively low congestion, such as Expedited Forwarding traffic, will experience delays very close to the sum of the reported link delays" Removing queuing delay is the agreed result for draft-ietf-ospf-te-metric-e= xtensions. As far as jitter and loss goes, these can still be somewhat meaningful. Fo= r instance, jitter does allow capturing the differences in serialization de= lays - which is relevant in some parts of the network. The acceptable loss= to take a link down may vary. I don't actually see the reasoning or need= to remove jitter and loss from the draft - given that we have constrained = the measurements in the draft-ietf-ospf-te-metric-extensions to not include= queuing delay. General: It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, see nits below) is specific to a link, and not an NPO per LSP. A "non-conformance to NPO" flag in the IGP link advertisement is intractable if there are multiple NPO being applied to the link. [Alia] As you may recall from draft-ietf-ospf-te-metric-extensions, the Ano= malous bit is specified per characteristic advertised per link. This draf= t (draft-atlas-mpls-te-express-path-02) describes the Anomalous bit as clea= rly inside a links' sub-TLV as in Sec 2.3.1: "If the answer to (a) is no for latency SLAs, then any link which has the Anomalous bit set in the Unidirectional Link Delay sub- TLV[I-D.ietf-ospf-te-metric-extensions] [I-D.previdi-isis-te-metric-extensions] should be removed from the topology before a CSPF calculation is used to compute a new path." The use of a "non-conformance to NPO" flag as the only means to alert the set of LSP ingress of a significant change is also at best a poor solution. For example, a change from 2 msec to 15 msec may be a problem for some LSP. That same change may not be a problem for others, such as LSPs where only this one hop is needed. So advertising out of NPO in the IGP doesn't help the second case. LSP ingress must evaluate the path delay constraint, each time a change in IGP link advertised delay is received. [Alia] Sure - different LSPs may have different requirements as to the Anom= alous flag. Using it doesn't replace paying attention to the value that is= advertised. The anomalous flag is reporting that the link is not complyin= g to the expected performance - this can indicate that there is something s= trange going on and some LSPs should avoid using that link due to administr= ative policy. The use of a "non-conformance to NPO" flag solely as a constraint makes sense, where some LSP are configured to exclude links with this flag set. [Alia] Right - case (a) and (c) for Sec 2.3 For path delay computation it would also be useful if the NPO threshhold were advertised. In some cases, it may make sense to minimize or place bounds on the sum of NPO delays. [Alia] I think that should be a comment on draft-ietf-ospf-te-metric-extens= ions. This draft doesn't define what is flooded. A question though is wh= ether in the same network it would make sense to consider both the NPO dela= ys and the actual measured delays? If only one or the other - then that co= uld be a local router's decision as to which is flooded. Specific: Abstract: Remove mention of jitter and loss. [Alia] I am interested in the opinion of the WG on this. In my view, this = draft is describing how the information flooded via the new sub-TLVs in dra= ft-ietf-ospf-te-metric-extensions-04 should be used. Loss and jitter are i= ncluded in that draft; of course, that draft could change as well - but I'd= like to hear stronger arguments for why it is harmful to include them than= that they're only relevant when queuing behavior is included and that can = lead to oscillations. I am, perhaps stubbornly, not convinced that they ar= e irrelevant. 1. Introduction: This sentence is awkward but I think I know what you are trying to say. The method suggested is not optimal for both minimizing path cost and additional constraints, such as latency; optimal solutions are computationally complex. Please consider this replacement. Methods of optimizing path selection for multiple parameters are generally computationally complex. The method proposed here are to make use of either a single metric in path selection, such as minimal path delay, or to make use of another single metric, such as the existing TE metric with additional constraints, such as target link delay bounds and target path delay bounds. [Alia] Thanks for the better text - put in... Please note: The path selection mechanisms described in this document apply to paths that are fully computed by the head-end of the LSP and then signaled in an ERO where every sub-object is strict. This allows the head-end to consider IGP-distributed performance data without requiring the ability to signal the performance constraints in an object of the RSVP Path message. There is work in MPLS or CCAMP by George Swallow and others on cummulative metrics in RSVP-TE with delay as a major motivation. Perhaps that work should be considered. [Alia] I believe you are referring to http://tools.ietf.org/html/draft-iet= f-ccamp-te-metric-recording-01? That draft appears to me to be about how t= o get measurements for latency, jitter, and cost for a given Forwarding Adj= acency or Routing Adjacency so that those values can be advertised into the= IGP. I think this draft is providing a means to collect the data to flood= in draft-ietf-ospf-te-metrics-04. I did add the last sentence in the following: "This document does not specify how a router determines what values to advertise by the IGP; it does assume that the constraints specified in [I-D.ietf-ospf-te-metric-extensions] and [I-D.previdi-isis-te-metric-ext= ensions] are followed. Mechanisms for determining latency and delay variat= ion for Forwarding Adjacencies and Routing Adjacencies are defined in [I-D.ietf-ccamp-te-metri= c-recording]." This paragraph could use rewording: When considering performance-based data, it is obvious that there are additional contributors beyond just the links. Clearly end-to-end latency is a combination of router latency, queuing latency, physical link latency and other factors. However, if application traffic requires paths to be selected based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal queuing delay or another PHB with known maximal per-hop queuing delay. While traversing a router can cause delay, that can be included in the advertised link delay. What you are getting at is that where traffic levels can't possibly have a significant impact the measurements, such as low levels of EF traffic in a WAN with high geographic delays, and delay meansured with EF priority, stability is not impacted if delay measurements are considered. In this case, loss MUST be zero or the EF service is broken (replace routers and try again). OTOH jitter will increase as traffic levels increase, even in such a case where the traffic is only a few percent, potentially causing oscillations and impacting stability. For this reason, jitter and loss should not be considered. I will leave the rewording up to you. I suggest that you create a subsection of "Introduction" which discusses potential oscillations and stability in greater detail. If you like, I will provide some text. [Alia] I do hear your concern that jitter could cause oscillations and impa= ct stability. I am not fully persuaded that this is a practical issue - gi= ven the delays in ingress re-optimization, not trying to minimize the jitte= r, and the ability for an LSP to reserve bandwidth. I would be interested = in what text you might provide and a focused discussion on whether this is = something that needs to have restrictions clearly described to avoid oscill= ations. For now, I have changed this paragraph to: "When considering performance-based data, it is obvious that there are additional contributors beyond just the links. Clearly end-to-end latency is a combination of router latency, queuing latency, physical link latency and other factors. While traversing a router can cause delay, that can be included in the advertised link delay. As described in [I-D.ietf-ospf-te-metric-extensions] and [I-D.previdi-isis-te-metric-extensions], queuing delay should not be included in the measurements advertised by OSPF or ISIS. Queuing latency is specifically excluded to insure freedom from oscillations and stability issues that have plagued prior attempts to use delay as a routing metric. If application traffic which follows path based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing delay or another PHB with potentially very substantial per-hop queuing delay. Only traffic which experiences relatively low congestion, such as Expedited Forwarding traffic, will experience delays very close to the sum of the reported link delays." 1.1. Basic Requirements: Drop "packet loss, jitter" from the first numeric item. Otherwise OK except use of the word SLA. See nits below. [Alia] Changed SLAs to NPO After the list please state that "For existing MPLS constraints, corresponding RSVP-TE signaling allows midpoint LSR to use Path Tear and/or notification and would use this mechanism to accomplish items 3-6. In the absense of RSVP-TE signaling corresponding to these new constraints, new mechanisms at the LSP ingress are needed." Alternately, consider citing the work by George Swallow et al and explain how that solves it in the same way that a change in admin attr of a link would (or should, poor implementations not withstanding). [Alia] Frankly, I'm confused by this. I don't agree that RSVP-TE signaling= extensions would solve, for instance, (3): "3. Ability to periodically verify that a TE tunnel's current LSP complies with its configured end-to-end performance requirements." Even if the ingress signaled the end-to-end performance requirements, I don= 't see how that stops the ingress from verifying compliance? Similarly, only the ingress could do: " 4. Ability to move tunnels, using make-before-break, based upon computed end-to-end performance complying with configuration 5. Ability to move tunnels away from any link that is violating an underlying SLA 6. Ability to optionally avoid setting up tunnels using any link that is violating an SLA, regardless of whether end-to-end performance would still meet requirements." I have looked for the additional work that you are talking about by George = Swallow unsuccessfully. Can you find a pointer to explain what you're talk= ing about? The anomalous bits provide a trigger mechanism that a router ca= n use to tell the ingress to do (5); different admin attributes could do a = similar behavior - and similarly for (6) - but again that is the flooding f= or notification aspect. I think the lack of RSVP-TE extensions doesn't cau= se an issue - these are handled by IGP instead and thus don't have to be si= gnaled per LSP. I am not irrevocably opposed to RSVP-TE extensions - if we really need them= for practical use-cases. This draft was trying to do the minimum that is = sufficient and then, if and when there is a need for more, what extra is ne= eded could be better defined. 2.1. End-to-End Constraints: Note: I've requested that jitter and loss be dropped from draft-ietf-ospf-te-metric-extensions and draft-previdi-isis-te-metric-extensions for the same potential oscillations and stability reasons cited above. [Alia] Yes - I think we clearly need to have a good email discussion with t= hose interested about what oscillations might actually occur and what could= be done to prevent that. s/While it has been possible to compute a CSPF/It is possible to compute a CSPF/ s/Instead of this approach to minimize path latency, an/An alternative to this approach to minimize path latency is an approach to place a upper bound on path latency. An/ Note: both approaches are valid. Delete next paragraph starting with "This is illustrated as follows." This seems to be taken from email and is good email discussion but not needed in the draft. [Alia] I've put in some pseudo-code so I'm ok with taking the example out -= but there does seem to have been confusion even with it in. Delete next paragraph starting with "An end-to-end bound on delay variation". Lets get rid of jitter altogether. (Let the old SNA networks be damned. :) Delete next paragraph starting with "For link loss". Get rid of link loss altogether. [Alia] Not done - discussion is needed. I understand that you really reall= y really don't want to see loss or delay variation in any of these drafts. 2.2. Link Constraints: Drop delay variation and link loss. If we are dealing with EF traffic then using Unidirectional Available Bandwidth and Residual Bandwidth makes no sense. If we are dealing with low priority traffic and we are using Unidirectional Available Bandwidth and Residual Bandwidth in path selection will be prone to oscillations and network instability. Therefore delete the entire second paragraph (the one starting with "When doing path selection for TE tunnels,". [Alia] If we are trying to avoid congesting the link, then Residual Bandwi= dth is important and useful regardless of the LSP traffic class. What is y= our specific concern with oscillation for bandwidth? Why is it different t= han for the bandwidths already advertised and used for TE path computation?= Come on - the Residual Bandwidth is just the Link Capacity minus that re= served by RSVP-TE - so pretty darn similar characteristics to the Unreserve= d Bandwidth per priority... The Unidirectional Available bandwidth does i= nclude an actual traffic measurement - that is averaged over a reasonable i= nterval, that can only change with limited frequency - and then the LSPs ne= ed to be reoptimized to use them. Please explain precisely the oscillation= concern with a clear example. Also delete the entire third paragraph (starting with "Similarly, only links whose loss is"). As stated earlier, use of loss is either a NOOP (low volume of EF traffic) or can lead to oscillations. Get rid of loss entirely. 2.3. Links out of SLA: s/SLA/NPO/g (see nits below). General: A better mechanism than an "Anomalous State" flag is needed to provide notifications of change. One mechanism would be to put the commulative constraint and the cummulative total in the ERO and RRO. A link adding delay can then notify the ingress of any LSP for which the commulative constraint is violated. See work by Swallow et al and perhaps align with that work. [Alia] That could be done as well - but the signaling extensions seem like = overkill for the basic problem of letting the ingress compute a complete ER= O. Carrying both the cumulative constraint and the cumulative total just m= eans that the midpoint detects a changed link and then has to verify the pe= rformance on each LSP and individually signal it. Having an anomalous flag= provides a succinct notification to the ingress which can then do the veri= fication and be known to have the updated information. This solution also = requires that the midpoints all support it before it can be used. An advan= tage of the ingress computation is that only the ingress needs to have upda= ted code. The "Anomalous State" flag is helpful for c in the list, but not for b. The case where a link is out of NPO by 1 msec then changes to out of NPO by 10s of msec is an example. The flag is already set and therefore the trigger is unavailable. [Alia] Right - but LSPs that are particular sensitive (i.e. a or c) can hav= e been moved already. Having the Anomalous flag set is expected to be unu= sual. I agree that it is more a hint for (b) than a full solution. 2.3.1. Use of Anomalous Links for New Paths Delete second paragraph regarding jitter and loss. 2.3.2. Links entering the Anomalous State This section ignores two cases in which the Anomalous State does not change but a change makes the path violate a delay constraint. The first is where all of the links are within NPO but a change to a link has make the path delay sum exceed the path delay constraint. The second is where a link which is already in the Anomalous State by a small margin but the path delay is still within the constraint. A large change in delay at that point will not affect the Anomalous State since it is already set. [Alia] The Anomalous bit is NOT meant to replace reading the actual value = associated with the link and checking each potentially affected LSP. In th= e case of (b), it is a hint to focus on those LSPs first. A better means of handling case (b) in "2.3. Links out of SLA" is needed. [Alia] I've added the following paragraph at the end of 2.3.2: "It is not sufficient to just look at the Anomalous bit in order to determine when TE tunnels must have their compliance verified. When changing to set, the Anomalous bit merely provides a hint that interested TE tunnels for case (b) should have their continued compliance verified." 2.3.3. Links leaving the Anomalous State Same issue as in "2.3.2. Links entering the Anomalous State". A better means of handling case (b) in "2.3. Links out of SLA" is needed. [Alia] I've added the following sentence: "The hint provided by the Anomalous state change may help optimize when to = recompute for a better path." XML version nits: CV: you really should remove the template comments. [Alia] I find them helpful for when I want to do additional things... and = very very few people read the XML. You should also enable strict mode. For example, you have one author too many and strict would catch that. [Alia] So does basic arithmetic :) It will be resolved before the draft = is passed to the RFC editor. Other nits: The "A" in SLA is "Agreement" as in contract. The acronym NPO for network performance objective seems to be in vogue for that reason. IETF since diffserv has wanted to steer clear of making recommendations regarding provider contracts (agreements) with customers, peer, or anyone else. [Alia] True - changed I agree with Sri on the suggestions to change the title, short name and document filename but I'm not fond of his suggested new names. Authors please suggest new title, short name, and filename. [Alia] I did do a new short name and title. As for filename, we'll deal w= ith that if/when the draft is adopted as a WG draft. Thanks again, Alia ------- Forwarded Message On 4/5/13 9:50 PM, "Loa Andersson" > wrote: > >Xiaohu, Sri, Rajiv and Pranjal, > >You have been selected as an MPLS Review team reviewers for >draft-atlas-mpls-te-express-path-02. > >Note to authors: You have been CC'd on this email so that you can know >that this review is going on. However, please do not review your own >document. > >Reviews should comment on whether the document is coherent, is it >useful (ie, is it likely to be actually useful in operational >networks), and is the document technically sound? We are interested in >knowing whether the document is ready to be considered for WG adoption >(ie, it doesn't have to be perfect at this point, but should be a good >start). > >Reviews should be sent to the document authors, WG co-chairs and WG >secretary, and CC'd to the MPLS WG email list. If necessary, comments >may be sent privately to only the WG chairs. > >Are you able to review this draft by April 20, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------- End of Forwarded Message --_000_CDFBD39D51B6734A9402D4B52ABDF05901C740C1C111HBREMBX71ER_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to get = more feedback on removing jitter and loss from OSPF TE ME before doing so. = So far, Curtis, it’s only you asking for it (to be removed). Also, no= one else seems uncomfortable with the A bit.. I am not personally in favor of removing them, and I feel the A bit is fine = for my use case.

 

 

 

From: Alia Atl= as [mailto:akatlas@juniper.net]
Sent: Tuesday, July 09, 2013 4:00 PM
To: curtis@ipv6.occnc.com; MPLS WG Mailing List; draft-atlas-mpls-te= -express-path authors; The Great and Mighty MPLS Co-Chairs
Subject: RE: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review= of ...)

 

Hi Curtis,

 

Thanks for your det= ailed comments and suggestions.  My responses are in-line, as always.<= o:p>

 

Alia

 

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]
Sent: Tuesday, April 23, 2013 12:59 PM
To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Gre= at and Mighty MPLS Co-Chairs
Cc: curtis@ipv6.occnc.com
Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...)

 

 

Loa, authors, et al,

 

So far I have seen two of the four MPLS-RT review= s (maybe I missed the others).  I've commented before on the mailing l= ist about this draft but at this point I would like to provide a detailed r= eview.

 

I think there are very major issues with this doc= ument as it now stands.  IMO these issues should be addressed before t= he draft is even accepted as a WG document.

 

You can choose to consider this during MPLS-RT re= view or after.

 

Curtis

 

 

 

 

Major issues:

 

  Jitter and loss are very close to meaningl= ess if queueing delays and

  loss are not considered.  Links that = are losing packets at the link

  layer are generally taken down.  Osci= llations can occur if queueing

  delay and loss is considered, such as meas= urements at a low priority

  and therefore possible to congest or measu= rements which are

  otherwise affected by traffic load.  = Unless there is adequate

  discussion of stability and mechanisms to = insure stability, then

  jitter and loss should be removed.

 

[Alia] I have chang= ed the second paragraph of the introduction to be:

 

" Queuing late= ncy is specifically excluded to insure freedom from

   oscill= ations and stability issues that have plagued prior attempts to<= /span>

   use de= lay as a routing metric.  If application traffic which follows

   path b= ased upon latency constraints, the same traffic might be in an

   Expedi= ted Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing

   delay = or another PHB with potentially very substantial per-hop<= /p>

   queuin= g delay.  Only traffic which experiences relatively low

   conges= tion, such as Expedited Forwarding traffic, will experience

   delays= very close to the sum of the reported link delays"<= /p>

 

Removing queuing de= lay is the agreed result for draft-ietf-ospf-te-metric-extensions.

As far as jitter an= d loss goes, these can still be somewhat meaningful.  For instance, ji= tter does allow capturing the differences in serialization delays - which i= s relevant in some parts of the network.  The acceptable loss to take a link down may vary.   I don't actu= ally see the reasoning or need to remove jitter and loss from the draft - g= iven that we have constrained the measurements in the draft-ietf-ospf-te-me= tric-extensions to not include queuing delay.

 

General:

 

  It needs to be much more clearly stated th= at the NPO (s/SLA/NPO/g,

  see nits below) is specific to a link, and= not an NPO per LSP.  A

  "non-conformance to NPO" flag in= the IGP link advertisement is

  intractable if there are multiple NPO bein= g applied to the link.

 

[Alia] As you may r= ecall from draft-ietf-ospf-te-metric-extensions, the Anomalous bit is speci= fied per characteristic advertised per link.   This draft (draft-= atlas-mpls-te-express-path-02) describes the Anomalous bit as clearly inside a links’ sub-TLV as in Sec 2.3.1:

 

“If the answe= r to (a) is no for latency SLAs, then any link which has<= /p>

the Anomalous bit s= et in the Unidirectional Link Delay sub-

TLV[I-D.ietf-ospf-t= e-metric-extensions]

[I-D.previdi-isis-t= e-metric-extensions] should be removed from the

topology before a C= SPF calculation is used to compute a new path.”

 

  The use of a "non-conformance to NPO&= quot; flag as the only means to

  alert the set of LSP ingress of a signific= ant change is also at best

  a poor solution.  For example, a chan= ge from 2 msec to 15 msec may

  be a problem for some LSP.  That same= change may not be a problem

  for others, such as LSPs where only this o= ne hop is needed.  So

  advertising out of NPO in the IGP doesn't = help the second case.  LSP

  ingress must evaluate the path delay const= raint, each time a change

  in IGP link advertised delay is received.<= o:p>

 

[Alia] Sure –= different LSPs may have different requirements as to the Anomalous flag.&n= bsp; Using it doesn’t replace paying attention to the value that is a= dvertised.  The anomalous flag is reporting that the link is not complying to the expected performance – this can indicat= e that there is something strange going on and some LSPs should avoid using= that link due to administrative policy. 

 

  The use of a "non-conformance to NPO&= quot; flag solely as a constraint

  makes sense, where some LSP are configured= to exclude links with

  this flag set.

 

[Alia] Right –= ; case (a) and (c) for Sec 2.3

 

  For path delay computation it would also b= e useful if the NPO

  threshhold were advertised.  In some = cases, it may make sense to

  minimize or place bounds on the sum of NPO= delays.

 

[Alia] I think that= should be a comment on draft-ietf-ospf-te-metric-extensions.  This dr= aft doesn’t define what is flooded.   A question though is = whether in the same network it would make sense to consider both the NPO delays and the actual measured delays?  If only one or t= he other – then that could be a local router’s decision as to w= hich is flooded.

 

Specific:

 

  Abstract:

 

    Remove mention of jitter and l= oss.

 

 

[Alia] I am interes= ted in the opinion of the WG on this.  In my view, this draft is descr= ibing how the information flooded via the new sub-TLVs in draft-ietf-ospf-t= e-metric-extensions-04 should be used.  Loss and jitter are included in that draft; of course, that draft could change = as well – but I’d like to hear stronger arguments for why it is= harmful to include them than that they’re only relevant when queuing= behavior is included and that can lead to oscillations.  I am, perhaps stubbornly, not convinced that they are irrelevant.

 

  1.  Introduction:

 

    This sentence is awkward but I= think I know what you are trying to

    say.

 

      The method suggest= ed is not optimal for both minimizing path

      cost and additiona= l constraints, such as latency; optimal

      solutions are comp= utationally complex.

 

    Please consider this replaceme= nt.

 

      Methods of optimiz= ing path selection for multiple parameters are

      generally computat= ionally complex.  The method proposed here are

      to make use of eit= her a single metric in path selection, such as

      minimal path delay= , or to make use of another single metric,

      such as the existi= ng TE metric with additional constraints, such

      as target link del= ay bounds and target path delay bounds.

 

[Alia] Thanks for t= he better text – put in…

 

    Please note:

 

      The path selection= mechanisms described in this document apply

      to paths that are = fully computed by the head-end of the LSP and

      then signaled in a= n ERO where every sub-object is strict.  This

      allows the head-en= d to consider IGP-distributed performance data

      without requiring = the ability to signal the performance

      constraints in an = object of the RSVP Path message.

 

    There is work in MPLS or CCAMP= by George Swallow and others on

    cummulative metrics in RSVP-TE= with delay as a major motivation.

    Perhaps that work should be co= nsidered.

 

[Alia]  I beli= eve you are referring to http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-= 01?  That draft appears to me to be = about how to get measurements for latency, jitter, and cost for a given Forwarding Adjacency or Routing Adjacency so = that those values can be advertised into the IGP.  I think this draft = is providing a means to collect the data to flood in draft-ietf-ospf-te-met= rics-04. 

 

I did add the last = sentence in the following:

 

“This documen= t does not specify how a router determines what values

to advertise by the= IGP; it does assume that the constraints specified

in [I-D.ietf-ospf-t= e-metric-extensions] and [I-D.previdi-isis-te-metric-extensions] are follow= ed.  Mechanisms for determining latency and delay variation for Forwar= ding

Adjacencies and Rou= ting Adjacencies are defined in [I-D.ietf-ccamp-te-metric-recording].”= ;

 

 

    This paragraph could use rewor= ding:

 

      When considering p= erformance-based data, it is obvious that

      there are addition= al contributors beyond just the links.

      Clearly end-to-end= latency is a combination of router latency,

      queuing latency, p= hysical link latency and other factors.

      However, if applic= ation traffic requires paths to be selected

      based upon latency= constraints, the same traffic might be in an

      Expedited Forwardi= ng Per-Hop- Behavior[RFC3246] with minimal

      queuing delay or a= nother PHB with known maximal per-hop queuing

      delay.  While= traversing a router can cause delay, that can be

      included in the ad= vertised link delay.

 

    What you are getting at is tha= t where traffic levels can't

    possibly have a significant im= pact the measurements, such as low

    levels of EF traffic in a WAN = with high geographic delays, and

    delay meansured with EF priori= ty, stability is not impacted if

    delay measurements are conside= red.  In this case, loss MUST be

    zero or the EF service is brok= en (replace routers and try again).

    OTOH jitter will increase as t= raffic levels increase, even in such

    a case where the traffic is on= ly a few percent, potentially

    causing oscillations and impac= ting stability.  For this reason,

    jitter and loss should not be = considered.

 

    I will leave the rewording up = to you.  I suggest that you create a

    subsection of "Introducti= on" which discusses potential

    oscillations and stability in = greater detail.  If you like, I will

    provide some text.<= /p>

 

[Alia] I do hear yo= ur concern that jitter could cause oscillations and impact stability. = I am not fully persuaded that this is a practical issue – given the = delays in ingress re-optimization, not trying to minimize the jitter, and the ability for an LSP to reserve bandwidth. = ; I would be interested in what text you might provide and a focused discus= sion on whether this is something that needs to have restrictions clearly d= escribed to avoid oscillations.

 

For now, I have cha= nged this paragraph to:

 

“When conside= ring performance-based data, it is obvious that there

are additional cont= ributors beyond just the links. Clearly end-to-end

latency is a combin= ation of router latency, queuing latency, physical

link latency and ot= her factors.  While traversing a router can cause

delay, that can be = included in the advertised link delay.  As

described in [I-D.i= etf-ospf-te-metric-extensions] and

[I-D.previdi-isis-t= e-metric-extensions], queuing delay

should not be inclu= ded in the measurements advertised by OSPF or ISIS.

 

Queuing latency is = specifically excluded to insure freedom from

oscillations and st= ability issues that have plagued prior attempts to

use delay as a rout= ing metric.  If application traffic which follows

path based upon lat= ency constraints, the same traffic might be in an

Expedited Forwardin= g Per-Hop-Behavior [RFC3246] with

minimal queuing del= ay or another PHB with potentially very substantial

per-hop queuing del= ay.  Only traffic which experiences relatively low

congestion, such as= Expedited Forwarding traffic, will experience

delays very close t= o the sum of the reported link delays.”

 

  1.1.  Basic Requirements:<= /p>

 

    Drop "packet loss, jitter= " from the first numeric item.  Otherwise

    OK except use of the word SLA.=   See nits below.

 

[Alia] Changed SLAs= to NPO

 

    After the list please state th= at "For existing MPLS constraints,

    corresponding RSVP-TE signalin= g allows midpoint LSR to use Path

    Tear and/or notification and w= ould use this mechanism to

    accomplish items 3-6.  In= the absense of RSVP-TE signaling

    corresponding to these new con= straints, new mechanisms at the LSP

    ingress are needed." = ; Alternately, consider citing the work by

    George Swallow et al and expla= in how that solves it in the same

    way that a change in admin att= r of a link would (or should, poor

    implementations not withstandi= ng).

 

[Alia] Frankly, I&#= 8217;m confused by this.  I don’t agree that RSVP-TE signaling e= xtensions would solve, for instance, (3):

 

“3. Ability t= o periodically verify that a TE tunnel's current LSP

complies with its c= onfigured end-to-end performance requirements.”

 

Even if the ingress= signaled the end-to-end performance requirements, I don’t see how th= at stops the ingress from verifying compliance?

 

Similarly, only the= ingress could do:

“  = 4.  Ability to move tunnels, using make-before-break, based upon=

   &= nbsp;   computed end-to-end performance complying with configurat= ion

 

   5.&nbs= p; Ability to move tunnels away from any link that is violating an

   &= nbsp;   underlying SLA

 

   6.&nbs= p; Ability to optionally avoid setting up tunnels using any link=

   &= nbsp;   that is violating an SLA, regardless of whether end-to-en= d

   &= nbsp;   performance would still meet requirements.”

 

I have looked for t= he additional work that you are talking about by George Swallow unsuccessfu= lly.  Can you find a pointer to explain what you’re talking abou= t?  The anomalous bits provide a trigger mechanism that a router can use to tell the ingress to do (5); different admin attri= butes could do a similar behavior – and similarly for (6) – but= again that is the flooding for notification aspect.  I think the lack= of RSVP-TE extensions doesn’t cause an issue – these are handled by IGP instead and thus don’t have to be signaled per LS= P.

 

I am not irrevocabl= y opposed to RSVP-TE extensions – if we really need them for practica= l use-cases.  This draft was trying to do the minimum that is sufficie= nt and then, if and when there is a need for more, what extra is needed could be better defined.

 

  2.1.  End-to-End Constraints:

 

    Note: I've requested that jitt= er and loss be dropped from

    draft-ietf-ospf-te-metric-exte= nsions and

    draft-previdi-isis-te-metric-e= xtensions for the same potential

    oscillations and stability rea= sons cited above.

 

[Alia] Yes – = I think we clearly need to have a good email discussion with those interest= ed about what oscillations might actually occur and what could be done to p= revent that.

 

    s/While it has been possible t= o compute a CSPF/It is possible to

    compute a CSPF/

    s/Instead of this approach to = minimize path latency, an/An

    alternative to this approach t= o minimize path latency is an

    approach to place a upper boun= d on path latency.  An/

    Note: both approaches are vali= d.

 

    Delete next paragraph starting= with "This is illustrated as

    follows."  This seem= s to be taken from email and is good email

    discussion but not needed in t= he draft.

 

[Alia] I’ve p= ut in some pseudo-code so I’m ok with taking the example out – = but there does seem to have been confusion even with it in.

 

    Delete next paragraph starting= with "An end-to-end bound on delay

    variation".  Lets ge= t rid of jitter altogether.  (Let the old SNA

    networks be damned. :)

 

    Delete next paragraph starting= with "For link loss".  Get rid of

    link loss altogether.

 

[Alia] Not done = 211; discussion is needed.  I understand that you really really really= don’t want to see loss or delay variation in any of these drafts.

 

  2.2.  Link Constraints:

 

    Drop delay variation and link = loss.

 

    If we are dealing with EF traf= fic then using Unidirectional

    Available Bandwidth and Residu= al Bandwidth makes no sense.  If we

    are dealing with low priority = traffic and we are using

    Unidirectional Available Bandw= idth and Residual Bandwidth in path

    selection will be prone to osc= illations and network instability.

    Therefore delete the entire se= cond paragraph (the one starting

    with "When doing path sel= ection for TE tunnels,".

 

[Alia]  If we = are trying to avoid congesting the link, then Residual Bandwidth is importa= nt and useful regardless of the LSP traffic class.  What is your speci= fic concern with oscillation for bandwidth?  Why is it different than for the bandwidths already advertised and used for TE= path computation?   Come on – the Residual Bandwidth is ju= st the Link Capacity minus that reserved by RSVP-TE – so pretty darn = similar characteristics to the Unreserved Bandwidth per priority…   The Unidirectional Available bandwidth does in= clude an actual traffic measurement – that is averaged over a reasona= ble interval, that can only change with limited frequency – and then = the LSPs need to be reoptimized to use them.  Please explain precisely the oscillation concern with a clear example.<= /p>

 

 

    Also delete the entire third p= aragraph (starting with "Similarly,

    only links whose loss is"= ).  As stated earlier, use of loss is

    either a NOOP (low volume of E= F traffic) or can lead to

    oscillations.  Get rid of= loss entirely.

 

  2.3.  Links out of SLA:

 

    s/SLA/NPO/g (see nits below).<= o:p>

 

    General: A better mechanism th= an an "Anomalous State" flag is

    needed to provide notification= s of change.  One mechanism would be

    to put the commulative constra= int and the cummulative total in the

    ERO and RRO.  A link addi= ng delay can then notify the ingress of

    any LSP for which the commulat= ive constraint is violated.  See

    work by Swallow et al and perh= aps align with that work.

 

[Alia] That could b= e done as well – but the signaling extensions seem like overkill for = the basic problem of letting the ingress compute a complete ERO.  Carr= ying both the cumulative constraint and the cumulative total just means that the midpoint detects a changed link and then has to = verify the performance on each LSP and individually signal it.  Having= an anomalous flag provides a succinct notification to the ingress which ca= n then do the verification and be known to have the updated information.  This solution also requires that th= e midpoints all support it before it can be used.  An advantage of the= ingress computation is that only the ingress needs to have updated code.

 

    The "Anomalous State"= ; flag is helpful for c in the list, but not

    for b.  The case where a = link is out of NPO by 1 msec then changes

    to out of NPO by 10s of msec i= s an example.  The flag is already

    set and therefore the trigger = is unavailable.

 

[Alia] Right –= ; but LSPs that are particular sensitive (i.e. a or c) can have been moved = already.   Having the Anomalous flag set is expected to be unusua= l.  I agree that it is more a hint for (b) than a full solution.

 

  2.3.1.  Use of Anomalous Links for Ne= w Paths

 

    Delete second paragraph regard= ing jitter and loss.

 

  2.3.2.  Links entering the Anomalous = State

 

    This section ignores two cases= in which the Anomalous State does

    not change but a change makes = the path violate a delay

    constraint.  The first is= where all of the links are within NPO

    but a change to a link has mak= e the path delay sum exceed the path

    delay constraint.  The se= cond is where a link which is already in

    the Anomalous State by a small= margin but the path delay is still

    within the constraint.  A= large change in delay at that point will

    not affect the Anomalous State= since it is already set.

 

[Alia]  The An= omalous bit is NOT meant to replace reading the actual value associated wit= h the link and checking each potentially affected LSP.  In the case of= (b), it is a hint to focus on those LSPs first.

 

    A better means of handling cas= e (b) in "2.3.  Links out of SLA" is

    needed.

 

[Alia]  I̵= 7;ve added the following paragraph at the end of 2.3.2:

“It is not su= fficient to just look at the Anomalous bit in order to

determine when TE t= unnels must have their compliance verified.  When

changing to set, th= e Anomalous bit merely provides a hint that

interested TE tunne= ls for case (b) should have their continued

compliance verified= .”

 

  2.3.3.  Links leaving the Anomalous S= tate

 

    Same issue as in "2.3.2.&= nbsp; Links entering the Anomalous State".  A

    better means of handling case = (b) in "2.3.  Links out of SLA" is

    needed.

 

 

[Alia]  I̵= 7;ve added the following sentence:

“The hint pro= vided by the Anomalous state change may help optimize when to recompute for= a better path.”

 

XML version nits:

 

  CV: you really should remove the template = comments.

 

[Alia]  I find= them helpful for when I want to do additional things… and very very = few people read the XML.

 

  You should also enable strict mode.  = For example, you have one

  author too many and strict would catch tha= t.

 

[Alia]  So doe= s basic arithmetic J   It will be resolved before the draft is = passed to the RFC editor.

 

Other nits:

 

  The "A" in SLA is "Agreemen= t" as in contract.  The acronym NPO for

  network performance objective seems to be = in vogue for that reason.

  IETF since diffserv has wanted to steer cl= ear of making

  recommendations regarding provider contrac= ts (agreements) with

  customers, peer, or anyone else.

 

[Alia]  True -= changed

 

  I agree with Sri on the suggestions to cha= nge the title, short name

  and document filename but I'm not fond of = his suggested new names.

  Authors please suggest new title, short na= me, and filename.

 

[Alia]  I did = do a new short name and title.  As for filename, we’ll deal with= that if/when the draft is adopted as a WG draft.

 

Thanks again,<= /o:p>

Alia

 

 

------- Forwarded Message

 

On 4/5/13 9:50 PM, "Loa Andersson" <= loa@pi.nu> wrote:

> 

>Xiaohu, Sri, Rajiv and Pranjal,

> 

>You have been selected as an MPLS Review team= reviewers for

>draft-atlas-mpls-te-express-path-02.

> 

>Note to authors: You have been CC'd on this e= mail so that you can know

>that this review is going on. However, please= do not review your own

>document.

> 

>Reviews should comment on whether the documen= t is coherent, is it

>useful (ie, is it likely to be actually usefu= l in operational

>networks), and is the document technically so= und?  We are interested in

>knowing whether the document is ready to be c= onsidered for WG adoption

>(ie, it doesn't have to be perfect at this po= int, but should be a good

>start).

> 

>Reviews should be sent to the document author= s, WG co-chairs and WG

>secretary, and CC'd to the MPLS WG email list= . If necessary, comments

>may be sent privately to only the WG chairs.<= o:p>

> 

>Are you able to review this draft by April 20= , 2013?

> 

>Thanks, Loa

>(as MPLS WG chair)

> 

>/Loa

>--

> 

> 

>Loa Andersson     &n= bsp;            = ;      email: loa@mail01.huawei.com

>Senior MPLS Expert    &nb= sp;            =          loa@pi.nu<= o:p>

>Huawei Technologies (consultant)  &= nbsp;  phone: +46 739 81 21 64

 

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.iet= f.org/mailman/listinfo/mpls

 

------- End of Forwarded Message

 

--_000_CDFBD39D51B6734A9402D4B52ABDF05901C740C1C111HBREMBX71ER_-- From davari@broadcom.com Wed Jul 10 09:10:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17C21F99BB; Wed, 10 Jul 2013 09:10:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNCCPCMj-Vs1; Wed, 10 Jul 2013 09:10:45 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2773221F9956; Wed, 10 Jul 2013 09:10:45 -0700 (PDT) Received: from [10.9.208.53] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 10 Jul 2013 09:01:04 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 10 Jul 2013 09:10:33 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 10 Jul 2013 09:10:32 -0700 From: "Shahram Davari" To: "Yaakov Stein" Thread-Topic: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfYgAr9RTnf48JUaTh89fq3HURg== Date: Wed, 10 Jul 2013 16:10:32 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il>, <07F7D7DED63154409F13298786A2ADC904E5CC95@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E5CC95@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7DC35ACA2L847044251-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:10:49 -0000 Hi I support this draft to go ahead as RFC. We have worked almost 2 years on t= his draft and have addressed all comments by participants and area director= . I disagree with Greg's comment. We have made the draft generic based on Ste= wart's request so that if in future IETF decided to carry other Timing prot= ocols such as NTP they can use the same mechanism. Also I disagree with using GAL-ACH channel, since if the proposal is To use= Section Channel then it can't support TC and can only support BC. And if t= he proposal is to use LSP Channel, then intermediate routers need to do dee= p packet inspection of all packets and detect 1588 packets encapsulated in = the ACH. Also most routers upon detection of any terminated ACH send those = packets directly to CPU. This method had been considered by authors and rej= ected due to its issues. The current method is simple and supports TC and BC. Regards, Shahram >=20 >=20 >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: 04 July, 2013 12:21 > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From edc@google.com Wed Jul 10 09:28:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447A121F9AAB for ; Wed, 10 Jul 2013 09:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.023 X-Spam-Level: *** X-Spam-Status: No, score=3.023 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hOLOa-foXRG for ; Wed, 10 Jul 2013 09:28:34 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6521F9B58 for ; Wed, 10 Jul 2013 09:28:33 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so9723331oah.39 for ; Wed, 10 Jul 2013 09:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ATcReIGfD0EcogC6yNEOohB9e+qiSNlE7CsSYXxkGLA=; b=f04NE02EXfY/UAvof9oXg7M3O6zyganTwWcSBGhxO8VLnTAwe7jT+zdv+uWYsGVjnr BQwIOmwQnstpMPdAjrcqux9R2ViZwyznOIVMVxxTvX8A+0t006jYVUeC0ycld7+WIpFU VIycGDvtgeVoGLzCb1wR9Vn+epqY27fNz72jpDyAFdmaFhZp+mDJQl2xsVIjQyqIFhHC V9Fh9prv4OvrZjOiYffZEAUMz3JhiIO/PMgA7EjLdx+osIZyuyN2KladEBZU2y5rNE0g PhdJHx+Hzzn3Gk2yYitcTc2L1T4mwStoY8gw1zD7U+Pd6ZNAxrayFs2k/JI8Ze3QbjjO KlIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ATcReIGfD0EcogC6yNEOohB9e+qiSNlE7CsSYXxkGLA=; b=LzQoEHOJLPs3mWAsXMuC2SQPYh5A7hg6bnD9UgYN9XKacS1O10Spkx3iegeuJQOCjo nPa/P2GBGrl/v8kifp6Ah9+gHhGV9Tew4YQlqcOpqdxRT7QsduiiBx6dVobPYAe7xlGT LOMBLGIfwX2U5bp4ZltYQU7Zk49mUHKFbvfiq+klrC40cCn6zGowg8SX19Hoad4B7dWH +S9LG9HJ3R9peqrC9rVgh84RITF5KcXRRhU3nCERBPq5el7mzmpyRZ1uzjHaCHXYg7YZ Ui789jBNgX+HboxHDKzbCxqcpIv6yRee2n1kHE+PKTR7A+MAEZTY04pUArMKUZ8dwxnx 6+Tg== X-Received: by 10.182.125.1 with SMTP id mm1mr28033287obb.47.1373473704775; Wed, 10 Jul 2013 09:28:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.88.115 with HTTP; Wed, 10 Jul 2013 09:27:44 -0700 (PDT) In-Reply-To: References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> From: Edward Crabbe Date: Wed, 10 Jul 2013 17:27:44 +0100 Message-ID: To: "spencer.giacalone" Content-Type: multipart/alternative; boundary=089e0122ac5048364304e12ac4f3 X-Gm-Message-State: ALoCoQl7isJbyTTcXEGsdbAae4UB30rpU2RE5LDJsBJM4/ObMLeQrIot7OILGj61jSIy8+vx87UXsPHJqgbgOCIgAhXQBlTHXTD9ZDStf23Zs7ppmVIUJzrGtZyHcNMiImhZB3BF4BHVazE6d7v6iei+Dg2HWNNfTeWKgEIoHwgKNiJkK+wz/qmin/ZWtMzFGkKxLYtm9BwP Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Alia Atlas , draft-atlas-mpls-te-express-path@tools.ietf.org Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:28:37 -0000 --089e0122ac5048364304e12ac4f3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not uncomfortable with the A bit. I just think it's redundant, as discussed in Orlando. On Wed, Jul 10, 2013 at 1:42 PM, wrot= e: > I=92d like to get more feedback on removing jitter and loss from OSPF TE > ME before doing so. So far, Curtis, it=92s only you asking for it (to be > removed). Also, no one else seems uncomfortable with the A bit.. I am not > personally in favor of removing them, and I feel the A bit is fine for my > use case. **** > > ** ** > > ** ** > > ** ** > > *From:* Alia Atlas [mailto:akatlas@juniper.net] > *Sent:* Tuesday, July 09, 2013 4:00 PM > *To:* curtis@ipv6.occnc.com; MPLS WG Mailing List; > draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > Co-Chairs > *Subject:* RE: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of > ...)**** > > ** ** > > Hi Curtis,**** > > ** ** > > Thanks for your detailed comments and suggestions. My responses are > in-line, as always.**** > > ** ** > > Alia**** > > ** ** > > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Tuesday, April 23, 2013 12:59 PM > To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The > Great and Mighty MPLS Co-Chairs > Cc: curtis@ipv6.occnc.com > Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...)*= * > ** > > ** ** > > ** ** > > Loa, authors, et al,**** > > ** ** > > So far I have seen two of the four MPLS-RT reviews (maybe I missed the > others). I've commented before on the mailing list about this draft but = at > this point I would like to provide a detailed review.**** > > ** ** > > I think there are very major issues with this document as it now stands. > IMO these issues should be addressed before the draft is even accepted as= a > WG document.**** > > ** ** > > You can choose to consider this during MPLS-RT review or after.**** > > ** ** > > Curtis**** > > ** ** > > ** ** > > ** ** > > ** ** > > Major issues:**** > > ** ** > > Jitter and loss are very close to meaningless if queueing delays and***= * > > loss are not considered. Links that are losing packets at the link**** > > layer are generally taken down. Oscillations can occur if queueing**** > > delay and loss is considered, such as measurements at a low priority***= * > > and therefore possible to congest or measurements which are**** > > otherwise affected by traffic load. Unless there is adequate**** > > discussion of stability and mechanisms to insure stability, then**** > > jitter and loss should be removed.**** > > ** ** > > [Alia] I have changed the second paragraph of the introduction to be:**** > > ** ** > > " Queuing latency is specifically excluded to insure freedom from**** > > oscillations and stability issues that have plagued prior attempts to*= * > ** > > use delay as a routing metric. If application traffic which follows**= * > * > > path based upon latency constraints, the same traffic might be in an**= * > * > > Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing**= * > * > > delay or another PHB with potentially very substantial per-hop**** > > queuing delay. Only traffic which experiences relatively low**** > > congestion, such as Expedited Forwarding traffic, will experience**** > > delays very close to the sum of the reported link delays"**** > > ** ** > > Removing queuing delay is the agreed result for > draft-ietf-ospf-te-metric-extensions.**** > > As far as jitter and loss goes, these can still be somewhat meaningful. > For instance, jitter does allow capturing the differences in serializatio= n > delays - which is relevant in some parts of the network. The acceptable > loss to take a link down may vary. I don't actually see the reasoning o= r > need to remove jitter and loss from the draft - given that we have > constrained the measurements in the draft-ietf-ospf-te-metric-extensions = to > not include queuing delay.**** > > ** ** > > General:**** > > ** ** > > It needs to be much more clearly stated that the NPO (s/SLA/NPO/g,**** > > see nits below) is specific to a link, and not an NPO per LSP. A**** > > "non-conformance to NPO" flag in the IGP link advertisement is**** > > intractable if there are multiple NPO being applied to the link.**** > > ** ** > > [Alia] As you may recall from draft-ietf-ospf-te-metric-extensions, the > Anomalous bit is specified per characteristic advertised per link. This > draft (draft-atlas-mpls-te-express-path-02) describes the Anomalous bit a= s > clearly inside a links=92 sub-TLV as in Sec 2.3.1:**** > > ** ** > > =93If the answer to (a) is no for latency SLAs, then any link which has**= ** > > the Anomalous bit set in the Unidirectional Link Delay sub-**** > > TLV[I-D.ietf-ospf-te-metric-extensions]**** > > [I-D.previdi-isis-te-metric-extensions] should be removed from the**** > > topology before a CSPF calculation is used to compute a new path.=94**** > > ** ** > > The use of a "non-conformance to NPO" flag as the only means to**** > > alert the set of LSP ingress of a significant change is also at best***= * > > a poor solution. For example, a change from 2 msec to 15 msec may**** > > be a problem for some LSP. That same change may not be a problem**** > > for others, such as LSPs where only this one hop is needed. So**** > > advertising out of NPO in the IGP doesn't help the second case. LSP***= * > > ingress must evaluate the path delay constraint, each time a change**** > > in IGP link advertised delay is received.**** > > ** ** > > [Alia] Sure =96 different LSPs may have different requirements as to the > Anomalous flag. Using it doesn=92t replace paying attention to the value > that is advertised. The anomalous flag is reporting that the link is not > complying to the expected performance =96 this can indicate that there is > something strange going on and some LSPs should avoid using that link due > to administrative policy. **** > > ** ** > > The use of a "non-conformance to NPO" flag solely as a constraint**** > > makes sense, where some LSP are configured to exclude links with**** > > this flag set.**** > > ** ** > > [Alia] Right =96 case (a) and (c) for Sec 2.3**** > > ** ** > > For path delay computation it would also be useful if the NPO**** > > threshhold were advertised. In some cases, it may make sense to**** > > minimize or place bounds on the sum of NPO delays.**** > > ** ** > > [Alia] I think that should be a comment on > draft-ietf-ospf-te-metric-extensions. This draft doesn=92t define what i= s > flooded. A question though is whether in the same network it would make > sense to consider both the NPO delays and the actual measured delays? If > only one or the other =96 then that could be a local router=92s decision = as to > which is flooded.**** > > ** ** > > Specific:**** > > ** ** > > Abstract:**** > > ** ** > > Remove mention of jitter and loss.**** > > ** ** > > ** ** > > [Alia] I am interested in the opinion of the WG on this. In my view, thi= s > draft is describing how the information flooded via the new sub-TLVs in > draft-ietf-ospf-te-metric-extensions-04 should be used. Loss and jitter > are included in that draft; of course, that draft could change as well = =96 > but I=92d like to hear stronger arguments for why it is harmful to includ= e > them than that they=92re only relevant when queuing behavior is included = and > that can lead to oscillations. I am, perhaps stubbornly, not convinced > that they are irrelevant.**** > > ** ** > > 1. Introduction:**** > > ** ** > > This sentence is awkward but I think I know what you are trying to***= * > > say.**** > > ** ** > > The method suggested is not optimal for both minimizing path**** > > cost and additional constraints, such as latency; optimal**** > > solutions are computationally complex.**** > > ** ** > > Please consider this replacement.**** > > ** ** > > Methods of optimizing path selection for multiple parameters are***= * > > generally computationally complex. The method proposed here are***= * > > to make use of either a single metric in path selection, such as***= * > > minimal path delay, or to make use of another single metric,**** > > such as the existing TE metric with additional constraints, such***= * > > as target link delay bounds and target path delay bounds.**** > > ** ** > > [Alia] Thanks for the better text =96 put in=85**** > > ** ** > > Please note:**** > > ** ** > > The path selection mechanisms described in this document apply**** > > to paths that are fully computed by the head-end of the LSP and**** > > then signaled in an ERO where every sub-object is strict. This**** > > allows the head-end to consider IGP-distributed performance data***= * > > without requiring the ability to signal the performance**** > > constraints in an object of the RSVP Path message.**** > > ** ** > > There is work in MPLS or CCAMP by George Swallow and others on**** > > cummulative metrics in RSVP-TE with delay as a major motivation.**** > > Perhaps that work should be considered.**** > > ** ** > > [Alia] I believe you are referring to > http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-01? That > draft appears to me to be about how to get measurements for latency, > jitter, and cost for a given Forwarding Adjacency or Routing Adjacency so > that those values can be advertised into the IGP. I think this draft is > providing a means to collect the data to flood in > draft-ietf-ospf-te-metrics-04. **** > > ** ** > > I did add the last sentence in the following:**** > > ** ** > > =93This document does not specify how a router determines what values**** > > to advertise by the IGP; it does assume that the constraints specified***= * > > in [I-D.ietf-ospf-te-metric-extensions] and > [I-D.previdi-isis-te-metric-extensions] are followed. Mechanisms for > determining latency and delay variation for Forwarding**** > > Adjacencies and Routing Adjacencies are defined in > [I-D.ietf-ccamp-te-metric-recording].=94**** > > ** ** > > ** ** > > This paragraph could use rewording:**** > > ** ** > > When considering performance-based data, it is obvious that**** > > there are additional contributors beyond just the links.**** > > Clearly end-to-end latency is a combination of router latency,**** > > queuing latency, physical link latency and other factors.**** > > However, if application traffic requires paths to be selected**** > > based upon latency constraints, the same traffic might be in an**** > > Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal**** > > queuing delay or another PHB with known maximal per-hop queuing**** > > delay. While traversing a router can cause delay, that can be**** > > included in the advertised link delay.**** > > ** ** > > What you are getting at is that where traffic levels can't**** > > possibly have a significant impact the measurements, such as low**** > > levels of EF traffic in a WAN with high geographic delays, and**** > > delay meansured with EF priority, stability is not impacted if**** > > delay measurements are considered. In this case, loss MUST be**** > > zero or the EF service is broken (replace routers and try again).**** > > OTOH jitter will increase as traffic levels increase, even in such***= * > > a case where the traffic is only a few percent, potentially**** > > causing oscillations and impacting stability. For this reason,**** > > jitter and loss should not be considered.**** > > ** ** > > I will leave the rewording up to you. I suggest that you create a***= * > > subsection of "Introduction" which discusses potential**** > > oscillations and stability in greater detail. If you like, I will***= * > > provide some text.**** > > ** ** > > [Alia] I do hear your concern that jitter could cause oscillations and > impact stability. I am not fully persuaded that this is a practical issu= e > =96 given the delays in ingress re-optimization, not trying to minimize t= he > jitter, and the ability for an LSP to reserve bandwidth. I would be > interested in what text you might provide and a focused discussion on > whether this is something that needs to have restrictions clearly describ= ed > to avoid oscillations.**** > > ** ** > > For now, I have changed this paragraph to:**** > > ** ** > > =93When considering performance-based data, it is obvious that there**** > > are additional contributors beyond just the links. Clearly end-to-end**** > > latency is a combination of router latency, queuing latency, physical**** > > link latency and other factors. While traversing a router can cause**** > > delay, that can be included in the advertised link delay. As**** > > described in [I-D.ietf-ospf-te-metric-extensions] and**** > > [I-D.previdi-isis-te-metric-extensions], queuing delay**** > > should not be included in the measurements advertised by OSPF or ISIS.***= * > > ** ** > > Queuing latency is specifically excluded to insure freedom from**** > > oscillations and stability issues that have plagued prior attempts to**** > > use delay as a routing metric. If application traffic which follows**** > > path based upon latency constraints, the same traffic might be in an**** > > Expedited Forwarding Per-Hop-Behavior [RFC3246] with**** > > minimal queuing delay or another PHB with potentially very substantial***= * > > per-hop queuing delay. Only traffic which experiences relatively low**** > > congestion, such as Expedited Forwarding traffic, will experience**** > > delays very close to the sum of the reported link delays.=94**** > > ** ** > > 1.1. Basic Requirements:**** > > ** ** > > Drop "packet loss, jitter" from the first numeric item. Otherwise***= * > > OK except use of the word SLA. See nits below.**** > > ** ** > > [Alia] Changed SLAs to NPO**** > > ** ** > > After the list please state that "For existing MPLS constraints,**** > > corresponding RSVP-TE signaling allows midpoint LSR to use Path**** > > Tear and/or notification and would use this mechanism to**** > > accomplish items 3-6. In the absense of RSVP-TE signaling**** > > corresponding to these new constraints, new mechanisms at the LSP**** > > ingress are needed." Alternately, consider citing the work by**** > > George Swallow et al and explain how that solves it in the same**** > > way that a change in admin attr of a link would (or should, poor**** > > implementations not withstanding).**** > > ** ** > > [Alia] Frankly, I=92m confused by this. I don=92t agree that RSVP-TE > signaling extensions would solve, for instance, (3):**** > > ** ** > > =933. Ability to periodically verify that a TE tunnel's current LSP**** > > complies with its configured end-to-end performance requirements.=94**** > > ** ** > > Even if the ingress signaled the end-to-end performance requirements, I > don=92t see how that stops the ingress from verifying compliance?**** > > ** ** > > Similarly, only the ingress could do:**** > > =93 4. Ability to move tunnels, using make-before-break, based upon***= * > > computed end-to-end performance complying with configuration**** > > ** ** > > 5. Ability to move tunnels away from any link that is violating an***= * > > underlying SLA**** > > ** ** > > 6. Ability to optionally avoid setting up tunnels using any link**** > > that is violating an SLA, regardless of whether end-to-end**** > > performance would still meet requirements.=94**** > > ** ** > > I have looked for the additional work that you are talking about by Georg= e > Swallow unsuccessfully. Can you find a pointer to explain what you=92re > talking about? The anomalous bits provide a trigger mechanism that a > router can use to tell the ingress to do (5); different admin attributes > could do a similar behavior =96 and similarly for (6) =96 but again that = is the > flooding for notification aspect. I think the lack of RSVP-TE extensions > doesn=92t cause an issue =96 these are handled by IGP instead and thus do= n=92t > have to be signaled per LSP.**** > > ** ** > > I am not irrevocably opposed to RSVP-TE extensions =96 if we really need > them for practical use-cases. This draft was trying to do the minimum th= at > is sufficient and then, if and when there is a need for more, what extra = is > needed could be better defined.**** > > ** ** > > 2.1. End-to-End Constraints:**** > > ** ** > > Note: I've requested that jitter and loss be dropped from**** > > draft-ietf-ospf-te-metric-extensions and**** > > draft-previdi-isis-te-metric-extensions for the same potential**** > > oscillations and stability reasons cited above.**** > > ** ** > > [Alia] Yes =96 I think we clearly need to have a good email discussion wi= th > those interested about what oscillations might actually occur and what > could be done to prevent that.**** > > ** ** > > s/While it has been possible to compute a CSPF/It is possible to**** > > compute a CSPF/**** > > s/Instead of this approach to minimize path latency, an/An**** > > alternative to this approach to minimize path latency is an**** > > approach to place a upper bound on path latency. An/**** > > Note: both approaches are valid.**** > > ** ** > > Delete next paragraph starting with "This is illustrated as**** > > follows." This seems to be taken from email and is good email**** > > discussion but not needed in the draft.**** > > ** ** > > [Alia] I=92ve put in some pseudo-code so I=92m ok with taking the example= out > =96 but there does seem to have been confusion even with it in.**** > > ** ** > > Delete next paragraph starting with "An end-to-end bound on delay**** > > variation". Lets get rid of jitter altogether. (Let the old SNA**** > > networks be damned. :)**** > > ** ** > > Delete next paragraph starting with "For link loss". Get rid of**** > > link loss altogether.**** > > ** ** > > [Alia] Not done =96 discussion is needed. I understand that you really > really really don=92t want to see loss or delay variation in any of these > drafts.**** > > ** ** > > 2.2. Link Constraints:**** > > ** ** > > Drop delay variation and link loss.**** > > ** ** > > If we are dealing with EF traffic then using Unidirectional**** > > Available Bandwidth and Residual Bandwidth makes no sense. If we**** > > are dealing with low priority traffic and we are using**** > > Unidirectional Available Bandwidth and Residual Bandwidth in path**** > > selection will be prone to oscillations and network instability.**** > > Therefore delete the entire second paragraph (the one starting**** > > with "When doing path selection for TE tunnels,".**** > > ** ** > > [Alia] If we are trying to avoid congesting the link, then Residual > Bandwidth is important and useful regardless of the LSP traffic class. > What is your specific concern with oscillation for bandwidth? Why is it > different than for the bandwidths already advertised and used for TE path > computation? Come on =96 the Residual Bandwidth is just the Link Capaci= ty > minus that reserved by RSVP-TE =96 so pretty darn similar characteristics= to > the Unreserved Bandwidth per priority=85 The Unidirectional Available > bandwidth does include an actual traffic measurement =96 that is averaged > over a reasonable interval, that can only change with limited frequency = =96 > and then the LSPs need to be reoptimized to use them. Please explain > precisely the oscillation concern with a clear example.**** > > ** ** > > ** ** > > Also delete the entire third paragraph (starting with "Similarly,**** > > only links whose loss is"). As stated earlier, use of loss is**** > > either a NOOP (low volume of EF traffic) or can lead to**** > > oscillations. Get rid of loss entirely.**** > > ** ** > > 2.3. Links out of SLA:**** > > ** ** > > s/SLA/NPO/g (see nits below).**** > > ** ** > > General: A better mechanism than an "Anomalous State" flag is**** > > needed to provide notifications of change. One mechanism would be***= * > > to put the commulative constraint and the cummulative total in the***= * > > ERO and RRO. A link adding delay can then notify the ingress of**** > > any LSP for which the commulative constraint is violated. See**** > > work by Swallow et al and perhaps align with that work.**** > > ** ** > > [Alia] That could be done as well =96 but the signaling extensions seem l= ike > overkill for the basic problem of letting the ingress compute a complete > ERO. Carrying both the cumulative constraint and the cumulative total ju= st > means that the midpoint detects a changed link and then has to verify the > performance on each LSP and individually signal it. Having an anomalous > flag provides a succinct notification to the ingress which can then do th= e > verification and be known to have the updated information. This solution > also requires that the midpoints all support it before it can be used. A= n > advantage of the ingress computation is that only the ingress needs to ha= ve > updated code.**** > > ** ** > > The "Anomalous State" flag is helpful for c in the list, but not**** > > for b. The case where a link is out of NPO by 1 msec then changes***= * > > to out of NPO by 10s of msec is an example. The flag is already**** > > set and therefore the trigger is unavailable.**** > > ** ** > > [Alia] Right =96 but LSPs that are particular sensitive (i.e. a or c) can > have been moved already. Having the Anomalous flag set is expected to b= e > unusual. I agree that it is more a hint for (b) than a full solution.***= * > > ** ** > > 2.3.1. Use of Anomalous Links for New Paths**** > > ** ** > > Delete second paragraph regarding jitter and loss.**** > > ** ** > > 2.3.2. Links entering the Anomalous State**** > > ** ** > > This section ignores two cases in which the Anomalous State does**** > > not change but a change makes the path violate a delay**** > > constraint. The first is where all of the links are within NPO**** > > but a change to a link has make the path delay sum exceed the path***= * > > delay constraint. The second is where a link which is already in**** > > the Anomalous State by a small margin but the path delay is still**** > > within the constraint. A large change in delay at that point will***= * > > not affect the Anomalous State since it is already set.**** > > ** ** > > [Alia] The Anomalous bit is NOT meant to replace reading the actual valu= e > associated with the link and checking each potentially affected LSP. In > the case of (b), it is a hint to focus on those LSPs first.**** > > ** ** > > A better means of handling case (b) in "2.3. Links out of SLA" is***= * > > needed.**** > > ** ** > > [Alia] I=92ve added the following paragraph at the end of 2.3.2:**** > > =93It is not sufficient to just look at the Anomalous bit in order to**** > > determine when TE tunnels must have their compliance verified. When**** > > changing to set, the Anomalous bit merely provides a hint that**** > > interested TE tunnels for case (b) should have their continued**** > > compliance verified.=94**** > > ** ** > > 2.3.3. Links leaving the Anomalous State**** > > ** ** > > Same issue as in "2.3.2. Links entering the Anomalous State". A**** > > better means of handling case (b) in "2.3. Links out of SLA" is**** > > needed.**** > > ** ** > > ** ** > > [Alia] I=92ve added the following sentence:**** > > =93The hint provided by the Anomalous state change may help optimize when= to > recompute for a better path.=94**** > > ** ** > > XML version nits:**** > > ** ** > > CV: you really should remove the template comments.**** > > ** ** > > [Alia] I find them helpful for when I want to do additional things=85 an= d > very very few people read the XML.**** > > ** ** > > You should also enable strict mode. For example, you have one**** > > author too many and strict would catch that.**** > > ** ** > > [Alia] So does basic arithmetic J It will be resolved before the draft > is passed to the RFC editor.**** > > ** ** > > Other nits:**** > > ** ** > > The "A" in SLA is "Agreement" as in contract. The acronym NPO for**** > > network performance objective seems to be in vogue for that reason.**** > > IETF since diffserv has wanted to steer clear of making**** > > recommendations regarding provider contracts (agreements) with**** > > customers, peer, or anyone else.**** > > ** ** > > [Alia] True - changed**** > > ** ** > > I agree with Sri on the suggestions to change the title, short name**** > > and document filename but I'm not fond of his suggested new names.**** > > Authors please suggest new title, short name, and filename.**** > > ** ** > > [Alia] I did do a new short name and title. As for filename, we=92ll de= al > with that if/when the draft is adopted as a WG draft.**** > > ** ** > > Thanks again,**** > > Alia**** > > ** ** > > ** ** > > ------- Forwarded Message**** > > ** ** > > On 4/5/13 9:50 PM, "Loa Andersson" wrote:**** > > >** ** > > >Xiaohu, Sri, Rajiv and Pranjal,**** > > >** ** > > >You have been selected as an MPLS Review team reviewers for **** > > >draft-atlas-mpls-te-express-path-02.**** > > >** ** > > >Note to authors: You have been CC'd on this email so that you can know *= * > ** > > >that this review is going on. However, please do not review your own ***= * > > >document.**** > > >** ** > > >Reviews should comment on whether the document is coherent, is it **** > > >useful (ie, is it likely to be actually useful in operational **** > > >networks), and is the document technically sound? We are interested in = * > *** > > >knowing whether the document is ready to be considered for WG adoption *= * > ** > > >(ie, it doesn't have to be perfect at this point, but should be a good *= * > ** > > >start).**** > > >** ** > > >Reviews should be sent to the document authors, WG co-chairs and WG **** > > >secretary, and CC'd to the MPLS WG email list. If necessary, comments **= * > * > > >may be sent privately to only the WG chairs.**** > > >** ** > > >Are you able to review this draft by April 20, 2013?**** > > >** ** > > >Thanks, Loa**** > > >(as MPLS WG chair)**** > > >** ** > > >/Loa**** > > >--**** > > >** ** > > >** ** > > >Loa Andersson email: loa@mail01.huawei.com**** > > >Senior MPLS Expert loa@pi.nu**** > > >Huawei Technologies (consultant) phone: +46 739 81 21 64**** > > ** ** > > _______________________________________________**** > > mpls mailing list**** > > mpls@ietf.org**** > > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > > ------- End of Forwarded Message**** > > ** ** > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --089e0122ac5048364304e12ac4f3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'm not uncomfortable with the A bit. =A0I just think = it's redundant, as discussed in Orlando. =A0


On Wed, Jul 10, 2013 at 1:42 PM, = <spencer.giacalone@thomsonreuters.com> wr= ote:

I=92d like to get more= feedback on removing jitter and loss from OSPF TE ME before doing so. So f= ar, Curtis, it=92s only you asking for it (to be removed). Also, no one els= e seems uncomfortable with the A bit.. I am not personally in favor of removing them, and I feel the A bit is fine = for my use case.

=A0

=A0

=A0

From: Alia Atl= as [mailto:akatlas= @juniper.net]
Sent: Tuesday, July 09, 2013 4:00 PM
To: curti= s@ipv6.occnc.com; MPLS WG Mailing List; draft-atlas-mpls-te-express-pat= h authors; The Great and Mighty MPLS Co-Chairs
Subject: RE: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review= of ...)

=A0

Hi Curtis,

=A0

Thanks for your detailed comments and sugg= estions.=A0 My responses are in-line, as always.

=A0

Alia

=A0

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]
Sent: Tuesday, April 23, 2013 12:59 PM
To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Gre= at and Mighty MPLS Co-Chairs
Cc: curtis@ipv6.= occnc.com
Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...)=

=A0

=A0

Loa, authors, et al,

=A0

So far I have seen two of the four MPLS-RT reviews (maybe I missed the o= thers).=A0 I've commented before on the mailing list about this draft b= ut at this point I would like to provide a detailed review.

=A0

I think there are very major issues with this document as it now stands.= =A0 IMO these issues should be addressed before the draft is even accepted = as a WG document.

=A0

You can choose to consider this during MPLS-RT review or after.

=A0

Curtis

=A0

=A0

=A0

=A0

Major issues:

=A0

=A0 Jitter and loss are very close to meaningless if queueing delays and=

=A0 loss are not considered.=A0 Links that are losing packets at the lin= k

=A0 layer are generally taken down. =A0Oscillations can occur if queuein= g

=A0 delay and loss is considered, such as measurements at a low priority=

=A0 and therefore possible to congest or measurements which are

=A0 otherwise affected by traffic load.=A0 Unless there is adequate

=A0 discussion of stability and mechanisms to insure stability, then<= /u>

=A0 jitter and loss should be removed.

=A0

[Alia] I have changed the second paragraph= of the introduction to be:

=A0

" Queuing latency is specifically exc= luded to insure freedom from

=A0=A0 oscillations and stability issues t= hat have plagued prior attempts to

=A0=A0 use delay as a routing metric.=A0 I= f application traffic which follows

=A0=A0 path based upon latency constraints= , the same traffic might be in an

=A0=A0 Expedited Forwarding Per-Hop-Behavi= or [RFC3246] with minimal queuing

=A0=A0 delay or another PHB with potential= ly very substantial per-hop

=A0=A0 queuing delay.=A0 Only traffic whic= h experiences relatively low

=A0=A0 congestion, such as Expedited Forwa= rding traffic, will experience

=A0=A0 delays very close to the sum of the= reported link delays"

=A0

Removing queuing delay is the agreed resul= t for draft-ietf-ospf-te-metric-extensions.

As far as jitter and loss goes, these can = still be somewhat meaningful.=A0 For instance, jitter does allow capturing = the differences in serialization delays - which is relevant in some parts o= f the network.=A0 The acceptable loss to take a link down may vary.=A0=A0 I don't actual= ly see the reasoning or need to remove jitter and loss from the draft - giv= en that we have constrained the measurements in the draft-ietf-ospf-te-metr= ic-extensions to not include queuing delay.

=A0

General:

=A0

=A0 It needs to be much more clearly stated that the NPO (s/SLA/NPO/g,

=A0 see nits below) is specific to a link, and not an NPO per LSP.=A0 A<= u>

=A0 "non-conformance to NPO" flag in the IGP link advertisemen= t is

=A0 intractable if there are multiple NPO being applied to the link.<= /u>

=A0

[Alia] As you may recall from draft-ietf-o= spf-te-metric-extensions, the Anomalous bit is specified per characteristic= advertised per link.=A0=A0 This draft (draft-atlas-mpls-te-express-path-02= ) describes the Anomalous bit as clearly inside a links=92 sub-TLV as in Sec 2.3.1:

=A0

=93If the answer to (a) is no for latency = SLAs, then any link which has

the Anomalous bit set in the Unidirectiona= l Link Delay sub-

TLV[I-D.ietf-ospf-te-metric-extensions]=

[I-D.previdi-isis-te-metric-extensions] sh= ould be removed from the

topology before a CSPF calculation is used= to compute a new path.=94

=A0

=A0 The use of a "non-conformance to NPO" flag as the only mea= ns to

=A0 alert the set of LSP ingress of a significant change is also at best=

=A0 a poor solution.=A0 For example, a change from 2 msec to 15 msec may=

=A0 be a problem for some LSP.=A0 That same change may not be a problem<= u>

=A0 for others, such as LSPs where only this one hop is needed.=A0 So=

=A0 advertising out of NPO in the IGP doesn't help the second case.= =A0 LSP

=A0 ingress must evaluate the path delay constraint, each time a change<= u>

=A0 in IGP link advertised delay is received.

=A0

[Alia] Sure =96 different LSPs may have di= fferent requirements as to the Anomalous flag.=A0 Using it doesn=92t replac= e paying attention to the value that is advertised.=A0 The anomalous flag i= s reporting that the link is not complying to the expected performance =96 this can indicate th= at there is something strange going on and some LSPs should avoid using tha= t link due to administrative policy.=A0

=A0

=A0 The use of a "non-conformance to NPO" flag solely as a con= straint

=A0 makes sense, where some LSP are configured to exclude links with<= /u>

=A0 this flag set.

=A0

[Alia] Right =96 case (a) and (c) for Sec = 2.3

=A0

=A0 For path delay computation it would also be useful if the NPO=

=A0 threshhold were advertised.=A0 In some cases, it may make sense to

=A0 minimize or place bounds on the sum of NPO delays.

=A0

[Alia] I think that should be a comment on= draft-ietf-ospf-te-metric-extensions.=A0 This draft doesn=92t define what = is flooded.=A0=A0 A question though is whether in the same network it would= make sense to consider both the NPO delays and the actual measured delays?=A0 If only one or the = other =96 then that could be a local router=92s decision as to which is flo= oded.

=A0

Specific:

=A0

=A0 Abstract:

=A0

=A0=A0=A0 Remove mention of jitter and loss.

=A0

=A0

[Alia] I am interested in the opinion of t= he WG on this.=A0 In my view, this draft is describing how the information = flooded via the new sub-TLVs in draft-ietf-ospf-te-metric-extensions-04 sho= uld be used.=A0 Loss and jitter are included in that draft; of course, that draft could change = as well =96 but I=92d like to hear stronger arguments for why it is harmful= to include them than that they=92re only relevant when queuing behavior is= included and that can lead to oscillations.=A0 I am, perhaps stubbornly, not convinced that they are irrelevant.

=A0

=A0 1.=A0 Introduction:

=A0

=A0=A0=A0 This sentence is awkward but I think I know what you are tryin= g to

=A0=A0=A0 say.

=A0

=A0=A0=A0=A0=A0 The method suggested is not optimal for both minimizing = path

=A0=A0=A0=A0=A0 cost and additional constraints, such as latency; optima= l

=A0=A0=A0=A0=A0 solutions are computationally complex.

=A0

=A0=A0=A0 Please consider this replacement.

=A0

=A0=A0=A0=A0=A0 Methods of optimizing path selection for multiple parame= ters are

=A0=A0=A0=A0=A0 generally computationally complex.=A0 The method propose= d here are

=A0=A0=A0=A0=A0 to make use of either a single metric in path selection,= such as

=A0=A0=A0=A0=A0 minimal path delay, or to make use of another single met= ric,

=A0=A0=A0=A0=A0 such as the existing TE metric with additional constrain= ts, such

=A0=A0=A0=A0=A0 as target link delay bounds and target path delay bounds= .

=A0

[Alia] Thanks for the better text =96 put = in=85

=A0

=A0=A0=A0 Please note:

=A0

=A0=A0=A0=A0=A0 The path selection mechanisms described in this document= apply

=A0=A0=A0=A0=A0 to paths that are fully computed by the head-end of the = LSP and

=A0=A0=A0=A0=A0 then signaled in an ERO where every sub-object is strict= .=A0 This

=A0=A0=A0=A0=A0 allows the head-end to consider IGP-distributed performa= nce data

=A0=A0=A0=A0=A0 without requiring the ability to signal the performance<= u>

=A0=A0=A0=A0=A0 constraints in an object of the RSVP Path message.

=A0

=A0=A0=A0 There is work in MPLS or CCAMP by George Swallow and others on=

=A0=A0=A0 cummulative metrics in RSVP-TE with delay as a major motivatio= n.

=A0=A0=A0 Perhaps that work should be considered.

=A0

[Alia]=A0 I believe you are referring to http://tools.ietf.org/html/draft-ietf-ccamp-te= -metric-recording-01?=A0 That draft appea= rs to me to be about how to get measurements for latency, jitter, and cost for a given Forwarding Adjacency or Routing Adjacency so = that those values can be advertised into the IGP.=A0 I think this draft is = providing a means to collect the data to flood in draft-ietf-ospf-te-metric= s-04.=A0

=A0

I did add the last sentence in the followi= ng:

=A0

=93This document does not specify how a ro= uter determines what values

to advertise by the IGP; it does assume th= at the constraints specified

in [I-D.ietf-ospf-te-metric-extensions] an= d [I-D.previdi-isis-te-metric-extensions] are followed.=A0 Mechanisms for d= etermining latency and delay variation for Forwarding<= /p>

Adjacencies and Routing Adjacencies are de= fined in [I-D.ietf-ccamp-te-metric-recording].=94

=A0

=A0

=A0=A0=A0 This paragraph could use rewording:

=A0

=A0=A0=A0=A0=A0 When considering performance-based data, it is obvious t= hat

=A0=A0=A0=A0=A0 there are additional contributors beyond just the links.=

=A0=A0=A0=A0=A0 Clearly end-to-end latency is a combination of router la= tency,

=A0=A0=A0=A0=A0 queuing latency, physical link latency and other factors= .

=A0=A0=A0=A0=A0 However, if application traffic requires paths to be sel= ected

=A0=A0=A0=A0=A0 based upon latency constraints, the same traffic might b= e in an

=A0=A0=A0=A0=A0 Expedited Forwarding Per-Hop- Behavior[RFC3246] with min= imal

=A0=A0=A0=A0=A0 queuing delay or another PHB with known maximal per-hop = queuing

=A0=A0=A0=A0=A0 delay.=A0 While traversing a router can cause delay, tha= t can be

=A0=A0=A0=A0=A0 included in the advertised link delay.

=A0

=A0=A0=A0 What you are getting at is that where traffic levels can't=

=A0=A0=A0 possibly have a significant impact the measurements, such as l= ow

=A0=A0=A0 levels of EF traffic in a WAN with high geographic delays, and=

=A0=A0=A0 delay meansured with EF priority, stability is not impacted if=

=A0=A0=A0 delay measurements are considered.=A0 In this case, loss MUST = be

=A0=A0=A0 zero or the EF service is broken (replace routers and try agai= n).

=A0=A0=A0 OTOH jitter will increase as traffic levels increase, even in = such

=A0=A0=A0 a case where the traffic is only a few percent, potentially=

=A0=A0=A0 causing oscillations and impacting stability.=A0 For this reas= on,

=A0=A0=A0 jitter and loss should not be considered.

=A0

=A0=A0=A0 I will leave the rewording up to you.=A0 I suggest that you cr= eate a

=A0=A0=A0 subsection of "Introduction" which discusses potenti= al

=A0=A0=A0 oscillations and stability in greater detail.=A0 If you like, = I will

=A0=A0=A0 provide some text.

=A0

[Alia] I do hear your concern that jitter = could cause oscillations and impact stability.=A0 I am not fully persuaded = that this is a practical issue =96 given the delays in ingress re-optimizat= ion, not trying to minimize the jitter, and the ability for an LSP to reserve bandwidth.=A0 I= would be interested in what text you might provide and a focused discussio= n on whether this is something that needs to have restrictions clearly desc= ribed to avoid oscillations.

=A0

For now, I have changed this paragraph to:=

=A0

=93When considering performance-based data= , it is obvious that there

are additional contributors beyond just th= e links. Clearly end-to-end

latency is a combination of router latency= , queuing latency, physical

link latency and other factors.=A0 While t= raversing a router can cause

delay, that can be included in the adverti= sed link delay.=A0 As

described in [I-D.ietf-ospf-te-metric-exte= nsions] and

[I-D.previdi-isis-te-metric-extensions], q= ueuing delay

should not be included in the measurements= advertised by OSPF or ISIS.

=A0

Queuing latency is specifically excluded t= o insure freedom from

oscillations and stability issues that hav= e plagued prior attempts to

use delay as a routing metric.=A0 If appli= cation traffic which follows

path based upon latency constraints, the s= ame traffic might be in an

Expedited Forwarding Per-Hop-Behavior [RFC= 3246] with

minimal queuing delay or another PHB with = potentially very substantial

per-hop queuing delay.=A0 Only traffic whi= ch experiences relatively low

congestion, such as Expedited Forwarding t= raffic, will experience

delays very close to the sum of the report= ed link delays.=94

=A0

=A0 1.1.=A0 Basic Requirements:

=A0

=A0=A0=A0 Drop "packet loss, jitter" from the first numeric it= em.=A0 Otherwise

=A0 =A0=A0OK except use of the word SLA.=A0 See nits below.

=A0

[Alia] Changed SLAs to NPO

=A0

=A0=A0=A0 After the list please state that "For existing MPLS const= raints,

=A0=A0=A0 corresponding RSVP-TE signaling allows midpoint LSR to use Pat= h

=A0=A0=A0 Tear and/or notification and would use this mechanism to

=A0=A0=A0 accomplish items 3-6.=A0 In the absense of RSVP-TE signaling

=A0=A0=A0 corresponding to these new constraints, new mechanisms at the = LSP

=A0=A0=A0 ingress are needed."=A0 Alternately, consider citing the = work by

=A0=A0=A0 George Swallow et al and explain how that solves it in the sam= e

=A0=A0=A0 way that a change in admin attr of a link would (or should, po= or

=A0=A0=A0 implementations not withstanding).

=A0

[Alia] Frankly, I=92m confused by this.=A0= I don=92t agree that RSVP-TE signaling extensions would solve, for instanc= e, (3):

=A0

=933. Ability to periodically verify that = a TE tunnel's current LSP

complies with its configured end-to-end pe= rformance requirements.=94

=A0

Even if the ingress signaled the end-to-en= d performance requirements, I don=92t see how that stops the ingress from v= erifying compliance?

=A0

Similarly, only the ingress could do:

=93=A0=A0 4.=A0 Ability to move tunnels, u= sing make-before-break, based upon

=A0=A0=A0=A0=A0=A0 computed end-to-end per= formance complying with configuration

=A0

=A0=A0 5.=A0 Ability to move tunnels away = from any link that is violating an

=A0=A0=A0=A0=A0=A0 underlying SLA

=A0

=A0=A0 6.=A0 Ability to optionally avoid s= etting up tunnels using any link

=A0=A0=A0=A0=A0=A0 that is violating an SL= A, regardless of whether end-to-end

=A0=A0=A0=A0=A0=A0 performance would still= meet requirements.=94

=A0

I have looked for the additional work that= you are talking about by George Swallow unsuccessfully.=A0 Can you find a = pointer to explain what you=92re talking about?=A0 The anomalous bits provi= de a trigger mechanism that a router can use to tell the ingress to do (5); different admin attri= butes could do a similar behavior =96 and similarly for (6) =96 but again t= hat is the flooding for notification aspect.=A0 I think the lack of RSVP-TE= extensions doesn=92t cause an issue =96 these are handled by IGP instead and thus don=92t have to be signaled per LSP.

=A0

I am not irrevocably opposed to RSVP-TE ex= tensions =96 if we really need them for practical use-cases.=A0 This draft = was trying to do the minimum that is sufficient and then, if and when there= is a need for more, what extra is needed could be better defined.

=A0

=A0 2.1.=A0 End-to-End Constraints:

=A0

=A0=A0=A0 Note: I've requested that jitter and loss be dropped from<= u>

=A0=A0=A0 draft-ietf-ospf-te-metric-extensions and

=A0 =A0=A0draft-previdi-isis-te-metric-extensions for the same potential=

=A0=A0=A0 oscillations and stability reasons cited above.<= /p>

=A0

[Alia] Yes =96 I think we clearly need to = have a good email discussion with those interested about what oscillations = might actually occur and what could be done to prevent that.<= /span>

=A0

=A0=A0=A0 s/While it has been possible to compute a CSPF/It is possible = to

=A0=A0=A0 compute a CSPF/

=A0=A0=A0 s/Instead of this approach to minimize path latency, an/An<= /u>

=A0=A0=A0 alternative to this approach to minimize path latency is an=

=A0=A0=A0 approach to place a upper bound on path latency.=A0 An/=

=A0=A0=A0 Note: both approaches are valid.

=A0

=A0=A0=A0 Delete next paragraph starting with "This is illustrated = as

=A0=A0=A0 follows."=A0 This seems to be taken from email and is goo= d email

=A0=A0=A0 discussion but not needed in the draft.

=A0

[Alia] I=92ve put in some pseudo-code so I= =92m ok with taking the example out =96 but there does seem to have been co= nfusion even with it in.

=A0

=A0=A0=A0 Delete next paragraph starting with "An end-to-end bound = on delay

=A0=A0=A0 variation".=A0 Lets get rid of jitter altogether.=A0 (Let= the old SNA

=A0=A0=A0 networks be damned. :)

=A0

=A0=A0=A0 Delete next paragraph starting with "For link loss".= =A0 Get rid of

=A0=A0=A0 link loss altogether.

=A0

[Alia] Not done =96 discussion is needed.= =A0 I understand that you really really really don=92t want to see loss or = delay variation in any of these drafts.

=A0

=A0 2.2.=A0 Link Constraints:

=A0

=A0=A0=A0 Drop delay variation and link loss.

=A0

=A0=A0=A0 If we are dealing with EF traffic then using Unidirectional=

=A0=A0=A0 Available Bandwidth and Residual Bandwidth makes no sense.=A0 = If we

=A0=A0=A0 are dealing with low priority traffic and we are using<= u>

=A0=A0=A0 Unidirectional Available Bandwidth and Residual Bandwidth in p= ath

=A0=A0=A0 selection will be prone to oscillations and network instabilit= y.

=A0=A0=A0 Therefore delete the entire second paragraph (the one starting=

=A0=A0=A0 with "When doing path selection for TE tunnels,".=

=A0

[Alia]=A0 If we are trying to avoid conges= ting the link, then Residual Bandwidth is important and useful regardless o= f the LSP traffic class.=A0 What is your specific concern with oscillation = for bandwidth?=A0 Why is it different than for the bandwidths already advertised and used for TE= path computation?=A0=A0 Come on =96 the Residual Bandwidth is just the Lin= k Capacity minus that reserved by RSVP-TE =96 so pretty darn similar charac= teristics to the Unreserved Bandwidth per priority=85=A0=A0 The Unidirectional Available bandwidth does include an a= ctual traffic measurement =96 that is averaged over a reasonable interval, = that can only change with limited frequency =96 and then the LSPs need to b= e reoptimized to use them.=A0 Please explain precisely the oscillation concern with a clear example.

=A0

=A0

=A0=A0=A0 Also delete the entire third paragraph (starting with "Si= milarly,

=A0=A0=A0 only links whose loss is").=A0 As stated earlier, use of = loss is

=A0=A0=A0 either a NOOP (low volume of EF traffic) or can lead to=

=A0=A0=A0 oscillations.=A0 Get rid of loss entirely.

=A0

=A0 2.3.=A0 Links out of SLA:

=A0

=A0=A0=A0 s/SLA/NPO/g (see nits below).

=A0

=A0=A0=A0 General: A better mechanism than an "Anomalous State"= ; flag is

=A0=A0=A0 needed to provide notifications of change.=A0 One mechanism wo= uld be

=A0=A0=A0 to put the commulative constraint and the cummulative total in= the

=A0=A0=A0 ERO and RRO.=A0 A link adding delay can then notify the ingres= s of

=A0=A0=A0 any LSP for which the commulative constraint is violated.=A0 S= ee

=A0=A0=A0 work by Swallow et al and perhaps align with that work.=

=A0

[Alia] That could be done as well =96 but = the signaling extensions seem like overkill for the basic problem of lettin= g the ingress compute a complete ERO.=A0 Carrying both the cumulative const= raint and the cumulative total just means that the midpoint detects a changed link and then has to = verify the performance on each LSP and individually signal it.=A0 Having an= anomalous flag provides a succinct notification to the ingress which can t= hen do the verification and be known to have the updated information.=A0 This solution also requires that the m= idpoints all support it before it can be used.=A0 An advantage of the ingre= ss computation is that only the ingress needs to have updated code.<= span style>

=A0

=A0=A0=A0 The "Anomalous State" flag is helpful for c in the l= ist, but not

=A0=A0=A0 for b.=A0 The case where a link is out of NPO by 1 msec then c= hanges

=A0=A0=A0 to out of NPO by 10s of msec is an example.=A0 The flag is alr= eady

=A0=A0=A0 set and therefore the trigger is unavailable.

=A0

[Alia] Right =96 but LSPs that are particu= lar sensitive (i.e. a or c) can have been moved already.=A0=A0 Having the A= nomalous flag set is expected to be unusual.=A0 I agree that it is more a h= int for (b) than a full solution.

=A0

=A0 2.3.1.=A0 Use of Anomalous Links for New Paths

=A0

=A0=A0=A0 Delete second paragraph regarding jitter and loss.

=A0

=A0 2.3.2.=A0 Links entering the Anomalous State

=A0

=A0=A0=A0 This section ignores two cases in which the Anomalous State do= es

=A0=A0=A0 not change but a change makes the path violate a delay<= u>

=A0=A0=A0 constraint.=A0 The first is where all of the links are within = NPO

=A0=A0=A0 but a change to a link has make the path delay sum exceed the = path

=A0=A0=A0 delay constraint.=A0 The second is where a link which is alrea= dy in

=A0=A0=A0 the Anomalous State by a small margin but the path delay is st= ill

=A0=A0=A0 within the constraint.=A0 A large change in delay at that poin= t will

=A0=A0=A0 not affect the Anomalous State since it is already set.=

=A0

[Alia]=A0 The Anomalous bit is NOT meant t= o replace reading the actual value associated with the link and checking ea= ch potentially affected LSP.=A0 In the case of (b), it is a hint to focus o= n those LSPs first.

=A0

=A0=A0=A0 A better means of handling case (b) in "2.3.=A0 Links out= of SLA" is

=A0=A0=A0 needed.

=A0

[Alia]=A0 I=92ve added the following parag= raph at the end of 2.3.2:

=93It is not sufficient to just look at th= e Anomalous bit in order to

determine when TE tunnels must have their = compliance verified.=A0 When

changing to set, the Anomalous bit merely = provides a hint that

interested TE tunnels for case (b) should = have their continued

compliance verified.=94=

=A0

=A0 2.3.3.=A0 Links leaving the Anomalous State

=A0

=A0=A0=A0 Same issue as in "2.3.2.=A0 Links entering the Anomalous = State".=A0 A

=A0=A0=A0 better means of handling case (b) in "2.3.=A0 Links out o= f SLA" is

=A0=A0=A0 needed.

=A0

=A0

[Alia]=A0 I=92ve added the following sente= nce:

=93The hint provided by the Anomalous stat= e change may help optimize when to recompute for a better path.=94

=A0

XML version nits:

=A0

=A0 CV: you really should remove the template comments.

=A0

[Alia]=A0 I find them helpful for when I w= ant to do additional things=85 and very very few people read the XML.

=A0

=A0 You should also enable strict mode.=A0 For example, you have one<= /u>

=A0 author too many and strict would catch that.

=A0

[Alia]=A0 So does basic arithmetic J=A0=A0 It will be resolved before the draft is passed= to the RFC editor.

=A0

Other nits:

=A0

=A0 The "A" in SLA is "Agreement" as in contract.=A0= The acronym NPO for

=A0 network performance objective seems to be in vogue for that reason.<= u>

=A0 IETF since diffserv has wanted to steer clear of making

=A0 recommendations regarding provider contracts (agreements) with

=A0 customers, peer, or anyone else.

=A0

[Alia]=A0 True - changed

=A0

=A0 I agree with Sri on the suggestions to change the title, short name<= u>

=A0 and document filename but I'm not fond of his suggested new name= s.

=A0 Authors please suggest new title, short name, and filename.

=A0

[Alia]=A0 I did do a new short name and ti= tle.=A0 As for filename, we=92ll deal with that if/when the draft is adopte= d as a WG draft.

=A0

Thanks again,

Alia

=A0

=A0

------- Forwarded Message

=A0

On 4/5/13 9:50 PM, "Loa Andersson" <loa@pi.nu> wrote:

>=A0

>Xiaohu, Sri, Rajiv and Pranjal,

>=A0

>You have been selected as an MPLS Review team reviewers for

>draft-atlas-mpls-te-express-path-02.

>=A0

>Note to authors: You have been CC'd on this email so that you ca= n know

>that this review is going on. However, please do not review your own

>document.

>=A0

>Reviews should comment on whether the document is coherent, is it

>useful (ie, is it likely to be actually useful in operational

>networks), and is the document technically sound?=A0 We are interest= ed in

>knowing whether the document is ready to be considered for WG adopti= on

>(ie, it doesn't have to be perfect at this point, but should be = a good

>start).

>=A0

>Reviews should be sent to the document authors, WG co-chairs and WG

>secretary, and CC'd to the MPLS WG email list. If necessary, com= ments

>may be sent privately to only the WG chairs.

>=A0

>Are you able to review this draft by April 20, 2013?

>=A0

>Thanks, Loa

>(as MPLS WG chair)

>=A0

>/Loa

>--

>=A0

>=A0

>Loa Andersson=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 email: loa@mail01.huawei.com=

>Senior MPLS Expert=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 loa@pi.nu<= u>

>Huawei Technologies (consultant)=A0=A0=A0=A0 phone: +46 739= 81 21 64

=A0

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org= /mailman/listinfo/mpls

=A0

------- End of Forwarded Message

=A0


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


--089e0122ac5048364304e12ac4f3-- From curtis@ipv6.occnc.com Wed Jul 10 09:55:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D17B21F935A for ; Wed, 10 Jul 2013 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn8NIHLafdOq for ; Wed, 10 Jul 2013 09:55:54 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4A721F8F61 for ; Wed, 10 Jul 2013 09:55:39 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6AGqbGJ079840; Wed, 10 Jul 2013 12:52:42 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201307101652.r6AGqbGJ079840@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar In-reply-to: Your message of "Tue, 09 Jul 2013 18:12:49 -0000." Date: Wed, 10 Jul 2013 12:52:37 -0400 Cc: The Great and Mighty MPLS Co-Chairs , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:55:59 -0000 Hi Alia, I think the confusion here is that there are approaches to minimize multiple metrics which are too computationally complex to be practical but that is not what is being proposed. There are two things being proposed. One is minimizing the delay by using the delay as a single metric. The other is bounding the delay. This is done using the existing CSPF but truncating the CSPF search when the cumulative delay exceeds the target. Perhaps it is not sufficiently clear that the former approach *is not* requiring or even recommending the use of algorithms that some vendors have toyed with in the past to optimize for multiple metrics. Those algorithms are not prohibited except any practical prohibition which will arise from an inability (so far) in meeting convergence time and restoration time requirements of providers. Curtis In message Alia Atlas writes: > Can you clarify why you think constraining the links explored based > upon a latency isn't a practical approach? It is still O(n log n) - > granted, it's a heuristic and may not find a path. > > Alia > > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > Sent: Tuesday, April 23, 2013 9:44 PM > To: curtis@ipv6.occnc.com; MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS Co-Chairs > Subject: re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) > > > s/While it has been possible to compute a CSPF/It is possible to > > compute a CSPF/ > > s/Instead of this approach to minimize path latency, an/An > > alternative to this approach to minimize path latency is an > > approach to place a upper bound on path latency. An/ > > Note: both approaches are valid. > > I think the alternative approach (i.e., to compute a CSPF path based > on the TE metric while placing a upper bound on the path latency) is > not a practical approach due to computationally complexity. > > Best regards, > Xiaohu From gregory.mirsky@ericsson.com Wed Jul 10 11:25:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A3921F8624; Wed, 10 Jul 2013 11:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOc+Dy9+Teoy; Wed, 10 Jul 2013 11:25:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61F21F8C9F; Wed, 10 Jul 2013 11:25:44 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-d6-51dda723740f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A9.14.13034.327ADD15; Wed, 10 Jul 2013 20:25:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Wed, 10 Jul 2013 14:25:39 -0400 From: Gregory Mirsky To: Shahram Davari , Yaakov Stein Thread-Topic: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gE5BdwQAAtnBQAABINY8A== Date: Wed, 10 Jul 2013 18:25:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4C9CE3@eusaamb103.ericsson.se> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il>, <07F7D7DED63154409F13298786A2ADC904E5CC95@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4C9CE3eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPoK7K8ruBBtufcVus7/W0uLV0JavF 3+YedosPXT9YHVg8Zt0/y+axZMlPJo9Ja9MCmKO4bFJSczLLUov07RK4Mp7vPcpScNqx4t7D d+wNjP/Nuxg5OSQETCS6z85mgbDFJC7cW8/WxcjFISRwlFFiyfTNLBDOckaJ7w+msINUsQkY SbzY2ANmiwh4SnTP3cEKYjMLeEh8W76HsYuRg0NYwFni/7I6iBIXiQ+zjzJD2E4Sp97uAyth EVCV2LPFCcTkFfCV+HvRA2LTIUaJrZvvgE3nFHCQ2D13IxOIzQh02/dTa5ggNolL3Hoynwni ZgGJJXvOM0PYohIvH/9jhbCVJZY82c8CUZ8vseo8xMW8AoISJ2c+YZnAKDoLyahZSMpmISmD iOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw2MQKj7ZgEm+4Oxj0vLQ8x SnOwKInzrtI7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMeHSht61a8RLpnq5v3jv/Onz 0+NSn324+Jvn3ZOM2HH5YDkz24Ha4Lmb/4pEJOwJd06yXljLWdpj+GBV9H49BcU1W9l+7WB6 x81WY64T+YpBNzTS8hmPcoiy3GLFZzd01waW5HGLH0824bqeZ741TPaVl59e64GnC2+IHa3h 9l9uIvY13XKGEktxRqKhFnNRcSIAyVW0GYQCAAA= Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:25:51 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B4C9CE3eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Shahram, as Yaacov noted "... sending 1588 over the GACh DCN would be an alternative= mechanism that was not discussed in TICTOC." And that is unfortunate and = perhaps I should have written a document earlier. Timing Distribution DCN c= an interconnect 1588-capable ports with combination of section and LSP span= s. I am interested to understand why you believe that TC function can not b= e supported by a node terminating G-ACh and only BC functionality can be su= pported. Regards, Greg -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Shahram Davari Sent: Wednesday, July 10, 2013 9:11 AM To: Yaakov Stein Cc: mpls@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpl= s Hi I support this draft to go ahead as RFC. We have worked almost 2 years on t= his draft and have addressed all comments by participants and area director= . I disagree with Greg's comment. We have made the draft generic based on Ste= wart's request so that if in future IETF decided to carry other Timing prot= ocols such as NTP they can use the same mechanism. Also I disagree with using GAL-ACH channel, since if the proposal is To use= Section Channel then it can't support TC and can only support BC. And if t= he proposal is to use LSP Channel, then intermediate routers need to do dee= p packet inspection of all packets and detect 1588 packets encapsulated in = the ACH. Also most routers upon detection of any terminated ACH send those = packets directly to CPU. This method had been considered by authors and rej= ected due to its issues. The current method is simple and supports TC and BC. Regards, Shahram > > > > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On > Behalf Of Yaakov Stein > Sent: 04 July, 2013 12:21 > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls > > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). > > Please send indications of support, as well as any remaining technical co= mments, to the list. > > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. > > This working group last call will end on July 19, 2013. > > Y(J)S > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc --_000_7347100B5761DC41A166AC17F22DF1121B4C9CE3eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Shahram,
as Yaacov noted "... sending 1588 over the GACh DCN would be an a= lternative mechanism that was not discussed in TICTOC." And that is&nb= sp; unfortunate and perhaps I should have written a document earlier. Timin= g Distribution DCN can interconnect 1588-capable ports with combination of section and LSP spans. I am interested to underst= and why you believe that TC function can not be supported by a node termina= ting G-ACh and only BC functionality can be supported.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] = On Behalf Of Shahram Davari
Sent: Wednesday, July 10, 2013 9:11 AM
To: Yaakov Stein
Cc: mpls@ietf.org; tictoc@ietf.org
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588ov= ermpls
 
Hi
 
I support this draft to go ahead as RFC. We have worked almost 2 years= on this draft and have addressed all comments by participants and area dir= ector.
 
I disagree with Greg's comment. We have made the draft generic based o= n Stewart's request so that if in future IETF decided to carry other Timing= protocols such as NTP they can use the same mechanism.
 
Also I disagree with using GAL-ACH channel, since if the proposal is T= o use Section Channel then it can't support TC and can only support BC. And= if the proposal is to use LSP Channel, then intermediate routers need to d= o deep packet inspection of all packets and detect 1588 packets encapsulated in the ACH. Also most routers = upon detection of any terminated ACH send those packets directly to CPU. Th= is method had been considered by authors and rejected due to its issues.
 
The current method is simple and supports TC and BC.
 
Regards,
Shahram
 
 
>
>
>
> -----Original Message-----
> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org<= /a>] On
> Behalf Of Yaakov Stein
> Sent: 04 July, 2013 12:21
> To: tictoc@ietf.org
> Cc: mpls@ietf.org
> Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls=
>
>
> Please send indications of support, as well as any remaining tech= nical comments, to the list.
>
> Due to the MPLS aspects of this draft this email is also being se= nt to the MPLS WG, but please conduct all discussion on the TICTOC working = group mailing list.
>
> This working group last call will end on July 19, 2013.
>
> Y(J)S
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
 
_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
 
 --_000_7347100B5761DC41A166AC17F22DF1121B4C9CE3eusaamb103erics_-- From christian.jacquenet@orange.com Thu Jul 11 00:52:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8879421F99F0 for ; Thu, 11 Jul 2013 00:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLQJgcvDZ6VY for ; Thu, 11 Jul 2013 00:52:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 364B721F9A65 for ; Thu, 11 Jul 2013 00:52:51 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id E17CF3B4B9C for ; Thu, 11 Jul 2013 09:52:49 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C9AF335C055 for ; Thu, 11 Jul 2013 09:52:49 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 11 Jul 2013 09:52:49 +0200 From: To: "'mpls@ietf.org' (mpls@ietf.org)" Date: Thu, 11 Jul 2013 09:52:48 +0200 Thread-Topic: New Version Notification for draft-jacquenet-mpls-rd-p2mp-te-requirements-03.txt Thread-Index: Ac59aXj2NRibmMKnR029+DQQ1vJvrgAoWrrw Message-ID: <3373_1373529169_51DE6451_3373_8288_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C46FE6BFE@PUEXCB1C.nanterre.francetelecom.fr> References: <20130710123156.8137.53931.idtracker@ietfa.amsl.com> In-Reply-To: <20130710123156.8137.53931.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.11.41527 Subject: [mpls] TR: New Version Notification for draft-jacquenet-mpls-rd-p2mp-te-requirements-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, 11 Jul 2013 07:52:55 -0000 RllJIC0gdGhpcyB2ZXJzaW9uIHdlbGNvbWVzIHR3byBhZGRpdGlvbmFsIGF1dGhvcnMgYW5kIGFs c28gZGV0YWlscyBhIGNvdXBsZSBvZiBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cy4NCg0KQ29tbWVu dHMgd2VsY29tZS4NCg0KQ2hlZXJzLA0KDQpDaHJpc3RpYW4uDQoNCi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANCkVudm95w6nCoDogbWVyY3JlZGkgMTAganVpbGxldCAyMDEz IDE0OjMyDQrDgMKgOiBUZWx1cyBDb21tdW5pY2F0aW9uczsgUXVpbnRpbiBaaGFvOyBFZHVhcmQg TWV0ejsgQm9yaXMgWmhhbmc7IEpBQ1FVRU5FVCBDaHJpc3RpYW4gT0xOQy9PTE4NCk9iamV0wqA6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtamFjcXVlbmV0LW1wbHMtcmQtcDJt cC10ZS1yZXF1aXJlbWVudHMtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWphY3F1ZW5ldC1tcGxzLXJkLXAybXAtdGUtcmVxdWlyZW1lbnRzLTAzLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaHJpc3RpYW4gSmFjcXVlbmV0IGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1qYWNxdWVuZXQtbXBs cy1yZC1wMm1wLXRlLXJlcXVpcmVtZW50cw0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgUmVxdWly ZW1lbnRzIGZvciBSZWNlaXZlci1Ecml2ZW4gVHJhZmZpYyBFbmdpbmVlcmVkIFBvaW50LXRvLU11 bHRpLVBvaW50IChQMk1QKSBNUExTIFRyZWUgU3RydWN0dXJlcw0KQ3JlYXRpb24gZGF0ZToJIDIw MTMtMDctMTANCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2Vz OiAxNA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1qYWNxdWVuZXQtbXBscy1yZC1wMm1wLXRlLXJlcXVpcmVtZW50cy0wMy50eHQNClN0 YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qYWNx dWVuZXQtbXBscy1yZC1wMm1wLXRlLXJlcXVpcmVtZW50cw0KSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qYWNxdWVuZXQtbXBscy1yZC1wMm1wLXRlLXJl cXVpcmVtZW50cy0wMw0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1qYWNxdWVuZXQtbXBscy1yZC1wMm1wLXRlLXJlcXVpcmVtZW50cy0wMw0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSBzZXQgb2YgcmVxdWlyZW1l bnRzIGZvciB0aGUgZXN0YWJsaXNobWVudA0KICAgYW5kIG1haW50ZW5hbmNlIG9mIFJlY2VpdmVy LURyaXZlbiBQb2ludC10by1NdWx0aXBvaW50IChSRC1QMk1QKSBhbmQNCiAgIE11bHRpcG9pbnQt dG8tTXVsdGlwb2ludCAoUkQtTVAyTVApIFRyYWZmaWMtRW5naW5lZXJlZCAoVEUpDQogICBNdWx0 aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExT UHMpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From sebastien.jobert@orange.com Thu Jul 11 01:05:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26DA21F9A87; Thu, 11 Jul 2013 01:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWsmZFrPksts; Thu, 11 Jul 2013 01:05:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 278D621F9AFB; Thu, 11 Jul 2013 01:05:35 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 5DAAC2DC8C1; Thu, 11 Jul 2013 10:05:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2BC9035C061; Thu, 11 Jul 2013 10:05:34 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 11 Jul 2013 10:05:33 +0200 From: To: Gregory Mirsky , Yaakov Stein , "tictoc@ietf.org" Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gBBhpewAPyFpRA= Date: Thu, 11 Jul 2013 08:05:33 +0000 Message-ID: <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.11.41527 X-Mailman-Approved-At: Thu, 11 Jul 2013 05:00:59 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:05:39 -0000 Hi, In general, I do not support this document, mainly because I don't think th= at the problem statement it tries to address really exists. That being said, I did not check more in details its content, so I cannot j= udge whether or not what it proposes is correct. I just think that there is no use case for this mechanism. =20 "There is a need to transport Timing messages over MPLS networks while supp= orting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (= OC) functionality in the LER and LSRs in the MPLS network." =3D> this state= ment is not supported by any argumentation, and each time that the point ha= s been raised on the mailing list, no clear answer or use case was provided= in my opinion. As mentioned several times, I do not think that there is a = real need to involve the MPLS layer to transport PTP messages; using the ex= isting mappings defined in IEEE 1588-2008 is sufficient for all the use cas= es that I can imagine. And I have not heard any other use case from other i= ndustries than telecoms. Operators are requesting Ethernet encapsulation for PTP (full timing suppor= t from the network scenario) or IP mapping (partial timing support from the= network scenario and no timing support scenario), but not MPLS encapsulati= on... A quick feedback from an operator monitoring this topic from the beginning. Thanks for considering (or not) this input. BR, S=E9bastien -----Message d'origine----- De=A0: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky Envoy=E9=A0: vendredi 5 juillet 2013 18:47 =C0=A0: Yaakov Stein; tictoc@ietf.org Cc=A0: mpls@ietf.org Objet=A0: Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Do not support - As document describing Transporting Timing messages over MPLS Networks it= comes short in justification of complexity of PTP LSP for non-1588 protoco= ls; - I do believe that even for IEEE 1588 distribution through MPLS-TP domain = PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnecti= ng ports that support IEEE 1588 (new capability advertised in IGP-TE) is ar= chitectually clean and sufficient. Regards, Greg -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Yaakov Stein Sent: Thursday, July 04, 2013 2:21 AM To: tictoc@ietf.org Cc: mpls@ietf.org Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-= 05). Please send indications of support, as well as any remaining technical comm= ents, to the list. Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG, but please conduct all discussion on the TICTOC working group mail= ing list. This working group last call will end on July 19, 2013. Y(J)S=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From loa@pi.nu Thu Jul 11 06:49:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C13211E816E for ; Thu, 11 Jul 2013 06:49:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNXzs2fB5imG for ; Thu, 11 Jul 2013 06:49:39 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4039911E8178 for ; Thu, 11 Jul 2013 06:49:39 -0700 (PDT) Received: from [109.58.209.69] (109.58.209.69.bredband.tre.se [109.58.209.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2CF77180110A; Thu, 11 Jul 2013 15:49:38 +0200 (CEST) Message-ID: <51DEB7F1.2030206@pi.nu> Date: Thu, 11 Jul 2013 15:49:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] new structure of the LSP Ping TLV and sub-TLV registries X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:49:44 -0000 Working Group, We have restructured the LSP Ping TLV and sub-TLV registries, there is no change of content in the registries, but they are hopefully a bit easier to read now. http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#tlvs /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From davari@broadcom.com Thu Jul 11 07:51:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A00C11E8194; Thu, 11 Jul 2013 07:51:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt8-tRHjOvyQ; Thu, 11 Jul 2013 07:51:32 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38321F9A98; Thu, 11 Jul 2013 07:51:32 -0700 (PDT) Received: from [10.9.208.53] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 11 Jul 2013 07:45:29 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 11 Jul 2013 07:51:25 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Thu, 11 Jul 2013 07:51:24 -0700 From: "Shahram Davari" To: "sebastien.jobert@orange.com" Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfkYcnR6ysw913kqs7UWvMFFaBQ== Date: Thu, 11 Jul 2013 14:51:23 +0000 Message-ID: <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7DC01A831R043167410-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:51:38 -0000 Hi Sebastian, Thanks for your comments. This draft is an IETF working draft and was accep= ted as such based on IETF consensus. Are you saying there is no need to carry 1588 in the networks that use MPLS= or are you saying there are other methods which are simpler?=20 If you mean the former, then I disagree and I can give you examples from Ch= ina mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul acce= ss and aggregation network are MPLS and they wang to use 1588 at the cell s= ite. If you mean the later one then I disagree as well. If you are proposing to = use Ethernet encapsulation for 1588 without MPLS, then the problem is that = not all links are Ethernet. Even when all links are Ethernet, Ethernet is j= ust used for P2P link and is not switched in routers. This means you can on= ly do BC in such cases. If you are proposing to use Ethernet encapsulation = with MPLS (aka PW), then this is exactly what we do in this draft. If you are proposing to use IP encapsulation for 1588, then you are either = proposing to use IP without MPLS encapsulation, which doesn't work since ob= viously many networks such as MPLS-TP can't perform IP routing. Or you are = proposing to use IP with MPLS encapsulation, which is exactly what we are d= oing in this draft. The other issue is assume a service provider who is using say Ethernet enca= psulation to carry 1588, leases some connections from another network opera= tor. The network operator needs to carry these 1588 messages without termin= ating them but also needs to do TC on them. Using flat Ethernet switching i= s not possible since the operator network is carrying traffic from many oth= er customers and his network is virtualized. I suggest you reading the draft first. Regards, Shahram On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: > Hi, >=20 > In general, I do not support this document, mainly because I don't think = that the problem statement it tries to address really exists. > That being said, I did not check more in details its content, so I cannot= judge whether or not what it proposes is correct. > I just think that there is no use case for this mechanism. >=20 > "There is a need to transport Timing messages over MPLS networks while su= pporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock= (OC) functionality in the LER and LSRs in the MPLS network." =3D> this sta= tement is not supported by any argumentation, and each time that the point = has been raised on the mailing list, no clear answer or use case was provid= ed in my opinion. As mentioned several times, I do not think that there is = a real need to involve the MPLS layer to transport PTP messages; using the = existing mappings defined in IEEE 1588-2008 is sufficient for all the use c= ases that I can imagine. And I have not heard any other use case from other= industries than telecoms. >=20 > Operators are requesting Ethernet encapsulation for PTP (full timing supp= ort from the network scenario) or IP mapping (partial timing support from t= he network scenario and no timing support scenario), but not MPLS encapsula= tion... >=20 > A quick feedback from an operator monitoring this topic from the beginnin= g. >=20 > Thanks for considering (or not) this input. >=20 > BR, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky > Envoy=E9 : vendredi 5 juillet 2013 18:47 > =C0 : Yaakov Stein; tictoc@ietf.org > Cc : mpls@ietf.org > Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > Do not support > - As document describing Transporting Timing messages over MPLS Networks = it comes short in justification of complexity of PTP LSP for non-1588 proto= cols; > - I do believe that even for IEEE 1588 distribution through MPLS-TP domai= n PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnec= ting ports that support IEEE 1588 (new capability advertised in IGP-TE) is = architectually clean and sufficient. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:21 AM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 From davari@broadcom.com Thu Jul 11 07:56:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAEC21F9C22; Thu, 11 Jul 2013 07:56: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oyj4y98heHF; Thu, 11 Jul 2013 07:56:06 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5321F9C25; Thu, 11 Jul 2013 07:56:06 -0700 (PDT) Received: from [10.9.208.53] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 11 Jul 2013 07:52:03 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 11 Jul 2013 07:55:48 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Thu, 11 Jul 2013 07:55:48 -0700 From: "Shahram Davari" To: "sebastien.jobert@orange.com" Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gBBhpewAPyFpRAAPDDqgP//i+PX Date: Thu, 11 Jul 2013 14:55:48 +0000 Message-ID: <932289B6-87A5-40F5-8F19-CB11755B721E@broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup>, <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> In-Reply-To: <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7DC0191931W50853053-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:56:15 -0000 I forgot to mention that in my below example the operator network is MPLS. Regards, Shahram On Jul 11, 2013, at 7:52 AM, "Shahram Davari" wrote: > Hi Sebastian, >=20 > Thanks for your comments. This draft is an IETF working draft and was acc= epted as such based on IETF consensus. >=20 > Are you saying there is no need to carry 1588 in the networks that use MP= LS or are you saying there are other methods which are simpler?=20 >=20 > If you mean the former, then I disagree and I can give you examples from = China mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul ac= cess and aggregation network are MPLS and they wang to use 1588 at the cell= site. >=20 > If you mean the later one then I disagree as well. If you are proposing t= o use Ethernet encapsulation for 1588 without MPLS, then the problem is tha= t not all links are Ethernet. Even when all links are Ethernet, Ethernet is= just used for P2P link and is not switched in routers. This means you can = only do BC in such cases. If you are proposing to use Ethernet encapsulatio= n with MPLS (aka PW), then this is exactly what we do in this draft. >=20 > If you are proposing to use IP encapsulation for 1588, then you are eithe= r proposing to use IP without MPLS encapsulation, which doesn't work since = obviously many networks such as MPLS-TP can't perform IP routing. Or you ar= e proposing to use IP with MPLS encapsulation, which is exactly what we are= doing in this draft. >=20 > The other issue is assume a service provider who is using say Ethernet en= capsulation to carry 1588, leases some connections from another network ope= rator. The network operator needs to carry these 1588 messages without term= inating them but also needs to do TC on them. Using flat Ethernet switching= is not possible since the operator network is carrying traffic from many o= ther customers and his network is virtualized. >=20 > I suggest you reading the draft first. >=20 > Regards, > Shahram >=20 >=20 > On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: >=20 >> Hi, >>=20 >> In general, I do not support this document, mainly because I don't think= that the problem statement it tries to address really exists. >> That being said, I did not check more in details its content, so I canno= t judge whether or not what it proposes is correct. >> I just think that there is no use case for this mechanism. >>=20 >> "There is a need to transport Timing messages over MPLS networks while s= upporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Cloc= k (OC) functionality in the LER and LSRs in the MPLS network." =3D> this st= atement is not supported by any argumentation, and each time that the point= has been raised on the mailing list, no clear answer or use case was provi= ded in my opinion. As mentioned several times, I do not think that there is= a real need to involve the MPLS layer to transport PTP messages; using the= existing mappings defined in IEEE 1588-2008 is sufficient for all the use = cases that I can imagine. And I have not heard any other use case from othe= r industries than telecoms. >>=20 >> Operators are requesting Ethernet encapsulation for PTP (full timing sup= port from the network scenario) or IP mapping (partial timing support from = the network scenario and no timing support scenario), but not MPLS encapsul= ation... >>=20 >> A quick feedback from an operator monitoring this topic from the beginni= ng. >>=20 >> Thanks for considering (or not) this input. >>=20 >> BR, >>=20 >> S=E9bastien >>=20 >> -----Message d'origine----- >> De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part= de Gregory Mirsky >> Envoy=E9 : vendredi 5 juillet 2013 18:47 >> =C0 : Yaakov Stein; tictoc@ietf.org >> Cc : mpls@ietf.org >> Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >>=20 >> Do not support >> - As document describing Transporting Timing messages over MPLS Networks= it comes short in justification of complexity of PTP LSP for non-1588 prot= ocols; >> - I do believe that even for IEEE 1588 distribution through MPLS-TP doma= in PTP LSPs are not required. DCN constructed of dedicated G-ACh interconne= cting ports that support IEEE 1588 (new capability advertised in IGP-TE) is= architectually clean and sufficient. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf= Of Yaakov Stein >> Sent: Thursday, July 04, 2013 2:21 AM >> To: tictoc@ietf.org >> Cc: mpls@ietf.org >> Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >>=20 >> We hereby announce a TICTOC working group last call for draft-ietf-ticto= c-1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmp= ls-05). >>=20 >> Please send indications of support, as well as any remaining technical c= omments, to the list. >>=20 >> Due to the MPLS aspects of this draft this email is also being sent to t= he MPLS WG, but please conduct all discussion on the TICTOC working group m= ailing list. >>=20 >> This working group last call will end on July 19, 2013. >>=20 >> Y(J)S=20 >>=20 >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 From curtis@ipv6.occnc.com Thu Jul 11 12:39:42 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D278511E8112 for ; Thu, 11 Jul 2013 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.005 X-Spam-Level: ** X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmxnbX+W7PCf for ; Thu, 11 Jul 2013 12:39:38 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4524511E8118 for ; Thu, 11 Jul 2013 12:39:37 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6BJcKlG089921; Thu, 11 Jul 2013 15:38:21 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201307111938.r6BJcKlG089921@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar In-reply-to: Your message of "Tue, 09 Jul 2013 19:59:44 -0000." Date: Thu, 11 Jul 2013 15:38:20 -0400 Cc: MPLS WG Mailing List , The Great and Mighty MPLS Co-Chairs , draft-atlas-mpls-te-express-path authors Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:39:42 -0000 In message Alia Atlas writes: > > Hi Curtis, > > Thanks for your detailed comments and suggestions. My responses are > in-line, as always. > > Alia Hi Alia, I have to say that it was *very* hard to determine the context in the mail below from the formating alone, in other words what I wrote vs your reply. The HTML had MsoPlainText tags and the mail headers had X-MS- headers so the culprit can be identified but there was no header identifying the sending MUA (mail user agent). This is the first email I got from you that suffered from this. It would be helpful if you could use an alternate mailer for at least IETF work. Anyway, comments are inline. I tried to reformat to regain context. btw- NPO is no longer in vogue as you are now well aware (due to the perception that the ITU may feel they own the term and we are misusing it). Therefore s/NPO/performance objective/. Or perhaps for this set of documents you could define link performance objective (LPO) and avoid any issues with NPO (btw ITU defines NPO as UNI to UNI and given that definition NPO makes no sense at all in this context). > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > Sent: Tuesday, April 23, 2013 12:59 PM > > To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS Co-Chairs > > Cc: curtis@ipv6.occnc.com > > Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) > > > > Loa, authors, et al, > > > > So far I have seen two of the four MPLS-RT reviews (maybe I missed the > > others). I've commented before on the mailing list about this draft > > but at this point I would like to provide a detailed review. > > > > I think there are very major issues with this document as it now > > stands. IMO these issues should be addressed before the draft is even > > accepted as a WG document. > > > > You can choose to consider this during MPLS-RT review or after. > > > > Curtis > > > > > > Major issues: > > > > Jitter and loss are very close to meaningless if queueing delays and > > loss are not considered. Links that are losing packets at the link > > layer are generally taken down. Oscillations can occur if queueing > > delay and loss is considered, such as measurements at a low priority > > and therefore possible to congest or measurements which are > > otherwise affected by traffic load. Unless there is adequate > > discussion of stability and mechanisms to insure stability, then > > jitter and loss should be removed. > > [Alia] I have changed the second paragraph of the introduction to be: > > Queuing latency is specifically excluded to insure freedom from > oscillations and stability issues that have plagued prior attempts > to use delay as a routing metric. If application traffic which > follows path based upon latency constraints, the same traffic might > be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with > minimal queuing delay or another PHB with potentially very > substantial per-hop queuing delay. Only traffic which experiences > relatively low congestion, such as Expedited Forwarding traffic, > will experience delays very close to the sum of the reported link > delays > > Removing queuing delay is the agreed result for > draft-ietf-ospf-te-metric-extensions. OK > As far as jitter and loss goes, these can still be somewhat > meaningful. For instance, jitter does allow capturing the differences > in serialization delays - which is relevant in some parts of the > network. The acceptable loss to take a link down may vary. I don't > actually see the reasoning or need to remove jitter and loss from the > draft - given that we have constrained the measurements in the > draft-ietf-ospf-te-metric-extensions to not include queuing delay. The argument above regarding jitter and loss doesn't pass the "reasonable" threshhold. Lets do some quick math on the jitter number. On a 10 Gb/s link the time it takes to pass 1532 bytes is (1532*8)/(10*10^9) or 1225*10^-9 or 1.225*10^-6 sec or a bit over 1.2 usec. That is the delay in about 240 meters of fiber. That amount of fiber won't even get you down the elevator shaft in a lot of Manhattan buildings let alone down the street. The argument for jitter as a measure of serialization delay doesn't seem to me to be very credible. Besides, serialization is queuing jitter when only occupancies of 0 and 1 are considered. In the real world when you add more traffic even for EF the probabilities of occupancies of 2, 3, or more rises even if there is no congestion. If you include this jitter measurement which is inherently a queuing effect and extremely sensitive to loading, then you risk oscillations and instability. Your statement "The acceptable loss to take a link down may vary" also doesn't justify including loss. If you want to advertise a protection or restoration time, that might be more reasonable. These things are not measured in "loss" units because how much gets lost depends on the utilization during the protection or restoration time. This is also something that today is generally handled by rfc3209 administrative attributes (colors) to indicate protected vs unprotected links if it matters to some LSP. Note that the difference between end-to-end protection and link by link protection only makes sense for fairly long delay links, where the delay (time in flight before detection) is long compared to the typical protection times of about 10 msec for small number of LSP or under 45 msec for lots of LSP (except some implementation that don't acheive this for lots of links but certainly won't be advertising that). I have made the same comment regarding draft-ietf-ospf-te-metric-extensions. There is no reason to have jitter and delay if queuing impacts are not considered. > > General: > > > > It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, > > see nits below) is specific to a link, and not an NPO per LSP. A > > "non-conformance to NPO" flag in the IGP link advertisement is > > intractable if there are multiple NPO being applied to the link. > > [Alia] As you may recall from draft-ietf-ospf-te-metric-extensions, > the Anomalous bit is specified per characteristic advertised per link. > This draft (draft-atlas-mpls-te-express-path-02) describes the > Anomalous bit as clearly inside a links' sub-TLV as in Sec 2.3.1: > > "If the answer to (a) is no for latency SLAs, then any link which has > the Anomalous bit set in the Unidirectional Link Delay sub- > TLV[I-D.ietf-ospf-te-metric-extensions] > [I-D.previdi-isis-te-metric-extensions] should be removed from the > topology before a CSPF calculation is used to compute a new path." I think s/SLA/link performance objective/ (or LPO as mentioned above) in a lot of places would help. Where you mean end-to-end, just say end-to-end performance objective. The document would then read easier for those who haven't already read the document a dozen times (or read the email conversations that make it already very clear). > > The use of a "non-conformance to NPO" flag as the only means to > > alert the set of LSP ingress of a significant change is also at best > > a poor solution. For example, a change from 2 msec to 15 msec may > > be a problem for some LSP. That same change may not be a problem > > for others, such as LSPs where only this one hop is needed. So > > advertising out of NPO in the IGP doesn't help the second case. LSP > > ingress must evaluate the path delay constraint, each time a change > > in IGP link advertised delay is received. > > [Alia] Sure - different LSPs may have different requirements as to the > Anomalous flag. Using it doesn't replace paying attention to the > value that is advertised. The anomalous flag is reporting that the > link is not complying to the expected performance - this can indicate > that there is something strange going on and some LSPs should avoid > using that link due to administrative policy. > > > The use of a "non-conformance to NPO" flag solely as a constraint > > makes sense, where some LSP are configured to exclude links with > > this flag set. > > [Alia] Right - case (a) and (c) for Sec 2.3 > > > For path delay computation it would also be useful if the NPO > > threshhold were advertised. In some cases, it may make sense to > > minimize or place bounds on the sum of NPO delays. > > [Alia] I think that should be a comment on > draft-ietf-ospf-te-metric-extensions. This draft doesn't define what > is flooded. A question though is whether in the same network it would > make sense to consider both the NPO delays and the actual measured > delays? If only one or the other - then that could be a local > router's decision as to which is flooded. NPO (or link performance objective) delay and measured delay would be two different numbers. If this document is about the use of draft-ietf-ospf-te-metric-extensions, then whether it needs to have a link performance objective advertised in order for "anomolous" to make sense is an issue for this document. > > Specific: > > > > Abstract: > > > > Remove mention of jitter and loss. > > [Alia] I am interested in the opinion of the WG on this. In my view, > this draft is describing how the information flooded via the new > sub-TLVs in draft-ietf-ospf-te-metric-extensions-04 should be used. > Loss and jitter are included in that draft; of course, that draft > could change as well - but I'd like to hear stronger arguments for why > it is harmful to include them than that they're only relevant when > queuing behavior is included and that can lead to oscillations. I am, > perhaps stubbornly, not convinced that they are irrelevant. See argument above. btw- If we add queuing delay and loss, then we can do OSPF-OMP, ISIS-OMP, and MPLS-OMP as defined back in the mid to late 1990s without requiring any protocol changes. :-) Scary thought of the day. > > 1. Introduction: > > > > This sentence is awkward but I think I know what you are trying to > > say. > > > > The method suggested is not optimal for both minimizing path > > cost and additional constraints, such as latency; optimal > > solutions are computationally complex. > > > > Please consider this replacement. > > > > Methods of optimizing path selection for multiple parameters are > > generally computationally complex. The method proposed here are > > to make use of either a single metric in path selection, such as > > minimal path delay, or to make use of another single metric, > > such as the existing TE metric with additional constraints, such > > as target link delay bounds and target path delay bounds. > > [Alia] Thanks for the better text - put in... > > > Please note: > > > > The path selection mechanisms described in this document apply > > to paths that are fully computed by the head-end of the LSP and > > then signaled in an ERO where every sub-object is strict. This > > allows the head-end to consider IGP-distributed performance data > > without requiring the ability to signal the performance > > constraints in an object of the RSVP Path message. > > > > There is work in MPLS or CCAMP by George Swallow and others on > > cummulative metrics in RSVP-TE with delay as a major motivation. > > Perhaps that work should be considered. > > [Alia] I believe you are referring to > http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-01? > That draft appears to me to be about how to get measurements for > latency, jitter, and cost for a given Forwarding Adjacency or Routing > Adjacency so that those values can be advertised into the IGP. I > think this draft is providing a means to collect the data to flood in > draft-ietf-ospf-te-metrics-04. Yes, that is the draft. But no I don't think that the intent is strictly to readvertise the delay for an FA given that the ingress could just sum the values advertised for the links. I think by recording the sum, the ingress can more easily check the latest RESV for a change that could require a route computation. The motivation could also be for MPLS with loose hops where a midpoint LSR could change the hops (but I'm not sure how often if ever that is used, not being a firm beleiver that multidomain RSVP-TE ever got much deployment or persisted where experimented with). Perhaps we should ask George et al about the intended usage. The stated motivation in the abstract is: This draft provides extensions for the Resource ReserVation Protocol Traffic Engineering (RSVP-TE) for the support of the discovery of cost, latency and latency variation of an LSP. The introduction gives examples, most of which are multidomain related. Another example is the egress of a bidirectional LSP. > I did add the last sentence in the following: > > This document does not specify how a router determines what values > to advertise by the IGP; it does assume that the constraints > specified in [I-D.ietf-ospf-te-metric-extensions] and > [I-D.previdi-isis-te-metric-extensions] are followed. Mechanisms > for determining latency and delay variation for Forwarding > Adjacencies and Routing Adjacencies are defined in > [I-D.ietf-ccamp-te-metric-recording]." You wouldn't use a direct measurement of delay using IP-Prec 6 or 7 on an FA? If so, you might want to cite the MPLS-TP DM RFCs and note that an Entropy Label may be needed in some cases to insure that the measurement is accurate. Better to just not cite anything as the means of measurement. > > This paragraph could use rewording: > > > > When considering performance-based data, it is obvious that > > there are additional contributors beyond just the links. > > Clearly end-to-end latency is a combination of router latency, > > queuing latency, physical link latency and other factors. > > However, if application traffic requires paths to be selected > > based upon latency constraints, the same traffic might be in an > > Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal > > queuing delay or another PHB with known maximal per-hop queuing > > delay. While traversing a router can cause delay, that can be > > included in the advertised link delay. > > > > What you are getting at is that where traffic levels can't > > possibly have a significant impact the measurements, such as low > > levels of EF traffic in a WAN with high geographic delays, and > > delay meansured with EF priority, stability is not impacted if > > delay measurements are considered. In this case, loss MUST be > > zero or the EF service is broken (replace routers and try again). > > OTOH jitter will increase as traffic levels increase, even in such > > a case where the traffic is only a few percent, potentially > > causing oscillations and impacting stability. For this reason, > > jitter and loss should not be considered. > > > > I will leave the rewording up to you. I suggest that you create a > > subsection of "Introduction" which discusses potential > > oscillations and stability in greater detail. If you like, I will > > provide some text. > > [Alia] I do hear your concern that jitter could cause oscillations and > impact stability. I am not fully persuaded that this is a practical > issue - given the delays in ingress re-optimization, not trying to > minimize the jitter, and the ability for an LSP to reserve bandwidth. > I would be interested in what text you might provide and a focused > discussion on whether this is something that needs to have > restrictions clearly described to avoid oscillations. Here is a start: 1.2 Oscillation and Stability Considerations Past attempts to use delay or loss as metric sufferred from severe oscillations []. The use of performance based data MUST be such that ocillations are not possible and stability cannot be impacted. The use of timers is often cited as a cure. Oscillation that is damped by timers is known as "slosh". If advertisement timers are very short relative to the jitter applied to RSVP-TE CSPF timers, then a partial oscillation occurs. If RSVP-TE CSPF timers are short relative to advertisement timers, full oscillation (all traffic moving back and forth) can occur. Even a partial oscillation causes unnecessary reordering which is considered at least minimally disruptive. Delay variation or jitter is affected by even small traffic levels. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter proportional to or equal to the packet serialization delay. Very low levels of traffic can increase the probability of queue occupancies of two or three packets enough to further increase the measured jitter. Because jitter measurement is extremely sensitive to even very low traffic levels, any use of jitter is likely to oscillate. There may be legitimate use of a jitter measurement in path computation that can be considered free of oscillation. Delay measurements that are not sensitive to traffic loads may be safely used in path computation. Delay measurements made at the link layer or measurements made at a queuing priority higher than any significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 if traffic levels at CS3 and higher or EF and AF can affect the measurement). Making delay measurements at the same priority as the traffic on affected paths is likely to cause oscillations. Delay measurements that include queuing delay or loss measurement that includes queuing loss would be very difficult to use in path computation in a way that can be assured to be stable. No technique to date has successfully accomplished this. Timers values must reflect the number of contributors to traffic on each given link or a very conservative estimate of the potential contributors. Moving large LSP can itself be problematic and techniques which allow movement of partial LSP traffic, such as multipath techniques, may help. If queuing delay or loss measurement is considered, a proof of stability should be undertaken. These proofs insure that no positive feedback exists such that small or moderate changes in traffic patterns could cause path decisions to fluctuate wildly. Proof of stability for an arbitrary topology with arbitrary traffic patterns and using a set of rules for determining timer values and traffic adjustment amounts can be exceedingly difficult. Until a path selection technique is available which is provably stable, a condition that today has not been met, queuing delay and queuing loss MUST NOT be included in delay and loss measurements. Note that most of RFC4594 provides nothing more than recommendations is routinely ignored except that CS6 is normally used for control and management (IGP, BGP, RSVP-TE control, LDP control, SNMP, etc), though often SNMP is often given lesser priority. Proof of stability is very difficult (I tried to get help with this with OMP back in the 1990s). Note that OMP could move traffic in one direction and then move half that amount in the other direction if overshoot occurred, yet we still couldn't come up with a stability proof for an arbitrary topology, even with timers and backoffs that considered the number of "other" contributors to traffic (number of other LSP ingress ingress in the topology). > For now, I have changed this paragraph to: > > When considering performance-based data, it is obvious that there > are additional contributors beyond just the links. Clearly > end-to-end latency is a combination of router latency, queuing > latency, physical link latency and other factors. While traversing > a router can cause delay, that can be included in the advertised > link delay. As described in [I-D.ietf-ospf-te-metric-extensions] > and [I-D.previdi-isis-te-metric-extensions], queuing delay should > not be included in the measurements advertised by OSPF or ISIS. ... queuing delay MUST NOT be included ... > Queuing latency is specifically excluded to insure freedom from > oscillations and stability issues that have plagued prior attempts > to use delay as a routing metric. If application traffic which > follows path based upon latency constraints, the same traffic might > be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with > minimal queuing delay or another PHB with potentially very > substantial per-hop queuing delay. Only traffic which experiences > relatively low congestion, such as Expedited Forwarding traffic, > will experience delays very close to the sum of the reported link > delays. The traffic levels can't impact the measured delay. For that to occur, the delay measurements have to be queued ahead of the traffic. Changing the path of EF traffic and making the delay measurements at EF is unsafe. If CS7 and CS6 is queued ahead of EF, then delay must be measured at CS6 or better yet CS7 (or still better at link layer). > > 1.1. Basic Requirements: > > > > Drop "packet loss, jitter" from the first numeric item. Otherwise > > OK except use of the word SLA. See nits below. > > [Alia] Changed SLAs to NPO Sorry, but now change it to "performance objective" or "link performance objective" or LPO. See discussion way above. > > After the list please state that "For existing MPLS constraints, > > corresponding RSVP-TE signaling allows midpoint LSR to use Path > > Tear and/or notification and would use this mechanism to > > accomplish items 3-6. In the absense of RSVP-TE signaling > > corresponding to these new constraints, new mechanisms at the LSP > > ingress are needed." Alternately, consider citing the work by > > George Swallow et al and explain how that solves it in the same > > way that a change in admin attr of a link would (or should, poor > > implementations not withstanding). > > [Alia] Frankly, I'm confused by this. I don't agree that RSVP-TE > signaling extensions would solve, for instance, (3): > > 3. Ability to periodically verify that a TE tunnel's current LSP > complies with its configured end-to-end performance > requirements. Sure. The RESV changes if the delay of a link along the way changes. If the link delay or end-to-end delay is a constraint, the LSP can be rejected which would best be handled using soft preemption. > Even if the ingress signaled the end-to-end performance requirements, > I don't see how that stops the ingress from verifying compliance? If the RESV has to be updated with the latest value, the ingress at the very least gets a verification without requiring the use of probe packets by the ingress. Link to link DM packets are much more efficient that each ingress sending probe packets to verify delay. > Similarly, only the ingress could do: > > 4. Ability to move tunnels, using make-before-break, based upon > computed end-to-end performance complying with configuration > > 5. Ability to move tunnels away from any link that is violating an > underlying SLA > > 6. Ability to optionally avoid setting up tunnels using any link > that is violating an SLA, regardless of whether end-to-end > performance would still meet requirements." Any change in the RESV or a soft preempt give the ingress a higher priority heads up that something changed. A soft preempt is a good heads up on an SLA violation for any LSP that cares about that. > I have looked for the additional work that you are talking about by > George Swallow unsuccessfully. Can you find a pointer to explain what > you're talking about? The anomalous bits provide a trigger mechanism > that a router can use to tell the ingress to do (5); different admin > attributes could do a similar behavior - and similarly for (6) - but > again that is the flooding for notification aspect. I think the lack > of RSVP-TE extensions doesn't cause an issue - these are handled by > IGP instead and thus don't have to be signaled per LSP. The work by Swallow does not solve your problems. It is a good starting point and like the prior situation with multiple delay metric related drafts consolidating very similar efforts is a good thing. So if you would consider RSVP-TE extensions, then try to align your work with George Swallow's work. > I am not irrevocably opposed to RSVP-TE extensions - if we really need > them for practical use-cases. This draft was trying to do the minimum > that is sufficient and then, if and when there is a need for more, > what extra is needed could be better defined. The point is to be realistic about what the limited mechanisms do well and don't do well. Note: At one point at least one major RSVP-TE implementation didn't check to see if constraints for LSP were met after an IGP change. For example if a set of LSP include the admin attribute constraint "exclude color blue" and a link gets changed to color blue, then those LSP could sit there for hours before being rerouted. That (or those) implementation(s) only prioritized CSPF for LSP where a notification or PATH/RESV TEAR had been received. You might want to check to see how your employers RSVP-TE handles this. It used to do this but I don't know if it still does. > > 2.1. End-to-End Constraints: > > > > Note: I've requested that jitter and loss be dropped from > > draft-ietf-ospf-te-metric-extensions and > > draft-previdi-isis-te-metric-extensions for the same potential > > oscillations and stability reasons cited above. > > [Alia] Yes - I think we clearly need to have a good email discussion > with those interested about what oscillations might actually occur and > what could be done to prevent that. > > > s/While it has been possible to compute a CSPF/It is possible to > > compute a CSPF/ > > > > s/Instead of this approach to minimize path latency, an/An > > alternative to this approach to minimize path latency is an > > approach to place a upper bound on path latency. An/ > > > > Note: both approaches are valid. > > > > Delete next paragraph starting with "This is illustrated as > > follows." This seems to be taken from email and is good email > > discussion but not needed in the draft. > > [Alia] I've put in some pseudo-code so I'm ok with taking the example > out - but there does seem to have been confusion even with it in. > > > Delete next paragraph starting with "An end-to-end bound on delay > > variation". Lets get rid of jitter altogether. (Let the old SNA > > networks be damned. :) > > > > Delete next paragraph starting with "For link loss". Get rid of > > link loss altogether. > > [Alia] Not done - discussion is needed. I understand that you really > really really don't want to see loss or delay variation in any of > these drafts. Yes, for reasons very clearly stated above. > > 2.2. Link Constraints: > > > > Drop delay variation and link loss. > > > > If we are dealing with EF traffic then using Unidirectional > > Available Bandwidth and Residual Bandwidth makes no sense. If we > > are dealing with low priority traffic and we are using > > Unidirectional Available Bandwidth and Residual Bandwidth in path > > selection will be prone to oscillations and network instability. > > Therefore delete the entire second paragraph (the one starting > > with "When doing path selection for TE tunnels,". > > [Alia] If we are trying to avoid congesting the link, then Residual > Bandwidth is important and useful regardless of the LSP traffic class. > What is your specific concern with oscillation for bandwidth? Why is > it different than for the bandwidths already advertised and used for > TE path computation? Come on - the Residual Bandwidth is just the > Link Capacity minus that reserved by RSVP-TE - so pretty darn similar > characteristics to the Unreserved Bandwidth per priority... The > Unidirectional Available bandwidth does include an actual traffic > measurement - that is averaged over a reasonable interval, that can > only change with limited frequency - and then the LSPs need to be > reoptimized to use them. Please explain precisely the oscillation > concern with a clear example. On rereading draft-ietf-ospf-te-metric-extensions this is OK as defined. Residual Bandwidth doesn't use any measured traffic and is therefore OK. Available Bandwidth also subtracts out just the non-RSVP-TE traffic and so that too should be OK. The non-RSVP-TE traffic (IP and LDP traffic) will not move as long as the IGP metrics don't change. > > Also delete the entire third paragraph (starting with "Similarly, > > only links whose loss is"). As stated earlier, use of loss is > > either a NOOP (low volume of EF traffic) or can lead to > > oscillations. Get rid of loss entirely. > > > > 2.3. Links out of SLA: > > > > s/SLA/NPO/g (see nits below). > > > > General: A better mechanism than an "Anomalous State" flag is > > needed to provide notifications of change. One mechanism would be > > to put the commulative constraint and the cummulative total in the > > ERO and RRO. A link adding delay can then notify the ingress of > > any LSP for which the commulative constraint is violated. See > > work by Swallow et al and perhaps align with that work. > > [Alia] That could be done as well - but the signaling extensions seem > like overkill for the basic problem of letting the ingress compute a > complete ERO. Carrying both the cumulative constraint and the > cumulative total just means that the midpoint detects a changed link > and then has to verify the performance on each LSP and individually > signal it. Having an anomalous flag provides a succinct notification > to the ingress which can then do the verification and be known to have > the updated information. This solution also requires that the > midpoints all support it before it can be used. An advantage of the > ingress computation is that only the ingress needs to have updated > code. Coding this at the midpoint is very easy and efficient. First when an LSP is signaled, compute the difference between the LSP delay target and the experienced delay (the PATH can give the delay total of prior links, the RESV can give delay total for downstream links. Take that headroom figure and install a pointer to the LSP in a sorted collection with good insert/delete times (a balanced tree for example). When another link delay changes, the PATH or RESV changes and the LSP has to be scheduled for removal and reinsertion into the sorted collection. Initially put it on a DLL to make this computationally trivial. Clean up the DLL entries periodically in spare time. When a link changes, start at the end of the sorted collection with the most sensitive LSP. Go through the list doing soft preempt on all those in violation. Simply update the delay value in the PATH and RESV on the rest and that can be done in spare time. Those LSP that don't care about delay don't get on any of these lists. > > The "Anomalous State" flag is helpful for c in the list, but not > > for b. The case where a link is out of NPO by 1 msec then changes > > to out of NPO by 10s of msec is an example. The flag is already > > set and therefore the trigger is unavailable. > > [Alia] Right - but LSPs that are particular sensitive (i.e. a or c) > can have been moved already. Having the Anomalous flag set is > expected to be unusual. I agree that it is more a hint for (b) than a > full solution. > > > 2.3.1. Use of Anomalous Links for New Paths > > > > Delete second paragraph regarding jitter and loss. > > > > 2.3.2. Links entering the Anomalous State > > > > This section ignores two cases in which the Anomalous State does > > not change but a change makes the path violate a delay > > constraint. The first is where all of the links are within NPO > > but a change to a link has make the path delay sum exceed the path > > delay constraint. The second is where a link which is already in > > the Anomalous State by a small margin but the path delay is still > > within the constraint. A large change in delay at that point will > > not affect the Anomalous State since it is already set. > > [Alia] The Anomalous bit is NOT meant to replace reading the actual > value associated with the link and checking each potentially affected > LSP. In the case of (b), it is a hint to focus on those LSPs first. > > > A better means of handling case (b) in "2.3. Links out of SLA" is > > needed. > > [Alia] I've added the following paragraph at the end of 2.3.2: > > It is not sufficient to just look at the Anomalous bit in order to > determine when TE tunnels must have their compliance verified. > When changing to set, the Anomalous bit merely provides a hint that > interested TE tunnels for case (b) should have their continued > compliance verified. The point that I am making is that a change to the "Anomalous State" flag is an unreliable hint for (b) where (b) is: b. Should LSPs using this link be immediately verified for continued compliance to their end-to-end constraints? Perhaps you should take (b) out of the list and state that for LSP which have end-to-end constraints, but for which the "Anomalous State" flag does not automatically disqualify a link, the advertised parameters will have to be checked on every received advertisement with a change. Or take out (b) and leave the paragraph that you have suggested adding. > > 2.3.3. Links leaving the Anomalous State > > > > Same issue as in "2.3.2. Links entering the Anomalous State". A > > better means of handling case (b) in "2.3. Links out of SLA" is > > needed. > > [Alia] I've added the following sentence: > > The hint provided by the Anomalous state change may help optimize > when to recompute for a better path. It is an unreliable hint so using that hint is a bad practice. Unreliable hints don't "help". > > XML version nits: > > > > CV: you really should remove the template comments. > > [Alia] I find them helpful for when I want to do additional > things... and very very few people read the XML. OK > > You should also enable strict mode. For example, you have one > > author too many and strict would catch that. > > [Alia] So does basic arithmetic :) It will be resolved before the > draft is passed to the RFC editor. Strict mode does a lot of other checks that are supposed to get run when a doc becomes a WG doc, long before it goes to the RFC Editor. I just used datatracker to do a check nits and it had a few things to complain about. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. == Unused Reference: 'RFC5420' is defined on line 291, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-ospf-te-metric-extensions-02 == Outdated reference: A later version (-03) exists of draft-previdi-isis-te-metric-extensions-02 The first two need to be fixed. The second two are just a matter of updating the references. > > Other nits: > > > > The "A" in SLA is "Agreement" as in contract. The acronym NPO for > > network performance objective seems to be in vogue for that reason. > > IETF since diffserv has wanted to steer clear of making > > recommendations regarding provider contracts (agreements) with > > customers, peer, or anyone else. > > [Alia] True - changed Sorry about this but s/NPO/?/ Where "?" is "performance objective", "link performance objective", LPO, or descriptive term of your choice. See above. > > I agree with Sri on the suggestions to change the title, short name > > and document filename but I'm not fond of his suggested new names. > > Authors please suggest new title, short name, and filename. > > [Alia] I did do a new short name and title. As for filename, we'll > deal with that if/when the draft is adopted as a WG draft. I haven't seen the new name. > Thanks again, > > Alia Thanks, Curtis > [ ... trimmed forwarded MPLS-RT message from Loa ... ] From sebastien.jobert@orange.com Thu Jul 11 15:10:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0011E819A; Thu, 11 Jul 2013 15:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwNOU8B-3Rs4; Thu, 11 Jul 2013 15:10:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D871D11E81BA; Thu, 11 Jul 2013 15:10:24 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 8FADC3B513D; Fri, 12 Jul 2013 00:10:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 711A927C053; Fri, 12 Jul 2013 00:10:14 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 00:10:14 +0200 From: To: Shahram Davari Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfkYcnR6ysw913kqs7UWvMFFaBZlf/wSg Date: Thu, 11 Jul 2013 22:10:13 +0000 Message-ID: <17365_1373580614_51DF2D46_17365_10736_1_7F67B91079F7C74F9DAB55FC7872661E143FA5@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> In-Reply-To: <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.11.183343 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:10:30 -0000 Hi Shahram, Thanks for your reply and explanations. See some comments below in your tex= t. It is interesting discussion. Thanks. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: jeudi 11 juillet 2013 16:51 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastian, Thanks for your comments. This draft is an IETF working draft and was accep= ted as such based on IETF consensus. [JOBERT Sebastien RD-CORE-LAN] Absolutely, and this is not something that I= dispute. However, since it has been asked to the mailing list to indicate = support and provide comments, I do not feel that giving an opinion was outs= ide the IETF process. The group may or may not consider this input at the e= nd. Are you saying there is no need to carry 1588 in the networks that use MPLS= or are you saying there are other methods which are simpler?=20 [JOBERT Sebastien RD-CORE-LAN] Of course, there is a need to carry PTP mess= ages over networks that operate the MPLS layer; what I am saying is simply = that, over such networks, I do not think that carrying these PTP messages i= nside an MPLS layer is required. Other existing encapsulations are fine and= probably simpler, indeed. If you mean the former, then I disagree and I can give you examples from Ch= ina mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul acce= ss and aggregation network are MPLS and they wang to use 1588 at the cell s= ite. [JOBERT Sebastien RD-CORE-LAN] Of course, we agree on this point: MPLS netw= orks are widely deployed. It is on the method to carry PTP messages that we= have different views, I think. If you mean the later one then I disagree as well. [JOBERT Sebastien RD-CORE-LAN] OK, let's discuss then to see where the diff= erent views are. If you are proposing to use Ethernet encapsulation for 1588 without MPLS, t= hen the problem is that not all links are Ethernet.=20 [JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only o= ne possibility, as IP mapping is also possible, see below), the links that = use an Ethernet mapping for the PTP messages must obviously support Etherne= t. That being said: 1- not all the links must use this mapping, it is possi= ble to mix different mappings (e.g. Ethernet and IP) and allow some kind of= interworking mechanisms; 2- it is not because the PTP messages are carried= over Ethernet that the entire traffic must also be carried over Ethernet, = it is fully possible to envisage that only the "synchronization plane" be o= ver Ethernet, and the data and control planes be over MPLS if desirable. Do= we agree on this? Even when all links are Ethernet, Ethernet is just used for P2P link and is= not switched in routers.=20 [JOBERT Sebastien RD-CORE-LAN] Some routers may also implement a L2... This means you can only do BC in such cases.=20 [JOBERT Sebastien RD-CORE-LAN] No, there are ways to build a TC system with= Ethernet encapsulation (we actually presented a draft in Paris providing o= ne possible solution). If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then= this is exactly what we do in this draft. [JOBERT Sebastien RD-CORE-LAN] Indeed, but this is not what I am proposing = ;-) If you are proposing to use IP encapsulation for 1588, then you are either = proposing to use IP without MPLS encapsulation, which doesn't work since ob= viously many networks such as MPLS-TP can't perform IP routing.=20 [JOBERT Sebastien RD-CORE-LAN] This is probably the main point where we do = not agree. I can hardly imagine personally a network operating an MPLS laye= r where everything is carried over MPLS. As mentioned before, there is no p= roblem in having the data and control planes over MPLS if desirable (althou= gh I doubt that the control plane be always over MPLS, but it is a differen= t debate), and the "synchronization plane" over IP. Synchronization is gene= rally uncorrelated from the other planes: consider for instance Synchronous= Ethernet, it is a layer 1 mechanism, which is totally uncorrelated from th= e way the data plane is transported. Correlating these layers is not necess= ary. Or you are proposing to use IP with MPLS encapsulation, which is exactly wh= at we are doing in this draft. [JOBERT Sebastien RD-CORE-LAN] No, as I mentioned, I do not think that such= encapsulation is required. The other issue is assume a service provider who is using say Ethernet enca= psulation to carry 1588, leases some connections from another network opera= tor. The network operator needs to carry these 1588 messages without termin= ating them but also needs to do TC on them.=20 [JOBERT Sebastien RD-CORE-LAN] Another point where we also probably disagre= e, I believe. TC is one possible solution, but there are many other ways to= enable "timing transparency" (for instance, without going into the details= : differential methods, "network TC" concept, etc.). However, the real ques= tion seems to be: is timing transparency a real requirement? My opinion is = that this is not a strong requirement, because at the end, for mobile appli= cations, one has to deliver some sort of UTC traceable signal. Hence, where= the synchronization reference is coming from is not really important, as l= ong as the synchronization requirements are met, because the ultimate sourc= e is at the end the same for everyone: UTC. Future applications do not real= ly have plesiochronous requirements anymore. I really believe that a scenar= io where the carrier operator is providing the reference to the mobile oper= ator, in case of leased lines, is what will occur. Otherwise, this will be = a scenario where the carrier operator does not provide any support at all f= or PTP and where the mobile operator is on its own to get rid of the PDV an= d asymmetry generated by the network. I cannot imagine why the carrier oper= ator would like to spend money on hardware support such as TC in every sing= le NEs simply to provide to other operators some kind of timing transparenc= y not really required; the carrier operator would better spend his money bu= ilding a robust network enabling to deliver very accurate synchronization, = and provide his own timing reference, with possible guarantees, as part of = the leased line offer. Using flat Ethernet switching is not possible since the operator network is= carrying traffic from many other customers and his network is virtualized. I suggest you reading the draft first. [JOBERT Sebastien RD-CORE-LAN] Good suggestion indeed ;-) I'll do this for = my own education; however, still, I believe that the use cases that this dr= aft tries to address are subject to discussion. Regards, Shahram On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: > Hi, >=20 > In general, I do not support this document, mainly because I don't think = that the problem statement it tries to address really exists. > That being said, I did not check more in details its content, so I cannot= judge whether or not what it proposes is correct. > I just think that there is no use case for this mechanism. >=20 > "There is a need to transport Timing messages over MPLS networks while su= pporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock= (OC) functionality in the LER and LSRs in the MPLS network." =3D> this sta= tement is not supported by any argumentation, and each time that the point = has been raised on the mailing list, no clear answer or use case was provid= ed in my opinion. As mentioned several times, I do not think that there is = a real need to involve the MPLS layer to transport PTP messages; using the = existing mappings defined in IEEE 1588-2008 is sufficient for all the use c= ases that I can imagine. And I have not heard any other use case from other= industries than telecoms. >=20 > Operators are requesting Ethernet encapsulation for PTP (full timing supp= ort from the network scenario) or IP mapping (partial timing support from t= he network scenario and no timing support scenario), but not MPLS encapsula= tion... >=20 > A quick feedback from an operator monitoring this topic from the beginnin= g. >=20 > Thanks for considering (or not) this input. >=20 > BR, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky > Envoy=E9 : vendredi 5 juillet 2013 18:47 > =C0 : Yaakov Stein; tictoc@ietf.org > Cc : mpls@ietf.org > Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > Do not support > - As document describing Transporting Timing messages over MPLS Networks = it comes short in justification of complexity of PTP LSP for non-1588 proto= cols; > - I do believe that even for IEEE 1588 distribution through MPLS-TP domai= n PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnec= ting ports that support IEEE 1588 (new capability advertised in IGP-TE) is = architectually clean and sufficient. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:21 AM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From davari@broadcom.com Thu Jul 11 16:06:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB8721F9D9B; Thu, 11 Jul 2013 16:06:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTuuGL5Sv0re; Thu, 11 Jul 2013 16:06:31 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id B1ABB21F90DC; Thu, 11 Jul 2013 16:06:12 -0700 (PDT) Received: from [10.9.208.57] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 11 Jul 2013 16:00:06 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.8) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 11 Jul 2013 16:06:02 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Thu, 11 Jul 2013 16:06:01 -0700 From: "Shahram Davari" To: "sebastien.jobert@orange.com" Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfkYcnR6ysw913kqs7UWvMFFaBZlf/wSggAASeYA= Date: Thu, 11 Jul 2013 23:06:00 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE85AD7@SJEXCHMB12.corp.ad.broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> <17365_1373580614_51DF2D46_17365_10736_1_7F67B91079F7C74F9DAB55FC7872661E143FA5@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17365_1373580614_51DF2D46_17365_10736_1_7F67B91079F7C74F9DAB55FC7872661E143FA5@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DC1E77C1R043350344-02-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:06:35 -0000 Hi Sebastien, Please see my response inline. Thank Shahram -----Original Message----- From: sebastien.jobert@orange.com [mailto:sebastien.jobert@orange.com]=20 Sent: Thursday, July 11, 2013 3:10 PM To: Shahram Davari Cc: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Shahram, Thanks for your reply and explanations. See some comments below in your tex= t. It is interesting discussion. Thanks. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: jeudi 11 juillet 2013 16:51 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastian, Thanks for your comments. This draft is an IETF working draft and was accep= ted as such based on IETF consensus. [JOBERT Sebastien RD-CORE-LAN] Absolutely, and this is not something that I= dispute. However, since it has been asked to the mailing list to indicate = support and provide comments, I do not feel that giving an opinion was outs= ide the IETF process. The group may or may not consider this input at the e= nd. Are you saying there is no need to carry 1588 in the networks that use MPLS= or are you saying there are other methods which are simpler?=20 [JOBERT Sebastien RD-CORE-LAN] Of course, there is a need to carry PTP mess= ages over networks that operate the MPLS layer; what I am saying is simply = that, over such networks, I do not think that carrying these PTP messages i= nside an MPLS layer is required. Other existing encapsulations are fine and= probably simpler, indeed. If you mean the former, then I disagree and I can give you examples from Ch= ina mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul acce= ss and aggregation network are MPLS and they wang to use 1588 at the cell s= ite. [JOBERT Sebastien RD-CORE-LAN] Of course, we agree on this point: MPLS netw= orks are widely deployed. It is on the method to carry PTP messages that we= have different views, I think. If you mean the later one then I disagree as well. [JOBERT Sebastien RD-CORE-LAN] OK, let's discuss then to see where the diff= erent views are. If you are proposing to use Ethernet encapsulation for 1588 without MPLS, t= hen the problem is that not all links are Ethernet.=20 [JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only o= ne possibility, as IP mapping is also possible, see below), the links that = use an Ethernet mapping for the PTP messages must obviously support Etherne= t. That being said: 1- not all the links must use this mapping, it is possi= ble to mix different mappings (e.g. Ethernet and IP) and allow some kind of= interworking mechanisms;=20 SD> So you agree that you need some interworking function which can convert= Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, etc= . I am sure you don't want to do this interworking in the CPU, do you? So y= ou need new HW. Basically what you are saying is that carry 1588 over the s= erver layer such as Ethernet or OTN, etc. The problem as you figured out yo= urself is that the span of the server layer is not the same span as the LSP= . Therefore you either need to terminate the 1588 and regenerate it (BC), o= r as you said you need service interworking. 2- it is not because the PTP messages are carried over Ethernet that the en= tire traffic must also be carried over Ethernet, it is fully possible to en= visage that only the "synchronization plane" be over Ethernet, and the data= and control planes be over MPLS if desirable. Do we agree on this? SD> Yes. But as I said the issue is that the span of server layer may not b= e the same as the LSP. Even when all links are Ethernet, Ethernet is just used for P2P link and is= not switched in routers.=20 [JOBERT Sebastien RD-CORE-LAN] Some routers may also implement a L2... SD> yes some do L2 switching, but some don't. This means you can only do BC in such cases.=20 [JOBERT Sebastien RD-CORE-LAN] No, there are ways to build a TC system with= Ethernet encapsulation (we actually presented a draft in Paris providing o= ne possible solution). SD> I haven't seen that. Could you please email that to me. If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then= this is exactly what we do in this draft. [JOBERT Sebastien RD-CORE-LAN] Indeed, but this is not what I am proposing = ;-) If you are proposing to use IP encapsulation for 1588, then you are either = proposing to use IP without MPLS encapsulation, which doesn't work since ob= viously many networks such as MPLS-TP can't perform IP routing.=20 [JOBERT Sebastien RD-CORE-LAN] This is probably the main point where we do = not agree. I can hardly imagine personally a network operating an MPLS laye= r where everything is carried over MPLS. As mentioned before, there is no p= roblem in having the data and control planes over MPLS if desirable (althou= gh I doubt that the control plane be always over MPLS, but it is a differen= t debate), and the "synchronization plane" over IP. Synchronization is gene= rally uncorrelated from the other planes: consider for instance Synchronous= Ethernet, it is a layer 1 mechanism, which is totally uncorrelated from th= e way the data plane is transported. Correlating these layers is not necess= ary. SD> There are networks that don't do IP routing. PTN networks that are base= d on MPLS-TP don't do IP routing at all. You can refer to come of the China= and Japan carriers. I agree that Synch can be uncorrelated to data, but y= ou the issue is that the logically out-of-band network you are referring to= in most cases has short span (such as one link) and therefore can't suppor= t 1588 end-to-end TC. Or you are proposing to use IP with MPLS encapsulation, which is exactly wh= at we are doing in this draft. [JOBERT Sebastien RD-CORE-LAN] No, as I mentioned, I do not think that such= encapsulation is required. The other issue is assume a service provider who is using say Ethernet enca= psulation to carry 1588, leases some connections from another network opera= tor. The network operator needs to carry these 1588 messages without termin= ating them but also needs to do TC on them.=20 [JOBERT Sebastien RD-CORE-LAN] Another point where we also probably disagre= e, I believe. TC is one possible solution, but there are many other ways to= enable "timing transparency" (for instance, without going into the details= : differential methods, "network TC" concept, etc.). However, the real ques= tion seems to be: is timing transparency a real requirement? My opinion is = that this is not a strong requirement, because at the end, for mobile appli= cations, one has to deliver some sort of UTC traceable signal. Hence, where= the synchronization reference is coming from is not really important, as l= ong as the synchronization requirements are met, because the ultimate sourc= e is at the end the same for everyone: UTC. Future applications do not real= ly have plesiochronous requirements anymore. I really believe that a scenar= io where the carrier operator is providing the reference to the mobile oper= ator, in case of leased lines, is what will occur. Otherwise, this will be = a scenario where the carrier operator does not provide any support at all f= or PTP and where the mobile operator is on its own to get rid of the PDV an= d asymmetry generated by the network. I cannot imagine why the carrier oper= ator would like to spend money on hardware support such as TC in every sing= le NEs simply to provide to other operators some kind of timing transparenc= y not really required; the carrier operator would better spend his money bu= ilding a robust network enabling to deliver very accurate synchronization, = and provide his own timing reference, with possible guarantees, as part of = the leased line offer. SD> While the model that you describe where a Transit provider also provide= s reference clock is possible, but it require 1588 protocol exchange betwee= n Operator and the service provider that leases from operator. And I think= it is not embraced in the industry (as of yet). But 1588 transparency is s= imple and does not require 1588 protocol exchange between operator and serv= ice provider. Using flat Ethernet switching is not possible since the operator network is= carrying traffic from many other customers and his network is virtualized. SD> I agree with you that if the entire network is built out of Switch-Rout= ers and all links are Ethernet then you probably don't need this draft and = can do 1588 over Ethernet end-to-end. I suggest you reading the draft first. [JOBERT Sebastien RD-CORE-LAN] Good suggestion indeed ;-) I'll do this for = my own education; however, still, I believe that the use cases that this dr= aft tries to address are subject to discussion. Regards, Shahram On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: > Hi, >=20 > In general, I do not support this document, mainly because I don't think = that the problem statement it tries to address really exists. > That being said, I did not check more in details its content, so I cannot= judge whether or not what it proposes is correct. > I just think that there is no use case for this mechanism. >=20 > "There is a need to transport Timing messages over MPLS networks while su= pporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock= (OC) functionality in the LER and LSRs in the MPLS network." =3D> this sta= tement is not supported by any argumentation, and each time that the point = has been raised on the mailing list, no clear answer or use case was provid= ed in my opinion. As mentioned several times, I do not think that there is = a real need to involve the MPLS layer to transport PTP messages; using the = existing mappings defined in IEEE 1588-2008 is sufficient for all the use c= ases that I can imagine. And I have not heard any other use case from other= industries than telecoms. >=20 > Operators are requesting Ethernet encapsulation for PTP (full timing supp= ort from the network scenario) or IP mapping (partial timing support from t= he network scenario and no timing support scenario), but not MPLS encapsula= tion... >=20 > A quick feedback from an operator monitoring this topic from the beginnin= g. >=20 > Thanks for considering (or not) this input. >=20 > BR, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky > Envoy=E9 : vendredi 5 juillet 2013 18:47 > =C0 : Yaakov Stein; tictoc@ietf.org > Cc : mpls@ietf.org > Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > Do not support > - As document describing Transporting Timing messages over MPLS Networks = it comes short in justification of complexity of PTP LSP for non-1588 proto= cols; > - I do believe that even for IEEE 1588 distribution through MPLS-TP domai= n PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnec= ting ports that support IEEE 1588 (new capability advertised in IGP-TE) is = architectually clean and sufficient. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:21 AM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From xuxiaohu@huawei.com Thu Jul 11 18:19:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCC11E820C for ; Thu, 11 Jul 2013 18:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-3.297, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+1lHBubDQCU for ; Thu, 11 Jul 2013 18:19:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 634FD11E820F for ; Thu, 11 Jul 2013 18:19:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ03583; Fri, 12 Jul 2013 01:19:30 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 02:18:00 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 02:18:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 09:18:30 +0800 From: Xuxiaohu To: Kireeti Kompella , Lizhong Jin Thread-Topic: [mpls] draft-ietf-mpls-special-purpose-labels-01 Thread-Index: AQHOe+L6kiq70CghjUWGy1AKFqebFJlbUpkAgAPtspA= Date: Fri, 12 Jul 2013 01:18:30 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECC@NKGEML512-MBS.china.huawei.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> In-Reply-To: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECCNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson Subject: [mpls] =?gb2312?b?tPC4tDogIGRyYWZ0LWlldGYtbXBscy1zcGVjaWFsLXB1?= =?gb2312?b?cnBvc2UtbGFiZWxzLTAx?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 01:19:38 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECCNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIGxhYmVsIDcgYWZ0ZXIgbGFiZWwgMTUgY2FuJ3QgYmUgdXNlZCBmb3Igb3RoZXIgcHVycG9z ZSB0aGFuIEVMSS4gT3RoZXJ3aXNlLCBpdCBtYXkgYmUgY29uZnVzZWQgdG8gc29tZSBlYXJseSBp bXBsZW1lbnRhdGlvbnMgb2YgdGhlIGVudHJvcHkgbGFiZWwgd2hpY2ggbWF5IGp1c3Qgc2VhcmNo IGxhYmVsIDcgaW4gdGhlIGxhYmVsIHN0YWNrIHdpdGhvdXQgd29ycnlpbmcgYWJvdXQgd2hldGhl ciB0aGUgbGFiZWwgYmVmb3JlIGxhYmVsIDcgaXMgbGFiZWwgMTUNCg0KSGVuY2UsIGVpdGhlciBy ZXNlcnZpbmcgdGhlIGxhYmVsIDcgYWZ0ZXIgbGFiZWwgMTUgd2hpbGUgcmVsYXhpbmcgdGhlIHJl c3RyaWN0aW9uIG9uIHRyYW5zaXQgTFNScyAoYXMgc3VnZ2VzdGVkIGJ5IEtpcmVldGkpIG9yIGRl ZmluaW5nIHRoZSBsYWJlbCA3IGFmdGVyIDE1IGFzIGFuIEVMSSBhcyB3ZWxsIGlzIGZpbmUsIElN Ty4NCg0KDQoNCkJlc3QgcmVnYXJkcw0KDQpYaWFvaHUNCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS2lyZWV0aSBLb21w ZWxsYQ0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjnI1SAxMzo1MQ0KytW8/sjLOiBMaXpob25nIEppbg0K s63LzTogUm9zcyBDYWxsb247IG1wbHNAaWV0Zi5vcmc7IExvYSBBbmRlcnNzb24NCtb3zOI6IFJl OiBbbXBsc10gZHJhZnQtaWV0Zi1tcGxzLXNwZWNpYWwtcHVycG9zZS1sYWJlbHMtMDENCg0KSGkg TGl6aG9uZywNCg0KSW4gdGhlIGZhc3QgcGF0aCBpbiBhIHRyYW5zaXQgTFNSLCB3b3VsZCB5b3Ug cHJlZmVyOg0KYSkgbG9vayBmb3IgbGFiZWwgNzsgdGhlbiB1c2UgdGhlIGxhYmVsIGFmdGVyIGl0 IGFzIHRoZSBlbnRyb3B5IGxhYmVsOyBPUg0KYikgbG9vayBmb3IgYSB0d28gbGFiZWwgY29tYmlu YXRpb24gb2YgPG5vdCBsYWJlbCAxNSwgbGFiZWwgNz4sIHRoZW4gdXNlIHRoZSBsYWJlbCBhZnRl ciBpdCBhcyB0aGUgZW50cm9weSBsYWJlbD8NCg0KTGV0IG1lIGV4cGxhaW4gKGIpLiAgSWYgd2Ug YXJlIHN0cmljdCBhYm91dCBoYXZpbmcgb25seSBvbmUgZW50cm9weSBsYWJlbCBwb3NzaWJpbGl0 eSwgdGhlbiBhbiBpbXBsZW1lbnRhdGlvbiBfc2hvdWxkXyBsb29rIGZvciBhIGxhYmVsIHNlcXVl bmNlIG9mOg0KPCChrSAhMTUgNyBFTCChrSA+IHRvIHRydWx5IGlkZW50aWZ5IGFuIGVudHJvcHkg bGFiZWwuLCBzaW5jZSA8IKGtIDE1IDcgTCChrSA+IGlzIGlsbGVnYWwsIGFuZCBkb2VzIG5vdCBp ZGVudGlmeSBMIGFzIGFuIGVudHJvcHkgbGFiZWwuICAoSWdub3JlIHRoZSBzcGVjaWFsIGNhc2Ug dGhhdCB0aGUgZmlyc3QgbGFiZWwgaXMgNy4pDQoNCkluIG90aGVyIHdvcmRzLCBpZiB3ZSBzYXkg Ik1VU1QgTk9UIHVzZSBsYWJlbCA3IGFzIGFuIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZSBsYWJl bCIsIHRoZW4gaW4gcHJpbmNpcGxlLCAoYikgaXMgbmVlZGVkLg0KDQpJZiB3ZSBhcmUgbG9vc2Us IHRoZW4gYW4gaW1wbGVtZW50YXRpb24gY2FuIHNpbXBseSBsb29rIGZvciA8IKGtIDcgRUwgoa0g PiB3aXRob3V0IHdvcnJ5aW5nIGFib3V0IHdoZXRoZXIgdGhlIGxhYmVsIGJlZm9yZSA3IGlzIDE1 LiAgT2YgY291cnNlLCB0aGlzIG1lYW5zIHRoYXQgTFNScyBpbnNlcnRpbmcgYW4gZW50cm9weSBs YWJlbCBoYXZlIHR3byBjaG9pY2VzLCBidXQgdGhleSBjYW4gY2hvb3NlIGp1c3QgdG8gdXNlIG9u ZS4gIFNlbmRlcnMgaGF2ZSBhbiBlYXN5IHRpbWU7IEkgd2FudCB0cmFuc2l0IExTUnMgdG8gaGF2 ZSBhbiBlYXN5IHRpbWUgYXMgd2VsbC4gIE9mIGNvdXJzZSwgcmVjZWl2ZXJzIHdpbGwgaGF2ZSB0 byBwYXJzZSBib3RoIHBvc3NpYmlsaXRpZXMuICBJIGNhbiBhZGQ6ICJSZWNlaXZlcnMgcHJvY2Vz c2luZyBsYWJlbCA3IGFmdGVyIGFuIGV4dGVuc2lvbiBsYWJlbCBNQVkgZHJvcCB0aGUgcGFja2V0 IiB0byByZS1lbXBoYXNpemUgdGhlICJTSE9VTEQgTk9UIiwgYnV0IHRoYXQgc2VlbXMgbGlrZSBh biBvdmVya2lsbC4NCg0KRG9lcyB0aGF0IG1ha2Ugc2Vuc2U/ICAoUXVlc3Rpb24gdG8gV0cgYXQg bGFyZ2UgYXMgd2VsbC4pDQoNCg0KDQpLaXJlZXRpLg0KDQpPbiBKdWwgOCwgMjAxMywgYXQgMDY6 NTYgLCBMaXpob25nIEppbiA8bGl6aG8uamluQGdtYWlsLmNvbTxtYWlsdG86bGl6aG8uamluQGdt YWlsLmNvbT4+IHdyb3RlOg0KDQoNCkhpIEtpcmVldGksDQpJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0 YW5kIHdoeSBoYXZpbmcgdHdvIGVudHJvcHkgbGFiZWwgcG9zc2liaWxpdGllcyB3b3VsZCBzaW1w bGlmeSB0aGUgcGFyc2luZy4gRnJvbSBteSBrbm93bGVkZ2Ugb2YgdGhlIHN3aXRjaGluZyBhc2lj LCB0aGUgYXNpYyB3b3VsZCBhbHdheXMgcGFyc2UgYWxsIHRoZSBNUExTIGxhYmVscywgYW5kIGNo ZWNrIGVhY2ggTVBMUyByZXNlcnZlIGxhYmVsIGJ5IGluZGV4aW5nIChub3QgaGFzaGluZykgdG8g YSBjb250ZW50IHJlZ2lzdGVyIHdoaWNoIGluZGljYXRlcyB0aGUgZW50cm9weSBsYWJlbCBwcm9w ZXJ0eS4gSWYgd2UgaGF2ZSB0d28gcG9zc2liaWxpdGllcyBmb3IgZW50cm9weSBsYWJlbCwgdGhl biB3ZSBoYXZlIHRvIHVzZSB0d28gcmVnaXN0ZXJzIGluIGhhcmR3YXJlIGZvciB0aGUgc2FtZSBw dXJwb3NlLiBJIGRvIG5vdCBzZWUgdGhlIGJlbmVmaXQgeWV0LiBDb3VsZCB5b3UgcGxlYXNlIGlu ZGljYXRlIGEgYml0Pw0KDQpSZWdhcmRzDQpMaXpob25nDQoNCg0KDQoNCk1lc3NhZ2U6IDINCkRh dGU6IFN1biwgNyBKdWwgMjAxMyAxMTo1MToyOCAtMDcwMA0KRnJvbTogS2lyZWV0aSBLb21wZWxs YSA8a2lyZWV0aS5rb21wZWxsYUBnbWFpbC5jb208bWFpbHRvOmtpcmVldGkua29tcGVsbGFAZ21h aWwuY29tPj4NClRvOiBNUExTIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4N CkNjOiBSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBqdW5p cGVyLm5ldD4+LCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+DQpT dWJqZWN0OiBbbXBsc10gZHJhZnQtaWV0Zi1tcGxzLXNwZWNpYWwtcHVycG9zZS1sYWJlbHMtMDEN Ck1lc3NhZ2UtSUQ6IDw3NENDNTU4MC03QUU2LTQ3MzktQTMwQi04MzhCQjA4RjJGMjFAZ21haWwu Y29tPG1haWx0bzo3NENDNTU4MC03QUU2LTQ3MzktQTMwQi04MzhCQjA4RjJGMjFAZ21haWwuY29t Pj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQoNCkhpIEFs bCwNCg0KSSBoYXZlIHVwZGF0ZWQgdGhpcyBkb2N1bWVudCB3aXRoIHRoZSBmb2xsb3dpbmc6DQph KSB0aGUgcmFuZ2Ugb2YgU3RhbmRhcmRzIEFjdGlvbiBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2Ug bGFiZWxzIGlzIDE2LTIzOTsgZXhwZXJpbWVudGFsIGlzIDI0MC0yNTUuICBUaGUgcmVzdCBhcmUg cmVzZXJ2ZWQgZm9yIG5vdy4NCmIpIEkndmUgYWRkZWQgYSBxdWVzdGlvbi9hbnN3ZXIgb24gd2hl dGhlciB0byB1c2UgZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlIGxhYmVscyBpbiBsb2FkIGJhbGFu Y2luZyAtLSBzYXlpbmcgTVVTVCBOT1QuDQpjKSBDbGFyaWZpZWQgdGV4dCByZWdhcmRpbmcgYSBs YWJlbCBmb2xsb3dpbmcgYW4gZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlIChYdXhpYW9odSdzIGNv bW1lbnQpLg0KDQpGaW5hbGx5LCBJIG5vdGUgTGl6aG9uZydzIGNvbW1lbnQgcmVnYXJkaW5nIGxh YmVsIDcuICBUaGUgZ29hbCBpbiBhbGxvd2luZyBsYWJlbCA3IGFzIGVpdGhlciBhIHJlZ3VsYXIg c3BlY2lhbCBwdXJwb3NlIGxhYmVsIG9yIGFuIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZSBsYWJl bCBpcyB0byBzaW1wbGlmeSBwYXJzaW5nIHdoZW4gc2VhcmNoaW5nIGZvciBhbiBlbnRyb3B5IGxh YmVsLiAgSSBhZGRlZCB0ZXh0IGFyb3VuZCB0aGlzLCBidXQgZGlkIG5vdCBjaGFuZ2UgU0hPVUxE IE5PVCB0byBNVVNUIE5PVC4NCg0KV0cgY2hhaXJzLCBJIGJlbGlldmUgdGhpcyBkb2MgaXMgcmVh ZHkgZm9yIFdHIExDLg0KDQpLaXJlZXRpLg0KLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0t LS0tLS0tLS0tDQpBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uDQpVUkw6IDxodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9hdHRhY2htZW50cy8yMDEzMDcw Ny9hMTAwZDdkNC9hdHRhY2htZW50Lmh0bT4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt cGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCkVuZCBvZiBtcGxz IERpZ2VzdCwgVm9sIDExMSwgSXNzdWUgMTMNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCg0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECCNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The label 7 after label 15 c= an't be used for other purpose than ELI. Otherwise, it may be confused to s= ome early implementations of the entropy label which may just search label = 7 in the label stack without worrying about whether the label before label 7 is label 15

Hence, either reserving the = label 7 after label 15 while relaxing the restriction on transit LSRs (as su= ggested by Kireeti) or defining the label 7 after 15 as an ELI as well is f= ine, IMO.

 

Best regards

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bo= unces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA= =B1=ED Kireeti Kompella
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C29=C8=D5 13:51
=CA=D5=BC=FE=C8=CB: Lizhong Jin
=B3=AD=CB=CD: Ross Callon; mpls@ietf.org; Loa Andersson
=D6=F7=CC=E2: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01

 

Hi Lizhong,

 

In the fast path in a transit L= SR, would you prefer:

a) look for label 7; then use t= he label after it as the entropy label; OR

b) look for a two label combina= tion of <not label 15, label 7>, then use the label after it as the e= ntropy label?

 

Let me explain (b).  If we= are strict about having only one entropy label possibility, then an implem= entation _should_ look for a label sequence of:

< =A1=AD !15 7 EL =A1=AD >= ; to truly identify an entropy label., since < =A1=AD 15 7 L =A1=AD >= is illegal, and does not identify L as an entropy label.  (Ignore the= special case that the first label is 7.)

 

In other words, if we say "= ;MUST NOT use label 7 as an extended special purpose label", then in p= rinciple, (b) is needed.

 

If we are loose, then an implem= entation can simply look for < =A1=AD 7 EL =A1=AD > without= worrying about whether the label before 7 is 15.  Of course, this mea= ns that LSRs inserting an entropy label have two choices, but they can choose just to use one.  Senders have an easy time; I want transi= t LSRs to have an easy time as well.  Of course, receivers will have t= o parse both possibilities.  I can add: "Receivers processing lab= el 7 after an extension label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that seems like an overkill.<= o:p>

 

Does that make sense?  (Qu= estion to WG at large as well.)

 = ;

 = ;

 

Kireeti.

 

On Jul 8, 2013, at 06:56 , Lizh= ong Jin <lizho.jin@gmail.com&= gt; wrote:



Hi Kireeti,

I do not quite understand why h= aving two entropy label possibilities would simplify the parsing. From my k= nowledge of the switching asic, the asic would always parse all the MPLS la= bels, and check each MPLS reserve label by indexing (not hashing) to a content register which indicates the entrop= y label property. If we have two possibilities for entropy label, then we h= ave to use two registers in hardware for the same purpose. I do not see the= benefit yet. Could you please indicate a bit?

 

Regards

Lizhong

 

 

 


Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <ki= reeti.kompella@gmail.com>
To: MPLS <mpls@ietf.org>
Cc: Ross Callon <rcallon@juniper.= net>, Loa Andersson <loa@pi.nu&g= t;
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255.  The rest are reserved for now.
b) I've added a question/answer on whether to use extended special purpose = labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7.  The goal in allo= wing label 7 as either a regular special purpose label or an extended speci= al purpose label is to simplify parsing when searching for an entropy label= .  I added text around this, but did not change SHOULD NOT to MUST NOT.

WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>

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

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


End of mpls Digest, Vol 111, Issue 13
*************************************

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECCNKGEML512MBSchi_-- From xuxiaohu@huawei.com Thu Jul 11 19:52:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E021F9E80 for ; Thu, 11 Jul 2013 19:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-3.054, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZzu4EtOz+Ma for ; Thu, 11 Jul 2013 19:52:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8FE21F9EE3 for ; Thu, 11 Jul 2013 19:52:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY07393; Fri, 12 Jul 2013 02:52:28 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 03:51:40 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 03:52:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 10:52:15 +0800 From: Xuxiaohu To: Alia Atlas , "curtis@ipv6.occnc.com" , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs Thread-Topic: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQI1v7AdXBiEf1kGpZztZc1tuJpldHnDggAOlvMA= Date: Fri, 12 Jul 2013 02:52:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDF14@NKGEML512-MBS.china.huawei.com> References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] =?gb2312?b?tPC4tDogIGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVz?= =?gb2312?b?cy1wYXRoLTAyICh3YXMgTVBMUy1SVCByZXZpZXcgb2YJLi4uKQ==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 02:52:39 -0000 SGkgQWxpYSwNCg0KTGV0IG1lIGdpdmUgYW4gZXhhbXBsZSBhcyBpbGx1c3RyYXRlZCBiZWxvdzoN Cg0KQS0tLS0tLS0tKE1ldHJpYzoxOyBEZWxheToxKS0tLS0tLS1CLS0tKE1ldHJpYzoxOyBEZWxh eToxMCktLS1ELS0tLS0tLS0tLS1GDQp8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgIC8gfA0KfCAgICAgICAgICAgICAgICAgICAgICAgICstLS0oTWV0 cmljOjI7IERlbGF5OjEwKS0tLUUtLS0tLS0tLS8gIHwNCnwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCistLS0tLS0tKE1ldHJpYzoxMDsgRGVs YXk6MSktLS0tLS1DLS0tLS0tLS0oTWV0cmljOjE7IERlbGF5IDEpLS0tLS0tLS0tLS0tLS0rDQoN CkFzc3VtZSBBIHdhbnRzIHRvIGZpbmQgYW4gb3B0aW1hbCBwYXRoIHRvIEYgd2l0aCBkZWxheSB1 cHBlciBib3VuZCBvZiAxMC4gSW4gc3RlcCAxLCBBIHNlbGVjdHMgQiBhbW9uZyBhbGwgb2YgaXRz IGFkamFjZW50IHJvdXRlcnMgYXMgdGhlIG5leHRfcm91dGVyIHNpbmNlIGl0cyBkaXN0YW5jZSB0 byBvdGhlciBhZGphY2VudCByb3V0ZXJzIChpLmUuLCBDKSBpcyBsYXJnZXIgdGhhbiB0aGF0IHRv IEIuIGluIHN0ZXAgMiwgQiBmaW5kcyB0aGF0IG5laXRoZXIgb2YgaXRzIGFkamFjZW50IHJvdXRl cnMgKGkuZS4sIEQgYW5kIEUpIGNvdWxkIGJlIHNlbGVjdGVkIGFzIG5leHRfcm91dGVyIHNpbmNl IHRoZSBsYXRlbmN5IG9mIHRoZSBlaXRoZXIgcGF0aCAoaS5lLiwgQS0+Qi0+RCBhbmQgQS0+Qi0+ RSkgaXMgYWxyZWFkeSBiZXlvbmQgdGhlIGUyZSBkZWxheSBib3VuZC4gQXQgYSByZXN1bHQsIGlu IHN0ZXAgMywgQSBoYXMgdG8gZ2l2ZSB1cCBCIGFuZCB0aGVuIGV4cGxvcmUgaXRzIG90aGVyIGFk amFjZW50IHJvdXRlcnMuIElzIHRoYXQgdGhlIGhldXJpc3RpYyBhbGdvcml0aG0geW91IG1lYW50 PyBJZiBzbywgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2NyaWJlIHRoZSBzdGVwIDMgKGkuZS4s IGEgcmV0cmVhdCBzdGVwKSBhcyB3ZWxsIGluIHlvdXIgcHNldWRvLWNvZGUgd2hpbGUgbWVudGlv bmluZyB0aGF0IHJldHJlYXQgc3RlcCBtYXkgYmUgcGVyZm9ybWVkIG11bHRpcGxlIHRpbWVzIGJh Y2sgYW5kIGZvcnRoLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCiAgIA0KPiAtLS0tLdPKvP7U rbz+LS0tLS0NCj4gt6K8/sjLOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BqdW5pcGVyLm5l dF0NCj4gt6LLzcqxvOQ6IDIwMTPE6jfUwjEwyNUgMjoxMw0KPiDK1bz+yMs6IFh1eGlhb2h1OyBj dXJ0aXNAaXB2Ni5vY2NuYy5jb207IE1QTFMgV0cgTWFpbGluZyBMaXN0Ow0KPiBkcmFmdC1hdGxh cy1tcGxzLXRlLWV4cHJlc3MtcGF0aCBhdXRob3JzOyBUaGUgR3JlYXQgYW5kIE1pZ2h0eSBNUExT DQo+IENvLUNoYWlycw0KPiDW98ziOiBSRTogW21wbHNdIGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhw cmVzcy1wYXRoLTAyICh3YXMgTVBMUy1SVCByZXZpZXcNCj4gb2YgLi4uKQ0KPiANCj4gQ2FuIHlv dSBjbGFyaWZ5IHdoeSB5b3UgdGhpbmsgY29uc3RyYWluaW5nIHRoZSBsaW5rcyBleHBsb3JlZCBi YXNlZCB1cG9uIGENCj4gbGF0ZW5jeSBpc24ndCBhIHByYWN0aWNhbCBhcHByb2FjaD8gIEl0IGlz IHN0aWxsIE8obiBsb2cgbikgLSBncmFudGVkLCBpdCdzIGEgaGV1cmlzdGljDQo+IGFuZCBtYXkg bm90IGZpbmQgYSBwYXRoLg0KPiANCj4gQWxpYQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBT ZW50OiBUdWVzZGF5LCBBcHJpbCAyMywgMjAxMyA5OjQ0IFBNDQo+IFRvOiBjdXJ0aXNAaXB2Ni5v Y2NuYy5jb207IE1QTFMgV0cgTWFpbGluZyBMaXN0Ow0KPiBkcmFmdC1hdGxhcy1tcGxzLXRlLWV4 cHJlc3MtcGF0aCBhdXRob3JzOyBUaGUgR3JlYXQgYW5kIE1pZ2h0eSBNUExTDQo+IENvLUNoYWly cw0KPiBTdWJqZWN0OiByZTogW21wbHNdIGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRo LTAyICh3YXMgTVBMUy1SVCByZXZpZXcNCj4gb2YgLi4uKQ0KPiANCj4gPiAgICAgcy9XaGlsZSBp dCBoYXMgYmVlbiBwb3NzaWJsZSB0byBjb21wdXRlIGEgQ1NQRi9JdCBpcyBwb3NzaWJsZSB0bw0K PiA+ICAgICBjb21wdXRlIGEgQ1NQRi8NCj4gPiAgICAgcy9JbnN0ZWFkIG9mIHRoaXMgYXBwcm9h Y2ggdG8gbWluaW1pemUgcGF0aCBsYXRlbmN5LCBhbi9Bbg0KPiA+ICAgICBhbHRlcm5hdGl2ZSB0 byB0aGlzIGFwcHJvYWNoIHRvIG1pbmltaXplIHBhdGggbGF0ZW5jeSBpcyBhbg0KPiA+ICAgICBh cHByb2FjaCB0byBwbGFjZSBhIHVwcGVyIGJvdW5kIG9uIHBhdGggbGF0ZW5jeS4gIEFuLw0KPiA+ ICAgICBOb3RlOiBib3RoIGFwcHJvYWNoZXMgYXJlIHZhbGlkLg0KPiANCj4gSSB0aGluayB0aGUg YWx0ZXJuYXRpdmUgYXBwcm9hY2ggKGkuZS4sIHRvIGNvbXB1dGUgYSBDU1BGIHBhdGggYmFzZWQg b24gdGhlIFRFDQo+IG1ldHJpYyB3aGlsZSBwbGFjaW5nIGEgdXBwZXIgYm91bmQgb24gdGhlIHBh dGggbGF0ZW5jeSkgaXMgbm90IGEgcHJhY3RpY2FsDQo+IGFwcHJvYWNoIGR1ZSB0byBjb21wdXRh dGlvbmFsbHkgY29tcGxleGl0eS4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0K PiANCg0K From akatlas@juniper.net Thu Jul 11 22:05:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56021F9EE9 for ; Thu, 11 Jul 2013 22:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.699 X-Spam-Level: *** X-Spam-Status: No, score=3.699 tagged_above=-999 required=5 tests=[AWL=-3.617, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IThR7QEYgHWq for ; Thu, 11 Jul 2013 22:05:37 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2FB21F9EE3 for ; Thu, 11 Jul 2013 22:05:37 -0700 (PDT) Received: from mail19-co1-R.bigfish.com (10.243.78.233) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 05:05:36 +0000 Received: from mail19-co1 (localhost [127.0.0.1]) by mail19-co1-R.bigfish.com (Postfix) with ESMTP id 794C97C0862 for ; Fri, 12 Jul 2013 05:05:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz9371Ic89bh542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail19-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=akatlas@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail19-co1 (localhost.localdomain [127.0.0.1]) by mail19-co1 (MessageSwitch) id 1373605534591165_10191; Fri, 12 Jul 2013 05:05:34 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.246]) by mail19-co1.bigfish.com (Postfix) with ESMTP id 840B5680054 for ; Fri, 12 Jul 2013 05:05:34 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Jul 2013 05:05:34 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Jul 2013 22:05:33 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Jul 2013 22:05:33 -0700 Received: from CO9EHSOBE028.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Jul 2013 22:18:13 -0700 Received: from mail35-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 05:05:32 +0000 Received: from mail35-co9 (localhost [127.0.0.1]) by mail35-co9-R.bigfish.com (Postfix) with ESMTP id 174A44E0B2A for ; Fri, 12 Jul 2013 05:05:32 +0000 (UTC) Received: from mail35-co9 (localhost.localdomain [127.0.0.1]) by mail35-co9 (MessageSwitch) id 1373605530792638_28466; Fri, 12 Jul 2013 05:05:30 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.247]) by mail35-co9.bigfish.com (Postfix) with ESMTP id BD91F320084; Fri, 12 Jul 2013 05:05:30 +0000 (UTC) Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (157.56.236.101) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Jul 2013 05:05:19 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.99]) by BY2PRD0510HT002.namprd05.prod.outlook.com ([10.255.84.37]) with mapi id 14.16.0324.000; Fri, 12 Jul 2013 05:05:18 +0000 From: Alia Atlas To: Xuxiaohu , "curtis@ipv6.occnc.com" , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs Thread-Topic: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQI1v7AdXBiEf1kGpZztZc1tuJpldHnDggAOlvMCAADN/8A== Date: Fri, 12 Jul 2013 05:05:18 +0000 Message-ID: References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDF14@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDF14@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IPV6.OCCNC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 05:05:44 -0000 SGkgWGlhb2h1LA0KDQpObywgdGhlcmUgaXMgbm8gcmV0cmVhdGluZy4gIEkgdGhpbmsgeW91J3Jl IGRlc2NyaWJpbmcgc29tZXRoaW5nIGJhc2VkIG9uIGEgZGVwdGgtZmlyc3Qtc2VhcmNoIHRoYXQn cyBjb3N0IGF3YXJlPz8/IEkgZG9uJ3Qga25vdyBidXQgaXQncyBub3QgYmFzZWQgb24gYSBub3Jt YWwgU1BGLiAgVGhlIHBzZXVkby1jb2RlIEkgZ2F2ZSBpcyBjb3JyZWN0LiAgDQoNCkhlcmUncyB0 aGUgYnJpZWYgZXhhbXBsZSAtICBJIG1lYW4gYW4gU1BGIHdoZXJlIGxpbmtzIGFyZW4ndCBleHBs b3JlZCBpZiB0aGV5IHJlc3VsdCBpbiBhIHBhdGggdGhhdCBpcyB0b28gbG9uZy4NCg0KU3RlcCAx IENTUEY6ICAgQSBoYXMgY29zdCAwLCBkZWxheSAwICAgLSBleHBsb3JlIEEncyBsaW5rcw0KICAg ICAgICAgIEIuY29zdCA9IDEgIEIuZGVsYXk9IDEgIGluc2VydCBCIGludG8gdGhlIGZpYmhlYXAg b3JkZXJlZCBieSBjb3N0DQogICAgICAgICAgQy5jb3N0ID0gMTAgIEMuZGVsYXkgPSAxICAgaW5z ZXJ0IEMgaW50byB0aGUgZmliaGVhcCBvcmRlcmVkIGJ5IGNvc3QNCg0KU3RlcCAyIENTUEY6ICBy ZW1vdmUgZmlyc3Qgbm9kZSBmcm9tIGZpYmhlYXAgLSBpdCBpcyBCICAtIGV4cGxvcmUgQidzIGxp bmtzDQogICAgICAgICAgVmlhIEItPkQgd291bGQgZ2l2ZSBELmRlbGF5IHRvIGJlIDExIC0gb3Zl ciBib3VuZCBzbyBkb24ndCBzYXZlIA0KICAgICAgICAgIFZpYSBCLT5FIHdvdWxkIGdpdmUgRS5k ZWxheSB0byBiZSAxMSAtIG92ZXIgYm91bmQgc28gZG9uJ3Qgc2F2ZQ0KDQpTdGVwIDMgQ1NQRjog cmVtb3ZlIGZpcnN0IG5vZGUgZnJvbSBmaWJoZWFwICAtIGl0IGlzIEMgLSBleHBsb3JlIEMncyBs aW5rcw0KICAgICAgICAgICAgVmlhIEMtPkYgd291bGQgZ2l2ZSBGLmRlbGF5PTIgLXVuZGVyIGJv dW5kIHNvIHNhdmUNCiAgICAgICAgICAgICAgICAgRi5jb3N0ID0gMTEgICBGLmRlbGF5ID0gMiAg aW5zZXJ0IEYgaW50byBmaWJoZWFwDQoNClN0ZXAgNCBDU1BGOiAgcmVtb3ZlIGZpcnN0IG5vZGUg ZnJvbSBmaWJoZWFwIC0gaXQgaXMgRg0KICAgICAgICAgQ1NQRiB3YXMgZnJvbSBBIHRvIEYgYW5k IEYgaXMgbm93IG1pbmltaXplZCBzbyB0ZXJtaW5hdGUuDQoNCkFsaWEgICAgICAgICAgICAgICAg ICAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBYdXhpYW9odSBbbWFpbHRv Onh1eGlhb2h1QGh1YXdlaS5jb21dIA0KU2VudDogVGh1cnNkYXksIEp1bHkgMTEsIDIwMTMgMTA6 NTIgUE0NClRvOiBBbGlhIEF0bGFzOyBjdXJ0aXNAaXB2Ni5vY2NuYy5jb207IE1QTFMgV0cgTWFp bGluZyBMaXN0OyBkcmFmdC1hdGxhcy1tcGxzLXRlLWV4cHJlc3MtcGF0aCBhdXRob3JzOyBUaGUg R3JlYXQgYW5kIE1pZ2h0eSBNUExTIENvLUNoYWlycw0KU3ViamVjdDogtPC4tDogW21wbHNdIGRy YWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoLTAyICh3YXMgTVBMUy1SVCByZXZpZXcgb2Yg Li4uKQ0KDQpIaSBBbGlhLA0KDQpMZXQgbWUgZ2l2ZSBhbiBleGFtcGxlIGFzIGlsbHVzdHJhdGVk IGJlbG93Og0KDQpBLS0tLS0tLS0oTWV0cmljOjE7IERlbGF5OjEpLS0tLS0tLUItLS0oTWV0cmlj OjE7IERlbGF5OjEwKS0tLUQtLS0tLS0tLS0tLUYNCnwgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgLyB8DQp8ICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLShNZXRyaWM6MjsgRGVsYXk6MTApLS0tRS0tLS0tLS0tLyAgfA0KfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKy0tLS0tLS0oTWV0cmlj OjEwOyBEZWxheToxKS0tLS0tLUMtLS0tLS0tLShNZXRyaWM6MTsgRGVsYXkgDQorMSktLS0tLS0t LS0tLS0tLSsNCg0KQXNzdW1lIEEgd2FudHMgdG8gZmluZCBhbiBvcHRpbWFsIHBhdGggdG8gRiB3 aXRoIGRlbGF5IHVwcGVyIGJvdW5kIG9mIDEwLiBJbiBzdGVwIDEsIEEgc2VsZWN0cyBCIGFtb25n IGFsbCBvZiBpdHMgYWRqYWNlbnQgcm91dGVycyBhcyB0aGUgbmV4dF9yb3V0ZXIgc2luY2UgaXRz IGRpc3RhbmNlIHRvIG90aGVyIGFkamFjZW50IHJvdXRlcnMgKGkuZS4sIEMpIGlzIGxhcmdlciB0 aGFuIHRoYXQgdG8gQi4gaW4gc3RlcCAyLCBCIGZpbmRzIHRoYXQgbmVpdGhlciBvZiBpdHMgYWRq YWNlbnQgcm91dGVycyAoaS5lLiwgRCBhbmQgRSkgY291bGQgYmUgc2VsZWN0ZWQgYXMgbmV4dF9y b3V0ZXIgc2luY2UgdGhlIGxhdGVuY3kgb2YgdGhlIGVpdGhlciBwYXRoIChpLmUuLCBBLT5CLT5E IGFuZCBBLT5CLT5FKSBpcyBhbHJlYWR5IGJleW9uZCB0aGUgZTJlIGRlbGF5IGJvdW5kLiBBdCBh IHJlc3VsdCwgaW4gc3RlcCAzLCBBIGhhcyB0byBnaXZlIHVwIEIgYW5kIHRoZW4gZXhwbG9yZSBp dHMgb3RoZXIgYWRqYWNlbnQgcm91dGVycy4gSXMgdGhhdCB0aGUgaGV1cmlzdGljIGFsZ29yaXRo bSB5b3UgbWVhbnQ/IElmIHNvLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIHN0 ZXAgMyAoaS5lLiwgYSByZXRyZWF0IHN0ZXApIGFzIHdlbGwgaW4geW91ciBwc2V1ZG8tY29kZSB3 aGlsZSBtZW50aW9uaW5nIHRoYXQgcmV0cmVhdCBzdGVwIG1heSBiZSBwZXJmb3JtZWQgbXVsdGlw bGUgdGltZXMgYmFjayBhbmQgZm9ydGguDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KICAgDQo+ IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFz QGp1bmlwZXIubmV0XQ0KPiC3osvNyrG85DogMjAxM8TqN9TCMTDI1SAyOjEzDQo+IMrVvP7Iyzog WHV4aWFvaHU7IGN1cnRpc0BpcHY2Lm9jY25jLmNvbTsgTVBMUyBXRyBNYWlsaW5nIExpc3Q7IA0K PiBkcmFmdC1hdGxhcy1tcGxzLXRlLWV4cHJlc3MtcGF0aCBhdXRob3JzOyBUaGUgR3JlYXQgYW5k IE1pZ2h0eSBNUExTIA0KPiBDby1DaGFpcnMNCj4g1vfM4jogUkU6IFttcGxzXSBkcmFmdC1hdGxh cy1tcGxzLXRlLWV4cHJlc3MtcGF0aC0wMiAod2FzIE1QTFMtUlQgcmV2aWV3IA0KPiBvZiAuLi4p DQo+IA0KPiBDYW4geW91IGNsYXJpZnkgd2h5IHlvdSB0aGluayBjb25zdHJhaW5pbmcgdGhlIGxp bmtzIGV4cGxvcmVkIGJhc2VkIA0KPiB1cG9uIGEgbGF0ZW5jeSBpc24ndCBhIHByYWN0aWNhbCBh cHByb2FjaD8gIEl0IGlzIHN0aWxsIE8obiBsb2cgbikgLSANCj4gZ3JhbnRlZCwgaXQncyBhIGhl dXJpc3RpYyBhbmQgbWF5IG5vdCBmaW5kIGEgcGF0aC4NCj4gDQo+IEFsaWENCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVA aHVhd2VpLmNvbV0NCj4gU2VudDogVHVlc2RheSwgQXByaWwgMjMsIDIwMTMgOTo0NCBQTQ0KPiBU bzogY3VydGlzQGlwdjYub2NjbmMuY29tOyBNUExTIFdHIE1haWxpbmcgTGlzdDsgDQo+IGRyYWZ0 LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoIGF1dGhvcnM7IFRoZSBHcmVhdCBhbmQgTWlnaHR5 IE1QTFMgDQo+IENvLUNoYWlycw0KPiBTdWJqZWN0OiByZTogW21wbHNdIGRyYWZ0LWF0bGFzLW1w bHMtdGUtZXhwcmVzcy1wYXRoLTAyICh3YXMgTVBMUy1SVCANCj4gcmV2aWV3IG9mIC4uLikNCj4g DQo+ID4gICAgIHMvV2hpbGUgaXQgaGFzIGJlZW4gcG9zc2libGUgdG8gY29tcHV0ZSBhIENTUEYv SXQgaXMgcG9zc2libGUgdG8NCj4gPiAgICAgY29tcHV0ZSBhIENTUEYvDQo+ID4gICAgIHMvSW5z dGVhZCBvZiB0aGlzIGFwcHJvYWNoIHRvIG1pbmltaXplIHBhdGggbGF0ZW5jeSwgYW4vQW4NCj4g PiAgICAgYWx0ZXJuYXRpdmUgdG8gdGhpcyBhcHByb2FjaCB0byBtaW5pbWl6ZSBwYXRoIGxhdGVu Y3kgaXMgYW4NCj4gPiAgICAgYXBwcm9hY2ggdG8gcGxhY2UgYSB1cHBlciBib3VuZCBvbiBwYXRo IGxhdGVuY3kuICBBbi8NCj4gPiAgICAgTm90ZTogYm90aCBhcHByb2FjaGVzIGFyZSB2YWxpZC4N Cj4gDQo+IEkgdGhpbmsgdGhlIGFsdGVybmF0aXZlIGFwcHJvYWNoIChpLmUuLCB0byBjb21wdXRl IGEgQ1NQRiBwYXRoIGJhc2VkIA0KPiBvbiB0aGUgVEUgbWV0cmljIHdoaWxlIHBsYWNpbmcgYSB1 cHBlciBib3VuZCBvbiB0aGUgcGF0aCBsYXRlbmN5KSBpcyANCj4gbm90IGEgcHJhY3RpY2FsIGFw cHJvYWNoIGR1ZSB0byBjb21wdXRhdGlvbmFsbHkgY29tcGxleGl0eS4NCj4gDQo+IEJlc3QgcmVn YXJkcywNCj4gWGlhb2h1DQo+IA0KPiANCg0K From akatlas@gmail.com Thu Jul 11 23:27:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696DC11E8202 for ; Thu, 11 Jul 2013 23:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=-2.116, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgGoWQ++3nwS for ; Thu, 11 Jul 2013 23:27:24 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9811E8141 for ; Thu, 11 Jul 2013 23:27:23 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a11so12297753iee.6 for ; Thu, 11 Jul 2013 23:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DJNH1f8ZYZWD8z9aat3LdaTq3UjaF3CGW8/Yz3RL/I4=; b=HAL+Ad8DgK3wis8md2mKYLpSVB+AxOrxhBwuZEaxM34/kzGOjrjjuOD9rmw0vdVS/y DZCsEsc1DSbA1/a6aln1ReFGdYIFtOqe2Xb3RP0NNsCHwX9kYezCIxl9Vwv6pH3mpVT+ r8QcoX4CvKAy9VfGGubIb74NyIATZ62dnc9Mf63o4khTBYYgR1Zri2T5D0RoBP3okZvs EBFa+Brq8UPM23cKb4O51DvaXcj5J93E2ZvPASFUQw0LrReix8KJgPfcooZROrEJ+O97 469M+8hZ0iKZYgxWF9T3/3YCCe7x3GlZHs7UhJR7GpkdMGqC1mKQyBOYZBBPdPSC15mP M4ZA== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr12275835icb.2.1373610437800; Thu, 11 Jul 2013 23:27:17 -0700 (PDT) Received: by 10.64.165.197 with HTTP; Thu, 11 Jul 2013 23:27:17 -0700 (PDT) In-Reply-To: <201307111938.r6BJcKlG089921@gateway1.orleans.occnc.com> References: <201307111938.r6BJcKlG089921@gateway1.orleans.occnc.com> Date: Fri, 12 Jul 2013 02:27:17 -0400 Message-ID: From: Alia Atlas To: curtis@ipv6.occnc.com Content-Type: multipart/alternative; boundary=bcaec511e1b6347a9b04e14a9ac0 Cc: MPLS WG Mailing List , The Great and Mighty MPLS Co-Chairs , Alia Atlas , draft-atlas-mpls-te-express-path authors Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 06:27:29 -0000 --bcaec511e1b6347a9b04e14a9ac0 Content-Type: text/plain; charset=ISO-8859-1 Hi Curtis, Comments in-line On Thu, Jul 11, 2013 at 3:38 PM, Curtis Villamizar wrote: > > In message < > D1CF735B7C7B744582438550F826E01B3513CFDF@BY2PRD0510MB389.namprd05.prod.outlook.com > > > Alia Atlas writes: > > > > Hi Curtis, > > > > Thanks for your detailed comments and suggestions. My responses are > > in-line, as always. > > > > Alia > > > Hi Alia, > > I have to say that it was *very* hard to determine the context in the > mail below from the formating alone, in other words what I wrote vs > your reply. The HTML had MsoPlainText tags and the mail headers had > X-MS- headers so the culprit can be identified but there was no header > identifying the sending MUA (mail user agent). This is the first > email I got from you that suffered from this. It would be helpful if > you could use an alternate mailer for at least IETF work. > [Alia] Sorry about that - I'm using the same mail programs as always. > > Anyway, comments are inline. I tried to reformat to regain context. > > btw- NPO is no longer in vogue as you are now well aware (due to the > perception that the ITU may feel they own the term and we are misusing > it). Therefore s/NPO/performance objective/. Or perhaps for this set > of documents you could define link performance objective (LPO) and > avoid any issues with NPO (btw ITU defines NPO as UNI to UNI and given > that definition NPO makes no sense at all in this context). > [Alia] Right - I knew I didn't like NPO - but couldn't recall the reason readily. I've changed to using link performance objective - but didn't turn it into an acronym. I don't have a terminology section yet. > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > Sent: Tuesday, April 23, 2013 12:59 PM > > > To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path authors; > The Great and Mighty MPLS Co-Chairs > > > Cc: curtis@ipv6.occnc.com > > > Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of > ...) > > > > > > Loa, authors, et al, > > > > > > So far I have seen two of the four MPLS-RT reviews (maybe I missed the > > > others). I've commented before on the mailing list about this draft > > > but at this point I would like to provide a detailed review. > > > > > > I think there are very major issues with this document as it now > > > stands. IMO these issues should be addressed before the draft is even > > > accepted as a WG document. > > > > > > You can choose to consider this during MPLS-RT review or after. > > > > > > Curtis > > > > > > > > > Major issues: > > > > > > Jitter and loss are very close to meaningless if queueing delays and > > > loss are not considered. Links that are losing packets at the link > > > layer are generally taken down. Oscillations can occur if queueing > > > delay and loss is considered, such as measurements at a low priority > > > and therefore possible to congest or measurements which are > > > otherwise affected by traffic load. Unless there is adequate > > > discussion of stability and mechanisms to insure stability, then > > > jitter and loss should be removed. > > > > [Alia] I have changed the second paragraph of the introduction to be: > > > > Queuing latency is specifically excluded to insure freedom from > > oscillations and stability issues that have plagued prior attempts > > to use delay as a routing metric. If application traffic which > > follows path based upon latency constraints, the same traffic might > > be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with > > minimal queuing delay or another PHB with potentially very > > substantial per-hop queuing delay. Only traffic which experiences > > relatively low congestion, such as Expedited Forwarding traffic, > > will experience delays very close to the sum of the reported link > > delays > > > > Removing queuing delay is the agreed result for > > draft-ietf-ospf-te-metric-extensions. > > OK > > > As far as jitter and loss goes, these can still be somewhat > > meaningful. For instance, jitter does allow capturing the differences > > in serialization delays - which is relevant in some parts of the > > network. The acceptable loss to take a link down may vary. I don't > > actually see the reasoning or need to remove jitter and loss from the > > draft - given that we have constrained the measurements in the > > draft-ietf-ospf-te-metric-extensions to not include queuing delay. > > The argument above regarding jitter and loss doesn't pass the > "reasonable" threshhold. > > Lets do some quick math on the jitter number. On a 10 Gb/s link the > time it takes to pass 1532 bytes is (1532*8)/(10*10^9) or 1225*10^-9 > or 1.225*10^-6 sec or a bit over 1.2 usec. That is the delay in about > 240 meters of fiber. That amount of fiber won't even get you down the > elevator shaft in a lot of Manhattan buildings let alone down the > street. The argument for jitter as a measure of serialization delay > doesn't seem to me to be very credible. > [Alia] Not all links are 10 Gb/s - there are still slow links in the world. There are still leased paths. Besides, serialization is queuing jitter when only occupancies of 0 > and 1 are considered. In the real world when you add more traffic > even for EF the probabilities of occupancies of 2, 3, or more rises > even if there is no congestion. If you include this jitter > measurement which is inherently a queuing effect and extremely > sensitive to loading, then you risk oscillations and instability. > [Alia] Curtis, I hear your claims on this. I know about what happened in ARPAnet (from many sources :-) and I am not convinced that pruning links that have too much jitter to use is going to cause horrific instability. Why doesn't pruning links based on the reservable bandwidth cause the same problems?? Can you please describe a clear example where the potential is clear? I don't claim to have thought through, much less simulated, every possible case. > Your statement "The acceptable loss to take a link down may vary" also > doesn't justify including loss. If you want to advertise a protection > or restoration time, that might be more reasonable. These things are > not measured in "loss" units because how much gets lost depends on the > utilization during the protection or restoration time. This is also > something that today is generally handled by rfc3209 administrative > attributes (colors) to indicate protected vs unprotected links if it > matters to some LSP. Note that the difference between end-to-end > protection and link by link protection only makes sense for fairly > long delay links, where the delay (time in flight before detection) is > long compared to the typical protection times of about 10 msec for > small number of LSP or under 45 msec for lots of LSP (except some > implementation that don't acheive this for lots of links but certainly > won't be advertising that). > > I have made the same comment regarding > draft-ietf-ospf-te-metric-extensions. There is no reason to have > jitter and delay if queuing impacts are not considered. [Alia] I have people who run networks who want to have jitter and loss in there. I understand that you don't see a reason - and I am certainly willing to encourage discussion from those who are interested in using this technology (and diligent enough to read this far). > > > General: > > > > > > It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, > > > see nits below) is specific to a link, and not an NPO per LSP. A > > > "non-conformance to NPO" flag in the IGP link advertisement is > > > intractable if there are multiple NPO being applied to the link. > > > > [Alia] As you may recall from draft-ietf-ospf-te-metric-extensions, > > the Anomalous bit is specified per characteristic advertised per link. > > This draft (draft-atlas-mpls-te-express-path-02) describes the > > Anomalous bit as clearly inside a links' sub-TLV as in Sec 2.3.1: > > > > "If the answer to (a) is no for latency SLAs, then any link which has > > the Anomalous bit set in the Unidirectional Link Delay sub- > > TLV[I-D.ietf-ospf-te-metric-extensions] > > [I-D.previdi-isis-te-metric-extensions] should be removed from the > > topology before a CSPF calculation is used to compute a new path." > > I think s/SLA/link performance objective/ (or LPO as mentioned above) > in a lot of places would help. Where you mean end-to-end, just say > end-to-end performance objective. The document would then read easier > for those who haven't already read the document a dozen times (or read > the email conversations that make it already very clear). > [Alia] done - as above > > > > The use of a "non-conformance to NPO" flag as the only means to > > > alert the set of LSP ingress of a significant change is also at best > > > a poor solution. For example, a change from 2 msec to 15 msec may > > > be a problem for some LSP. That same change may not be a problem > > > for others, such as LSPs where only this one hop is needed. So > > > advertising out of NPO in the IGP doesn't help the second case. LSP > > > ingress must evaluate the path delay constraint, each time a change > > > in IGP link advertised delay is received. > > > > [Alia] Sure - different LSPs may have different requirements as to the > > Anomalous flag. Using it doesn't replace paying attention to the > > value that is advertised. The anomalous flag is reporting that the > > link is not complying to the expected performance - this can indicate > > that there is something strange going on and some LSPs should avoid > > using that link due to administrative policy. > > > > > The use of a "non-conformance to NPO" flag solely as a constraint > > > makes sense, where some LSP are configured to exclude links with > > > this flag set. > > > > [Alia] Right - case (a) and (c) for Sec 2.3 > > > > > For path delay computation it would also be useful if the NPO > > > threshhold were advertised. In some cases, it may make sense to > > > minimize or place bounds on the sum of NPO delays. > > > > [Alia] I think that should be a comment on > > draft-ietf-ospf-te-metric-extensions. This draft doesn't define what > > is flooded. A question though is whether in the same network it would > > make sense to consider both the NPO delays and the actual measured > > delays? If only one or the other - then that could be a local > > router's decision as to which is flooded. > > NPO (or link performance objective) delay and measured delay would be > two different numbers. If this document is about the use of > draft-ietf-ospf-te-metric-extensions, then whether it needs to have a > link performance objective advertised in order for "anomolous" to make > sense is an issue for this document. > [Alia] Please explain the use-case where it is important to know the actual link performance objective. There can be administrative policy for violating it; that just cares about the violation. There can be LSP performance objectives that depend on the actual measured delays. I don't see a use-case where the specific value for the link performance objective is important. > > > > Specific: > > > > > > Abstract: > > > > > > Remove mention of jitter and loss. > > > > [Alia] I am interested in the opinion of the WG on this. In my view, > > this draft is describing how the information flooded via the new > > sub-TLVs in draft-ietf-ospf-te-metric-extensions-04 should be used. > > Loss and jitter are included in that draft; of course, that draft > > could change as well - but I'd like to hear stronger arguments for why > > it is harmful to include them than that they're only relevant when > > queuing behavior is included and that can lead to oscillations. I am, > > perhaps stubbornly, not convinced that they are irrelevant. > > See argument above. > > btw- If we add queuing delay and loss, then we can do OSPF-OMP, > ISIS-OMP, and MPLS-OMP as defined back in the mid to late 1990s > without requiring any protocol changes. :-) > Scary thought of the day. [Alia] blast from the past :-) but what might be better done with ECMP is a different story. > > > 1. Introduction: > > > > > > This sentence is awkward but I think I know what you are trying to > > > say. > > > > > > The method suggested is not optimal for both minimizing path > > > cost and additional constraints, such as latency; optimal > > > solutions are computationally complex. > > > > > > Please consider this replacement. > > > > > > Methods of optimizing path selection for multiple parameters are > > > generally computationally complex. The method proposed here are > > > to make use of either a single metric in path selection, such as > > > minimal path delay, or to make use of another single metric, > > > such as the existing TE metric with additional constraints, such > > > as target link delay bounds and target path delay bounds. > > > > [Alia] Thanks for the better text - put in... > > > > > Please note: > > > > > > The path selection mechanisms described in this document apply > > > to paths that are fully computed by the head-end of the LSP and > > > then signaled in an ERO where every sub-object is strict. This > > > allows the head-end to consider IGP-distributed performance data > > > without requiring the ability to signal the performance > > > constraints in an object of the RSVP Path message. > > > > > > There is work in MPLS or CCAMP by George Swallow and others on > > > cummulative metrics in RSVP-TE with delay as a major motivation. > > > Perhaps that work should be considered. > > > > [Alia] I believe you are referring to > > http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-01? > > That draft appears to me to be about how to get measurements for > > latency, jitter, and cost for a given Forwarding Adjacency or Routing > > Adjacency so that those values can be advertised into the IGP. I > > think this draft is providing a means to collect the data to flood in > > draft-ietf-ospf-te-metrics-04. > > Yes, that is the draft. But no I don't think that the intent is > strictly to readvertise the delay for an FA given that the ingress > could just sum the values advertised for the links. I think by > recording the sum, the ingress can more easily check the latest RESV > for a change that could require a route computation. > > The motivation could also be for MPLS with loose hops where a midpoint > LSR could change the hops (but I'm not sure how often if ever that is > used, not being a firm beleiver that multidomain RSVP-TE ever got much > deployment or persisted where experimented with). > > Perhaps we should ask George et al about the intended usage. > > The stated motivation in the abstract is: > > This draft provides extensions for the Resource ReserVation > Protocol Traffic Engineering (RSVP-TE) for the support of the > discovery of cost, latency and latency variation of an LSP. > > The introduction gives examples, most of which are multidomain > related. Another example is the egress of a bidirectional LSP. > [Alia] My skim of the draft was that it was for the measurements. In a multidomain case, one couldn't just sum up the link measurements - particularly if the details of the path in a different domain were not shared due to policy. We could certainly verify with George if there's an additional motivation. (There's a lot of work in ccamp for years on multidomain - hard to believe it's to little purpose.) > > > I did add the last sentence in the following: > > > > This document does not specify how a router determines what values > > to advertise by the IGP; it does assume that the constraints > > specified in [I-D.ietf-ospf-te-metric-extensions] and > > [I-D.previdi-isis-te-metric-extensions] are followed. Mechanisms > > for determining latency and delay variation for Forwarding > > Adjacencies and Routing Adjacencies are defined in > > [I-D.ietf-ccamp-te-metric-recording]." > > You wouldn't use a direct measurement of delay using IP-Prec 6 or 7 on > an FA? > > If so, you might want to cite the MPLS-TP DM RFCs and note that an > Entropy Label may be needed in some cases to insure that the > measurement is accurate. > > Better to just not cite anything as the means of measurement. [Alia] Ok - I added that statement in to try and place the draft you mentioned into context. It doesn't say that one needs to use them - but one could do direct measurements or have the control plane compute and measure them. I do agree that there's no reason to talk about the means of measurement in this draft. > > > This paragraph could use rewording: > > > > > > When considering performance-based data, it is obvious that > > > there are additional contributors beyond just the links. > > > Clearly end-to-end latency is a combination of router latency, > > > queuing latency, physical link latency and other factors. > > > However, if application traffic requires paths to be selected > > > based upon latency constraints, the same traffic might be in an > > > Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal > > > queuing delay or another PHB with known maximal per-hop queuing > > > delay. While traversing a router can cause delay, that can be > > > included in the advertised link delay. > > > > > > What you are getting at is that where traffic levels can't > > > possibly have a significant impact the measurements, such as low > > > levels of EF traffic in a WAN with high geographic delays, and > > > delay meansured with EF priority, stability is not impacted if > > > delay measurements are considered. In this case, loss MUST be > > > zero or the EF service is broken (replace routers and try again). > > > OTOH jitter will increase as traffic levels increase, even in such > > > a case where the traffic is only a few percent, potentially > > > causing oscillations and impacting stability. For this reason, > > > jitter and loss should not be considered. > > > > > > I will leave the rewording up to you. I suggest that you create a > > > subsection of "Introduction" which discusses potential > > > oscillations and stability in greater detail. If you like, I will > > > provide some text. > > > > [Alia] I do hear your concern that jitter could cause oscillations and > > impact stability. I am not fully persuaded that this is a practical > > issue - given the delays in ingress re-optimization, not trying to > > minimize the jitter, and the ability for an LSP to reserve bandwidth. > > I would be interested in what text you might provide and a focused > > discussion on whether this is something that needs to have > > restrictions clearly described to avoid oscillations. > > Here is a start: > > 1.2 Oscillation and Stability Considerations > > Past attempts to use delay or loss as metric sufferred from severe > oscillations []. The use of performance based data MUST be such > that ocillations are not possible and stability cannot be impacted. > [Alia] Were they all uses of unbounded delay like ARPAnet? It's certainly the standard problem of everyone rushing to the shortest line. I'm also caveating "oscillations are not possible" to "undampened oscillations are not possible". Let's go for the merely very difficult :-) > The use of timers is often cited as a cure. Oscillation that is > damped by timers is known as "slosh". If advertisement timers are > very short relative to the jitter applied to RSVP-TE CSPF timers, > then a partial oscillation occurs. If RSVP-TE CSPF timers are > short relative to advertisement timers, full oscillation (all > traffic moving back and forth) can occur. Even a partial > oscillation causes unnecessary reordering which is considered at > least minimally disruptive. > > Delay variation or jitter is affected by even small traffic levels. > At even tiny traffic levels, the probability of a queue occupancy > of one can produce a measured jitter proportional to or equal to > the packet serialization delay. Very low levels of traffic can > increase the probability of queue occupancies of two or three > packets enough to further increase the measured jitter. Because > jitter measurement is extremely sensitive to even very low traffic > levels, any use of jitter is likely to oscillate. There may be > legitimate use of a jitter measurement in path computation that can > be considered free of oscillation. > > Delay measurements that are not sensitive to traffic loads may be > safely used in path computation. Delay measurements made at the > link layer or measurements made at a queuing priority higher than > any significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not > CS2 if traffic levels at CS3 and higher or EF and AF can affect the > measurement). Making delay measurements at the same priority as > the traffic on affected paths is likely to cause oscillations. > [Alia] I think I will cut it here. The draft-ietf-ospf-te-metric-extensions clearly specifies that queuing delay and queuing loss are not included. I don't think we need to hammer it in again here. > Delay measurements that include queuing delay or loss measurement > that includes queuing loss would be very difficult to use in path > computation in a way that can be assured to be stable. No > technique to date has successfully accomplished this. Timers > values must reflect the number of contributors to traffic on each > given link or a very conservative estimate of the potential > contributors. Moving large LSP can itself be problematic and > techniques which allow movement of partial LSP traffic, such as > multipath techniques, may help. > > If queuing delay or loss measurement is considered, a proof of > stability should be undertaken. These proofs insure that no > positive feedback exists such that small or moderate changes in > traffic patterns could cause path decisions to fluctuate wildly. > Proof of stability for an arbitrary topology with arbitrary traffic > patterns and using a set of rules for determining timer values and > traffic adjustment amounts can be exceedingly difficult. > > Until a path selection technique is available which is provably > stable, a condition that today has not been met, queuing delay and > queuing loss MUST NOT be included in delay and loss measurements. > > Note that most of RFC4594 provides nothing more than recommendations > is routinely ignored except that CS6 is normally used for control and > management (IGP, BGP, RSVP-TE control, LDP control, SNMP, etc), though > often SNMP is often given lesser priority. > > Proof of stability is very difficult (I tried to get help with this > with OMP back in the 1990s). Note that OMP could move traffic in one > direction and then move half that amount in the other direction if > overshoot occurred, yet we still couldn't come up with a stability > proof for an arbitrary topology, even with timers and backoffs that > considered the number of "other" contributors to traffic (number of > other LSP ingress ingress in the topology). > [Alia] Proofs can be hard. How did you approach it? What tool did you use? It may be interesting to revisit for other uses. I have a hard time believing that changing demand in response to loading hasn't been studied a great deal for other applications (load-balancing servers, etc). I haven't gone poking yet though to understand the similarities and differences. > > For now, I have changed this paragraph to: > > > > When considering performance-based data, it is obvious that there > > are additional contributors beyond just the links. Clearly > > end-to-end latency is a combination of router latency, queuing > > latency, physical link latency and other factors. While traversing > > a router can cause delay, that can be included in the advertised > > link delay. As described in [I-D.ietf-ospf-te-metric-extensions] > > and [I-D.previdi-isis-te-metric-extensions], queuing delay should > > not be included in the measurements advertised by OSPF or ISIS. > > ... queuing delay MUST NOT be included ... [Alia] yes > > Queuing latency is specifically excluded to insure freedom from > > oscillations and stability issues that have plagued prior attempts > > to use delay as a routing metric. If application traffic which > > follows path based upon latency constraints, the same traffic might > > be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with > > minimal queuing delay or another PHB with potentially very > > substantial per-hop queuing delay. Only traffic which experiences > > relatively low congestion, such as Expedited Forwarding traffic, > > will experience delays very close to the sum of the reported link > > delays. > > The traffic levels can't impact the measured delay. For that to > occur, the delay measurements have to be queued ahead of the traffic. > Changing the path of EF traffic and making the delay measurements at > EF is unsafe. If CS7 and CS6 is queued ahead of EF, then delay must > be measured at CS6 or better yet CS7 (or still better at link layer). > [Alia] Yes - but THIS DRAFT is not defining how the measurements are made. > > > > 1.1. Basic Requirements: > > > > > > Drop "packet loss, jitter" from the first numeric item. Otherwise > > > OK except use of the word SLA. See nits below. > > > > [Alia] Changed SLAs to NPO > > Sorry, but now change it to "performance objective" or "link > performance objective" or LPO. See discussion way above. > [Alia] yup - agreed and done > > > > After the list please state that "For existing MPLS constraints, > > > corresponding RSVP-TE signaling allows midpoint LSR to use Path > > > Tear and/or notification and would use this mechanism to > > > accomplish items 3-6. In the absense of RSVP-TE signaling > > > corresponding to these new constraints, new mechanisms at the LSP > > > ingress are needed." Alternately, consider citing the work by > > > George Swallow et al and explain how that solves it in the same > > > way that a change in admin attr of a link would (or should, poor > > > implementations not withstanding). > > > > [Alia] Frankly, I'm confused by this. I don't agree that RSVP-TE > > signaling extensions would solve, for instance, (3): > > > > 3. Ability to periodically verify that a TE tunnel's current LSP > > complies with its configured end-to-end performance > > requirements. > > Sure. The RESV changes if the delay of a link along the way changes. > If the link delay or end-to-end delay is a constraint, the LSP can be > rejected which would best be handled using soft preemption. > [Alia] So you are suggesting hauling the link delay values back in every RESV instead of just flooding it in the IGP. Then we also run into race conditions where the IGP hasn't updated the link delay but RSVP knows that it's violated and CSPF keeps landing on the same path. I don't see this as a superior solution to just flooding the link constraints in the IGP. > > Even if the ingress signaled the end-to-end performance requirements, > > I don't see how that stops the ingress from verifying compliance? > > If the RESV has to be updated with the latest value, the ingress at > the very least gets a verification without requiring the use of probe > packets by the ingress. Link to link DM packets are much more > efficient that each ingress sending probe packets to verify delay. [Alia] ?? I don't think the ingress is sending probe packets. I think it is getting the results of the link delay measurement reported via the IGP - and then the ingress is summing up the delays of the links in the path to determine conformance. > > Similarly, only the ingress could do: > > > > 4. Ability to move tunnels, using make-before-break, based upon > > computed end-to-end performance complying with configuration > > > > 5. Ability to move tunnels away from any link that is violating an > > underlying SLA > > > > 6. Ability to optionally avoid setting up tunnels using any link > > that is violating an SLA, regardless of whether end-to-end > > performance would still meet requirements." > > Any change in the RESV or a soft preempt give the ingress a higher > priority heads up that something changed. A soft preempt is a good > heads up on an SLA violation for any LSP that cares about that. > [Alia] If the midpoint knows what LSPs care about which link performance violations, it could, I guess, do a soft-preempt which might or might not cause the ingress to do the right thing. I think we've moved into "how else could it be designed with more complexity". > > I have looked for the additional work that you are talking about by > > George Swallow unsuccessfully. Can you find a pointer to explain what > > you're talking about? The anomalous bits provide a trigger mechanism > > that a router can use to tell the ingress to do (5); different admin > > attributes could do a similar behavior - and similarly for (6) - but > > again that is the flooding for notification aspect. I think the lack > > of RSVP-TE extensions doesn't cause an issue - these are handled by > > IGP instead and thus don't have to be signaled per LSP. > > The work by Swallow does not solve your problems. It is a good > starting point and like the prior situation with multiple delay metric > related drafts consolidating very similar efforts is a good thing. So > if you would consider RSVP-TE extensions, then try to align your work > with George Swallow's work. > [Alia] Considering the effort to get this draft acceptable - as a purely informational here's how you could compute paths that use the extra flooded info - I'd really like to hear substantial and significant use-cases for why we would need RSVP-TE extensions. > > I am not irrevocably opposed to RSVP-TE extensions - if we really need > > them for practical use-cases. This draft was trying to do the minimum > > that is sufficient and then, if and when there is a need for more, > > what extra is needed could be better defined. > > The point is to be realistic about what the limited mechanisms do well > and don't do well. > > Note: At one point at least one major RSVP-TE implementation didn't > check to see if constraints for LSP were met after an IGP change. For > example if a set of LSP include the admin attribute constraint > "exclude color blue" and a link gets changed to color blue, then those > LSP could sit there for hours before being rerouted. That (or those) > implementation(s) only prioritized CSPF for LSP where a notification > or PATH/RESV TEAR had been received. You might want to check to see > how your employers RSVP-TE handles this. It used to do this but I > don't know if it still does. > [Alia] Obviously an implementation that considers the anomalous bit would need to respond to it for relevant LSPs. Thanks for the heads-up. Markus has his hands in the RSVP-TE code; I haven't needed to yet. > > > 2.1. End-to-End Constraints: > > > > > > Note: I've requested that jitter and loss be dropped from > > > draft-ietf-ospf-te-metric-extensions and > > > draft-previdi-isis-te-metric-extensions for the same potential > > > oscillations and stability reasons cited above. > > > > [Alia] Yes - I think we clearly need to have a good email discussion > > with those interested about what oscillations might actually occur and > > what could be done to prevent that. > > > > > s/While it has been possible to compute a CSPF/It is possible to > > > compute a CSPF/ > > > > > > s/Instead of this approach to minimize path latency, an/An > > > alternative to this approach to minimize path latency is an > > > approach to place a upper bound on path latency. An/ > > > > > > Note: both approaches are valid. > > > > > > Delete next paragraph starting with "This is illustrated as > > > follows." This seems to be taken from email and is good email > > > discussion but not needed in the draft. > > > > [Alia] I've put in some pseudo-code so I'm ok with taking the example > > out - but there does seem to have been confusion even with it in. > > > > > Delete next paragraph starting with "An end-to-end bound on delay > > > variation". Lets get rid of jitter altogether. (Let the old SNA > > > networks be damned. :) > > > > > > Delete next paragraph starting with "For link loss". Get rid of > > > link loss altogether. > > > > [Alia] Not done - discussion is needed. I understand that you really > > really really don't want to see loss or delay variation in any of > > these drafts. > > Yes, for reasons very clearly stated above. > > > > 2.2. Link Constraints: > > > > > > Drop delay variation and link loss. > > > > > > If we are dealing with EF traffic then using Unidirectional > > > Available Bandwidth and Residual Bandwidth makes no sense. If we > > > are dealing with low priority traffic and we are using > > > Unidirectional Available Bandwidth and Residual Bandwidth in path > > > selection will be prone to oscillations and network instability. > > > Therefore delete the entire second paragraph (the one starting > > > with "When doing path selection for TE tunnels,". > > > > [Alia] If we are trying to avoid congesting the link, then Residual > > Bandwidth is important and useful regardless of the LSP traffic class. > > What is your specific concern with oscillation for bandwidth? Why is > > it different than for the bandwidths already advertised and used for > > TE path computation? Come on - the Residual Bandwidth is just the > > Link Capacity minus that reserved by RSVP-TE - so pretty darn similar > > characteristics to the Unreserved Bandwidth per priority... The > > Unidirectional Available bandwidth does include an actual traffic > > measurement - that is averaged over a reasonable interval, that can > > only change with limited frequency - and then the LSPs need to be > > reoptimized to use them. Please explain precisely the oscillation > > concern with a clear example. > > On rereading draft-ietf-ospf-te-metric-extensions this is OK as > defined. > > Residual Bandwidth doesn't use any measured traffic and is therefore > OK. > > Available Bandwidth also subtracts out just the non-RSVP-TE traffic > and so that too should be OK. The non-RSVP-TE traffic (IP and LDP > traffic) will not move as long as the IGP metrics don't change. > [Alia] Exactly so > > > Also delete the entire third paragraph (starting with "Similarly, > > > only links whose loss is"). As stated earlier, use of loss is > > > either a NOOP (low volume of EF traffic) or can lead to > > > oscillations. Get rid of loss entirely. > > > > > > 2.3. Links out of SLA: > > > > > > s/SLA/NPO/g (see nits below). > > > > > > General: A better mechanism than an "Anomalous State" flag is > > > needed to provide notifications of change. One mechanism would be > > > to put the commulative constraint and the cummulative total in the > > > ERO and RRO. A link adding delay can then notify the ingress of > > > any LSP for which the commulative constraint is violated. See > > > work by Swallow et al and perhaps align with that work. > > > > [Alia] That could be done as well - but the signaling extensions seem > > like overkill for the basic problem of letting the ingress compute a > > complete ERO. Carrying both the cumulative constraint and the > > cumulative total just means that the midpoint detects a changed link > > and then has to verify the performance on each LSP and individually > > signal it. Having an anomalous flag provides a succinct notification > > to the ingress which can then do the verification and be known to have > > the updated information. This solution also requires that the > > midpoints all support it before it can be used. An advantage of the > > ingress computation is that only the ingress needs to have updated > > code. > > Coding this at the midpoint is very easy and efficient. First when an > LSP is signaled, compute the difference between the LSP delay target > and the experienced delay (the PATH can give the delay total of prior > links, the RESV can give delay total for downstream links. Take that > headroom figure and install a pointer to the LSP in a sorted > collection with good insert/delete times (a balanced tree for > example). When another link delay changes, the PATH or RESV changes > and the LSP has to be scheduled for removal and reinsertion into the > sorted collection. Initially put it on a DLL to make this > computationally trivial. Clean up the DLL entries periodically in > spare time. When a link changes, start at the end of the sorted > collection with the most sensitive LSP. Go through the list doing > soft preempt on all those in violation. Simply update the delay value > in the PATH and RESV on the rest and that can be done in spare time. > > Those LSP that don't care about delay don't get on any of these lists. > [Alia] LOL - I'm not arguing that the coding is hard or even the RSVP-TE extensions to communicate the requirements and accumulation. It's a deployment consideration and a question of "is it necessary". > > > The "Anomalous State" flag is helpful for c in the list, but not > > > for b. The case where a link is out of NPO by 1 msec then changes > > > to out of NPO by 10s of msec is an example. The flag is already > > > set and therefore the trigger is unavailable. > > > > [Alia] Right - but LSPs that are particular sensitive (i.e. a or c) > > can have been moved already. Having the Anomalous flag set is > > expected to be unusual. I agree that it is more a hint for (b) than a > > full solution. > > > > > 2.3.1. Use of Anomalous Links for New Paths > > > > > > Delete second paragraph regarding jitter and loss. > > > > > > 2.3.2. Links entering the Anomalous State > > > > > > This section ignores two cases in which the Anomalous State does > > > not change but a change makes the path violate a delay > > > constraint. The first is where all of the links are within NPO > > > but a change to a link has make the path delay sum exceed the path > > > delay constraint. The second is where a link which is already in > > > the Anomalous State by a small margin but the path delay is still > > > within the constraint. A large change in delay at that point will > > > not affect the Anomalous State since it is already set. > > > > [Alia] The Anomalous bit is NOT meant to replace reading the actual > > value associated with the link and checking each potentially affected > > LSP. In the case of (b), it is a hint to focus on those LSPs first. > > > > > A better means of handling case (b) in "2.3. Links out of SLA" is > > > needed. > > > > [Alia] I've added the following paragraph at the end of 2.3.2: > > > > It is not sufficient to just look at the Anomalous bit in order to > > determine when TE tunnels must have their compliance verified. > > When changing to set, the Anomalous bit merely provides a hint that > > interested TE tunnels for case (b) should have their continued > > compliance verified. > > > The point that I am making is that a change to the "Anomalous State" > flag is an unreliable hint for (b) where (b) is: > > b. Should LSPs using this link be immediately verified for continued > compliance to their end-to-end constraints? > > Perhaps you should take (b) out of the list and state that for LSP > which have end-to-end constraints, but for which the "Anomalous State" > flag does not automatically disqualify a link, the advertised > parameters will have to be checked on every received advertisement > with a change. Or take out (b) and leave the paragraph that you have > suggested adding. > [Alia] Agreed - I removed (b) but left in the section and description. > > > > 2.3.3. Links leaving the Anomalous State > > > > > > Same issue as in "2.3.2. Links entering the Anomalous State". A > > > better means of handling case (b) in "2.3. Links out of SLA" is > > > needed. > > > > [Alia] I've added the following sentence: > > > > The hint provided by the Anomalous state change may help optimize > > when to recompute for a better path. > > It is an unreliable hint so using that hint is a bad practice. > Unreliable hints don't "help". > [Alia] It is not unreliable if the LSP was reoptimized due to administrative policy instead of, for example, delay bound. I clarified "whose LSPs were changed due to administrative policy when the link entered the Anomalous state"... > > > > XML version nits: > > > > > > CV: you really should remove the template comments. > > > > [Alia] I find them helpful for when I want to do additional > > things... and very very few people read the XML. > > OK > > > > You should also enable strict mode. For example, you have one > > > author too many and strict would catch that. > > > > [Alia] So does basic arithmetic :) It will be resolved before the > > draft is passed to the RFC editor. > > Strict mode does a lot of other checks that are supposed to get run > when a doc becomes a WG doc, long before it goes to the RFC Editor. > > I just used datatracker to do a check nits and it had a few things to > complain about. > > ** The document seems to lack a both a reference to RFC 2119 and the > recommended RFC 2119 boilerplate, even if it appears to use RFC > 2119 keywords. > [Alia] Yes - I'm not convinced it's meaningful to have RFC 2119 keywords in an informational draft. I've changed them to lower case. > == Unused Reference: 'RFC5420' is defined on line 291, but no > explicit reference was found in the text > [Alia] Yup > == Outdated reference: A later version (-04) exists of > draft-ietf-ospf-te-metric-extensions-02 > > == Outdated reference: A later version (-03) exists of > draft-previdi-isis-te-metric-extensions-02 > > The first two need to be fixed. The second two are just a matter of > updating the references. > [Alia] Done automatically with the new draft. > > > > Other nits: > > > > > > The "A" in SLA is "Agreement" as in contract. The acronym NPO for > > > network performance objective seems to be in vogue for that reason. > > > IETF since diffserv has wanted to steer clear of making > > > recommendations regarding provider contracts (agreements) with > > > customers, peer, or anyone else. > > > > [Alia] True - changed > > Sorry about this but s/NPO/?/ > Where "?" is "performance objective", "link performance objective", > LPO, or descriptive term of your choice. See above. > > [Alia] yup > > > I agree with Sri on the suggestions to change the title, short name > > > and document filename but I'm not fond of his suggested new names. > > > Authors please suggest new title, short name, and filename. > > > > [Alia] I did do a new short name and title. As for filename, we'll > > deal with that if/when the draft is adopted as a WG draft. > > I haven't seen the new name. > [Alia] The shortname is "Path Selection with TE Metric Extensions". I'll probably name the draft "Fred" unless the WG chairs have a better solution ;-) I'm taking the draft with all these changes and publishing it. Thanks, Alia --bcaec511e1b6347a9b04e14a9ac0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Curtis,

Comments in-line
On Thu, Jul 11, 2013 at 3:38 PM, Curtis Villamizar <curtis= @ipv6.occnc.com> wrote:

In message <D1CF735B7C7B744582438550F826E01B3= 513CFDF@BY2PRD0510MB389.namprd05.prod.outlook.com>
Alia Atlas writes:
>
> Hi Curtis,
>
> Thanks for your detailed comments and suggestions. =A0My responses are=
> in-line, as always.
>
> Alia


Hi Alia,

I have to say that it was *very* hard to determine the context in the
mail below from the formating alone, in other words what I wrote vs
your reply. =A0The HTML had MsoPlainText tags and the mail headers had
X-MS- headers so the culprit can be identified but there was no header
identifying the sending MUA (mail user agent). =A0This is the first
email I got from you that suffered from this. =A0It would be helpful if
you could use an alternate mailer for at least IETF work.
<= div>
[Alia] Sorry about that - I'm using the same mail pr= ograms as always.=A0

Anyway, comments are inline. =A0I tried to reformat to regain context.

btw- NPO is no longer in vogue as you are now well aware (due to the
perception that the ITU may feel they own the term and we are misusing
it). =A0Therefore s/NPO/performance objective/. =A0Or perhaps for this set<= br> of documents you could define link performance objective (LPO) and
avoid any issues with NPO (btw ITU defines NPO as UNI to UNI and given
that definition NPO makes no sense at all in this context).

[Alia] Right - I knew I didn't like NPO - but coul= dn't recall the reason readily.
I've changed to using lin= k performance objective - but didn't turn it into an acronym.
I don't have a terminology section yet.
=A0

> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]
> > Sent: Tuesday, April 23, 2013 12:59 PM
> > To: MPLS WG Mailing List; draft-atlas-mpls-te-express-path author= s; The Great and Mighty MPLS Co-Chairs
> > Cc: curtis@ipv6.occnc.co= m
> > Subject: draft-atlas-mpls-te-express-path-02 (was MPLS-RT review = of ...)
> >
> > Loa, authors, et al,
> >
> > So far I have seen two of the four MPLS-RT reviews (maybe I misse= d the
> > others). =A0I've commented before on the mailing list about t= his draft
> > but at this point I would like to provide a detailed review.
> >
> > I think there are very major issues with this document as it now<= br> > > stands. =A0IMO these issues should be addressed before the draft = is even
> > accepted as a WG document.
> >
> > You can choose to consider this during MPLS-RT review or after. > >
> > Curtis
> >
> >
> > Major issues:
> >
> > =A0 Jitter and loss are very close to meaningless if queueing del= ays and
> > =A0 loss are not considered. =A0Links that are losing packets at = the link
> > =A0 layer are generally taken down. =A0Oscillations can occur if = queueing
> > =A0 delay and loss is considered, such as measurements at a low p= riority
> > =A0 and therefore possible to congest or measurements which are > > =A0 otherwise affected by traffic load. =A0Unless there is adequa= te
> > =A0 discussion of stability and mechanisms to insure stability, t= hen
> > =A0 jitter and loss should be removed.
>
> [Alia] I have changed the second paragraph of the introduction to be:<= br> >
> =A0 =A0Queuing latency is specifically excluded to insure freedom from=
> =A0 =A0oscillations and stability issues that have plagued prior attem= pts
> =A0 =A0to use delay as a routing metric. =A0If application traffic whi= ch
> =A0 =A0follows path based upon latency constraints, the same traffic m= ight
> =A0 =A0be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with > =A0 =A0minimal queuing delay or another PHB with potentially very
> =A0 =A0substantial per-hop queuing delay. =A0Only traffic which experi= ences
> =A0 =A0relatively low congestion, such as Expedited Forwarding traffic= ,
> =A0 =A0will experience delays very close to the sum of the reported li= nk
> =A0 =A0delays
>
> Removing queuing delay is the agreed result for
> draft-ietf-ospf-te-metric-extensions.

OK

> As far as jitter and loss goes, these can still be somewhat
> meaningful. =A0For instance, jitter does allow capturing the differenc= es
> in serialization delays - which is relevant in some parts of the
> network. =A0The acceptable loss to take a link down may vary. =A0I don= 't
> actually see the reasoning or need to remove jitter and loss from the<= br> > draft - given that we have constrained the measurements in the
> draft-ietf-ospf-te-metric-extensions to not include queuing delay.

The argument above regarding jitter and loss doesn't pass the
"reasonable" threshhold.

Lets do some quick math on the jitter number. =A0On a 10 Gb/s link the
time it takes to pass 1532 bytes is (1532*8)/(10*10^9) or 1225*10^-9
or 1.225*10^-6 sec or a bit over 1.2 usec. =A0That is the delay in about 240 meters of fiber. =A0That amount of fiber won't even get you down th= e
elevator shaft in a lot of Manhattan buildings let alone down the
street. =A0The argument for jitter as a measure of serialization delay
doesn't seem to me to be very credible.
[Alia] Not= all links are 10 Gb/s - there are still slow links in the world. =A0There = are still leased paths.

Besides, serialization is queuing jitter when only occupancies of 0
and 1 are considered. =A0In the real world when you add more traffic
even for EF the probabilities of occupancies of 2, 3, or more rises
even if there is no congestion. =A0If you include this jitter
measurement which is inherently a queuing effect and extremely
sensitive to loading, then you risk oscillations and instability.

[Alia] Curtis, I hear your claims on this. =A0I = know about what happened in ARPAnet (from many
sources :-) and I = am not convinced that pruning links that have too much jitter to use is goi= ng to
cause horrific instability. =A0Why doesn't pruning links based on = the reservable bandwidth cause the
same problems?? =A0
=
Can you please describe a clear example where the potential = is clear? I don't claim to have
thought through, much less simulated, every possible case.
= =A0
Your statement "The acceptable loss to take a link down may vary"= also
doesn't justify including loss. =A0If you want to advertise a protectio= n
or restoration time, that might be more reasonable. =A0These things are
not measured in "loss" units because how much gets lost depends o= n the
utilization during the protection or restoration time. =A0This is also
something that today is generally handled by rfc3209 administrative
attributes (colors) to indicate protected vs unprotected links if it
matters to some LSP. =A0Note that the difference between end-to-end
protection and link by link protection only makes sense for fairly
long delay links, where the delay (time in flight before detection) is
long compared to the typical protection times of about 10 msec for
small number of LSP or under 45 msec for lots of LSP (except some
implementation that don't acheive this for lots of links but certainly<= br> won't be advertising that).

I have made the same comment regarding
draft-ietf-ospf-te-metric-extensions. =A0There is no reason to have
jitter and delay if queuing impacts are not considered.
[Alia] I have people who run networks who want to have jitter = and loss in there. =A0I understand
that you don't see a reaso= n - and I am certainly willing to encourage discussion from those who
are interested in using this technology (and diligent enough to read t= his far).=A0

=A0
> > General:
> >
> > =A0 It needs to be much more clearly stated that the NPO (s/SLA/N= PO/g,
> > =A0 see nits below) is specific to a link, and not an NPO per LSP= . =A0A
> > =A0 "non-conformance to NPO" flag in the IGP link adver= tisement is
> > =A0 intractable if there are multiple NPO being applied to the li= nk.
>
> [Alia] As you may recall from draft-ietf-ospf-te-metric-extensions, > the Anomalous bit is specified per characteristic advertised per link.=
> This draft (draft-atlas-mpls-te-express-path-02) describes the
> Anomalous bit as clearly inside a links' sub-TLV as in Sec 2.3.1:<= br> >
> "If the answer to (a) is no for latency SLAs, then any link which= has
> the Anomalous bit set in the Unidirectional Link Delay sub-
> TLV[I-D.ietf-ospf-te-metric-extensions]
> [I-D.previdi-isis-te-metric-extensions] should be removed from the
> topology before a CSPF calculation is used to compute a new path."= ;

I think s/SLA/link performance objective/ (or LPO as mentioned above)=
in a lot of places would help. =A0Where you mean end-to-end, just say
end-to-end performance objective. =A0The document would then read easier for those who haven't already read the document a dozen times (or read<= br> the email conversations that make it already very clear).
<= div>
[Alia] done - as above=A0

> > =A0 The use of a "non-conformance to NPO" flag as the o= nly means to
> > =A0 alert the set of LSP ingress of a significant change is also = at best
> > =A0 a poor solution. =A0For example, a change from 2 msec to 15 m= sec may
> > =A0 be a problem for some LSP. =A0That same change may not be a p= roblem
> > =A0 for others, such as LSPs where only this one hop is needed. = =A0So
> > =A0 advertising out of NPO in the IGP doesn't help the second= case. =A0LSP
> > =A0 ingress must evaluate the path delay constraint, each time a = change
> > =A0 in IGP link advertised delay is received.
>
> [Alia] Sure - different LSPs may have different requirements as to the=
> Anomalous flag. =A0Using it doesn't replace paying attention to th= e
> value that is advertised. =A0The anomalous flag is reporting that the<= br> > link is not complying to the expected performance - this can indicate<= br> > that there is something strange going on and some LSPs should avoid > using that link due to administrative policy.
>
> > =A0 The use of a "non-conformance to NPO" flag solely a= s a constraint
> > =A0 makes sense, where some LSP are configured to exclude links w= ith
> > =A0 this flag set.
>
> [Alia] Right - case (a) and (c) for Sec 2.3
>
> > =A0 For path delay computation it would also be useful if the NPO=
> > =A0 threshhold were advertised. =A0In some cases, it may make sen= se to
> > =A0 minimize or place bounds on the sum of NPO delays.
>
> [Alia] I think that should be a comment on
> draft-ietf-ospf-te-metric-extensions. =A0This draft doesn't define= what
> is flooded. =A0A question though is whether in the same network it wou= ld
> make sense to consider both the NPO delays and the actual measured
> delays? =A0If only one or the other - then that could be a= local
> router's decision as to which is flooded.

NPO (or link performance objective) delay and measured delay would be=
two different numbers. =A0If this document is about the use of
draft-ietf-ospf-te-metric-extensions, then whether it needs to have a
link performance objective advertised in order for "anomolous" to= make
sense is an issue for this document.

[A= lia] =A0Please explain the use-case where it is important to know the actua= l link
performance objective. =A0There can be administrative poli= cy for violating it; that just
cares about the violation. =A0There can be LSP performance objectives = that depend on
the actual measured delays. =A0 I don't see a = use-case where the specific value for the
link performance object= ive is important.

=A0

> > Specific:
> >
> > =A0 Abstract:
> >
> > =A0 =A0 Remove mention of jitter and loss.
>
> [Alia] I am interested in the opinion of the WG on this. =A0In my view= ,
> this draft is describing how the information flooded via the new
> sub-TLVs in draft-ietf-ospf-te-metric-extensions-04 should be used. > Loss and jitter are included in that draft; of course, that draft
> could change as well - but I'd like to hear stronger arguments for= why
> it is harmful to include them than that they're only relevant when=
> queuing behavior is included and that can lead to oscillations. =A0I a= m,
> perhaps stubbornly, not convinced that they are irrelevant.

See argument above.

btw- If we add queuing delay and loss, then we can do OSPF-OMP,
ISIS-OMP, and MPLS-OMP as defined back in the mid to late 1990s
without requiring any protocol changes. =A0:-)
Scary thought of the day.

[Alia] blast from= the past :-) =A0but what might be better done with ECMP is a different
story. =A0
=A0
> > =A0 1. =A0Introduction:
> >
> > =A0 =A0 This sentence is awkward but I think I know what you are = trying to
> > =A0 =A0 say.
> >
> > =A0 =A0 =A0 The method suggested is not optimal for both minimizi= ng path
> > =A0 =A0 =A0 cost and additional constraints, such as latency; opt= imal
> > =A0 =A0 =A0 solutions are computationally complex.
> >
> > =A0 =A0 Please consider this replacement.
> >
> > =A0 =A0 =A0 Methods of optimizing path selection for multiple par= ameters are
> > =A0 =A0 =A0 generally computationally complex. =A0The method prop= osed here are
> > =A0 =A0 =A0 to make use of either a single metric in path selecti= on, such as
> > =A0 =A0 =A0 minimal path delay, or to make use of another single = metric,
> > =A0 =A0 =A0 such as the existing TE metric with additional constr= aints, such
> > =A0 =A0 =A0 as target link delay bounds and target path delay bou= nds.
>
> [Alia] Thanks for the better text - put in...
>
> > =A0 =A0 Please note:
> >
> > =A0 =A0 =A0 The path selection mechanisms described in this docum= ent apply
> > =A0 =A0 =A0 to paths that are fully computed by the head-end of t= he LSP and
> > =A0 =A0 =A0 then signaled in an ERO where every sub-object is str= ict. =A0This
> > =A0 =A0 =A0 allows the head-end to consider IGP-distributed perfo= rmance data
> > =A0 =A0 =A0 without requiring the ability to signal the performan= ce
> > =A0 =A0 =A0 constraints in an object of the RSVP Path message. > >
> > =A0 =A0 There is work in MPLS or CCAMP by George Swallow and othe= rs on
> > =A0 =A0 cummulative metrics in RSVP-TE with delay as a major moti= vation.
> > =A0 =A0 Perhaps that work should be considered.
>
> [Alia] I believe you are referring to
> http://tools.ietf.org/html/draft-ietf-ccamp-te-m= etric-recording-01?
> That draft appears to me to be about how to get measurements for
> latency, jitter, and cost for a given Forwarding Adjacency or Routing<= br> > Adjacency so that those values can be advertised into the IGP. =A0I > think this draft is providing a means to collect the data to flood in<= br> > draft-ietf-ospf-te-metrics-04.

Yes, that is the draft. =A0But no I don't think that the intent i= s
strictly to readvertise the delay for an FA given that the ingress
could just sum the values advertised for the links. =A0I think by
recording the sum, the ingress can more easily check the latest RESV
for a change that could require a route computation.

The motivation could also be for MPLS with loose hops where a midpoint
LSR could change the hops (but I'm not sure how often if ever that is used, not being a firm beleiver that multidomain RSVP-TE ever got much
deployment or persisted where experimented with).

Perhaps we should ask George et al about the intended usage.

The stated motivation in the abstract is:

=A0 =A0This draft provides extensions for the Resource ReserVation
=A0 =A0Protocol Traffic Engineering (RSVP-TE) for the support of the
=A0 =A0discovery of cost, latency and latency variation of an LSP.

The introduction gives examples, most of which are multidomain
related. =A0Another example is the egress of a bidirectional LSP.

[Alia] My skim of the draft was that it was for = the measurements. =A0In a multidomain case,
one couldn't just= sum up the link measurements - particularly if the details of the path in = a
different domain were not shared due to policy. =A0 We could certainly= verify with George if there's
an additional motivation. =A0(= There's a lot of work in ccamp for years on multidomain - hard to=A0
believe it's to little purpose.)
=A0

> I did add the last sentence in the following:
>
> =A0 =A0This document does not specify how a router determines what val= ues
> =A0 =A0to advertise by the IGP; it does assume that the constraints > =A0 =A0specified in [I-D.ietf-ospf-te-metric-extensions] and
> =A0 =A0[I-D.previdi-isis-te-metric-extensions] are followed. =A0Mechan= isms
> =A0 =A0for determining latency and delay variation for Forwarding
> =A0 =A0Adjacencies and Routing Adjacencies are defined in
> =A0 =A0[I-D.ietf-ccamp-te-metric-recording]."

You wouldn't use a direct measurement of delay using IP-Prec 6 or= 7 on
an FA?
=A0
If so, you might want to cite the MPLS-TP DM RFCs and note that an
Entropy Label may be needed in some cases to insure that the
measurement is accurate.

Better to just not cite anything as the means of measurement.
<= div>
[Alia] Ok - =A0I added that statement in to try and plac= e the draft you mentioned into context. =A0
It doesn't say th= at one needs to use them - but one could do direct measurements or have
the control plane compute and measure them.

I= do agree that there's no reason to talk about the means of measurement= in this draft.
=A0
> > =A0 =A0 This paragraph could use rewording:
> >
> > =A0 =A0 =A0 When considering performance-based data, it is obviou= s that
> > =A0 =A0 =A0 there are additional contributors beyond just the lin= ks.
> > =A0 =A0 =A0 Clearly end-to-end latency is a combination of router= latency,
> > =A0 =A0 =A0 queuing latency, physical link latency and other fact= ors.
> > =A0 =A0 =A0 However, if application traffic requires paths to be = selected
> > =A0 =A0 =A0 based upon latency constraints, the same traffic migh= t be in an
> > =A0 =A0 =A0 Expedited Forwarding Per-Hop- Behavior[RFC3246] with = minimal
> > =A0 =A0 =A0 queuing delay or another PHB with known maximal per-h= op queuing
> > =A0 =A0 =A0 delay. =A0While traversing a router can cause delay, = that can be
> > =A0 =A0 =A0 included in the advertised link delay.
> >
> > =A0 =A0 What you are getting at is that where traffic levels can&= #39;t
> > =A0 =A0 possibly have a significant impact the measurements, such= as low
> > =A0 =A0 levels of EF traffic in a WAN with high geographic delays= , and
> > =A0 =A0 delay meansured with EF priority, stability is not impact= ed if
> > =A0 =A0 delay measurements are considered. =A0In this case, loss = MUST be
> > =A0 =A0 zero or the EF service is broken (replace routers and try= again).
> > =A0 =A0 OTOH jitter will increase as traffic levels increase, eve= n in such
> > =A0 =A0 a case where the traffic is only a few percent, potential= ly
> > =A0 =A0 causing oscillations and impacting stability. =A0For this= reason,
> > =A0 =A0 jitter and loss should not be considered.
> >
> > =A0 =A0 I will leave the rewording up to you. =A0I suggest that y= ou create a
> > =A0 =A0 subsection of "Introduction" which discusses po= tential
> > =A0 =A0 oscillations and stability in greater detail. =A0If you l= ike, I will
> > =A0 =A0 provide some text.
>
> [Alia] I do hear your concern that jitter could cause oscillations and=
> impact stability. =A0I am not fully persuaded that this is a practical=
> issue - given the delays in ingress re-optimization, not trying to
> minimize the jitter, and the ability for an LSP to reserve bandwidth.<= br> > I would be interested in what text you might provide and a focused
> discussion on whether this is something that needs to have
> restrictions clearly described to avoid oscillations.

Here is a start:

=A0 =A01.2 =A0Oscillation and Stability Considerations

=A0 =A0Past attempts to use delay or loss as metric sufferred from severe =A0 =A0oscillations []. =A0The use of performance based data MUST be such =A0 =A0that ocillations are not possible and stability cannot be impacted.<= br>

[Alia] Were they all uses of unbounded = delay like ARPAnet? =A0It's certainly=A0
the standard problem= of everyone rushing to the shortest line. =A0I'm also caveating
"oscillations are not possible" to "undampened oscillat= ions are not possible". =A0Let's
go for the merely very = difficult :-)=A0

=A0
=A0 =A0The use of timers is often cited as a cure. =A0Oscillation that is =A0 =A0damped by timers is known as "slosh". =A0If advertisement = timers are
=A0 =A0very short relative to the jitter applied to RSVP-TE CSPF timers, =A0 =A0then a partial oscillation occurs. =A0If RSVP-TE CSPF timers are
=A0 =A0short relative to advertisement timers, full oscillation (all
=A0 =A0traffic moving back and forth) can occur. =A0Even a partial
=A0 =A0oscillation causes unnecessary reordering which is considered at
=A0 =A0least minimally disruptive.

=A0 =A0Delay variation or jitter is affected by even small traffic levels.<= br> =A0 =A0At even tiny traffic levels, the probability of a queue occupancy =A0 =A0of one can produce a measured jitter proportional to or equal to
=A0 =A0the packet serialization delay. =A0Very low levels of traffic can =A0 =A0increase the probability of queue occupancies of two or three
=A0 =A0packets enough to further increase the measured jitter. =A0Because =A0 =A0jitter measurement is extremely sensitive to even very low traffic =A0 =A0levels, any use of jitter is likely to oscillate. =A0There may be =A0 =A0legitimate use of a jitter measurement in path computation that can<= br> =A0 =A0be considered free of oscillation.

=A0 =A0Delay measurements that are not sensitive to traffic loads may be =A0 =A0safely used in path computation. =A0Delay measurements made at the =A0 =A0link layer or measurements made at a queuing priority higher than =A0 =A0any significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not<= br> =A0 =A0CS2 if traffic levels at CS3 and higher or EF and AF can affect the<= br> =A0 =A0measurement). =A0Making delay measurements at the same priority as =A0 =A0the traffic on affected paths is likely to cause oscillations.

[Alia] I think I will cut it here. =A0The dr= aft-ietf-ospf-te-metric-extensions clearly specifies
that queuing= delay and queuing loss are not included. =A0I don't think we need to h= ammer
it in again here. =A0
=A0
=A0 =A0Delay= measurements that include queuing delay or loss measurement
=A0 =A0that includes queuing loss would be very difficult to use in path =A0 =A0computation in a way that can be assured to be stable. =A0No
=A0 =A0technique to date has successfully accomplished this. =A0Timers
=A0 =A0values must reflect the number of contributors to traffic on each =A0 =A0given link or a very conservative estimate of the potential
=A0 =A0contributors. =A0Moving large LSP can itself be problematic and
=A0 =A0techniques which allow movement of partial LSP traffic, such as
=A0 =A0multipath techniques, may help.

=A0 =A0If queuing delay or loss measurement is considered, a proof of
=A0 =A0stability should be undertaken. =A0These proofs insure that no
=A0 =A0positive feedback exists such that small or moderate changes in
=A0 =A0traffic patterns could cause path decisions to fluctuate wildly.
=A0 =A0Proof of stability for an arbitrary topology with arbitrary traffic<= br> =A0 =A0patterns and using a set of rules for determining timer values and =A0 =A0traffic adjustment amounts can be exceedingly difficult.

=A0 =A0Until a path selection technique is available which is provably
=A0 =A0stable, a condition that today has not been met, queuing delay and =A0 =A0queuing loss MUST NOT be included in delay and loss measurements.
Note that most of RFC4594 provides nothing more than recommendations
is routinely ignored except that CS6 is normally used for control and
management (IGP, BGP, RSVP-TE control, LDP control, SNMP, etc), though
often SNMP is often given lesser priority.

Proof of stability is very difficult (I tried to get help with this
with OMP back in the 1990s). =A0Note that OMP could move traffic in one
direction and then move half that amount in the other direction if
overshoot occurred, yet we still couldn't come up with a stability
proof for an arbitrary topology, even with timers and backoffs that
considered the number of "other" contributors to traffic (number = of
other LSP ingress ingress in the topology).

=
[Alia] Proofs can be hard. =A0How did you approach it? =A0What tool di= d you use?
It may be interesting to revisit for other uses.

I have a hard time believing that changing demand in re= sponse to loading hasn't
been studied a great deal for other = applications (load-balancing servers, etc). I=A0
haven't gone= poking yet though to understand the similarities and differences.

=A0
> For now, I have changed this paragraph to:
>
> =A0 =A0When considering performance-based data, it is obvious that the= re
> =A0 =A0are additional contributors beyond just the links. Clearly
> =A0 =A0end-to-end latency is a combination of router latency, queuing<= br> > =A0 =A0latency, physical link latency and other factors. =A0While trav= ersing
> =A0 =A0a router can cause delay, that can be included in the advertise= d
> =A0 =A0link delay. =A0As described in [I-D.ietf-ospf-te-metric-extensi= ons]
> =A0 =A0and [I-D.previdi-isis-te-metric-extensions], queuing delay shou= ld
> =A0 =A0not be included in the measurements advertised by OSPF or ISIS.=

... queuing delay MUST NOT be included ...

[Alia] yes
=A0
> =A0 =A0Queuing latency is specifically excluded to insure freedom from=
> =A0 =A0oscillations and stability issues that have plagued prior attem= pts
> =A0 =A0to use delay as a routing metric. =A0If application traffic whi= ch
> =A0 =A0follows path based upon latency constraints, the same traffic m= ight
> =A0 =A0be in an Expedited Forwarding Per-Hop-Behavior [RFC3246] with > =A0 =A0minimal queuing delay or another PHB with potentially very
> =A0 =A0substantial per-hop queuing delay. =A0Only traffic which experi= ences
> =A0 =A0relatively low congestion, such as Expedited Forwarding traffic= ,
> =A0 =A0will experience delays very close to the sum of the reported li= nk
> =A0 =A0delays.

The traffic levels can't impact the measured delay. =A0For that t= o
occur, the delay measurements have to be queued ahead of the traffic.
Changing the path of EF traffic and making the delay measurements at
EF is unsafe. =A0If CS7 and CS6 is queued ahead of EF, then delay must
be measured at CS6 or better yet CS7 (or still better at link layer).

[Alia] Yes - but THIS DRAFT is not defining = how the measurements are made.
=A0

> > =A0 1.1. =A0Basic Requirements:
> >
> > =A0 =A0 Drop "packet loss, jitter" from the first numer= ic item. =A0Otherwise
> > =A0 =A0 OK except use of the word SLA. =A0See nits below.
>
> [Alia] Changed SLAs to NPO

Sorry, but now change it to "performance objective" or &quo= t;link
performance objective" or LPO. =A0See discussion way above.

[Alia] yup - agreed and done=A0

> > =A0 =A0 After the list please state that "For existing MPLS = constraints,
> > =A0 =A0 corresponding RSVP-TE signaling allows midpoint LSR to us= e Path
> > =A0 =A0 Tear and/or notification and would use this mechanism to<= br> > > =A0 =A0 accomplish items 3-6. =A0In the absense of RSVP-TE signal= ing
> > =A0 =A0 corresponding to these new constraints, new mechanisms at= the LSP
> > =A0 =A0 ingress are needed." =A0Alternately, consider citing= the work by
> > =A0 =A0 George Swallow et al and explain how that solves it in th= e same
> > =A0 =A0 way that a change in admin attr of a link would (or shoul= d, poor
> > =A0 =A0 implementations not withstanding).
>
> [Alia] Frankly, I'm confused by this. =A0I don't agree that RS= VP-TE
> signaling extensions would solve, for instance, (3):
>
> =A0 =A03. Ability to periodically verify that a TE tunnel's curren= t LSP
> =A0 =A0 =A0 complies with its configured end-to-end performance
> =A0 =A0 =A0 requirements.

Sure. =A0The RESV changes if the delay of a link along the way change= s.
If the link delay or end-to-end delay is a constraint, the LSP can be
rejected which would best be handled using soft preemption.

[Alia] So you are suggesting hauling the link delay va= lues back in every RESV instead
of just flooding it in the IGP. = =A0Then we also run into race conditions where the IGP hasn't
updated the link delay but RSVP knows that it's violated and CSPF = keeps landing on the
same path. =A0 I don't see this as a sup= erior solution to just flooding the link constraints in
the IGP.<= /div>
=A0
> Even if the ingress signaled the end-to-end performa= nce requirements,
> I don't see how that stops the ingress from verifying compliance?<= br>
If the RESV has to be updated with the latest value, the ingress at the very least gets a verification without requiring the use of probe
packets by the ingress. =A0Link to link DM packets are much more
efficient that each ingress sending probe packets to verify delay.

[Alia] ?? =A0I don't think the ingress is sendi= ng probe packets. =A0I think it is getting
the results of the lin= k delay measurement reported via the IGP - and then the
ingress is summing up the delays of the links in the path to determine= conformance.
=A0
> Similarly, only the ingress could do:
>
> =A0 =A04. =A0Ability to move tunnels, using make-before-break, based u= pon
> =A0 =A0 =A0 =A0computed end-to-end performance complying with configur= ation
>
> =A0 =A05. =A0Ability to move tunnels away from any link that is violat= ing an
> =A0 =A0 =A0 =A0underlying SLA
>
> =A0 =A06. =A0Ability to optionally avoid setting up tunnels using any = link
> =A0 =A0 =A0 =A0that is violating an SLA, regardless of whether end-to-= end
> =A0 =A0 =A0 =A0performance would still meet requirements."

Any change in the RESV or a soft preempt give the ingress a higher priority heads up that something changed. =A0A soft preempt is a good
heads up on an SLA violation for any LSP that cares about that.

[Alia] If the midpoint knows what LSPs care about = which link performance violations,
it could, I guess, do a soft-p= reempt which might or might not cause the ingress to do
the right thing. =A0I think we've moved into "how else could = it be designed with more
complexity".
=A0
> I have looked for the additional work that you are t= alking about by
> George Swallow unsuccessfully. =A0Can you find a pointer to explain wh= at
> you're talking about? =A0The anomalous bits provide a trigger mech= anism
> that a router can use to tell the ingress to do (5); different admin > attributes could do a similar behavior - and similarly for (6) - but > again that is the flooding for notification aspect. =A0I think the lac= k
> of RSVP-TE extensions doesn't cause an issue - these are han= dled by
> IGP instead and thus don't have to be signaled p= er LSP.

The work by Swallow does not solve your problems. =A0It is a good
starting point and like the prior situation with multiple delay metric
related drafts consolidating very similar efforts is a good thing. =A0So if you would consider RSVP-TE extensions, then try to align your work
with George Swallow's work.

[Alia] = Considering the effort to get this draft acceptable - as a purely informati= onal
here's how you could compute paths that use the extra fl= ooded info - I'd really like
to hear substantial and significant use-cases for why we would need RS= VP-TE extensions.
=A0
> I am not irrevocably opposed to RSVP-TE extensions -= if we really need
> them for practical use-cases. =A0This draft was trying to do the minim= um
> that is sufficient and then, if and when there is a need for more,
> what extra is needed could be better defined.

The point is to be realistic about what the limited mechanisms do wel= l
and don't do well.

Note: At one point at least one major RSVP-TE implementation didn't
check to see if constraints for LSP were met after an IGP change. =A0For example if a set of LSP include the admin attribute constraint
"exclude color blue" and a link gets changed to color blue, then = those
LSP could sit there for hours before being rerouted. =A0That (or those)
implementation(s) only prioritized CSPF for LSP where a notification
or PATH/RESV TEAR had been received. =A0You might want to check to see
how your employers RSVP-TE handles this. =A0It used to do this but I
don't know if it still does.

[Alia]= Obviously an implementation that considers the anomalous bit would need
to respond to it for relevant LSPs. =A0Thanks for the heads-up. =A0= Markus has his hands=A0
in the RSVP-TE code; I =A0haven't needed to yet. =A0=A0
= =A0
> > =A0 2.1. =A0End-to-End Constraints:
> >
> > =A0 =A0 Note: I've requested that jitter and loss be dropped = from
> > =A0 =A0 draft-ietf-ospf-te-metric-extensions and
> > =A0 =A0 draft-previdi-isis-te-metric-extensions for the same pote= ntial
> > =A0 =A0 oscillations and stability reasons cited above.
>
> [Alia] Yes - I think we clearly need to have a good email discussion > with those interested about what oscillations might actually occur and=
> what could be done to prevent that.
>
> > =A0 =A0 s/While it has been possible to compute a CSPF/It is poss= ible to
> > =A0 =A0 compute a CSPF/
> >
> > =A0 =A0 s/Instead of this approach to minimize path latency, an/A= n
> > =A0 =A0 alternative to this approach to minimize path latency is = an
> > =A0 =A0 approach to place a upper bound on path latency. =A0An/ > >
> > =A0 =A0 Note: both approaches are valid.
> >
> > =A0 =A0 Delete next paragraph starting with "This is illustr= ated as
> > =A0 =A0 follows." =A0This seems to be taken from email and i= s good email
> > =A0 =A0 discussion but not needed in the draft.
>
> [Alia] I've put in some pseudo-code so I'm ok with taking the = example
> out - but there does seem to have been confusion even with it in.
>
> > =A0 =A0 Delete next paragraph starting with "An end-to-end b= ound on delay
> > =A0 =A0 variation". =A0Lets get rid of jitter altogether. = =A0(Let the old SNA
> > =A0 =A0 networks be damned. :)
> >
> > =A0 =A0 Delete next paragraph starting with "For link loss&q= uot;. =A0Get rid of
> > =A0 =A0 link loss altogether.
>
> [Alia] Not done - discussion is needed. =A0I understand that you reall= y
> really really don't want to see loss or delay variation in any of<= br> > these drafts.

Yes, for reasons very clearly stated above.

> > =A0 2.2. =A0Link Constraints:
> >
> > =A0 =A0 Drop delay variation and link loss.
> >
> > =A0 =A0 If we are dealing with EF traffic then using Unidirection= al
> > =A0 =A0 Available Bandwidth and Residual Bandwidth makes no sense= . =A0If we
> > =A0 =A0 are dealing with low priority traffic and we are using > > =A0 =A0 Unidirectional Available Bandwidth and Residual Bandwidth= in path
> > =A0 =A0 selection will be prone to oscillations and network insta= bility.
> > =A0 =A0 Therefore delete the entire second paragraph (the one sta= rting
> > =A0 =A0 with "When doing path selection for TE tunnels,"= ;.
>
> [Alia] If we are trying to avoid congesting the link, then Residual > Bandwidth is important and useful regardless of the LSP traffic class.=
> What is your specific concern with oscillation for bandwidth? =A0Why i= s
> it different than for the bandwidths already advertised and used for
> TE path computation? =A0Come on - the Residual Bandwidth is just= the
> Link Capacity minus that reserved by RSVP-TE - so pr= etty darn similar
> characteristics to the Unreserved Bandwidth per priority... =A0T= he
> Unidirectional Available bandwidth does include an a= ctual traffic
> measurement - that is averaged over a reasonable interval, that can > only change with limited frequency - and then the LSPs need to be
> reoptimized to use them. =A0Please explain precisely the oscillation > concern with a clear example.

On rereading draft-ietf-ospf-te-metric-extensions this is OK as
defined.

Residual Bandwidth doesn't use any measured traffic and is therefore OK.

Available Bandwidth also subtracts out just the non-RSVP-TE traffic
and so that too should be OK. =A0The non-RSVP-TE traffic (IP and LDP
traffic) will not move as long as the IGP metrics don't change.

[Alia] Exactly so
=A0
> > =A0 =A0 Also delete the entire third paragraph = (starting with "Similarly,
> > =A0 =A0 only links whose loss is"). =A0As stated earlier, us= e of loss is
> > =A0 =A0 either a NOOP (low volume of EF traffic) or can lead to > > =A0 =A0 oscillations. =A0Get rid of loss entirely.
> >
> > =A0 2.3. =A0Links out of SLA:
> >
> > =A0 =A0 s/SLA/NPO/g (see nits below).
> >
> > =A0 =A0 General: A better mechanism than an "Anomalous State= " flag is
> > =A0 =A0 needed to provide notifications of change. =A0One mechani= sm would be
> > =A0 =A0 to put the commulative constraint and the cummulative tot= al in the
> > =A0 =A0 ERO and RRO. =A0A link adding delay can then notify the i= ngress of
> > =A0 =A0 any LSP for which the commulative constraint is violated.= =A0See
> > =A0 =A0 work by Swallow et al and perhaps align with that work. >
> [Alia] That could be done as well - but the signaling extensions seem<= br> > like overkill for the basic problem of letting the ingress compute a > complete ERO. =A0Carrying both the cumulative constraint and the
> cumulative total just means that the midpoint detects a changed link > and then has to verify the performance on each LSP and individually > signal it. =A0Having an anomalous flag provides a succinct notificatio= n
> to the ingress which can then do the verification and be known to have=
> the updated information. =A0This solution also requires that the
> midpoints all support it before it can be used. =A0An advantage of the=
> ingress computation is that only the ingress needs to have updated
> code.

Coding this at the midpoint is very easy and efficient. =A0First when= an
LSP is signaled, compute the difference between the LSP delay target
and the experienced delay (the PATH can give the delay total of prior
links, the RESV can give delay total for downstream links. =A0Take that
headroom figure and install a pointer to the LSP in a sorted
collection with good insert/delete times (a balanced tree for
example). =A0When another link delay changes, the PATH or RESV changes
and the LSP has to be scheduled for removal and reinsertion into the
sorted collection. =A0Initially put it on a DLL to make this
computationally trivial. =A0Clean up the DLL entries periodically in
spare time. =A0When a link changes, start at the end of the sorted
collection with the most sensitive LSP. =A0Go through the list doing
soft preempt on all those in violation. =A0Simply update the delay value in the PATH and RESV on the rest and that can be done in spare time.

Those LSP that don't care about delay don't get on any of these lis= ts.

[Alia] LOL - I'm not arguing th= at the coding is hard or even the RSVP-TE extensions=A0
to commun= icate the requirements and accumulation. =A0It's a deployment considera= tion
and a question of "is it necessary".
=A0
> > =A0 =A0 The "Anomalous State" fl= ag is helpful for c in the list, but not
> > =A0 =A0 for b. =A0The case where a link is out of NPO by 1 msec t= hen changes
> > =A0 =A0 to out of NPO by 10s of msec is an example. =A0The flag i= s already
> > =A0 =A0 set and therefore the trigger is unavailable.
>
> [Alia] Right - but LSPs that are particular sensitive (i.e. a or c) > can have been moved already. =A0Having the Anomalous flag set is
> expected to be unusual. =A0I agree that it is more a hint for (b) than= a
> full solution.
>
> > =A0 2.3.1. =A0Use of Anomalous Links for New Paths
> >
> > =A0 =A0 Delete second paragraph regarding jitter and loss.
> >
> > =A0 2.3.2. =A0Links entering the Anomalous State
> >
> > =A0 =A0 This section ignores two cases in which the Anomalous Sta= te does
> > =A0 =A0 not change but a change makes the path violate a delay > > =A0 =A0 constraint. =A0The first is where all of the links are wi= thin NPO
> > =A0 =A0 but a change to a link has make the path delay sum exceed= the path
> > =A0 =A0 delay constraint. =A0The second is where a link which is = already in
> > =A0 =A0 the Anomalous State by a small margin but the path delay = is still
> > =A0 =A0 within the constraint. =A0A large change in delay at that= point will
> > =A0 =A0 not affect the Anomalous State since it is already set. >
> [Alia] The Anomalous bit is NOT meant to replace reading the actual > value associated with the link and checking each potentially affected<= br> > LSP. =A0In the case of (b), it is a hint to focus on those LSPs first.=
>
> > =A0 =A0 A better means of handling case (b) in "2.3. =A0Link= s out of SLA" is
> > =A0 =A0 needed.
>
> [Alia] =A0I've added the following paragraph at the end of 2.3.2:<= br> >
> =A0 =A0It is not sufficient to just look at the Anomalous bit in order= to
> =A0 =A0determine when TE tunnels must have their compliance verified.<= br> > =A0 =A0When changing to set, the Anomalous bit merely provides a hint = that
> =A0 =A0interested TE tunnels for case (b) should have their continued<= br> > =A0 =A0compliance verified.


The point that I am making is that a change to the "Anomal= ous State"
flag is an unreliable hint for (b) where (b) is:

=A0 =A0b. =A0Should LSPs using this link be immediately verified for contin= ued
=A0 =A0 =A0 =A0compliance to their end-to-end constraints?

Perhaps you should take (b) out of the list and state that for LSP
which have end-to-end constraints, but for which the "Anomalous State&= quot;
flag does not automatically disqualify a link, the advertised
parameters will have to be checked on every received advertisement
with a change. =A0Or take out (b) and leave the paragraph that you have
suggested adding.
=A0
[Alia] Agreed - I remo= ved (b) but left in the section and description.



> > =A0 2.3.3. =A0Links leaving the Anomalous State
> >
> > =A0 =A0 Same issue as in "2.3.2. =A0Links entering the Anoma= lous State". =A0A
> > =A0 =A0 better means of handling case (b) in "2.3. =A0Links = out of SLA" is
> > =A0 =A0 needed.
>
> [Alia] =A0I've added the following sentence:
>
> =A0 =A0The hint provided by the Anomalous state change may help optimi= ze
> =A0 =A0when to recompute for a better path.

It is an unreliable hint so using that hint is a bad practice.
Unreliable hints don't "help".

[Alia] It is not unreliable if the LSP was reoptimized due to adminis= trative policy instead
of, for example, delay bound. =A0I clarifi= ed "whose LSPs were changed due to administrative=A0
policy when the link entered the Anomalous state"...
= =A0

> > XML version nits:
> >
> > =A0 CV: you really should remove the template comments.
>
> [Alia] I find them helpful for when I want to do additional
> things... and very very few people read the XML.

OK

> > =A0 You should also enable strict mode. =A0For example, you have = one
> > =A0 author too many and strict would catch that.
>
> [Alia] So does basic arithmetic :) It will be resolved before th= e
> draft is passed to the RFC editor.

Strict mode does a lot of other checks that are supposed to get run when a doc becomes a WG doc, long before it goes to the RFC Editor.

I just used datatracker to do a check nits and it had a few things to
complain about.

=A0 ** The document seems to lack a both a reference to RFC 2119 and the =A0 =A0 =A0recommended RFC 2119 boilerplate, even if it appears to use RFC<= br> =A0 =A0 =A02119 keywords.

[Alia] Yes - = I'm not convinced it's meaningful to have RFC 2119 keywords in an= =A0
informational draft. =A0I've changed them to lower case.<= /div>
=A0
=A0 =3D=3D Unused Reference: 'RFC5420' is= defined on line 291, but no
=A0 =A0 =A0explicit reference was found in the text
[Alia] Yup
=A0
=A0 =3D=3D Outdated reference: A later version (-04) exists of
=A0 =A0 =A0draft-ietf-ospf-te-metric-extensions-02

=A0 =3D=3D Outdated reference: A later version (-03) exists of
=A0 =A0 =A0draft-previdi-isis-te-metric-extensions-02

The first two need to be fixed. =A0The second two are just a matter of
updating the references.
[Alia] Done automatically wit= h the new draft.
=A0

> > Other nits:
> >
> > =A0 The "A" in SLA is "Agreement" as in contr= act. =A0The acronym NPO for
> > =A0 network performance objective seems to be in vogue for that r= eason.
> > =A0 IETF since diffserv has wanted to steer clear of making
> > =A0 recommendations regarding provider contracts (agreements) wit= h
> > =A0 customers, peer, or anyone else.
>
> [Alia] =A0True - changed

Sorry about this but s/NPO/?/
Where "?" is "performance objective", "link perfor= mance objective",
LPO, or descriptive term of your choice. =A0See above.

[Alia] yup
=A0
> > =A0 I agree with Sri on the suggestions to change the title, shor= t name
> > =A0 and document filename but I'm not fond of his suggested n= ew names.
> > =A0 Authors please suggest new title, short name, and filename. >
> [Alia] =A0I did do a new short name and title. =A0As for filename, we&= #39;ll
> deal with that if/when the draft is adopted as a WG draft.

I haven't seen the new name.

= [Alia] =A0The shortname is "Path Selection with TE Metric Extensions&q= uot;. =A0I'll probably
name the draft "Fred" unless= the WG chairs have a better solution ;-)

I'm taking the draft with all these changes and pub= lishing it.

Thanks,
Alia
--bcaec511e1b6347a9b04e14a9ac0-- From internet-drafts@ietf.org Thu Jul 11 23:31:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87521F9C15; Thu, 11 Jul 2013 23:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYgmsq9THJgH; Thu, 11 Jul 2013 23:31:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD36121F9C06; Thu, 11 Jul 2013 23:31:30 -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: 4.51.p2 Message-ID: <20130712063130.30937.3370.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 23:31:30 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-atlas-mpls-te-express-path-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: Fri, 12 Jul 2013 06:31:31 -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 Gro= up of the IETF. Title : Performance-based Path Selection for Explicitly Routed L= SPs using TE Metric Extensions Author(s) : Alia Atlas John Drake Spencer Giacalone Dave Ward Stefano Previdi Clarence Filsfils Filename : draft-atlas-mpls-te-express-path-03.txt Pages : 10 Date : 2013-07-11 Abstract: In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE LSP. Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification uses network performance data, such as is advertised via the OSPF and ISIS TE metric extensions (defined outside the scope of this document) to perform such path selections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-mpls-te-express-path There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-mpls-te-express-path-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-mpls-te-express-path-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From akatlas@juniper.net Thu Jul 11 23:33:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40111E820D for ; Thu, 11 Jul 2013 23:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.586 X-Spam-Level: X-Spam-Status: No, score=0.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-0zSWRisuns for ; Thu, 11 Jul 2013 23:33:07 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 098AB21F9C06 for ; Thu, 11 Jul 2013 23:33:06 -0700 (PDT) Received: from mail29-db9-R.bigfish.com (10.174.16.249) by DB9EHSOBE025.bigfish.com (10.174.14.88) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 06:33:03 +0000 Received: from mail29-db9 (localhost [127.0.0.1]) by mail29-db9-R.bigfish.com (Postfix) with ESMTP id 6EC531406AC for ; Fri, 12 Jul 2013 06:33:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I936eI542Iec9Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail29-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=akatlas@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail29-db9 (localhost.localdomain [127.0.0.1]) by mail29-db9 (MessageSwitch) id 1373610780518412_13821; Fri, 12 Jul 2013 06:33:00 +0000 (UTC) Received: from DB9EHSMHS020.bigfish.com (unknown [10.174.16.236]) by mail29-db9.bigfish.com (Postfix) with ESMTP id 79EBF300031 for ; Fri, 12 Jul 2013 06:33:00 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by DB9EHSMHS020.bigfish.com (10.174.14.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 06:33:00 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Jul 2013 23:32:59 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Jul 2013 23:32:58 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Jul 2013 23:36:37 -0700 Received: from mail154-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 06:32:58 +0000 Received: from mail154-ch1 (localhost [127.0.0.1]) by mail154-ch1-R.bigfish.com (Postfix) with ESMTP id C222E320596 for ; Fri, 12 Jul 2013 06:32:57 +0000 (UTC) Received: from mail154-ch1 (localhost.localdomain [127.0.0.1]) by mail154-ch1 (MessageSwitch) id 1373610775239181_17908; Fri, 12 Jul 2013 06:32:55 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail154-ch1.bigfish.com (Postfix) with ESMTP id 2BCA61A004A for ; Fri, 12 Jul 2013 06:32:55 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 06:32:54 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.99]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Fri, 12 Jul 2013 06:32:54 +0000 From: Alia Atlas To: MPLS WG Mailing List Thread-Topic: New Version Notification for draft-atlas-mpls-te-express-path-03.txt Thread-Index: AQHOfsl44J34Doas4E6X7Dqi0um05plglX8w Date: Fri, 12 Jul 2013 06:32:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [mpls] FW: New Version Notification for draft-atlas-mpls-te-express-path-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: Fri, 12 Jul 2013 06:33:13 -0000 SSd2ZSBwdWJsaXNoZWQgYW4gdXBkYXRlZCBkcmFmdC1hdGxhcy1tcGxzLXRlLWV4cHJlc3MtcGF0 aCB0aGF0IHJlZmxlY3RzIHRoZSBkaXNjdXNzaW9uIGFuZCByZXZpZXdzIGJ5IHRoZSBNUExTLU1U IHRlYW0uDQoNCkFsaWENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBGcmlkYXksIEp1bHkgMTIsIDIwMTMgMjozMiBBTQ0KVG86IFN0ZWZhbm8gUHJldmlkaTsg QWxpYSBBdGxhczsgU3BlbmNlciBHaWFjYWxvbmU7IEpvaG4gRSBEcmFrZTsgRGF2aWQgV2FyZDsg U3BlbmNlciBHaWFjYWxvbmU7IENsYXJlbmNlIEZpbHNmaWxzOyBEYXZlIFdhcmQNClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNz LXBhdGgtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWF0bGFzLW1wbHMt dGUtZXhwcmVzcy1wYXRoLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBBbGlhIEF0bGFzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC1hdGxhcy1tcGxzLXRlLWV4cHJlc3MtcGF0aA0KUmV2aXNpb246CSAwMw0KVGl0 bGU6CQkgUGVyZm9ybWFuY2UtYmFzZWQgUGF0aCBTZWxlY3Rpb24gZm9yIEV4cGxpY2l0bHkgUm91 dGVkIExTUHMgdXNpbmcgVEUgTWV0cmljIEV4dGVuc2lvbnMNCkNyZWF0aW9uIGRhdGU6CSAyMDEz LTA3LTEyDQpHcm91cDoJCSBtcGxzDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWF0bGFzLW1wbHMt dGUtZXhwcmVzcy1wYXRoLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoDQpIdG1saXpl ZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF0bGFzLW1wbHMtdGUt ZXhwcmVzcy1wYXRoLTAzDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoLTAzDQoNCkFic3RyYWN0 Og0KICAgSW4gY2VydGFpbiBuZXR3b3JrcywgaXQgaXMgY3JpdGljYWwgdG8gY29uc2lkZXIgbmV0 d29yayBwZXJmb3JtYW5jZQ0KICAgY3JpdGVyaWEgd2hlbiBzZWxlY3RpbmcgdGhlIHBhdGggZm9y IGFuIGV4cGxpY2l0bHkgcm91dGVkIFJTVlAtVEUNCiAgIExTUC4gIFN1Y2ggcGVyZm9ybWFuY2Ug Y3JpdGVyaWEgY2FuIGluY2x1ZGUgbGF0ZW5jeSwgaml0dGVyLCBhbmQgbG9zcw0KICAgb3Igb3Ro ZXIgaW5kaWNhdGlvbnMgc3VjaCBhcyB0aGUgY29uZm9ybWFuY2UgdG8gbGluayBwZXJmb3JtYW5j ZQ0KICAgb2JqZWN0aXZlcyBhbmQgbm9uLVJTVlAgVEUgdHJhZmZpYyBsb2FkLiAgVGhpcyBzcGVj aWZpY2F0aW9uIHVzZXMNCiAgIG5ldHdvcmsgcGVyZm9ybWFuY2UgZGF0YSwgc3VjaCBhcyBpcyBh ZHZlcnRpc2VkIHZpYSB0aGUgT1NQRiBhbmQgSVNJUw0KICAgVEUgbWV0cmljIGV4dGVuc2lvbnMg KGRlZmluZWQgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCkgdG8NCiAgIHBlcmZv cm0gc3VjaCBwYXRoIHNlbGVjdGlvbnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K From xuxiaohu@huawei.com Thu Jul 11 23:34:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1021F9C6A for ; Thu, 11 Jul 2013 23:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.674 X-Spam-Level: X-Spam-Status: No, score=0.674 tagged_above=-999 required=5 tests=[AWL=-3.314, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1FF1XfPXb+M for ; Thu, 11 Jul 2013 23:34:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4521F9C06 for ; Thu, 11 Jul 2013 23:34:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ21417; Fri, 12 Jul 2013 06:34:21 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 07:33:15 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 07:33:52 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 14:33:44 +0800 From: Xuxiaohu To: Alia Atlas , "curtis@ipv6.occnc.com" , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs Thread-Topic: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQI1v7AdXBiEf1kGpZztZc1tuJpldHnDggAOlvMCAADN/8IAAFqXw Date: Fri, 12 Jul 2013 06:33:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDFF4@NKGEML512-MBS.china.huawei.com> References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDF14@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] =?gb2312?b?tPC4tDogIGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVz?= =?gb2312?b?cy1wYXRoLTAyICh3YXMgTVBMUy1SVCByZXZpZXcgb2YJLi4uKQ==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 06:34:29 -0000 T2gsIHllcywgeW91IGFyZSByaWdodC4gU29ycnkgZm9yIG15IGNvbmZ1c2lvbi4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQWxpYSBB dGxhcyBbbWFpbHRvOmFrYXRsYXNAanVuaXBlci5uZXRdDQo+ILeiy83KsbzkOiAyMDEzxOo31MIx MsjVIDEzOjA1DQo+IMrVvP7IyzogWHV4aWFvaHU7IGN1cnRpc0BpcHY2Lm9jY25jLmNvbTsgTVBM UyBXRyBNYWlsaW5nIExpc3Q7DQo+IGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoIGF1 dGhvcnM7IFRoZSBHcmVhdCBhbmQgTWlnaHR5IE1QTFMNCj4gQ28tQ2hhaXJzDQo+INb3zOI6IFJF OiBbbXBsc10gZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBhdGgtMDIgKHdhcyBNUExTLVJU IHJldmlldw0KPiBvZiAuLi4pDQo+IA0KPiBIaSBYaWFvaHUsDQo+IA0KPiBObywgdGhlcmUgaXMg bm8gcmV0cmVhdGluZy4gIEkgdGhpbmsgeW91J3JlIGRlc2NyaWJpbmcgc29tZXRoaW5nIGJhc2Vk IG9uIGENCj4gZGVwdGgtZmlyc3Qtc2VhcmNoIHRoYXQncyBjb3N0IGF3YXJlPz8/IEkgZG9uJ3Qg a25vdyBidXQgaXQncyBub3QgYmFzZWQgb24gYQ0KPiBub3JtYWwgU1BGLiAgVGhlIHBzZXVkby1j b2RlIEkgZ2F2ZSBpcyBjb3JyZWN0Lg0KPiANCj4gSGVyZSdzIHRoZSBicmllZiBleGFtcGxlIC0g IEkgbWVhbiBhbiBTUEYgd2hlcmUgbGlua3MgYXJlbid0IGV4cGxvcmVkIGlmIHRoZXkNCj4gcmVz dWx0IGluIGEgcGF0aCB0aGF0IGlzIHRvbyBsb25nLg0KPiANCj4gU3RlcCAxIENTUEY6ICAgQSBo YXMgY29zdCAwLCBkZWxheSAwICAgLSBleHBsb3JlIEEncyBsaW5rcw0KPiAgICAgICAgICAgQi5j b3N0ID0gMSAgQi5kZWxheT0gMSAgaW5zZXJ0IEIgaW50byB0aGUgZmliaGVhcCBvcmRlcmVkIGJ5 IGNvc3QNCj4gICAgICAgICAgIEMuY29zdCA9IDEwICBDLmRlbGF5ID0gMSAgIGluc2VydCBDIGlu dG8gdGhlIGZpYmhlYXAgb3JkZXJlZCBieQ0KPiBjb3N0DQo+IA0KPiBTdGVwIDIgQ1NQRjogIHJl bW92ZSBmaXJzdCBub2RlIGZyb20gZmliaGVhcCAtIGl0IGlzIEIgIC0gZXhwbG9yZSBCJ3MgbGlu a3MNCj4gICAgICAgICAgIFZpYSBCLT5EIHdvdWxkIGdpdmUgRC5kZWxheSB0byBiZSAxMSAtIG92 ZXIgYm91bmQgc28gZG9uJ3Qgc2F2ZQ0KPiAgICAgICAgICAgVmlhIEItPkUgd291bGQgZ2l2ZSBF LmRlbGF5IHRvIGJlIDExIC0gb3ZlciBib3VuZCBzbyBkb24ndCBzYXZlDQo+IA0KPiBTdGVwIDMg Q1NQRjogcmVtb3ZlIGZpcnN0IG5vZGUgZnJvbSBmaWJoZWFwICAtIGl0IGlzIEMgLSBleHBsb3Jl IEMncyBsaW5rcw0KPiAgICAgICAgICAgICBWaWEgQy0+RiB3b3VsZCBnaXZlIEYuZGVsYXk9MiAt dW5kZXIgYm91bmQgc28gc2F2ZQ0KPiAgICAgICAgICAgICAgICAgIEYuY29zdCA9IDExICAgRi5k ZWxheSA9IDIgIGluc2VydCBGIGludG8gZmliaGVhcA0KPiANCj4gU3RlcCA0IENTUEY6ICByZW1v dmUgZmlyc3Qgbm9kZSBmcm9tIGZpYmhlYXAgLSBpdCBpcyBGDQo+ICAgICAgICAgIENTUEYgd2Fz IGZyb20gQSB0byBGIGFuZCBGIGlzIG5vdyBtaW5pbWl6ZWQgc28gdGVybWluYXRlLg0KPiANCj4g QWxpYQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUg W21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMSwg MjAxMyAxMDo1MiBQTQ0KPiBUbzogQWxpYSBBdGxhczsgY3VydGlzQGlwdjYub2NjbmMuY29tOyBN UExTIFdHIE1haWxpbmcgTGlzdDsNCj4gZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBhdGgg YXV0aG9yczsgVGhlIEdyZWF0IGFuZCBNaWdodHkgTVBMUw0KPiBDby1DaGFpcnMNCj4gU3ViamVj dDogtPC4tDogW21wbHNdIGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoLTAyICh3YXMg TVBMUy1SVA0KPiByZXZpZXcgb2YgLi4uKQ0KPiANCj4gSGkgQWxpYSwNCj4gDQo+IExldCBtZSBn aXZlIGFuIGV4YW1wbGUgYXMgaWxsdXN0cmF0ZWQgYmVsb3c6DQo+IA0KPiBBLS0tLS0tLS0oTWV0 cmljOjE7IERlbGF5OjEpLS0tLS0tLUItLS0oTWV0cmljOjE7IERlbGF5OjEwKS0tLUQtLS0tLS0t LS0tLUYNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAvIHwNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgICstLS0oTWV0cmljOjI7IERlbGF5 OjEwKS0tLUUtLS0tLS0tLS8gIHwNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICstLS0tLS0tKE1ldHJpYzoxMDsgRGVsYXk6MSkt LS0tLS1DLS0tLS0tLS0oTWV0cmljOjE7IERlbGF5DQo+ICsxKS0tLS0tLS0tLS0tLS0tKw0KPiAN Cj4gQXNzdW1lIEEgd2FudHMgdG8gZmluZCBhbiBvcHRpbWFsIHBhdGggdG8gRiB3aXRoIGRlbGF5 IHVwcGVyIGJvdW5kIG9mIDEwLiBJbg0KPiBzdGVwIDEsIEEgc2VsZWN0cyBCIGFtb25nIGFsbCBv ZiBpdHMgYWRqYWNlbnQgcm91dGVycyBhcyB0aGUgbmV4dF9yb3V0ZXIgc2luY2UgaXRzDQo+IGRp c3RhbmNlIHRvIG90aGVyIGFkamFjZW50IHJvdXRlcnMgKGkuZS4sIEMpIGlzIGxhcmdlciB0aGFu IHRoYXQgdG8gQi4gaW4gc3RlcCAyLCBCDQo+IGZpbmRzIHRoYXQgbmVpdGhlciBvZiBpdHMgYWRq YWNlbnQgcm91dGVycyAoaS5lLiwgRCBhbmQgRSkgY291bGQgYmUgc2VsZWN0ZWQgYXMNCj4gbmV4 dF9yb3V0ZXIgc2luY2UgdGhlIGxhdGVuY3kgb2YgdGhlIGVpdGhlciBwYXRoIChpLmUuLCBBLT5C LT5EIGFuZCBBLT5CLT5FKSBpcw0KPiBhbHJlYWR5IGJleW9uZCB0aGUgZTJlIGRlbGF5IGJvdW5k LiBBdCBhIHJlc3VsdCwgaW4gc3RlcCAzLCBBIGhhcyB0byBnaXZlIHVwIEINCj4gYW5kIHRoZW4g ZXhwbG9yZSBpdHMgb3RoZXIgYWRqYWNlbnQgcm91dGVycy4gSXMgdGhhdCB0aGUgaGV1cmlzdGlj IGFsZ29yaXRobSB5b3UNCj4gbWVhbnQ/IElmIHNvLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVz Y3JpYmUgdGhlIHN0ZXAgMyAoaS5lLiwgYSByZXRyZWF0IHN0ZXApIGFzDQo+IHdlbGwgaW4geW91 ciBwc2V1ZG8tY29kZSB3aGlsZSBtZW50aW9uaW5nIHRoYXQgcmV0cmVhdCBzdGVwIG1heSBiZSBw ZXJmb3JtZWQNCj4gbXVsdGlwbGUgdGltZXMgYmFjayBhbmQgZm9ydGguDQo+IA0KPiBCZXN0IHJl Z2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+yMs6 IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGp1bmlwZXIubmV0XQ0KPiA+ILeiy83KsbzkOiAy MDEzxOo31MIxMMjVIDI6MTMNCj4gPiDK1bz+yMs6IFh1eGlhb2h1OyBjdXJ0aXNAaXB2Ni5vY2Nu Yy5jb207IE1QTFMgV0cgTWFpbGluZyBMaXN0Ow0KPiA+IGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhw cmVzcy1wYXRoIGF1dGhvcnM7IFRoZSBHcmVhdCBhbmQgTWlnaHR5IE1QTFMNCj4gPiBDby1DaGFp cnMNCj4gPiDW98ziOiBSRTogW21wbHNdIGRyYWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRo LTAyICh3YXMgTVBMUy1SVCByZXZpZXcNCj4gPiBvZiAuLi4pDQo+ID4NCj4gPiBDYW4geW91IGNs YXJpZnkgd2h5IHlvdSB0aGluayBjb25zdHJhaW5pbmcgdGhlIGxpbmtzIGV4cGxvcmVkIGJhc2Vk DQo+ID4gdXBvbiBhIGxhdGVuY3kgaXNuJ3QgYSBwcmFjdGljYWwgYXBwcm9hY2g/ICBJdCBpcyBz dGlsbCBPKG4gbG9nIG4pIC0NCj4gPiBncmFudGVkLCBpdCdzIGEgaGV1cmlzdGljIGFuZCBtYXkg bm90IGZpbmQgYSBwYXRoLg0KPiA+DQo+ID4gQWxpYQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5j b21dDQo+ID4gU2VudDogVHVlc2RheSwgQXByaWwgMjMsIDIwMTMgOTo0NCBQTQ0KPiA+IFRvOiBj dXJ0aXNAaXB2Ni5vY2NuYy5jb207IE1QTFMgV0cgTWFpbGluZyBMaXN0Ow0KPiA+IGRyYWZ0LWF0 bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoIGF1dGhvcnM7IFRoZSBHcmVhdCBhbmQgTWlnaHR5IE1Q TFMNCj4gPiBDby1DaGFpcnMNCj4gPiBTdWJqZWN0OiByZTogW21wbHNdIGRyYWZ0LWF0bGFzLW1w bHMtdGUtZXhwcmVzcy1wYXRoLTAyICh3YXMgTVBMUy1SVA0KPiA+IHJldmlldyBvZiAuLi4pDQo+ ID4NCj4gPiA+ICAgICBzL1doaWxlIGl0IGhhcyBiZWVuIHBvc3NpYmxlIHRvIGNvbXB1dGUgYSBD U1BGL0l0IGlzIHBvc3NpYmxlIHRvDQo+ID4gPiAgICAgY29tcHV0ZSBhIENTUEYvDQo+ID4gPiAg ICAgcy9JbnN0ZWFkIG9mIHRoaXMgYXBwcm9hY2ggdG8gbWluaW1pemUgcGF0aCBsYXRlbmN5LCBh bi9Bbg0KPiA+ID4gICAgIGFsdGVybmF0aXZlIHRvIHRoaXMgYXBwcm9hY2ggdG8gbWluaW1pemUg cGF0aCBsYXRlbmN5IGlzIGFuDQo+ID4gPiAgICAgYXBwcm9hY2ggdG8gcGxhY2UgYSB1cHBlciBi b3VuZCBvbiBwYXRoIGxhdGVuY3kuICBBbi8NCj4gPiA+ICAgICBOb3RlOiBib3RoIGFwcHJvYWNo ZXMgYXJlIHZhbGlkLg0KPiA+DQo+ID4gSSB0aGluayB0aGUgYWx0ZXJuYXRpdmUgYXBwcm9hY2gg KGkuZS4sIHRvIGNvbXB1dGUgYSBDU1BGIHBhdGggYmFzZWQNCj4gPiBvbiB0aGUgVEUgbWV0cmlj IHdoaWxlIHBsYWNpbmcgYSB1cHBlciBib3VuZCBvbiB0aGUgcGF0aCBsYXRlbmN5KSBpcw0KPiA+ IG5vdCBhIHByYWN0aWNhbCBhcHByb2FjaCBkdWUgdG8gY29tcHV0YXRpb25hbGx5IGNvbXBsZXhp dHkuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPg0KDQo= From akatlas@gmail.com Thu Jul 11 23:35:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1C221F9C38 for ; Thu, 11 Jul 2013 23:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.353 X-Spam-Level: ** X-Spam-Status: No, score=2.353 tagged_above=-999 required=5 tests=[AWL=-3.882, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQjIBA-cX++l for ; Thu, 11 Jul 2013 23:35:19 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2921C21F9C6E for ; Thu, 11 Jul 2013 23:35:19 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so19755049iea.11 for ; Thu, 11 Jul 2013 23:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tD5JZv3YTO0f8kPF1eWHPgJ2/ZcJxAmIQ9rUH0CQKNE=; b=Q8hgPfJgbhqSwNr8YghHQY7+yT0mBTNowMZ9p6RYNiAwGjGX3Dj+EJM3u1TwXFgRHi 2HhYnrswnSBeusmQo6Na7STNTgQpKi76dKAtuihDDNGqjH0UqJN0hpk3kyC6JnK0a3u2 VGgKNxc9zRTa6ja5BRHupVEqhIoHkkvWDew9+M6pesjt658AV4cq5xPTccIg4RWxt8PT IMDxTSeLIhysvN2+5d4S25YTu+Nlp7Vt/xZBwQREIdyoazFs/aamwwCiaiXz+MTZyhJF 1bgyRHdXnFtzZgdq//gmKgYteor+MDNR3DwAChRZ0nLMgkiMcJQV5UJl7igxkYcFAowL cIvQ== MIME-Version: 1.0 X-Received: by 10.50.3.103 with SMTP id b7mr437604igb.54.1373610918587; Thu, 11 Jul 2013 23:35:18 -0700 (PDT) Received: by 10.64.165.197 with HTTP; Thu, 11 Jul 2013 23:35:18 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDFF4@NKGEML512-MBS.china.huawei.com> References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDF14@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDFF4@NKGEML512-MBS.china.huawei.com> Date: Fri, 12 Jul 2013 02:35:18 -0400 Message-ID: From: Alia Atlas To: Xuxiaohu Content-Type: multipart/alternative; boundary=089e013c61e0dcb5b904e14ab6a8 Cc: MPLS WG Mailing List , The Great and Mighty MPLS Co-Chairs , Alia Atlas , draft-atlas-mpls-te-express-path authors Subject: Re: [mpls] =?gb2312?b?tPC4tDogZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNz?= =?gb2312?b?LXBhdGgtMDIgKHdhcyBNUExTLVJUIHJldmlldyBvZiAuLi4p?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 06:35:20 -0000 --089e013c61e0dcb5b904e14ab6a8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Happens to all of us. Thanks for doing the review. Alia On Fri, Jul 12, 2013 at 2:33 AM, Xuxiaohu wrote: > Oh, yes, you are right. Sorry for my confusion. > > Best regards, > Xiaohu > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Alia Atlas [mailto:akatlas@juniper.net] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C212=C8=D5 13:05 > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; curtis@ipv6.occnc.com; MPLS WG Mailing Li= st; > > draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > > Co-Chairs > > =D6=F7=CC=E2: RE: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-= RT review > > of ...) > > > > Hi Xiaohu, > > > > No, there is no retreating. I think you're describing something based > on a > > depth-first-search that's cost aware??? I don't know but it's not based > on a > > normal SPF. The pseudo-code I gave is correct. > > > > Here's the brief example - I mean an SPF where links aren't explored i= f > they > > result in a path that is too long. > > > > Step 1 CSPF: A has cost 0, delay 0 - explore A's links > > B.cost =3D 1 B.delay=3D 1 insert B into the fibheap ordered= by > cost > > C.cost =3D 10 C.delay =3D 1 insert C into the fibheap orde= red by > > cost > > > > Step 2 CSPF: remove first node from fibheap - it is B - explore B's > links > > Via B->D would give D.delay to be 11 - over bound so don't sa= ve > > Via B->E would give E.delay to be 11 - over bound so don't sa= ve > > > > Step 3 CSPF: remove first node from fibheap - it is C - explore C's > links > > Via C->F would give F.delay=3D2 -under bound so save > > F.cost =3D 11 F.delay =3D 2 insert F into fibheap > > > > Step 4 CSPF: remove first node from fibheap - it is F > > CSPF was from A to F and F is now minimized so terminate. > > > > Alia > > > > -----Original Message----- > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > Sent: Thursday, July 11, 2013 10:52 PM > > To: Alia Atlas; curtis@ipv6.occnc.com; MPLS WG Mailing List; > > draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > > Co-Chairs > > Subject: =B4=F0=B8=B4: [mpls] draft-atlas-mpls-te-express-path-02 (was = MPLS-RT > > review of ...) > > > > Hi Alia, > > > > Let me give an example as illustrated below: > > > > A--------(Metric:1; Delay:1)-------B---(Metric:1; > Delay:10)---D-----------F > > | | / | > > | +---(Metric:2; Delay:10)---E--------/ | > > | | > > | | > > +-------(Metric:10; Delay:1)------C--------(Metric:1; Delay > > +1)--------------+ > > > > Assume A wants to find an optimal path to F with delay upper bound of > 10. In > > step 1, A selects B among all of its adjacent routers as the next_route= r > since its > > distance to other adjacent routers (i.e., C) is larger than that to B. > in step 2, B > > finds that neither of its adjacent routers (i.e., D and E) could be > selected as > > next_router since the latency of the either path (i.e., A->B->D and > A->B->E) is > > already beyond the e2e delay bound. At a result, in step 3, A has to > give up B > > and then explore its other adjacent routers. Is that the heuristic > algorithm you > > meant? If so, it would be better to describe the step 3 (i.e., a retrea= t > step) as > > well in your pseudo-code while mentioning that retreat step may be > performed > > multiple times back and forth. > > > > Best regards, > > Xiaohu > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: Alia Atlas [mailto:akatlas@juniper.net] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C210=C8=D5 2:13 > > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; curtis@ipv6.occnc.com; MPLS WG Mailing = List; > > > draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > > > Co-Chairs > > > =D6=F7=CC=E2: RE: [mpls] draft-atlas-mpls-te-express-path-02 (was MPL= S-RT review > > > of ...) > > > > > > Can you clarify why you think constraining the links explored based > > > upon a latency isn't a practical approach? It is still O(n log n) - > > > granted, it's a heuristic and may not find a path. > > > > > > Alia > > > > > > -----Original Message----- > > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > > Sent: Tuesday, April 23, 2013 9:44 PM > > > To: curtis@ipv6.occnc.com; MPLS WG Mailing List; > > > draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > > > Co-Chairs > > > Subject: re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT > > > review of ...) > > > > > > > s/While it has been possible to compute a CSPF/It is possible t= o > > > > compute a CSPF/ > > > > s/Instead of this approach to minimize path latency, an/An > > > > alternative to this approach to minimize path latency is an > > > > approach to place a upper bound on path latency. An/ > > > > Note: both approaches are valid. > > > > > > I think the alternative approach (i.e., to compute a CSPF path based > > > on the TE metric while placing a upper bound on the path latency) is > > > not a practical approach due to computationally complexity. > > > > > > Best regards, > > > Xiaohu > > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --089e013c61e0dcb5b904e14ab6a8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Happens to all of us.  Thanks for doing the review.
Alia


On Fri, Jul 12, 2013 at 2:33 AM, Xuxiaohu &l= t;xuxiaohu@huawei.= com> wrote:
Oh, yes, you are right. Sorry for my confusi= on.

Best regards,
Xiaohu

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Alia Atlas [mailto:akatlas@juniper.net]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C212=C8=D5 13:05
> =CA=D5=BC=FE=C8=CB: Xuxiaohu; = curtis@ipv6.occnc.com; MPLS WG= Mailing List;
> draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > Co-Chairs
> =D6=F7=CC=E2: RE: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS= -RT review
> of ...)
>
> Hi Xiaohu,
>
> No, there is no retreating.  I think you're describing someth= ing based on a
> depth-first-search that's cost aware??? I don't know but it= 9;s not based on a
> normal SPF.  The pseudo-code I gave is correct.
>
> Here's the brief example -  I mean an SPF where links aren= 9;t explored if they
> result in a path that is too long.
>
> Step 1 CSPF:   A has cost 0, delay 0   - explore A's lin= ks
>           B.cost =3D 1  B.delay=3D 1 &nb= sp;insert B into the fibheap ordered by cost
>           C.cost =3D 10  C.delay =3D 1 &= nbsp; insert C into the fibheap ordered by
> cost
>
> Step 2 CSPF:  remove first node from fibheap - it is B  - ex= plore B's links
>           Via B->D would give D.delay to b= e 11 - over bound so don't save
>           Via B->E would give E.delay to b= e 11 - over bound so don't save
>
> Step 3 CSPF: remove first node from fibheap  - it is C - explore = C's links
>             Via C->F would give F.del= ay=3D2 -under bound so save
>                  F.cost = =3D 11   F.delay =3D 2  insert F into fibheap
>
> Step 4 CSPF:  remove first node from fibheap - it is F
>          CSPF was from A to F and F is now mi= nimized so terminate.
>
> Alia
>
> -----Original Message-----
> From: Xuxiaohu [mailto:xuxiaohu= @huawei.com]
> Sent: Thursday, July 11, 2013 10:52 PM
> To: Alia Atlas; curtis@ipv6.o= ccnc.com; MPLS WG Mailing List;
> draft-atlas-mpls-te-express-path authors; The Great and Mighty MPLS > Co-Chairs
> Subject: =B4=F0=B8=B4: [mpls] draft-atlas-mpls-te-express-path-02 (was= MPLS-RT
> review of ...)
>
> Hi Alia,
>
> Let me give an example as illustrated below:
>
> A--------(Metric:1; Delay:1)-------B---(Metric:1; Delay:10)---D-------= ----F
> |                    = ;    |                 &n= bsp;         / |
> |                    = ;    +---(Metric:2; Delay:10)---E--------/  |
> |                    = ;                     &nb= sp;           |
> |                    = ;                     &nb= sp;           |
> +-------(Metric:10; Delay:1)------C--------(Metric:1; Delay
> +1)--------------+
>
> Assume A wants to find an optimal path to F with delay upper bound of = 10. In
> step 1, A selects B among all of its adjacent routers as the next_rout= er since its
> distance to other adjacent routers (i.e., C) is larger than that to B.= in step 2, B
> finds that neither of its adjacent routers (i.e., D and E) could be se= lected as
> next_router since the latency of the either path (i.e., A->B->D = and A->B->E) is
> already beyond the e2e delay bound. At a result, in step 3, A has to g= ive up B
> and then explore its other adjacent routers. Is that the heuristic alg= orithm you
> meant? If so, it would be better to describe the step 3 (i.e., a retre= at step) as
> well in your pseudo-code while mentioning that retreat step may be per= formed
> multiple times back and forth.
>
> Best regards,
> Xiaohu
>
> > -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> > =B7=A2=BC=FE=C8=CB: Alia Atlas [mailto:akatlas@juniper.net]
> > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C210=C8=D5 2:13
> > =CA=D5=BC=FE=C8=CB: Xuxiaohu; curtis@ipv6.occnc.com; MPLS WG Mailing List;
> > draft-atlas-mpls-te-express-path authors; The Great and Mighty MP= LS
> > Co-Chairs
> > =D6=F7=CC=E2: RE: [mpls] draft-atlas-mpls-te-express-path-02 (was= MPLS-RT review
> > of ...)
> >
> > Can you clarify why you think constraining the links explored bas= ed
> > upon a latency isn't a practical approach?  It is still = O(n log n) -
> > granted, it's a heuristic and may not find a path.
> >
> > Alia
> >
> > -----Original Message-----
> > From: Xuxiaohu [mailto:xux= iaohu@huawei.com]
> > Sent: Tuesday, April 23, 2013 9:44 PM
> > To: curtis@ipv6.occnc.co= m; MPLS WG Mailing List;
> > draft-atlas-mpls-te-express-path authors; The Great and Mighty MP= LS
> > Co-Chairs
> > Subject: re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS= -RT
> > review of ...)
> >
> > >     s/While it has been possible to compute a CSPF= /It is possible to
> > >     compute a CSPF/
> > >     s/Instead of this approach to minimize path la= tency, an/An
> > >     alternative to this approach to minimize path = latency is an
> > >     approach to place a upper bound on path latenc= y.  An/
> > >     Note: both approaches are valid.
> >
> > I think the alternative approach (i.e., to compute a CSPF path ba= sed
> > on the TE metric while placing a upper bound on the path latency)= is
> > not a practical approach due to computationally complexity.
> >
> > Best regards,
> > Xiaohu
> >
> >

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

--089e013c61e0dcb5b904e14ab6a8-- From sebastien.jobert@orange.com Fri Jul 12 08:59:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333BE21E8088; Fri, 12 Jul 2013 08:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaIwRebpNK1C; Fri, 12 Jul 2013 08:59:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9955621F9FF2; Fri, 12 Jul 2013 08:59:40 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 0D876264EF5; Fri, 12 Jul 2013 17:59:40 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E2B2E4C060; Fri, 12 Jul 2013 17:59:39 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 17:59:39 +0200 From: To: Shahram Davari Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfkYcnR6ysw913kqs7UWvMFFaBZlf/wSggAASeYCAAKpT8A== Date: Fri, 12 Jul 2013 15:59:38 +0000 Message-ID: <28095_1373644779_51E027EB_28095_890_1_7F67B91079F7C74F9DAB55FC7872661E144BDE@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> <17365_1373580614_51DF2D46_17365_10736_1_7F67B91079F7C74F9DAB55FC7872661E143FA5@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4A6CE49E6084B141B15C0713B8993F281BE85AD7@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE85AD7@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 15:59:47 -0000 Hi Shahram, Thanks for the reply. I copied your text below in order to give some more feedback, to make it mo= re readable: "SD> So you agree that you need some interworking function which can conver= t Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, et= c. I am sure you don't want to do this interworking in the CPU, do you?" S=E9bastien: If such IWF occurs, it would involve several different physica= l ports. Then, I assume that some specific PTP HW would have to be supporte= d by the various ports involved for HW timestamping purposes, which may rel= y on different mappings if needed. But then, I assume that the relevant PTP= information is recovered from the PTP packets, and transmitted to the cent= ral clock in the equipment, without information about the mapping initially= used, which is at the end a transport facility only. I am then not sure wh= y such IWF is really needed in HW: the PTP packets may simply use different= mappings at the ingress and at the egress, as far as the relevant informat= ion has been processed inside the device; the IWF is at the end realized by= the entire device, not at a single place. This may look however more like = a BC-model only, but my assumption is that it should be possible to design = a TC with a similar model in which the PTP messages are terminated and proc= essed (again, refer to the draft that we presented in Paris). I don't see a= ny particular IWF problem then from the HW perspective (that being said, I = recognized that I am not expert in this field, so your feedback is really w= elcomed). "So you need new HW. Basically what you are saying is that carry 1588 over = the server layer such as Ethernet or OTN, etc. The problem as you figured o= ut yourself is that the span of the server layer is not the same span as th= e LSP. Therefore you either need to terminate the 1588 and regenerate it (B= C), or as you said you need service interworking." S=E9bastien: OK, I see where we diverge then. First, my assumption is that = we can build a TC-model in which the PTP messages are terminated and proces= sed (it is even better IMHO, as it avoids the layer violation problem, plea= se refer again to our draft from Paris). Second, my understanding is that y= our mechanism is really only for a TC-model used over an MPLS layer that "d= oes not terminate the PTP messages" (which I think is not a good model for = telecoms), and not really for a BC system. The layer violation problem of T= Cs should not be under-estimated IMHO; IEEE has delivered to ITU-T a very c= lear message that such architectural problems should be avoided. "SD> I haven't seen that. Could you please email that to me." S=E9bastien: draft from Paris =3D> http://tools.ietf.org/html/draft-jobert-= tictoc-ptp-link-local-00=20 "SD> There are networks that don't do IP routing. PTN networks that are bas= ed on MPLS-TP don't do IP routing at all. You can refer to come of the Chin= a and Japan carriers. I agree that Synch can be uncorrelated to data, but = you the issue is that the logically out-of-band network you are referring t= o in most cases has short span (such as one link)" S=E9bastien: such networks do not have to do IP *routing* (or Ethernet swit= ching) in the model that I propose, because in all the cases, the PTP messa= ges are terminated and processed. The IP or Ethernet layers are only used a= s "encapsulations", not for routing (otherwise, the layer violation is ther= e).=20 "SD> While the model that you describe where a Transit provider also provid= es reference clock is possible, but it require 1588 protocol exchange betwe= en Operator and the service provider that leases from operator. And I thin= k it is not embraced in the industry (as of yet). But 1588 transparency is = simple and does not require 1588 protocol exchange between operator and ser= vice provider." S=E9bastien: I really disagree: the model where the carrier operator delive= rs his timing reference as part of the service exists today in many cases (= I have several examples in mind for frequency synchronization). However, th= e "timing transparency" model in which the network operator puts very speci= fic HW in his equipment to ensure transparency to the mobile operator is re= ally a scenario that I have never seen, and that I really doubt will happen= one day (perhaps the only exception is SyncE timing transparency over OTN,= which implies specific mappings, but I consider this as different, because= there is no other way to carry timing over OTN than transparency to the cl= ient signals, so the carrier operator has anyway to implement such new mapp= ing for his own purpose - it is not a feature dedicated to the mobile opera= tor). In conclusion, from my perspective: - I think we have now identified the points that we do not agree: - PTP clock that terminates the PTP messages vs PTP clock that does not (a= nd layer violation implications) - Real need for "timing transparency" as far as PTP is concerned - These points are not related to issues with regards to the solution that = you propose, but to the need for this solution. Depending on the perspectiv= e, the MPLS layer may not need to be used to carry PTP messages over networ= ks that operate the MPLS layer. - So, my understanding is that the solution presented in your draft would b= e applicable only to an operator who would built a network with TC everywhe= re based on the MPLS layer, in order to provide timing transparency capabil= ity to other operators. Given that this timing transparency is subject to d= ebate, I wonder if there are operators having such requirements? - I wonder if your solution really makes sense for a BC-model? Thanks for the interesting discussion. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: vendredi 12 juillet 2013 01:06 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastien, Please see my response inline. Thank Shahram -----Original Message----- From: sebastien.jobert@orange.com [mailto:sebastien.jobert@orange.com]=20 Sent: Thursday, July 11, 2013 3:10 PM To: Shahram Davari Cc: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Shahram, Thanks for your reply and explanations. See some comments below in your tex= t. It is interesting discussion. Thanks. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: jeudi 11 juillet 2013 16:51 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastian, Thanks for your comments. This draft is an IETF working draft and was accep= ted as such based on IETF consensus. [JOBERT Sebastien RD-CORE-LAN] Absolutely, and this is not something that I= dispute. However, since it has been asked to the mailing list to indicate = support and provide comments, I do not feel that giving an opinion was outs= ide the IETF process. The group may or may not consider this input at the e= nd. Are you saying there is no need to carry 1588 in the networks that use MPLS= or are you saying there are other methods which are simpler?=20 [JOBERT Sebastien RD-CORE-LAN] Of course, there is a need to carry PTP mess= ages over networks that operate the MPLS layer; what I am saying is simply = that, over such networks, I do not think that carrying these PTP messages i= nside an MPLS layer is required. Other existing encapsulations are fine and= probably simpler, indeed. If you mean the former, then I disagree and I can give you examples from Ch= ina mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul acce= ss and aggregation network are MPLS and they wang to use 1588 at the cell s= ite. [JOBERT Sebastien RD-CORE-LAN] Of course, we agree on this point: MPLS netw= orks are widely deployed. It is on the method to carry PTP messages that we= have different views, I think. If you mean the later one then I disagree as well. [JOBERT Sebastien RD-CORE-LAN] OK, let's discuss then to see where the diff= erent views are. If you are proposing to use Ethernet encapsulation for 1588 without MPLS, t= hen the problem is that not all links are Ethernet.=20 [JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only o= ne possibility, as IP mapping is also possible, see below), the links that = use an Ethernet mapping for the PTP messages must obviously support Etherne= t. That being said: 1- not all the links must use this mapping, it is possi= ble to mix different mappings (e.g. Ethernet and IP) and allow some kind of= interworking mechanisms;=20 SD> So you agree that you need some interworking function which can convert= Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, etc= . I am sure you don't want to do this interworking in the CPU, do you? So y= ou need new HW. Basically what you are saying is that carry 1588 over the s= erver layer such as Ethernet or OTN, etc. The problem as you figured out yo= urself is that the span of the server layer is not the same span as the LSP= . Therefore you either need to terminate the 1588 and regenerate it (BC), o= r as you said you need service interworking. 2- it is not because the PTP messages are carried over Ethernet that the en= tire traffic must also be carried over Ethernet, it is fully possible to en= visage that only the "synchronization plane" be over Ethernet, and the data= and control planes be over MPLS if desirable. Do we agree on this? SD> Yes. But as I said the issue is that the span of server layer may not b= e the same as the LSP. Even when all links are Ethernet, Ethernet is just used for P2P link and is= not switched in routers.=20 [JOBERT Sebastien RD-CORE-LAN] Some routers may also implement a L2... SD> yes some do L2 switching, but some don't. This means you can only do BC in such cases.=20 [JOBERT Sebastien RD-CORE-LAN] No, there are ways to build a TC system with= Ethernet encapsulation (we actually presented a draft in Paris providing o= ne possible solution). SD> I haven't seen that. Could you please email that to me. If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then= this is exactly what we do in this draft. [JOBERT Sebastien RD-CORE-LAN] Indeed, but this is not what I am proposing = ;-) If you are proposing to use IP encapsulation for 1588, then you are either = proposing to use IP without MPLS encapsulation, which doesn't work since ob= viously many networks such as MPLS-TP can't perform IP routing.=20 [JOBERT Sebastien RD-CORE-LAN] This is probably the main point where we do = not agree. I can hardly imagine personally a network operating an MPLS laye= r where everything is carried over MPLS. As mentioned before, there is no p= roblem in having the data and control planes over MPLS if desirable (althou= gh I doubt that the control plane be always over MPLS, but it is a differen= t debate), and the "synchronization plane" over IP. Synchronization is gene= rally uncorrelated from the other planes: consider for instance Synchronous= Ethernet, it is a layer 1 mechanism, which is totally uncorrelated from th= e way the data plane is transported. Correlating these layers is not necess= ary. SD> There are networks that don't do IP routing. PTN networks that are base= d on MPLS-TP don't do IP routing at all. You can refer to come of the China= and Japan carriers. I agree that Synch can be uncorrelated to data, but y= ou the issue is that the logically out-of-band network you are referring to= in most cases has short span (such as one link) and therefore can't suppor= t 1588 end-to-end TC. Or you are proposing to use IP with MPLS encapsulation, which is exactly wh= at we are doing in this draft. [JOBERT Sebastien RD-CORE-LAN] No, as I mentioned, I do not think that such= encapsulation is required. The other issue is assume a service provider who is using say Ethernet enca= psulation to carry 1588, leases some connections from another network opera= tor. The network operator needs to carry these 1588 messages without termin= ating them but also needs to do TC on them.=20 [JOBERT Sebastien RD-CORE-LAN] Another point where we also probably disagre= e, I believe. TC is one possible solution, but there are many other ways to= enable "timing transparency" (for instance, without going into the details= : differential methods, "network TC" concept, etc.). However, the real ques= tion seems to be: is timing transparency a real requirement? My opinion is = that this is not a strong requirement, because at the end, for mobile appli= cations, one has to deliver some sort of UTC traceable signal. Hence, where= the synchronization reference is coming from is not really important, as l= ong as the synchronization requirements are met, because the ultimate sourc= e is at the end the same for everyone: UTC. Future applications do not real= ly have plesiochronous requirements anymore. I really believe that a scenar= io where the carrier operator is providing the reference to the mobile oper= ator, in case of leased lines, is what will occur. Otherwise, this will be = a scenario where the carrier operator does not provide any support at all f= or PTP and where the mobile operator is on its own to get rid of the PDV an= d asymmetry generated by the network. I cannot imagine why the carrier oper= ator would like to spend money on hardware support such as TC in every sing= le NEs simply to provide to other operators some kind of timing transparenc= y not really required; the carrier operator would better spend his money bu= ilding a robust network enabling to deliver very accurate synchronization, = and provide his own timing reference, with possible guarantees, as part of = the leased line offer. SD> While the model that you describe where a Transit provider also provide= s reference clock is possible, but it require 1588 protocol exchange betwee= n Operator and the service provider that leases from operator. And I think= it is not embraced in the industry (as of yet). But 1588 transparency is s= imple and does not require 1588 protocol exchange between operator and serv= ice provider. Using flat Ethernet switching is not possible since the operator network is= carrying traffic from many other customers and his network is virtualized. SD> I agree with you that if the entire network is built out of Switch-Rout= ers and all links are Ethernet then you probably don't need this draft and = can do 1588 over Ethernet end-to-end. I suggest you reading the draft first. [JOBERT Sebastien RD-CORE-LAN] Good suggestion indeed ;-) I'll do this for = my own education; however, still, I believe that the use cases that this dr= aft tries to address are subject to discussion. Regards, Shahram On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: > Hi, >=20 > In general, I do not support this document, mainly because I don't think = that the problem statement it tries to address really exists. > That being said, I did not check more in details its content, so I cannot= judge whether or not what it proposes is correct. > I just think that there is no use case for this mechanism. >=20 > "There is a need to transport Timing messages over MPLS networks while su= pporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock= (OC) functionality in the LER and LSRs in the MPLS network." =3D> this sta= tement is not supported by any argumentation, and each time that the point = has been raised on the mailing list, no clear answer or use case was provid= ed in my opinion. As mentioned several times, I do not think that there is = a real need to involve the MPLS layer to transport PTP messages; using the = existing mappings defined in IEEE 1588-2008 is sufficient for all the use c= ases that I can imagine. And I have not heard any other use case from other= industries than telecoms. >=20 > Operators are requesting Ethernet encapsulation for PTP (full timing supp= ort from the network scenario) or IP mapping (partial timing support from t= he network scenario and no timing support scenario), but not MPLS encapsula= tion... >=20 > A quick feedback from an operator monitoring this topic from the beginnin= g. >=20 > Thanks for considering (or not) this input. >=20 > BR, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky > Envoy=E9 : vendredi 5 juillet 2013 18:47 > =C0 : Yaakov Stein; tictoc@ietf.org > Cc : mpls@ietf.org > Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > Do not support > - As document describing Transporting Timing messages over MPLS Networks = it comes short in justification of complexity of PTP LSP for non-1588 proto= cols; > - I do believe that even for IEEE 1588 distribution through MPLS-TP domai= n PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnec= ting ports that support IEEE 1588 (new capability advertised in IGP-TE) is = architectually clean and sufficient. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:21 AM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From akatlas@juniper.net Fri Jul 12 10:40:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0D11E8150 for ; Fri, 12 Jul 2013 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.583 X-Spam-Level: X-Spam-Status: No, score=0.583 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvSkZ6KtZhMZ for ; Fri, 12 Jul 2013 10:40:08 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 64FCF21F9E22 for ; Fri, 12 Jul 2013 10:40:08 -0700 (PDT) Received: from mail102-db8-R.bigfish.com (10.174.8.248) by DB8EHSOBE015.bigfish.com (10.174.4.78) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 17:40:07 +0000 Received: from mail102-db8 (localhost [127.0.0.1]) by mail102-db8-R.bigfish.com (Postfix) with ESMTP id 60C05480747 for ; Fri, 12 Jul 2013 17:40:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz9371I936eI103dK542Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail102-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=akatlas@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail102-db8 (localhost.localdomain [127.0.0.1]) by mail102-db8 (MessageSwitch) id 1373650804394906_30826; Fri, 12 Jul 2013 17:40:04 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.249]) by mail102-db8.bigfish.com (Postfix) with ESMTP id 5510D60046 for ; Fri, 12 Jul 2013 17:40:04 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 17:40:00 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Jul 2013 10:39:57 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 12 Jul 2013 10:39:57 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 12 Jul 2013 10:52:37 -0700 Received: from mail69-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 17:39:56 +0000 Received: from mail69-va3 (localhost [127.0.0.1]) by mail69-va3-R.bigfish.com (Postfix) with ESMTP id 363E52E075F for ; Fri, 12 Jul 2013 17:39:56 +0000 (UTC) Received: from mail69-va3 (localhost.localdomain [127.0.0.1]) by mail69-va3 (MessageSwitch) id 1373650723198308_4343; Fri, 12 Jul 2013 17:38:43 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.236]) by mail69-va3.bigfish.com (Postfix) with ESMTP id 1E51B2C008E for ; Fri, 12 Jul 2013 17:38:39 +0000 (UTC) Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Jul 2013 17:38:34 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.99]) by BY2PRD0510HT002.namprd05.prod.outlook.com ([10.255.84.37]) with mapi id 14.16.0324.000; Fri, 12 Jul 2013 17:38:30 +0000 From: Alia Atlas To: MPLS WG Mailing List Thread-Topic: New Version Notification for draft-atlas-mpls-ldp-mrt-00.txt Thread-Index: AQHOfyZ2cznaploBb0axNrSeL3RxhZlhTrdg Date: Fri, 12 Jul 2013 17:38:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [mpls] FW: New Version Notification for draft-atlas-mpls-ldp-mrt-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, 12 Jul 2013 17:40:14 -0000 V2Ugd291bGQgYmUgaW50ZXJlc3RlZCBpbiBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0LiAgSXQgZGVz Y3JpYmVzIHRoZSBtaW5pbWFsIExEUCBleHRlbnNpb25zIG5lZWRlZCB0byBzdXBwb3J0IE1SVCBm YXN0LXJlcm91dGUuDQoNClRoYW5rcyENCkFsaWENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkgMTIsIDIwMTMgMTozNyBQTQ0KVG86IEtp c2hvcmUgVGlydXZlZWRodWxhOyBBbGlhIEF0bGFzOyBJSnNicmFuZCBXaWpuYW5kczsgSmVmZiBU YW50c3VyYQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hdGxh cy1tcGxzLWxkcC1tcnQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWF0 bGFzLW1wbHMtbGRwLW1ydC0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBBbGlhIEF0bGFzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC1hdGxhcy1tcGxzLWxkcC1tcnQNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIExE UCBFeHRlbnNpb25zIHRvIFN1cHBvcnQgTWF4aW1hbGx5IFJlZHVuZGFudCBUcmVlcw0KQ3JlYXRp b24gZGF0ZToJIDIwMTMtMDctMTINCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVt YmVyIG9mIHBhZ2VzOiAxMQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1hdGxhcy1tcGxzLWxkcC1tcnQtMDAudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXRsYXMtbXBscy1s ZHAtbXJ0DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWF0bGFzLW1wbHMtbGRwLW1ydC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgZXh0ZW5zaW9ucyB0byBMRFAgdG8gc3VwcG9ydCB0aGUgY3JlYXRpb24gb2YNCiAg IGxhYmVsLXN3aXRjaGVkIHBhdGhzIGZvciBNYXhpbWFsbHkgUmVkdW5kYW50IFRyZWVzIChNUlQp LiAgQSBwcmltZQ0KICAgdXNlIG9mIE1SVHMgaXMgZm9yIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBJ UC9MRFAgRmFzdC1SZXJvdXRlIChNUlQtDQogICBGUlIpLg0KDQogICBUaGUgc29sZSBwcm90b2Nv bCBleHRlbnNpb24gdG8gTERQIGlzIHNpbXBseSB0aGUgYWJpbGl0eSB0byBhZHZlcnRpc2UNCiAg IGFuIE1SVCBDYXBhYmlsaXR5LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhhdCBleHRlbnNp b24gYW5kIHRoZQ0KICAgYXNzb2NpYXRlZCBiZWhhdmlvciBleHBlY3RlZCBmb3IgTFNScyBhbmQg TEVScyBhZHZlcnRpc2luZyB0aGUgTVJUDQogICBDYXBhYmlsaXR5Lg0KDQogICBNUlQtRlJSIHVz ZXMgTERQIG11bHRpLXRvcG9sb2d5IGV4dGVuc2lvbnMgYW5kIHJlcXVpcmVzIHRocmVlDQogICBk aWZmZXJlbnQgbXVsdGktdG9wb2xvZ3kgSURzIHRvIGJlIGFsbG9jYXRlZCBmcm9tIHRoZSBMRFAg TVQtSUQNCiAgIHNwYWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQoNCg== From davari@broadcom.com Fri Jul 12 11:10:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6E11E811E; Fri, 12 Jul 2013 11:10:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8OvWVgqRu85; Fri, 12 Jul 2013 11:10:27 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id AC29C11E8162; Fri, 12 Jul 2013 11:10:23 -0700 (PDT) Received: from [10.9.208.53] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 12 Jul 2013 11:00:41 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 12 Jul 2013 11:10:12 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 12 Jul 2013 11:10:11 -0700 From: "Shahram Davari" To: "sebastien.jobert@orange.com" Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfkYcnR6ysw913kqs7UWvMFFaBZlf/wSggAASeYCAAKpT8IAAmZ3w Date: Fri, 12 Jul 2013 18:10:11 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE86987@SJEXCHMB12.corp.ad.broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> <17365_1373580614_51DF2D46_17365_10736_1_7F67B91079F7C74F9DAB55FC7872661E143FA5@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4A6CE49E6084B141B15C0713B8993F281BE85AD7@SJEXCHMB12.corp.ad.broadcom.com> <28095_1373644779_51E027EB_28095_890_1_7F67B91079F7C74F9DAB55FC7872661E144BDE@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <28095_1373644779_51E027EB_28095_890_1_7F67B91079F7C74F9DAB55FC7872661E144BDE@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DFE9BC32L847872214-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jul 2013 18:10:32 -0000 Hi Sebastien, Pls see inline. Thx SD -----Original Message----- From: sebastien.jobert@orange.com [mailto:sebastien.jobert@orange.com]=20 Sent: Friday, July 12, 2013 9:00 AM To: Shahram Davari Cc: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Shahram, Thanks for the reply. I copied your text below in order to give some more feedback, to make it mo= re readable: "SD> So you agree that you need some interworking function which can conver= t Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, et= c. I am sure you don't want to do this interworking in the CPU, do you?" S=E9bastien: If such IWF occurs, it would involve several different physica= l ports. Then, I assume that some specific PTP HW would have to be supporte= d by the various ports involved for HW timestamping purposes, which may rel= y on different mappings if needed. But then, I assume that the relevant PTP= information is recovered from the PTP packets, and transmitted to the cent= ral clock in the equipment, without information about the mapping initially= used, which is at the end a transport facility only. I am then not sure wh= y such IWF is really needed in HW: the PTP packets may simply use different= mappings at the ingress and at the egress, as far as the relevant informat= ion has been processed inside the device; the IWF is at the end realized by= the entire device, not at a single place. This may look however more like = a BC-model only, but my assumption is that it should be possible to design = a TC with a similar model in which the PTP messages are terminated and proc= essed (again, refer to the draft that we presented in Paris). I don't see a= ny particular IWF problem then from the HW perspective (that being said, I = recognized that I am not expert in this field, so your feedback is really w= elcomed). SD> If all links are Ethernet, and if your switch can do Ethernet bridging = then there is no issue. But if all links are not Ethernet then as you said = you need to convert from Ethernet to say IP. This can off course be done in= CPU, but then it will add significant PDV that makes it useless. So you wo= uld need new HW. Also if all links are Ethernet, based on your own draft, you still want to = use special forwarding for PTP packets, which means new HW. "So you need new HW. Basically what you are saying is that carry 1588 over = the server layer such as Ethernet or OTN, etc. The problem as you figured o= ut yourself is that the span of the server layer is not the same span as th= e LSP. Therefore you either need to terminate the 1588 and regenerate it (B= C), or as you said you need service interworking." S=E9bastien: OK, I see where we diverge then. First, my assumption is that = we can build a TC-model in which the PTP messages are terminated and proces= sed (it is even better IMHO, as it avoids the layer violation problem, plea= se refer again to our draft from Paris). Second, my understanding is that y= our mechanism is really only for a TC-model used over an MPLS layer that "d= oes not terminate the PTP messages" (which I think is not a good model for = telecoms), and not really for a BC system. The layer violation problem of T= Cs should not be under-estimated IMHO; IEEE has delivered to ITU-T a very c= lear message that such architectural problems should be avoided. SD> This is exactly where we disagree. For end-to-end TC you must not termi= nate and regenerate PTP messages, otherwise you are going to incur huge PDV= .=20 "SD> I haven't seen that. Could you please email that to me." S=E9bastien: draft from Paris =3D> http://tools.ietf.org/html/draft-jobert-= tictoc-ptp-link-local-00=20 SD> Thanks. It seems in order to avoid layer violation you have gone to gre= at length. But what you are doing is the same just calling it terminate and= regenerate.=20 "SD> There are networks that don't do IP routing. PTN networks that are bas= ed on MPLS-TP don't do IP routing at all. You can refer to come of the Chin= a and Japan carriers. I agree that Synch can be uncorrelated to data, but = you the issue is that the logically out-of-band network you are referring t= o in most cases has short span (such as one link)" S=E9bastien: such networks do not have to do IP *routing* (or Ethernet swit= ching) in the model that I propose, because in all the cases, the PTP messa= ges are terminated and processed. The IP or Ethernet layers are only used a= s "encapsulations", not for routing (otherwise, the layer violation is ther= e).=20 SD> Again, The termination and regeneration must be done somewhere. If it i= s done in CPU then it won't work for TC since the PDV is high. If it is don= e in HW then logically you are doing IP routing in HW, although you are not= calling it that way. But this would need new HW that doesn't exist. "SD> While the model that you describe where a Transit provider also provid= es reference clock is possible, but it require 1588 protocol exchange betwe= en Operator and the service provider that leases from operator. And I thin= k it is not embraced in the industry (as of yet). But 1588 transparency is = simple and does not require 1588 protocol exchange between operator and ser= vice provider." S=E9bastien: I really disagree: the model where the carrier operator delive= rs his timing reference as part of the service exists today in many cases (= I have several examples in mind for frequency synchronization). However, th= e "timing transparency" model in which the network operator puts very speci= fic HW in his equipment to ensure transparency to the mobile operator is re= ally a scenario that I have never seen, and that I really doubt will happen= one day (perhaps the only exception is SyncE timing transparency over OTN,= which implies specific mappings, but I consider this as different, because= there is no other way to carry timing over OTN than transparency to the cl= ient signals, so the carrier operator has anyway to implement such new mapp= ing for his own purpose - it is not a feature dedicated to the mobile opera= tor). SD> I disagree, the model that the provider provides ToD service to the oth= er operator requires interworking of PTP protocol stack between operators, = while Transparent PTP transport is simple and doesn't require protocol inte= rworking. In conclusion, from my perspective: - I think we have now identified the points that we do not agree: - PTP clock that terminates the PTP messages vs PTP clock that does not (a= nd layer violation implications) - Real need for "timing transparency" as far as PTP is concerned - These points are not related to issues with regards to the solution that = you propose, but to the need for this solution. Depending on the perspectiv= e, the MPLS layer may not need to be used to carry PTP messages over networ= ks that operate the MPLS layer. - So, my understanding is that the solution presented in your draft would b= e applicable only to an operator who would built a network with TC everywhe= re based on the MPLS layer, in order to provide timing transparency capabil= ity to other operators. Given that this timing transparency is subject to d= ebate, I wonder if there are operators having such requirements? - I wonder if your solution really makes sense for a BC-model? SD> Yes it does when the two BC nodes are many MPLS hops away from each oth= er.=20 Thanks for the interesting discussion. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: vendredi 12 juillet 2013 01:06 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastien, Please see my response inline. Thank Shahram -----Original Message----- From: sebastien.jobert@orange.com [mailto:sebastien.jobert@orange.com]=20 Sent: Thursday, July 11, 2013 3:10 PM To: Shahram Davari Cc: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Shahram, Thanks for your reply and explanations. See some comments below in your tex= t. It is interesting discussion. Thanks. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: jeudi 11 juillet 2013 16:51 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastian, Thanks for your comments. This draft is an IETF working draft and was accep= ted as such based on IETF consensus. [JOBERT Sebastien RD-CORE-LAN] Absolutely, and this is not something that I= dispute. However, since it has been asked to the mailing list to indicate = support and provide comments, I do not feel that giving an opinion was outs= ide the IETF process. The group may or may not consider this input at the e= nd. Are you saying there is no need to carry 1588 in the networks that use MPLS= or are you saying there are other methods which are simpler?=20 [JOBERT Sebastien RD-CORE-LAN] Of course, there is a need to carry PTP mess= ages over networks that operate the MPLS layer; what I am saying is simply = that, over such networks, I do not think that carrying these PTP messages i= nside an MPLS layer is required. Other existing encapsulations are fine and= probably simpler, indeed. If you mean the former, then I disagree and I can give you examples from Ch= ina mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul acce= ss and aggregation network are MPLS and they wang to use 1588 at the cell s= ite. [JOBERT Sebastien RD-CORE-LAN] Of course, we agree on this point: MPLS netw= orks are widely deployed. It is on the method to carry PTP messages that we= have different views, I think. If you mean the later one then I disagree as well. [JOBERT Sebastien RD-CORE-LAN] OK, let's discuss then to see where the diff= erent views are. If you are proposing to use Ethernet encapsulation for 1588 without MPLS, t= hen the problem is that not all links are Ethernet.=20 [JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only o= ne possibility, as IP mapping is also possible, see below), the links that = use an Ethernet mapping for the PTP messages must obviously support Etherne= t. That being said: 1- not all the links must use this mapping, it is possi= ble to mix different mappings (e.g. Ethernet and IP) and allow some kind of= interworking mechanisms;=20 SD> So you agree that you need some interworking function which can convert= Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, etc= . I am sure you don't want to do this interworking in the CPU, do you? So y= ou need new HW. Basically what you are saying is that carry 1588 over the s= erver layer such as Ethernet or OTN, etc. The problem as you figured out yo= urself is that the span of the server layer is not the same span as the LSP= . Therefore you either need to terminate the 1588 and regenerate it (BC), o= r as you said you need service interworking. 2- it is not because the PTP messages are carried over Ethernet that the en= tire traffic must also be carried over Ethernet, it is fully possible to en= visage that only the "synchronization plane" be over Ethernet, and the data= and control planes be over MPLS if desirable. Do we agree on this? SD> Yes. But as I said the issue is that the span of server layer may not b= e the same as the LSP. Even when all links are Ethernet, Ethernet is just used for P2P link and is= not switched in routers.=20 [JOBERT Sebastien RD-CORE-LAN] Some routers may also implement a L2... SD> yes some do L2 switching, but some don't. This means you can only do BC in such cases.=20 [JOBERT Sebastien RD-CORE-LAN] No, there are ways to build a TC system with= Ethernet encapsulation (we actually presented a draft in Paris providing o= ne possible solution). SD> I haven't seen that. Could you please email that to me. If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then= this is exactly what we do in this draft. [JOBERT Sebastien RD-CORE-LAN] Indeed, but this is not what I am proposing = ;-) If you are proposing to use IP encapsulation for 1588, then you are either = proposing to use IP without MPLS encapsulation, which doesn't work since ob= viously many networks such as MPLS-TP can't perform IP routing.=20 [JOBERT Sebastien RD-CORE-LAN] This is probably the main point where we do = not agree. I can hardly imagine personally a network operating an MPLS laye= r where everything is carried over MPLS. As mentioned before, there is no p= roblem in having the data and control planes over MPLS if desirable (althou= gh I doubt that the control plane be always over MPLS, but it is a differen= t debate), and the "synchronization plane" over IP. Synchronization is gene= rally uncorrelated from the other planes: consider for instance Synchronous= Ethernet, it is a layer 1 mechanism, which is totally uncorrelated from th= e way the data plane is transported. Correlating these layers is not necess= ary. SD> There are networks that don't do IP routing. PTN networks that are base= d on MPLS-TP don't do IP routing at all. You can refer to come of the China= and Japan carriers. I agree that Synch can be uncorrelated to data, but y= ou the issue is that the logically out-of-band network you are referring to= in most cases has short span (such as one link) and therefore can't suppor= t 1588 end-to-end TC. Or you are proposing to use IP with MPLS encapsulation, which is exactly wh= at we are doing in this draft. [JOBERT Sebastien RD-CORE-LAN] No, as I mentioned, I do not think that such= encapsulation is required. The other issue is assume a service provider who is using say Ethernet enca= psulation to carry 1588, leases some connections from another network opera= tor. The network operator needs to carry these 1588 messages without termin= ating them but also needs to do TC on them.=20 [JOBERT Sebastien RD-CORE-LAN] Another point where we also probably disagre= e, I believe. TC is one possible solution, but there are many other ways to= enable "timing transparency" (for instance, without going into the details= : differential methods, "network TC" concept, etc.). However, the real ques= tion seems to be: is timing transparency a real requirement? My opinion is = that this is not a strong requirement, because at the end, for mobile appli= cations, one has to deliver some sort of UTC traceable signal. Hence, where= the synchronization reference is coming from is not really important, as l= ong as the synchronization requirements are met, because the ultimate sourc= e is at the end the same for everyone: UTC. Future applications do not real= ly have plesiochronous requirements anymore. I really believe that a scenar= io where the carrier operator is providing the reference to the mobile oper= ator, in case of leased lines, is what will occur. Otherwise, this will be = a scenario where the carrier operator does not provide any support at all f= or PTP and where the mobile operator is on its own to get rid of the PDV an= d asymmetry generated by the network. I cannot imagine why the carrier oper= ator would like to spend money on hardware support such as TC in every sing= le NEs simply to provide to other operators some kind of timing transparenc= y not really required; the carrier operator would better spend his money bu= ilding a robust network enabling to deliver very accurate synchronization, = and provide his own timing reference, with possible guarantees, as part of = the leased line offer. SD> While the model that you describe where a Transit provider also provide= s reference clock is possible, but it require 1588 protocol exchange betwee= n Operator and the service provider that leases from operator. And I think= it is not embraced in the industry (as of yet). But 1588 transparency is s= imple and does not require 1588 protocol exchange between operator and serv= ice provider. Using flat Ethernet switching is not possible since the operator network is= carrying traffic from many other customers and his network is virtualized. SD> I agree with you that if the entire network is built out of Switch-Rout= ers and all links are Ethernet then you probably don't need this draft and = can do 1588 over Ethernet end-to-end. I suggest you reading the draft first. [JOBERT Sebastien RD-CORE-LAN] Good suggestion indeed ;-) I'll do this for = my own education; however, still, I believe that the use cases that this dr= aft tries to address are subject to discussion. Regards, Shahram On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: > Hi, >=20 > In general, I do not support this document, mainly because I don't think = that the problem statement it tries to address really exists. > That being said, I did not check more in details its content, so I cannot= judge whether or not what it proposes is correct. > I just think that there is no use case for this mechanism. >=20 > "There is a need to transport Timing messages over MPLS networks while su= pporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock= (OC) functionality in the LER and LSRs in the MPLS network." =3D> this sta= tement is not supported by any argumentation, and each time that the point = has been raised on the mailing list, no clear answer or use case was provid= ed in my opinion. As mentioned several times, I do not think that there is = a real need to involve the MPLS layer to transport PTP messages; using the = existing mappings defined in IEEE 1588-2008 is sufficient for all the use c= ases that I can imagine. And I have not heard any other use case from other= industries than telecoms. >=20 > Operators are requesting Ethernet encapsulation for PTP (full timing supp= ort from the network scenario) or IP mapping (partial timing support from t= he network scenario and no timing support scenario), but not MPLS encapsula= tion... >=20 > A quick feedback from an operator monitoring this topic from the beginnin= g. >=20 > Thanks for considering (or not) this input. >=20 > BR, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky > Envoy=E9 : vendredi 5 juillet 2013 18:47 > =C0 : Yaakov Stein; tictoc@ietf.org > Cc : mpls@ietf.org > Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > Do not support > - As document describing Transporting Timing messages over MPLS Networks = it comes short in justification of complexity of PTP LSP for non-1588 proto= cols; > - I do believe that even for IEEE 1588 distribution through MPLS-TP domai= n PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnec= ting ports that support IEEE 1588 (new capability advertised in IGP-TE) is = architectually clean and sufficient. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:21 AM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From curtis@ipv6.occnc.com Fri Jul 12 14:37:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF921F9FE5 for ; Fri, 12 Jul 2013 14:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlCfkdfJFQAX for ; Fri, 12 Jul 2013 14:37:35 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 93DA621F9FFE for ; Fri, 12 Jul 2013 14:37:33 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6CLaHop002361; Fri, 12 Jul 2013 17:36:17 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201307122136.r6CLaHop002361@gateway1.orleans.occnc.com> To: spencer.giacalone@thomsonreuters.com From: Curtis Villamizar In-reply-to: Your message of "Wed, 10 Jul 2013 12:42:11 -0000." Date: Fri, 12 Jul 2013 17:36:17 -0400 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, akatlas@juniper.net, draft-atlas-mpls-te-express-path@tools.ietf.org Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:37:40 -0000 In message spencer.giacalone@thomsonreuters.com writes: > I'd like to get more feedback on removing jitter and loss from OSPF TE > ME before doing so. So far, Curtis, it's only you asking for it (to be > removed). Also, no one else seems uncomfortable with the A bit.. I am > not personally in favor of removing them, and I feel the A bit is fine > for my use case. Spence, I made comments about the use of the A-bit. I did not ask that it be removed (someone else did, not me) but asked that its usefulness (or lack of) as a hint when the delay value also has to be checked be more accurately described. Briefly, in that case (when the delay value also has to be checked) I feel the A-bit is useless. In the case where an LSP is configured such that it would never use a link with the A-bit set on a given performance measure, then it is useful. My recomendation is that for the case where the A-bit is not useful at all, just say so. Don't dance around and say it may be useful because an unreliable hint is generally more harmful than useful. As for the inclusion of jitter and loss, in the past I suggested a few options. Briefly: 1. Remove jitter and delay. --- OR --- 2. Keep jitter and delay and effectively say that jitter and loss MUST NOT be used unless a provably stable means of using them is discovered, which has not occurred to date. And be very clear about this - no watered down wording. Adding Section 1.2 "Oscillation and Stability Considerations" is a step towards 2, but not adequate. See below for further discussion on that. Tony Li used to say that (sic) "If a customer asks us for rope, we give them plenty or rope to hang themselves with". Having been at a vendor before I'll add "If a customer asks for rope and tells us they plan to use it to hang themselves, we explain in detail that hanging themselves with it will be unpleasant at best and likely fatal. If they continue to insist we give them the rope and reiterate the advice and hope the advice sinks in before its too late." With that in mind I would like to offer a compromise. Leave jitter and loss in the OSPF, ISIS, and TE-express-path drafts but reference an additional document, to be written by me, Alia, and you, entitled "Oscillation and Stability Considerations for Performance based MPLS Path Selection" and including the brief information I suggested for draft-atlas-mpls-te-express-path plus further details on stability considerations, including stability discussion regarding advanced multipath (was CL work in RTGWG). I'm fine with you keeping jitter and loss in the documents, if you are willing to cite this document [Oscillation and Stability Considerations for Performance based MPLS Path Selection] from the OSPF, ISIS, and draft-atlas-mpls-te-express-path and state that "Any use of jitter or loss measurements or any use of queuing delay in delay measurements is strongly discouraged. Before considering whether to use jitter or loss measurements or any use of queuing delay in delay measurements network operators MUST consider the warnings in [Oscillation and Stability Considerations for Performance based MPLS Path Selection]." With this compromise you get the rope you wanted and you get a clear warning about specific ways to use it that are strongly inadvisable. Please let me know if you think that is a good compromise. Curtis Regarding other prior discussion on this topic: Here was my recommendation for Section 1.2 from prior email. 1.2 Oscillation and Stability Considerations Past attempts to use delay or loss as metric sufferred from severe oscillations []. The use of performance based data MUST be such that ocillations are not possible and stability cannot be impacted. The use of timers is often cited as a cure. Oscillation that is damped by timers is known as "slosh". If advertisement timers are very short relative to the jitter applied to RSVP-TE CSPF timers, then a partial oscillation occurs. If RSVP-TE CSPF timers are short relative to advertisement timers, full oscillation (all traffic moving back and forth) can occur. Even a partial oscillation causes unnecessary reordering which is considered at least minimally disruptive. Delay variation or jitter is affected by even small traffic levels. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter proportional to or equal to the packet serialization delay. Very low levels of traffic can increase the probability of queue occupancies of two or three packets enough to further increase the measured jitter. Because jitter measurement is extremely sensitive to even very low traffic levels, any use of jitter is likely to oscillate. There may be legitimate use of a jitter measurement in path computation that can be considered free of oscillation. Delay measurements that are not sensitive to traffic loads may be safely used in path computation. Delay measurements made at the link layer or measurements made at a queuing priority higher than any significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 if traffic levels at CS3 and higher or EF and AF can affect the measurement). Making delay measurements at the same priority as the traffic on affected paths is likely to cause oscillations. Delay measurements that include queuing delay or loss measurement that includes queuing loss would be very difficult to use in path computation in a way that can be assured to be stable. No technique to date has successfully accomplished this. Timers values must reflect the number of contributors to traffic on each given link or a very conservative estimate of the potential contributors. Moving large LSP can itself be problematic and techniques which allow movement of partial LSP traffic, such as multipath techniques, may help. If queuing delay or loss measurement is considered, a proof of stability should be undertaken. These proofs insure that no positive feedback exists such that small or moderate changes in traffic patterns could cause path decisions to fluctuate wildly. Proof of stability for an arbitrary topology with arbitrary traffic patterns and using a set of rules for determining timer values and traffic adjustment amounts can be exceedingly difficult. Until a path selection technique is available which is provably stable, a condition that today has not been met, queuing delay and queuing loss MUST NOT be included in delay and loss measurements. BTW- I meant to say "There may be *no* legitimate use of a jitter measurement in path computation that can be considered free of oscillation." Amazing what omiting one word can do. Here is what Alia added which includes most of the above. 1.2. Oscillation and Stability Considerations Past attempts to use unbounded delay or loss as metric sufferred from severe oscillations. The use of performance based data must be such that undampened oscillations are not possible and stability cannot be impacted. The use of timers is often cited as a cure. Oscillation that is damped by timers is known as "slosh". If advertisement timers are very short relative to the jitter applied to RSVP-TE CSPF timers, then a partial oscillation occurs. If RSVP-TE CSPF timers are short relative to advertisement timers, full oscillation (all traffic moving back and forth) can occur. Even a partial oscillation causes unnecessary reordering which is considered at least minimally disruptive. Delay variation or jitter is affected by even small traffic levels. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter proportional to or equal to the packet serialization delay. Very low levels of traffic can increase the probability of queue occupancies of two or three packets enough to further increase the measured jitter. Because jitter measurement is extremely sensitive to even very low traffic levels, any use of jitter is likely to oscillate. There may be legitimate use of a jitter measurement in path computation that can be considered free of oscillation. Delay measurements that are not sensitive to traffic loads may be safely used in path computation. Delay measurements made at the link layer or measurements made at a queuing priority higher than any significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 if traffic levels at CS3 and higher or EF and AF can affect the measurement). Making delay measurements at the same priority as the traffic on affected paths is likely to cause oscillations. And finally my latest comments on this on the MPLS-RT review thread which runs to the end of this email (74 lines, not that long). OLD Delay variation or jitter is affected by even small traffic levels. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter proportional to or equal to the packet serialization delay. Very low levels of traffic can increase the probability of queue occupancies of two or three packets enough to further increase the measured jitter. Because jitter measurement is extremely sensitive to even very low traffic levels, any use of jitter is likely to oscillate. There may be legitimate use of a jitter measurement in path computation that can be considered free of oscillation. The last sentence is unjustified and in conflict with the remaining paragraph. Please change that one sentence. OLD There may be legitimate use of a jitter measurement in path computation that can be considered free of oscillation. NEW While there may in the future be legitimate use of a jitter measurement in path computation that can be considered free of oscillation, except for uses with extremely low utilization within a given very high priority traffic class, and therefore almost no jitter to measure, no legitimate use of a jitter measurement in path computation that can be considered free of oscillation is known today. Nit: s/undampened oscillations/undamped oscillations/ I make this mistake all the time too. The former is "dry". There is no warning about using queuing loss measurements and the warnings about using delay measurements in certain circumstances was omitted. The text I had previously suggested is: Delay measurements that include queuing delay or loss measurement that includes queuing loss would be very difficult to use in path computation in a way that can be assured to be stable. No technique to date has successfully accomplished this. Timers values must reflect the number of contributors to traffic on each given link or a very conservative estimate of the potential contributors. Moving large LSP can itself be problematic and techniques which allow movement of partial LSP traffic, such as multipath techniques, may help. If queuing delay or loss measurement is considered, a proof of stability should be undertaken. These proofs insure that no positive feedback exists such that small or moderate changes in traffic patterns could cause path decisions to fluctuate wildly. Proof of stability for an arbitrary topology with arbitrary traffic patterns and using a set of rules for determining timer values and traffic adjustment amounts can be exceedingly difficult. Until a path selection technique is available which is provably stable, a condition that today has not been met, queuing delay and queuing loss MUST NOT be included in delay and loss measurements. Provably stable is not an insurmountable goal. TCP's feedback mechanism is provably stable and with a relatively simple proof. For the case of LAG or other multipath where local adjustment affects only traffic into adjacent links, a provable stable load balance can occur. This is more difficult for longer distance load balancing. It is even more difficult with the granularity of moving whole LSP rather that a portion of a hash space over a diverse key (ie: IP src/dst or Entropy Label) and it may turn out that given the use of path selection, and therefore moving whole LSP, stability cannot be assured. Therefore there is a strong argument that neither jitter or loss have any legitimate use for which stability cannot be assured. From internet-drafts@ietf.org Sat Jul 13 03:45:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D2E21E80DF; Sat, 13 Jul 2013 03:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbp8FOKuD3w3; Sat, 13 Jul 2013 03:45:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CF221F9D8A; Sat, 13 Jul 2013 03:45:49 -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: 4.51.p2 Message-ID: <20130713104549.1264.85043.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 03:45:49 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-11.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, 13 Jul 2013 10:45:54 -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 Gro= up 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 Transport= Network Recommendations. Author(s) : Huub van Helvoort Loa Andersson Nurit Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-11.txt Pages : 20 Date : 2013-07-13 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-rosetta-stone-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huubatwork@gmail.com Sat Jul 13 08:28:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E536A21F9D38 for ; Sat, 13 Jul 2013 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBfXiu+YFAeY for ; Sat, 13 Jul 2013 08:28:01 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id BFF4E21F9E6C for ; Sat, 13 Jul 2013 08:27:59 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id t10so6815590eei.13 for ; Sat, 13 Jul 2013 08:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding; bh=zz5jKpNimjZNrOU6EJbnkjMegEJ6SweHN3XHg9ZAUmw=; b=RDQIqLb3Vnm5gCLEXxwRzkUWsjH2Ux5VQIr65D3gEK84+MHAkJPVfV3bDfM1wsMK0F kLY4s8W7gTy753f58RSjARUTvAjqk1XohGt5Nn1KOWeR4DarxvVnStlMd8JpZyeJ+LDx foJza8izWWrmRcvFom2nWVLHdWd2blpUyE1Y87VmmgjjRB9+jqELsEW9Hq16PI5Z+jOS cPiwWHA5dl18icnyKjKymnzOS2ppavjZHioA/gY0eGkohIB+u6Oj+LHWNtHMYeKn3TuT FxJVjPZX+SDfFgkx9/0aPXAKKne0myDnYF8pbTFKIUmSQzfXsYP+A4KnAEYwWIOJSpzy ymQA== X-Received: by 10.15.108.142 with SMTP id cd14mr38607261eeb.125.1373729278885; Sat, 13 Jul 2013 08:27:58 -0700 (PDT) Received: from McAsterix.local (cust.static.62-202-10-161.swisscomdata.ch. [62.202.10.161]) by mx.google.com with ESMTPSA id n45sm87856300eew.1.2013.07.13.08.27.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 08:27:58 -0700 (PDT) Message-ID: <51E171F9.8020409@gmail.com> Date: Sat, 13 Jul 2013 17:27:53 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" References: <20130713104549.1264.85043.idtracker@ietfa.amsl.com> In-Reply-To: <20130713104549.1264.85043.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130713104549.1264.85043.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-tp-rosetta-stone-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 15:28:02 -0000 Hello, I have submitted version 11 of the Rosetta Stom=ne draft. I have added definition of protection priority as requested by WG chair. There were no further comments in the last few month, so it may be ready for WG last call. Best regards, Huub. -------- Original Message -------- Subject: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-11.txt Date: Sat, 13 Jul 2013 03:45:49 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. Author(s) : Huub van Helvoort Loa Andersson Nurit Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-11.txt Pages : 20 Date : 2013-07-13 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-rosetta-stone-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Sat Jul 13 11:24:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3121F9DCD; Sat, 13 Jul 2013 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoAanXhm3rXg; Sat, 13 Jul 2013 11:24:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5621F9D92; Sat, 13 Jul 2013 11:24:10 -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: 4.51.p2 Message-ID: <20130713182410.5305.80842.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 11:24:10 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:24:11 -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 Gro= up of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-09.txt Pages : 32 Date : 2013-07-13 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mn1921@att.com Sat Jul 13 16:51:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1852221F9C0A for ; Sat, 13 Jul 2013 16:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrsJu7yqKuLH for ; Sat, 13 Jul 2013 16:51:33 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60221F9C05 for ; Sat, 13 Jul 2013 16:51:32 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 508e1e15.2aab00e5a940.5684046.00-579.15772956.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 13 Jul 2013 23:51:33 +0000 (UTC) X-MXL-Hash: 51e1e8057571ff37-90afe6b95672a3b21d831fb71bbc8c5a2ea5e57f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 208e1e15.0.5684038.00-481.15772918.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 13 Jul 2013 23:51:32 +0000 (UTC) X-MXL-Hash: 51e1e804143a9a0b-4854f03d153c3d23aca4115d53d4916f7490670b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6DNpUa8030340; Sat, 13 Jul 2013 19:51:30 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6DNpH84030213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jul 2013 19:51:20 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sat, 13 Jul 2013 23:51:00 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Sat, 13 Jul 2013 19:50:59 -0400 From: "NAPIERALA, MARIA H" To: Xuxiaohu , Kireeti Kompella , Lizhong Jin Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6ICBkcmFmdC1pZXRmLW1wbHMtc3BlY2lhbC1wdXJwb3Nl?= =?gb2312?Q?-labels-01?= Thread-Index: AQHOe+L6kiq70CghjUWGy1AKFqebFJlbUpkAgAPtspCABA1pUA== Date: Sat, 13 Jul 2013 23:50:59 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012024C3@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECC@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECC@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.39.175] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E012024C3MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=eD-P08DquSEA:10 a=EjmC2Dxi6UgA:10 a=ofMgfj31e3cA:10 a=jPJ] X-AnalysisOut: [DawAOAc8A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=2ZtpKM1jah4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=OUXY8nFuAAAA:8 a=HBkLRu2ulroCOoLGiBYA:9 a=mFyHDrcPJccA:] X-AnalysisOut: [10 a=vgg1P2Nl_AMA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a] X-AnalysisOut: [=peF9eE_zjQwA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=tXsnliwV7b4A:10 a=gSZQPaP4HtSeIRXD:21] Cc: Ross Callon , "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] =?gb2312?b?tPC4tDogIGRyYWZ0LWlldGYtbXBscy1zcGVjaWFsLXB1?= =?gb2312?b?cnBvc2UtbGFiZWxzLTAx?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 23:51:39 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E012024C3MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgS2lyZWV0aSwNCg0KDQpBIGNvbW1lbnQgb24gdGhlIHJhbmdlcyBvZiBFeHRlbmRlZCBTcGVj aWFsIFB1cnBvc2UgTVBMUyBMYWJlbHM6DQoNCigxKSAgIFNob3VsZG6hr3QgdGhlcmUgYmUgYSBs YXJnZXIgVW5hc3NpZ25lZCByYW5nZSAodXNpbmcgdGVybWlub2xvZ3kgb2YgUkZDIDUyMjYpPw0K DQooMikgICBXaHkgaXMgUmVzZXJ2ZWQgcmFuZ2Ugc28gbGFyZ2U/IFdoYXQgaXMgdGhlIHB1cnBv c2U/DQoNCk1hcmlhDQoNCk1lc3NhZ2U6IDINCkRhdGU6IFN1biwgNyBKdWwgMjAxMyAxMTo1MToy OCAtMDcwMA0KRnJvbTogS2lyZWV0aSBLb21wZWxsYSA8a2lyZWV0aS5rb21wZWxsYUBnbWFpbC5j b208bWFpbHRvOmtpcmVldGkua29tcGVsbGFAZ21haWwuY29tPj4NClRvOiBNUExTIDxtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4NCkNjOiBSb3NzIENhbGxvbiA8cmNhbGxvbkBq dW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBqdW5pcGVyLm5ldD4+LCBMb2EgQW5kZXJzc29uIDxs b2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+DQpTdWJqZWN0OiBbbXBsc10gZHJhZnQtaWV0Zi1t cGxzLXNwZWNpYWwtcHVycG9zZS1sYWJlbHMtMDENCk1lc3NhZ2UtSUQ6IDw3NENDNTU4MC03QUU2 LTQ3MzktQTMwQi04MzhCQjA4RjJGMjFAZ21haWwuY29tPG1haWx0bzo3NENDNTU4MC03QUU2LTQ3 MzktQTMwQi04MzhCQjA4RjJGMjFAZ21haWwuY29tPj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD0idXMtYXNjaWkiDQoNCkhpIEFsbCwNCg0KSSBoYXZlIHVwZGF0ZWQgdGhpcyBk b2N1bWVudCB3aXRoIHRoZSBmb2xsb3dpbmc6DQphKSB0aGUgcmFuZ2Ugb2YgU3RhbmRhcmRzIEFj dGlvbiBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2UgbGFiZWxzIGlzIDE2LTIzOTsgZXhwZXJpbWVu dGFsIGlzIDI0MC0yNTUuICBUaGUgcmVzdCBhcmUgcmVzZXJ2ZWQgZm9yIG5vdy4NCmIpIEkndmUg YWRkZWQgYSBxdWVzdGlvbi9hbnN3ZXIgb24gd2hldGhlciB0byB1c2UgZXh0ZW5kZWQgc3BlY2lh bCBwdXJwb3NlIGxhYmVscyBpbiBsb2FkIGJhbGFuY2luZyAtLSBzYXlpbmcgTVVTVCBOT1QuDQpj KSBDbGFyaWZpZWQgdGV4dCByZWdhcmRpbmcgYSBsYWJlbCBmb2xsb3dpbmcgYW4gZXh0ZW5kZWQg c3BlY2lhbCBwdXJwb3NlIChYdXhpYW9odSdzIGNvbW1lbnQpLg0KDQpGaW5hbGx5LCBJIG5vdGUg TGl6aG9uZydzIGNvbW1lbnQgcmVnYXJkaW5nIGxhYmVsIDcuICBUaGUgZ29hbCBpbiBhbGxvd2lu ZyBsYWJlbCA3IGFzIGVpdGhlciBhIHJlZ3VsYXIgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIG9yIGFu IGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZSBsYWJlbCBpcyB0byBzaW1wbGlmeSBwYXJzaW5nIHdo ZW4gc2VhcmNoaW5nIGZvciBhbiBlbnRyb3B5IGxhYmVsLiAgSSBhZGRlZCB0ZXh0IGFyb3VuZCB0 aGlzLCBidXQgZGlkIG5vdCBjaGFuZ2UgU0hPVUxEIE5PVCB0byBNVVNUIE5PVC4NCg0KV0cgY2hh aXJzLCBJIGJlbGlldmUgdGhpcyBkb2MgaXMgcmVhZHkgZm9yIFdHIExDLg0KDQpLaXJlZXRpLg0K LS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tDQpBbiBIVE1MIGF0dGFjaG1l bnQgd2FzIHNjcnViYmVkLi4uDQpVUkw6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbXBscy9hdHRhY2htZW50cy8yMDEzMDcwNy9hMTAwZDdkNC9hdHRhY2htZW50Lmh0bT4N Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQoNCkVuZCBvZiBtcGxzIERpZ2VzdCwgVm9sIDExMSwgSXNzdWUgMTMN CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQo= --_000_1D70D757A2C9D54D83B4CBD7625FA80E012024C3MISOUT7MSGUSR9I_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Kireeti,

 

A comment on the ranges of Extended Special Purpose MPLS Labels:

(1)   Shouldn=A1=AFt there be a larger Unassigned range (using terminology of RFC 5226)?=

(2)   Why is Reserved range so large? What= is the purpose?

 

Maria

 

Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <ki= reeti.kompella@gmail.com>
To: MPLS <mpls@ietf.org>
Cc: Ross Callon <rcallon@juniper.= net>, Loa Andersson <loa@pi.nu&g= t;
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <74CC5580-7AE6-4739-A30B-838BB08F2F21@gmail.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi All,

I have updated this document with the following:
a) the range of Standards Action extended special purpose labels is 16-239;= experimental is 240-255.  The rest are reserved for now.
b) I've added a question/answer on whether to use extended special purpose = labels in load balancing -- saying MUST NOT.
c) Clarified text regarding a label following an extended special purpose (= Xuxiaohu's comment).

Finally, I note Lizhong's comment regarding label 7.  The goal in allo= wing label 7 as either a regular special purpose label or an extended speci= al purpose label is to simplify parsing when searching for an entropy label= .  I added text around this, but did not change SHOULD NOT to MUST NOT.

WG chairs, I believe this doc is ready for WG LC.

Kireeti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>

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

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


End of mpls Digest, Vol 111, Issue 13
*************************************

 

 

--_000_1D70D757A2C9D54D83B4CBD7625FA80E012024C3MISOUT7MSGUSR9I_-- From sriganeshkini@gmail.com Mon Jul 15 01:02:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4781321F8AA1 for ; Mon, 15 Jul 2013 01:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZiJTazdBx98 for ; Mon, 15 Jul 2013 01:02:28 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A378321F84D1 for ; Mon, 15 Jul 2013 01:02:27 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so11024781pbb.41 for ; Mon, 15 Jul 2013 01:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Ne9jon6YY0F0gqXWseTUpvsa8Lp6dNAoVRnV4+zlvvs=; b=GHa3daaGykuXgY1R/4ImQxcaenooWvDmJ+iLENYQk6dwQZdJ5GB99kgoAPhs+OMNsC ay7ofxLvPgIx/qV4gdxkRiI47zCEP/sCJyMDgCI3ZfEFfKaT+s/VUmsKYWrMelgp1pWQ /tsP8roXkecr5vqXJAPDCWHJeuaeLbaKgA/SZNRuiVBZCvkwlOkvgQiJfz42SLGBP387 bjn+Dp1GkW8SKgwe73BZOTJDm0G4IXrJUA3rOSahxgXufY5/qiUP4GSWEhp8BUOcc8vy iTiBsYUuExLBm94vs1mHj5M+EjvywJJEvPHe4/P63R+7qzCSEv27y/h8Z8751LCIScNV I7mQ== X-Received: by 10.68.221.102 with SMTP id qd6mr646090pbc.30.1373875347291; Mon, 15 Jul 2013 01:02:27 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Mon, 15 Jul 2013 01:01:56 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Mon, 15 Jul 2013 01:01:56 -0700 X-Google-Sender-Auth: JoH4KG9gOSKUlCho3G58EbunX2I Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7b2ed53d0a841e04e1884831 Cc: MPLS WG Mailing List Subject: Re: [mpls] FW: New Version Notification for draft-atlas-mpls-te-express-path-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 08:02:29 -0000 --047d7b2ed53d0a841e04e1884831 Content-Type: text/plain; charset=UTF-8 Hi Alia, Thanks for addressing the review comments of version -02. The pseudo-code in the new version looks good. Some additional comments are below - 1. Section 1 para 1 second last line s/with additional constraints,/with additional bound constraints/ 2. Section 1 para 3 Pg 3 - This para seems to be only about delay. I would suggest s/additional contributors beyond/additional contributors to latency beyond/ 3. Same location as previous comment. It is not clear what you mean by router latency (as opposed to queueing latency). Do you mean switching fabric latency ? Or do you mean latency through the router if there were no queueing latency ? Would be better to clarify. 4. Same location as previous comment. "While traversing a router can cause delay, that can be included in the advertised link delay.". Is this referring to the previously mentioned "router delay" ? If so s/While traversing a router can cause delay/The router-delay/. Also, is this sentence a recommendation being made by this draft ? The isis and ospf extension draft make no mention of router delay. Do you intend to say "The router delay CAN or SHOULD be included in each link delay" ? If so, re-word the sentence. 5. Section 1 para 4 Pg 3 - s/If application traffic which follows path/If application traffic follows a path/ 6. Section 1.1 enum 3. - I don't see how the solution in this draft achieves this. It is only as accurate as the TE LSDB which itself is not updated in real-time. s/verify that a TE tunnel's current LSP/verify with the TE LSDB that a TE tunnel's current LSP/. 7. Section 1.1 enum 7. - s/revert back to the best path/revert back using make-before-break to the best path/ 8. Section 2.1. The sentence "An alternative to this approach to minimize path latency is an approach to place an upper bound on path latency.". This does not make sense. Minimizing and placing a bound are two separate constraints. One does not substitute for the other. I suspect what you really wanted to say is - "In practical scenarios latency constraints are typically a bound constraint rather than a minimization objective". 9. Section 2.2 third para s/only links with at least a configurable amount/only links with at least a minimum amount/ - Sri On Thu, Jul 11, 2013 at 11:32 PM, Alia Atlas wrote: > I've published an updated draft-atlas-mpls-te-express-path that reflects > the discussion and reviews by the MPLS-MT team. > > Alia > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 12, 2013 2:32 AM > To: Stefano Previdi; Alia Atlas; Spencer Giacalone; John E Drake; David > Ward; Spencer Giacalone; Clarence Filsfils; Dave Ward > Subject: New Version Notification for > draft-atlas-mpls-te-express-path-03.txt > > > A new version of I-D, draft-atlas-mpls-te-express-path-03.txt > has been successfully submitted by Alia Atlas and posted to the IETF > repository. > > Filename: draft-atlas-mpls-te-express-path > Revision: 03 > Title: Performance-based Path Selection for Explicitly Routed > LSPs using TE Metric Extensions > Creation date: 2013-07-12 > Group: mpls > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-atlas-mpls-te-express-path-03.txt > Status: > http://datatracker.ietf.org/doc/draft-atlas-mpls-te-express-path > Htmlized: > http://tools.ietf.org/html/draft-atlas-mpls-te-express-path-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-atlas-mpls-te-express-path-03 > > Abstract: > In certain networks, it is critical to consider network performance > criteria when selecting the path for an explicitly routed RSVP-TE > LSP. Such performance criteria can include latency, jitter, and loss > or other indications such as the conformance to link performance > objectives and non-RSVP TE traffic load. This specification uses > network performance data, such as is advertised via the OSPF and ISIS > TE metric extensions (defined outside the scope of this document) to > perform such path selections. > > > > > The IETF Secretariat > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b2ed53d0a841e04e1884831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,

Thanks for addressing the revi= ew comments of version -02. The pseudo-code in the new version looks good. = Some additional comments are below -

  1. Section 1 para 1 second last line s/with addi= tional constraints,/with additional bound constraints/

  2. Section 1 para 3 Pg 3 - This para seems to be= only about delay. I would suggest s/additional contributors beyond/additio= nal contributors to latency beyond/

  3. Same location as previous comment. It is not = clear what you mean by router latency (as opposed to queueing latency). Do = you mean switching fabric latency ? Or do you mean latency through the rout= er if there were no queueing latency ? Would be better to clarify.

  4. Same location as previous comment. "Whil= e traversing a router can cause delay, that can be included in the advertis= ed link delay.". Is this referring to the previously mentioned "r= outer delay" ? If so s/While traversing a router can cause delay/The r= outer-delay/. Also, is this sentence a recommendation being made by this dr= aft ? The isis and ospf extension draft make no mention of router delay. Do= you intend to say "The router delay CAN or SHOULD be included in each= link delay" ? If so, re-word the sentence.

  5. Section 1 para 4 Pg 3 - s/If application traf= fic which follows path/If application traffic follows a path/

  6. Section 1.1 enum 3. - I don't see how the= solution in this draft achieves this. It is only as accurate as the TE LSD= B which itself is not updated in real-time. s/verify that a TE tunnel's= current LSP/verify with the TE LSDB that a TE tunnel's current LSP/.

  7. Section 1.1 enum 7. - s/revert back to the be= st path/revert back using make-before-break to the best path/

  8. Section 2.1. The sentence "An alternativ= e to this approach to minimize path latency is an approach to place an uppe= r bound on path latency.". This does not make sense. Minimizing and pl= acing a bound are two separate constraints. One does not substitute for the= other. I suspect what you really wanted to say is - "In practical sce= narios latency constraints are typically a bound constraint rather than a m= inimization objective".

  9. Section 2.2 third para s/only links w= ith at least a configurable amount/only links with at least a minimum amoun= t/


- Sri


On Thu, Jul 1= 1, 2013 at 11:32 PM, Alia Atlas <akatlas@juniper.net> wrot= e:
I've published an updated draft-atlas-mp= ls-te-express-path that reflects the discussion and reviews by the MPLS-MT = team.

Alia

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Friday, July 12, 2013 2:32 AM
To: Stefano Previdi; Alia Atlas; Spencer Giacalone; John E Drake; David War= d; Spencer Giacalone; Clarence Filsfils; Dave Ward
Subject: New Version Notification for draft-atlas-mpls-te-express-path-03.t= xt


A new version of I-D, draft-atlas-mpls-te-express-path-03.txt
has been successfully submitted by Alia Atlas and posted to the IETF reposi= tory.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-atlas-mpls-te-express-path
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A003
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Performance-based Path Selection = for Explicitly Routed LSPs using TE Metric Extensions
Creation date: =C2=A0 2013-07-12
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls
Number of pages: 10
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-atlas-mpls-te-express-path-03.= txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatr= acker.ietf.org/doc/draft-atlas-mpls-te-express-path
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.or= g/html/draft-atlas-mpls-te-express-path-03
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-mpls-te-express-path-03
Abstract:
=C2=A0 =C2=A0In certain networks, it is critical to consider network perfor= mance
=C2=A0 =C2=A0criteria when selecting the path for an explicitly routed RSVP= -TE
=C2=A0 =C2=A0LSP. =C2=A0Such performance criteria can include latency, jitt= er, and loss
=C2=A0 =C2=A0or other indications such as the conformance to link performan= ce
=C2=A0 =C2=A0objectives and non-RSVP TE traffic load. =C2=A0This specificat= ion uses
=C2=A0 =C2=A0network performance data, such as is advertised via the OSPF a= nd ISIS
=C2=A0 =C2=A0TE metric extensions (defined outside the scope of this docume= nt) to
=C2=A0 =C2=A0perform such path selections.




The IETF Secretariat



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

--047d7b2ed53d0a841e04e1884831-- From loa@pi.nu Mon Jul 15 06:48:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2144021F867B for ; Mon, 15 Jul 2013 06:48:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx7a3IgtgXGk for ; Mon, 15 Jul 2013 06:48:39 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47111E80D3 for ; Mon, 15 Jul 2013 06:48:38 -0700 (PDT) Received: from [109.58.255.169] (109.58.255.169.bredband.tre.se [109.58.255.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id AAAA91801274; Mon, 15 Jul 2013 15:48:33 +0200 (CEST) Message-ID: <51E3FDB2.6000909@pi.nu> Date: Mon, 15 Jul 2013 15:48:34 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , Adrian Farrel , draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] implementations of draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:48:45 -0000 Working Group, we have already requested publication of draft-ietf-mpls- ldp-applicability-label-adv. In the shepherd write-up I say that "we know of implementation" of the draft, that far it is correct. But it also says that I've sent out an implementation poll and will update shepherd write-up if and when we get information. That is not right, I forgot to send the poll. This is to start a poll for implementations of draft-ietf-mpls- ldp-applicability-label-adv. If you have an implementation please respond to the mailing-list or directly to the wg-chairs. /Loa for the wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From erosen@cisco.com Mon Jul 15 07:29:22 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C2011E80E4 for ; Mon, 15 Jul 2013 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.177 X-Spam-Level: X-Spam-Status: No, score=-8.177 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwaL91+In943 for ; Mon, 15 Jul 2013 07:29:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2754C21F9E97 for ; Mon, 15 Jul 2013 07:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3664; q=dns/txt; s=iport; t=1373898543; x=1375108143; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=d0oiqvDMpNhITf+x41PMuy8VThiEZVwr9NGMZbAl8Ok=; b=cYvqtLkmEm8v8DJKwsYyoI62CKz2Tr+lXPJlF8hU2gxq2KMFCJ5jcLfw z9s+CaCAkYfo41fv7nPwEBeEVJU1eRhOe/dQY/30ZbSpGIAy1Z+n4qFBa HmzSMWbJkwy5AtqLbLZIUs3Wl4s9p9750IEdmjKNlaxtJY1AANMJufwlL A=; X-IronPort-AV: E=Sophos;i="4.89,669,1367971200"; d="scan'208";a="234956647" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 15 Jul 2013 14:28:53 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6FESqWS005288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 14:28:52 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 r6FESo82003619; Mon, 15 Jul 2013 10:28:51 -0400 From: Eric Rosen To: Lizhenbin In-reply-to: Your message of Wed, 03 Jul 2013 07:13:52 -0000. <5A5B4DE12C0DAC44AF501CD9A2B01A8D08187790@nkgeml506-mbx.china.huawei.com> Date: Mon, 15 Jul 2013 10:28:50 -0400 Message-ID: <3618.1373898530@erosen-linux> Cc: "mpls@ietf.org" Subject: Re: [mpls] =?gb2312?b?tPC4tDogIHdvcmtpbmcgZ3JvdXAgbHN0IGNhbGwgb24g?= =?gb2312?b?ZHJhZnQtaWV0Zi1tcGxzLXRhcmdldGVkLW1sZHA=?= 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: Mon, 15 Jul 2013 14:29:22 -0000 Thanks for your comments. > We think the targeted mldp scenario is necessary. After review, follow > comments are proposed: > 1. Since using unicast or multicast tunnel is decided by downstream node, > unicast and others choose multicast, then what is U's choice? Maybe it can > treat the multicast tunnel as one branch with other unicast tunnel or can > use one new capability to negotiate this before MP-LSP setting up. Actually, we presupposed that the tunneling technique would be predetermined by the Service Provider, and that the provisioning process would ensure that all nodes know in advance what kind of tunneling is to be used. I see now that this presupposition is not clearly stated in the draft; I'll add some text to make it clear. It is conceivable that one might want to choose the tunneling type based on some characteristic of the data flow. E.g., perhaps one would want to use unicast tunneling for flows of low bandwidth (or low fanout), but use an RSVP-TE P2MP tunnel for other flows. However, that choice would need to be made by the upstream node. I don't think we need to support that scenario in this draft, but if any Service Provider shows interest in that scenario, additional procedures could be devised and a followup draft written. > 2. Maybe the procedure for the unsymmetrical network can be improved. For > example, the next hop interface from D to the root is a physical interface > but from U to D is an RSVP-TE tunnel , so D send one label mapping but > maybe U is waiting for one upstream label request. Section 1.3.1 describes two ways of determining the upstream LSR, and allows for other methods. (Section 1.4 seems to disallow other methods; that's a mistake.) The intention is to specify two possible methods, but not to rule out other methods that might make sense in a particular Service Provider's environment. We do presume that the method of determining the upstream LSR is known a priori, rather than determined dynamically. It is true that we have not specified a method that applies to the sort of asymmetric network you describe. I'll add some text to make it clear that while alternative methods of determining the LSR may be needed in some environments, specification of those alternative methods is outside the scope of the current document. > 3. In section 3(Targeted mLDP with Multicast Tunneling), if U choose using > different multicast tunnel for different MP-LSPs, maybe it can try other > methods to avoid upstream label allocation. For example, using one > 'Recursive Opaque TLV' in RFC6512, we can redirect the root to the U, and > trigger one multicast tunnel setup between U and D. Even we can avoid > tunneling since node D knows the in-label should map to which MP-LSP. If you want mLDP-created P2MP LSPs in the core, and don't want to aggregate, then the use of Targeted mLDP is not the best solution. > 4. The unicast tunneling method is still unsatisfactory since it may cause > traffic congestion if some of the unicast tunnels shares one link and this > is a very possible case under current backbone network deployment. Certainly multicast tunneling provides a more optimal use of bandwidth than unicast tunneling. However, some Service Providers regard the sub-optimal use of bandwidth as a good trade-off for the elimination of multicast state and control plane load in the "intermediate nodes" along the path of the unicast tunnel. This draft provides procedures for both tunneling techniques, but intentionally does not make any judgments about which technique is better in which circumstances. From lizho.jin@gmail.com Mon Jul 15 08:14:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF521E804D; Mon, 15 Jul 2013 08:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8UZEs+hp2FJ; Mon, 15 Jul 2013 08:14:12 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 853D421F9FF2; Mon, 15 Jul 2013 08:14:12 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so6582709qeb.1 for ; Mon, 15 Jul 2013 08:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=M1+mYOV9Q2A/V/ueBsc5D5MRYCd3Z/XKMLbW2zzAtIw=; b=n2Oewq73l/c0XJpzch76m6IJVZr013AaB9hanIHsqQnvo8l+errG0KCgTYTBjp4OXo wDiZuAit1MtxMF+Egwh/xPIdnPdGxwl9vkAmdxMRmrCIhNjsel/IKDcYml7rSl+UiVqQ HcF1x/dFR1EzNDsUCZvQTx6DqlTsi/IvDOvtIvYfKHfm76eTJ0y3FhSLxS4fIJMzTTOh 6yzfKFDgkaojsu9wUtMEvaqy857lkJ9K0ZzencYZNQwx0eVya9/Zo8I/98uPSsGLbWw6 hIKAzM4u915XB934H/TnntVH9mS9PQ+xVqXYIzL5ULBKTT2rHGKqzELZnF4LrB7LVCli dodw== MIME-Version: 1.0 X-Received: by 10.224.172.198 with SMTP id m6mr53201789qaz.44.1373901251977; Mon, 15 Jul 2013 08:14:11 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Mon, 15 Jul 2013 08:14:11 -0700 (PDT) Date: Mon, 15 Jul 2013 23:14:11 +0800 Message-ID: From: Lizhong Jin To: "mpls@ietf.org" , tictoc@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d8c7f14a8bd04e18e5091 Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:14:13 -0000 --047d7b5d8c7f14a8bd04e18e5091 Content-Type: text/plain; charset=ISO-8859-1 Hi, I support this last call. This is a useful solution for 1588 time synchronization. Lizhong > > Message: 2 > Date: Thu, 4 Jul 2013 09:21:13 +0000 > From: Yaakov Stein > To: "tictoc@ietf.org" > Cc: "mpls@ietf.org" > Subject: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls > Message-ID: > <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset="us-ascii" > > We hereby announce a TICTOC working group last call for > draft-ietf-tictoc-1588overmpls > (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). > > Please send indications of support, as well as any remaining technical > comments, to the list. > > Due to the MPLS aspects of this draft this email is also being sent to the > MPLS WG, > but please conduct all discussion on the TICTOC working group mailing list. > > This working group last call will end on July 19, 2013. > > Y(J)S > > > > ------------------------------ > > --047d7b5d8c7f14a8bd04e18e5091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I support this last call. This is a useful solution for 1588= time synchronization.

Lizhong
=A0
=

Message: 2
Date: Thu, 4 Jul 2013 09:21:13 +0000
From: Yaakov Stein <yaakov_s@rad.com= >
To: "tictoc@ietf.org" <= tictoc@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
Message-ID:
=A0 =A0 =A0 =A0 <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad= .rad.co.il>
Content-Type: text/plain; charset=3D"us-ascii"

We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls
(see http://tools.ietf.org/html/draft-ietf-tictoc-1588overm= pls-05).

Please send indications of support, as well as any remaining technical comm= ents, to the list.

Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG,
but please conduct all discussion on the TICTOC working group mailing list.=

This working group last call will end on July 19, 2013.

Y(J)S



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

--047d7b5d8c7f14a8bd04e18e5091-- From lizho.jin@gmail.com Mon Jul 15 08:18:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EDB21E8082; Mon, 15 Jul 2013 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eNd2C5DvJlX; Mon, 15 Jul 2013 08:18:07 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2E821E80A8; Mon, 15 Jul 2013 08:18:05 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so6485739qec.20 for ; Mon, 15 Jul 2013 08:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TYWrh5HLprgfFFaGbRQSpgIqUY0nbJvy8kUohDJpRpE=; b=Djf6FiOPcOc0BVuX5W+jhbPu/ZyMudzUeL1j3NhJzsNnRsxH4zh1LlFPq+t6EtUapM rORFZiHxcCXl9qJYEtyp3wO1D+XCumDVyURYBVoO1q+fcSQAQBqqS7FEHWq89TmCApkZ WIQTgFIgXTIu8xAuNcIAgU7SVpTRasIA2JS/n7NP4t+n91qB45XQGjAO8xEfTs8vDBlw grHOOIhhxMLdCQhtbZEWXZY91TS8TnkPdJn0V/dkMDKDdwQdZgZnmN/6xmhWDQkolGOF BFk/EexW56RAlJqCthPmXBT40plMlddEOgz1uOT4eQWlIc/4GQNOzq5kWdxVz9KulEtM BXpw== MIME-Version: 1.0 X-Received: by 10.49.127.4 with SMTP id nc4mr51018790qeb.41.1373901485292; Mon, 15 Jul 2013 08:18:05 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Mon, 15 Jul 2013 08:18:05 -0700 (PDT) Date: Mon, 15 Jul 2013 23:18:05 +0800 Message-ID: From: Lizhong Jin To: "mpls@ietf.org" , tictoc@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d6332fcdf1404e18e5d64 Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:18:07 -0000 --047d7b5d6332fcdf1404e18e5d64 Content-Type: text/plain; charset=ISO-8859-1 Hi, I support this last call. This is a useful solution for 1588 time synchronization. Lizhong > > Message: 2 > Date: Thu, 4 Jul 2013 09:21:13 +0000 > From: Yaakov Stein > To: "tictoc@ietf.org" > Cc: "mpls@ietf.org" > Subject: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls > Message-ID: > <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset="us-ascii" > > We hereby announce a TICTOC working group last call for > draft-ietf-tictoc-1588overmpls > (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). > > Please send indications of support, as well as any remaining technical > comments, to the list. > > Due to the MPLS aspects of this draft this email is also being sent to the > MPLS WG, > but please conduct all discussion on the TICTOC working group mailing list. > > This working group last call will end on July 19, 2013. > > Y(J)S > > > > ------------------------------ > > --047d7b5d6332fcdf1404e18e5d64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I support this last call. This is a useful solution for 1588= time synchronization.

Lizhong
=A0
=

Message: 2
Date: Thu, 4 Jul 2013 09:21:13 +0000
From: Yaakov Stein <yaakov_s@rad.com= >
To: "tictoc@ietf.org" <= tictoc@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
Message-ID:
=A0 =A0 =A0 =A0 <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad= .rad.co.il>
Content-Type: text/plain; charset=3D"us-ascii"

We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1= 588overmpls
(see http://tools.ietf.org/html/draft-ietf-tictoc-1588overm= pls-05).

Please send indications of support, as well as any remaining technical comm= ents, to the list.

Due to the MPLS aspects of this draft this email is also being sent to the = MPLS WG,
but please conduct all discussion on the TICTOC working group mailing list.=

This working group last call will end on July 19, 2013.

Y(J)S



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

--047d7b5d6332fcdf1404e18e5d64-- From internet-drafts@ietf.org Mon Jul 15 13:15:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5E321E811F; Mon, 15 Jul 2013 13:15:57 -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.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWQrNTimkrSh; Mon, 15 Jul 2013 13:15:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DABF11E8211; Mon, 15 Jul 2013 13:15: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: 4.51.p2 Message-ID: <20130715201557.2557.17647.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 13:15:57 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:15:58 -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 Gro= up of the IETF. Title : Updates to LDP for IPv6 Author(s) : Rajiv Asati Vishwas Manral Rajiv Papneja Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-09.txt Pages : 17 Date : 2013-07-15 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ipv6-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 13:34:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6545F11E8229; Mon, 15 Jul 2013 13:34:54 -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.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3NEtHRz4dc1; Mon, 15 Jul 2013 13:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9A621E80EE; Mon, 15 Jul 2013 13:34:53 -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: 4.51.p2 Message-ID: <20130715203452.22966.54193.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 13:34:52 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-zhao-mpls-mldp-protections-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, 15 Jul 2013 20:34:54 -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 Gro= up of the IETF. Title : P2MP Based mLDP Node Protection Mechanisms for mLDP LSP Author(s) : Quintin Zhao Tao Chou Boris Zhang Emily Chen Filename : draft-zhao-mpls-mldp-protections-05.txt Pages : 19 Date : 2013-07-15 Abstract: This document specifies the procedures and protocol extensions for the protection of mLDP nodes within Multi-Protocol Label Switching (MPLS) networks using P2MP backup LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhao-mpls-mldp-protections There's also a htmlized version available at: http://tools.ietf.org/html/draft-zhao-mpls-mldp-protections-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhao-mpls-mldp-protections-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 15:23:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E036C21F9EC4; Mon, 15 Jul 2013 15:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umE100h3YdXc; Mon, 15 Jul 2013 15:23:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BAA21F9EA7; Mon, 15 Jul 2013 15:23:17 -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: 4.51.p2 Message-ID: <20130715222317.5238.87722.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:23:17 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:23:22 -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 Gro= up of the IETF. Title : Seamless MPLS Architecture Author(s) : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-04.txt Pages : 38 Date : 2013-07-15 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mpls-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Tue Jul 16 06:35:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFDC21F9E7C for ; Tue, 16 Jul 2013 06:35:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgn23CKt5-AY for ; Tue, 16 Jul 2013 06:35:27 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E81B111E80F3 for ; Tue, 16 Jul 2013 06:35:26 -0700 (PDT) Received: from [109.58.181.212] (109.58.181.212.bredband.tre.se [109.58.181.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1D07B1801274; Tue, 16 Jul 2013 15:35:26 +0200 (CEST) Message-ID: <51E54C1F.3080801@pi.nu> Date: Tue, 16 Jul 2013 15:35:27 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] two house keeping drafts for discussin in Berlin X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:35:36 -0000 Working Group, I've posted to small drafts, the common denominator is that they are house keeping and have something to do with the IANA LSP Ping TLV parameter registry. I've been working against the cut-off date and did not really make there are at least one more draft in the pipe. The first draft-andersson-mpls-moving-iana-registries is fairly well baked and should be possible to move along quite quickly. When RFC 6374 "Packet Loss and Delay Measurement for MPLS Networks" were developed, the code points allocated by this RFC were mistakenly placed within the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameter registry. This document creates a new dedicated name space for Generic Associated Channel code points and move them to a name space their own. Since RFC 6374 is a standards track RFC we need to do this change by a new standards track RFC, this draft attempt to fill that gap. The other one draft-andersson-mpls-lsp-ping-upd is only half-baked (or worse). I've discussed the RFC4379 IANA section with several people, and there is a general agreement that it needs to be improved. George (one of the RFC 4379 authors) has supplied some text for this update. That text is part of draft. If we don't do anything else about 4379 we should at least do what George propose. However I think there a few more things that we should do. The current text is a mix of mine and Georges. I wanted to post this draft to have a possibility to continue discuss it in Berlin. I don't plan to spend much on these drafts in the wg meeting, but like to invite anyone interested to corridor discussions. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From rcallon@juniper.net Tue Jul 16 10:01:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEC611E80E9 for ; Tue, 16 Jul 2013 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.487 X-Spam-Level: X-Spam-Status: No, score=-99.487 tagged_above=-999 required=5 tests=[AWL=-2.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C37OB3NFFvW for ; Tue, 16 Jul 2013 10:01:01 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id B646F21F9D89 for ; Tue, 16 Jul 2013 10:00:49 -0700 (PDT) Received: from mail89-db9-R.bigfish.com (10.174.16.231) by DB9EHSOBE002.bigfish.com (10.174.14.65) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 17:00:48 +0000 Received: from mail89-db9 (localhost [127.0.0.1]) by mail89-db9-R.bigfish.com (Postfix) with ESMTP id A108A800D1 for ; Tue, 16 Jul 2013 17:00:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh182cceh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail89-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rcallon@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail89-db9 (localhost.localdomain [127.0.0.1]) by mail89-db9 (MessageSwitch) id 1373994046129106_6787; Tue, 16 Jul 2013 17:00:46 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.242]) by mail89-db9.bigfish.com (Postfix) with ESMTP id 116D12C004B for ; Tue, 16 Jul 2013 17:00:46 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.52) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 17:00:41 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Jul 2013 10:00:40 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 16 Jul 2013 10:00:40 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.251) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 16 Jul 2013 10:05:20 -0700 Received: from mail71-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE041.bigfish.com (10.174.14.104) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 17:00:37 +0000 Received: from mail71-db9 (localhost [127.0.0.1]) by mail71-db9-R.bigfish.com (Postfix) with ESMTP id BC9C82EC0214 for ; Tue, 16 Jul 2013 17:00:37 +0000 (UTC) Received: from mail71-db9 (localhost.localdomain [127.0.0.1]) by mail71-db9 (MessageSwitch) id 1373994002717146_26934; Tue, 16 Jul 2013 17:00:02 +0000 (UTC) Received: from DB9EHSMHS030.bigfish.com (unknown [10.174.16.227]) by mail71-db9.bigfish.com (Postfix) with ESMTP id A133235C0049; Tue, 16 Jul 2013 17:00:02 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by DB9EHSMHS030.bigfish.com (10.174.14.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 17:00:01 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.145]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0329.000; Tue, 16 Jul 2013 16:59:54 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqQ== Date: Tue, 16 Jul 2013 16:59:54 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:01:08 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpos= e-labels-03 Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier sta= ted that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 6, 2013. Ross for the wg co-chairs --_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 

If anyone else in the working group is aware of IPRs claims against

this draft, the time to disclose that i= s now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 6, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6CH1PRD0510MB355_-- From xuxiaohu@huawei.com Tue Jul 16 17:48:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA7821F9C12 for ; Tue, 16 Jul 2013 17:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=-2.360, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAzKj0XJLCOU for ; Tue, 16 Jul 2013 17:48:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 310C321F9C13 for ; Tue, 16 Jul 2013 17:48:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB88885; Wed, 17 Jul 2013 00:48:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 01:47:42 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 01:48:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 08:48:31 +0800 From: Xuxiaohu To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqZloChjA Date: Wed, 17 Jul 2013 00:48:31 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D63FC@NKGEML512-MBS.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D63FCNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIE1QTFMgV0cgbGFzdCBjYWxsIG9uCWRyYWZ0?= =?gb2312?b?LWlldGYtbXBscy1zcGVjaWFsLXB1cnBvc2UtbGFiZWxzLTAz?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:48:44 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D63FCNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gUm9zcyBDYWxsb24NCreiy83KsbzkOiAyMDEzxOo31MIxN8jV IDE6MDANCsrVvP7IyzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNwZWNpYWwtcHVy cG9zZS1sYWJlbHNAdG9vbHMuaWV0Zi5vcmcNCrOty806IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnDQrW98ziOiBbbXBsc10gTVBMUyBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXNw ZWNpYWwtcHVycG9zZS1sYWJlbHMtMDMNCg0KV29ya2luZyBHcm91cCwNCg0KVGhpcyBpcyB0byBz dGFydCBXb3JraW5nIEdyb3VwIGxhc3QgY2FsbCBvbiAgZHJhZnQtaWV0Zi1tcGxzLXNwZWNpYWwt cHVycG9zZS1sYWJlbHMtMDMNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBs cyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4pLg0KDQpQbGVhc2Ugc2VuZCBib3RoIHRlY2huaWNhbCBjb21tZW50cywgYW5kIChp ZiB5b3UgYXJlIGhhcHB5IHdpdGggdGhlIGRvY3VtZW50IGFzIGlzKQ0KYWxzbyBzZW5kIGluZGlj YXRpb25zIG9mIHN1cHBvcnQuDQoNClRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWluc3QgdGhp cyBkcmFmdC4gVGhlIGNvLWF1dGhvcnMgaGF2ZSBlYXJsaWVyIHN0YXRlZCB0aGF0IHRoZXkNCmFy ZSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQuDQoNCklmIGFu eW9uZSBlbHNlIGluIHRoZSB3b3JraW5nIGdyb3VwIGlzIGF3YXJlIG9mIElQUnMgY2xhaW1zIGFn YWluc3QNCnRoaXMgZHJhZnQsIHRoZSB0aW1lIHRvIGRpc2Nsb3NlIHRoYXQgaXMgbm93Lg0KDQpE dWUgdG8gdGhlIHVwY29taW5nIElFVEYgbWVldGluZyBpbiBCZXJsaW4sIHRoaXMgbGFzdCBjYWxs IHdpbGwgYmUgZXh0ZW5kZWQgYnkgYW4gZXh0cmEgd2Vlaw0KKHdoaWNoIGltcGxpZXMgdGhhdCB0 aGUgbGFzdCBjYWxsIHdpbGwgYmUgb25nb2luZyBkdXJpbmcgdGhlIElFVEYgbWVldGluZykuIFRo aXMgd29ya2luZyBncm91cA0KbGFzdCBjYWxsIHdpbGwgZW5kIG9uIEF1Z3VzdCA2LCAyMDEzLg0K DQpSb3NzDQpmb3IgdGhlIHdnIGNvLWNoYWlycw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D63FCNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org= [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA7=D4=C2<= span lang=3D"EN-US">17=C8=D5 1:00
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.or= g
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03

 

Working Group,

 =

This is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 =

Please send your comment= s to the mpls working group mailing list (mpls@ietf.org).

 =

Please send both technic= al comments, and (if you are happy with the document as is)

also send indications of= support.

 =

There are no IPR claims = against this draft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 =

If anyone else in the wo= rking group is aware of IPRs claims against

this draft, the time to = disclose that is now.

 =

Due to the upcoming IETF= meeting in Berlin, this last call will be extended by an extra week

(which implies that the = last call will be ongoing during the IETF meeting). This working group

last call will end on Au= gust 6, 2013.

 =

Ross

for the wg co-chairs

 = ;

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D63FCNKGEML512MBSchi_-- From rcallon@juniper.net Tue Jul 16 20:43:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE66921F9ACA for ; Tue, 16 Jul 2013 20:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.852 X-Spam-Level: X-Spam-Status: No, score=-99.852 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5mhNEpqZPLk for ; Tue, 16 Jul 2013 20:43:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93C21F9B18 for ; Tue, 16 Jul 2013 20:43:20 -0700 (PDT) Received: from mail217-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 03:43:19 +0000 Received: from mail217-ch1 (localhost [127.0.0.1]) by mail217-ch1-R.bigfish.com (Postfix) with ESMTP id 5CFE41A0246 for ; Wed, 17 Jul 2013 03:43:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail217-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rcallon@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail217-ch1 (localhost.localdomain [127.0.0.1]) by mail217-ch1 (MessageSwitch) id 1374032596672488_31972; Wed, 17 Jul 2013 03:43:16 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail217-ch1.bigfish.com (Postfix) with ESMTP id 9E7C01E004D for ; Wed, 17 Jul 2013 03:43:16 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 03:43:16 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Jul 2013 20:43:15 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 16 Jul 2013 20:43:14 -0700 Received: from DB8EHSOBE031.bigfish.com (213.199.154.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 16 Jul 2013 20:47:54 -0700 Received: from mail12-db8-R.bigfish.com (10.174.8.231) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 03:43:12 +0000 Received: from mail12-db8 (localhost [127.0.0.1]) by mail12-db8-R.bigfish.com (Postfix) with ESMTP id 4433C2C036D for ; Wed, 17 Jul 2013 03:43:12 +0000 (UTC) Received: from mail12-db8 (localhost.localdomain [127.0.0.1]) by mail12-db8 (MessageSwitch) id 1374032590604231_4437; Wed, 17 Jul 2013 03:43:10 +0000 (UTC) Received: from DB8EHSMHS002.bigfish.com (unknown [10.174.8.247]) by mail12-db8.bigfish.com (Postfix) with ESMTP id 8462120049; Wed, 17 Jul 2013 03:43:10 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by DB8EHSMHS002.bigfish.com (10.174.4.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 03:43:10 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.67]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0329.000; Wed, 17 Jul 2013 03:43:08 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqZloOvRQ Date: Wed, 17 Jul 2013 03:43:08 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-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, 17 Jul 2013 03:43:38 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder, please send responses to the MPLS WG email list. Thanks, Ross From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, July 16, 2013 1:00 PM To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpos= e-labels-03 Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier sta= ted that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 6, 2013. Ross for the wg co-chairs --_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder, please send res= ponses to the MPLS WG email list.

 <= /p>

Thanks, Ross

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf= .org
Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03

 

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 

If anyone else in the working group is aware of IPRs claims against

this draft, the time to disclose that i= s now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 6, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01CH1PRD0510MB355_-- From iesg-secretary@ietf.org Wed Jul 17 06:35:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3654121F9EDD; Wed, 17 Jul 2013 06:35:59 -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.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFkgqSPgUtqc; Wed, 17 Jul 2013 06:35:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CE21F9EA7; Wed, 17 Jul 2013 06:35:58 -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: 4.53 Sender: Message-ID: <20130717133558.17354.68035.idtracker@ietfa.amsl.com> Date: Wed, 17 Jul 2013 06:35:58 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel) 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, 17 Jul 2013 13:35:59 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel' as 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 2013-07-31. 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 MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv/ballot/ No IPR declarations have been submitted directly on this I-D. From iwijnand@cisco.com Wed Jul 17 08:11:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863CE11E80FA for ; Wed, 17 Jul 2013 08:11:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8eKFyrb5R5c for ; Wed, 17 Jul 2013 08:11:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2506211E8105 for ; Wed, 17 Jul 2013 08:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1399; q=dns/txt; s=iport; t=1374073903; x=1375283503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L+0wU8VBQfbVoNWkA5Hh/I+O6Pf+tBWv3FD5wLj713c=; b=MlUsw1ymIkMHTqV98Exe5Cb08vC/cHBEchJhwXJMqNF/lBEoOY/OpM/s +QDWlYzS896fT00R0DRD+GaEzwsDZaV6GKwPp/dzT6jb+IbvV9PvJtU2x 3aE88pHxhr46ViARLXQxwxgaEXdOaWshz/K89gvhlIcikJHFqEStqbzKe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAuy5lGtJV2c/2dsb2JhbABagwY0wyKBEBZ0giMBAQEDAQEBATcxAwsFCQICAQg2EBsMCyUCBA4FiAoGDLYFBASONIFCB4MNbgOXXJFNgxKBcQ X-IronPort-AV: E=Sophos;i="4.89,685,1367971200"; d="scan'208";a="235985070" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2013 15:11:42 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HFBg4w016828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 15:11:42 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.163]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 10:11:42 -0500 From: "IJsbrand Wijnands (iwijnand)" To: Loa Andersson Thread-Topic: [mpls] draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOd9/e4hssZ9Vpr0WLFblxiQRFQ5lpECLT Date: Wed, 17 Jul 2013 15:11:41 +0000 Message-ID: References: <51D40986.1040709@pi.nu> In-Reply-To: <51D40986.1040709@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:11:55 -0000 Support as co-author. On 03 Jul 2013, at 13:24, "Loa Andersson" wrote: > Working Group, >=20 > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-node-protection as an MPLS working > group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends July 17, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/1727/ > https://datatracker.ietf.org/ipr/2116/ >=20 >=20 > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. >=20 > /Loa > (mpls wg co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From renwei.li@huawei.com Wed Jul 17 08:39:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C074621F90FB for ; Wed, 17 Jul 2013 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdFX1iskCM9Q for ; Wed, 17 Jul 2013 08:39:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6721F8FD8 for ; Wed, 17 Jul 2013 08:39:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD31053; Wed, 17 Jul 2013 15:39:08 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:37:28 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:38:21 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 08:38:13 -0700 From: Richard Li To: "erosen@cisco.com" , William McCall Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOeZgLPkhJY0+Kvke3sDwL13/hpJloipsg Date: Wed, 17 Jul 2013 15:38:12 +0000 Message-ID: References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> In-Reply-To: <30677.1373039405@erosen-linux> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:39:14 -0000 Hi! Thanks for the comments. And I am sorry for the late reply; I was on vacati= ons. Now let me clarify and explain why we need something like big labels. 1.=20 You do have a good point here. Yes, it is true that one can always get a bi= gger label space by stacking labels over labels. The combination of two "sm= all" labels may achieve what a "big" label can do. But their fundamental co= ncepts and the consequences will be totally different. Conceptually, a labe= l has four components: label value, BOS indicator, the EXP bits and the TT= L value. If you use two "small" labels to represent a "big" label, you will= run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You can sem= antically combine the two label values, but you can't combine other fields = such as TTL. If the two labels are collectively considered as ONE label, th= ey should have one TTL, one EXP, and one BOS since they should be treated a= nd processed as a single and inseparable entity. Having multiple TTLs/EXPs/= BOSes is conceptually counter-intuitive against the very idea of "a label".= =20 2.=20 Context was introduced in the context of upstream-assigned labels for multi= cast LSPs. It provides the concept of context, but it doesn't provide the c= oncept of "big labels". The label itself is still 20 bits in length. The la= bel space in a context is not expanded; it is still 1M.=20 3.=20 If you use context labels, you will need 16 contexts since each context wil= l only hold 1M labels. Which label belongs to which context will be very ar= bitrary; If someone put a label in one context, it won't be wrong if anothe= r one put the same label in a different context. There is no semantic assoc= iation at all between contexts and labels, which is different from the situ= ation about contexts for upstream-assigned labels where one simply can't pu= t upstream-assigned labels in an arbitrary context. 4.=20 In this proposal, we only need two 32-bit entries for a "big label": the bi= g label indicator + big label value. The big label indicator is a reserved = label. We don't need three label entries in an MPLS packet. 5. With respect to the BGP protocol, the "big label" proposal has some scaling= benefits over the context-based solution. If you use context labels, you w= ill need to add 64 extra bits in BGP's NLRI: context label and a secondary = label. But if you use the big label proposal in this draft, you will only = need to add 32 bits: big label value. Saving the extra 32 bits to each VPN= route can be a big deal, especially when we are talking about up to 16M VP= Ns here for virtualized networks currently being standardized by NVO3/VXLAN= /NVGRE. 6. In the operating system and line cards, the "big label" proposal also has s= ome benefits over the context-based solution. If you use contexts, you have= to store the context label in conjunction with the VPN label. But if you u= se the big label proposal, you only need an attribute flag bit to mean the = VPN label is a big one. The same thing holds true in the forwarding softwar= e.=20 Regards, Richard -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Friday, July 05, 2013 11:50 PM To: William McCall Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) > What would this change alleviate that could not already be solved by=20 > adding another label to the stack? Excellent point. Please see also section 3 (especially the last paragraph) of RFC 5331 on "c= ontext labels". By using one label as a "context label" identifying a cont= ext in which the subsequent label is interpreted, one gets the effect of a = 40-bit label space, and the same mechanism can also be used to support upst= ream-assigned labels. It's also worth noting that the "big label" proposal would probably end up = using three label stack entries per big label: special purpose label indica= tor, big label indicator, big label value. The use of context labels will = require only two label stack entries. From renwei.li@huawei.com Wed Jul 17 08:39:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA4B21F9E26 for ; Wed, 17 Jul 2013 08:39:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9PbUqqz8cg0 for ; Wed, 17 Jul 2013 08:39:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF7E21F8FD8 for ; Wed, 17 Jul 2013 08:39:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD31067; Wed, 17 Jul 2013 15:39:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:37:53 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:38:46 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 08:38:41 -0700 From: Richard Li To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt Thread-Index: AQHOdd+A3aiwC4A4oU2RIaGDkUi0fplpG3Sg Date: Wed, 17 Jul 2013 15:38:41 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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, 17 Jul 2013 15:39:19 -0000 SGkgQWxsIQ0KDQpXZSBoYXZlIHVwZGF0ZWQgb3VyIHJlY2VpdmVyLWRyaXZlbiBSU1ZQLVRFIGRy YWZ0LiBZb3VyIGNvbW1lbnRzIHdpbGwgYmUgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQpSZWdhcmRz LA0KDQpSaWNoYXJkDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBNb25kYXksIEp1bHkgMDEsIDIwMTMgNjoxNyBBTQ0KVG86IFRlbHVzIENvbW11bmljYXRp b25zOyBDaHJpc3RpYW4gSmFjcXVlbmV0OyBFZHVhcmQgTWV0ejsgQm9yaXMgWmhhbmc7IFF1aW50 aW4gemhhbzsgUmljaGFyZCBMaQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1semotbXBscy1yZWNlaXZlci1kcml2ZW4tbXVsdGljYXN0LXJzdnAtdGUtMDMudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWx6ai1tcGxzLXJlY2VpdmVyLWRyaXZl bi1tdWx0aWNhc3QtcnN2cC10ZS0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgUmVud2VpIExpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6CSBkcmFmdC1semotbXBscy1yZWNlaXZlci1kcml2ZW4tbXVsdGljYXN0LXJzdnAtdGUN ClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIFJlY2VpdmVyLURyaXZlbiBNdWx0aWNhc3QgVHJhZmZp Yy1FbmdpbmVlcmVkIExhYmVsLVN3aXRjaGVkIFBhdGhzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0w Ny0wMQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDI0 DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWx6ai1tcGxzLXJlY2VpdmVyLWRyaXZlbi1tdWx0aWNhc3QtcnN2cC10ZS0wMy50eHQNClN0 YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1semot bXBscy1yZWNlaXZlci1kcml2ZW4tbXVsdGljYXN0LXJzdnAtdGUNCkh0bWxpemVkOiAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbHpqLW1wbHMtcmVjZWl2ZXItZHJpdmVu LW11bHRpY2FzdC1yc3ZwLXRlLTAzDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWx6ai1tcGxzLXJlY2VpdmVyLWRyaXZlbi1tdWx0aWNhc3Qt cnN2cC10ZS0wMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVu c2lvbnMgdG8gUmVzb3VyY2UgUmVzZXJ2YXRpb24gUHJvdG9jb2wgLQ0KICAgVHJhZmZpYyBFbmdp bmVlcmluZyAoUlNWUC1URSkgZm9yIHRoZSBzZXR1cCBvZiBSZWNlaXZlci1Ecml2ZW4NCiAgIFRy YWZmaWMtRW5naW5lZXJlZCBwb2ludC10by1tdWx0aXBvaW50IChQMk1QKSBhbmQgbXVsdGlwb2lu dC10by0NCiAgIG11bHRpcG9pbnQgKE1QMk1QKUxhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKSBp biBNdWx0aS1Qcm90b2NvbCBMYWJlbA0KICAgU3dpdGNoaW5nIChNUExTKSBhbmQgR2VuZXJhbGl6 ZWQgTVBMUyAoR01QTFMpbmV0d29ya3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From akatlas@gmail.com Wed Jul 17 09:19:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2221F9B40 for ; Wed, 17 Jul 2013 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSvyJsC0j72g for ; Wed, 17 Jul 2013 09:19:30 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08021F9E7C for ; Wed, 17 Jul 2013 09:19:28 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so4432210iec.22 for ; Wed, 17 Jul 2013 09:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0w8fZL4RZm1C5jaFWm0xer7qvBcBo1J/cEhJqrr77ic=; b=XcZWouCa/82kEJrzGclDw9ERim7/VECAcwtgnTFbxuIt4ZFeXeIcS2KOVy74mO3Zbh Ru/WnM+/wUut7g6dpbxubOpgx+OMG9AhOsZ6kySfN7KJPgjpo4fWV6YLRfvBEizMjQJw rpU6c63TXKhbyf7fq0AKtZ9hbF9t+QZbMjTQrHtwazfi3Z1Ek+iSn1PlXxucqLVDUNeI Zk+6Y2Jgq8Pir5L31jmOHXzZdg7QhFWqrb9yvxlnTc7QRXBy4zrwLHgpEbGDM9IMXk9N HlVLrtSyZ0Zuo7NI+EMA9/qHerxKXxjLP8RsV2EKSEin1Oiuz0fsA8SeGMD7fePKyzad 1uOw== MIME-Version: 1.0 X-Received: by 10.50.79.167 with SMTP id k7mr1535181igx.56.1374077968242; Wed, 17 Jul 2013 09:19:28 -0700 (PDT) Received: by 10.64.165.197 with HTTP; Wed, 17 Jul 2013 09:19:28 -0700 (PDT) Received: by 10.64.165.197 with HTTP; Wed, 17 Jul 2013 09:19:28 -0700 (PDT) In-Reply-To: <51D40986.1040709@pi.nu> References: <51D40986.1040709@pi.nu> Date: Wed, 17 Jul 2013 12:19:28 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=089e013a1a3830e59d04e1b77589 Cc: "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:19:30 -0000 --089e013a1a3830e59d04e1b77589 Content-Type: text/plain; charset=ISO-8859-1 Support as co-author. Alia On Jul 3, 2013 4:23 AM, "Loa Andersson" wrote: > Working Group, > > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-node-**protection as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends July 17, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/**ipr/1727/ > https://datatracker.ietf.org/**ipr/2116/ > > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --089e013a1a3830e59d04e1b77589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Support as co-author.

Alia

On Jul 3, 2013 4:23 AM, "Loa Andersson"= ; <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-wijnands-mpls-mldp-node-protection as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends July 17, 2013.

There are two IPR claims against this document:

https:= //datatracker.ietf.org/ipr/1727/
https:= //datatracker.ietf.org/ipr/2116/


The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
--089e013a1a3830e59d04e1b77589-- From naikumar@cisco.com Wed Jul 17 10:46:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DCE21F9BA0 for ; Wed, 17 Jul 2013 10:46:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-pIPw1KBaTW for ; Wed, 17 Jul 2013 10:46:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA221F9F00 for ; Wed, 17 Jul 2013 10:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5279; q=dns/txt; s=iport; t=1374083171; x=1375292771; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oF2HokLsUDcmxgNKoc2HV2tJ/oqKi/hI2KqcZFdcOyo=; b=DKwfaE3zoLNjVKuSqwqqXNndUq1++crBLjUwyQczX4uc84fZq42HN5Te SiB6aaq4xJFvEvZ90Yig9Qfl5NRFcWc2FO8xyKm6TfraTJFxat0urDx82 7z1CCZYjMl7OkbsDCFmsOkOXUzQ+pOA1GqSUYlKHuFhAWoxIaHyMR2s12 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIPX5lGtJV2c/2dsb2JhbABagwY0UMJWgREWdIIjAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQsUBQQHJwsUCQgCBAENBQgTh28GDLVfBI9JMQcGgwduA6kpgVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,686,1367971200"; d="scan'208";a="236062460" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jul 2013 17:46:10 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HHkAUA005129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 17:46:10 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 12:46:10 -0500 From: "Nagendra Kumar (naikumar)" To: Richard Li , "Eric Rosen (erosen)" , William McCall Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOgwPPPb/aF3zpcUGWhGzyR96Ic5lpGpvg Date: Wed, 17 Jul 2013 17:46:10 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:46:21 -0000 Hi Richard, Is the proposal is to use the big label indicator only when the label size = is more than 20 bits?. If not, I think it is a trade off between label sta= ck size vs fwding semantic. With big label, any service like VPN will requi= re 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP labe= l and application label) which is equivalent to 4 labels. But with context = label, it is going to be 3 labels. While context label is explained in terms of upstream label for MP-LSP, I t= hink nothing stops its usage for unicast LSP.=20 -Nagendra -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ric= hard Li Sent: Wednesday, July 17, 2013 9:08 PM To: Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi! Thanks for the comments. And I am sorry for the late reply; I was on vacati= ons. Now let me clarify and explain why we need something like big labels. 1.=20 You do have a good point here. Yes, it is true that one can always get a bi= gger label space by stacking labels over labels. The combination of two "sm= all" labels may achieve what a "big" label can do. But their fundamental co= ncepts and the consequences will be totally different. Conceptually, a labe= l has four components: label value, BOS indicator, the EXP bits and the TT= L value. If you use two "small" labels to represent a "big" label, you will= run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You can sem= antically combine the two label values, but you can't combine other fields = such as TTL. If the two labels are collectively considered as ONE label, th= ey should have one TTL, one EXP, and one BOS since they should be treated a= nd processed as a single and inseparable entity. Having multiple TTLs/EXPs/= BOSes is conceptually counter-intuitive against the very idea of "a label".= =20 2.=20 Context was introduced in the context of upstream-assigned labels for multi= cast LSPs. It provides the concept of context, but it doesn't provide the c= oncept of "big labels". The label itself is still 20 bits in length. The la= bel space in a context is not expanded; it is still 1M.=20 3.=20 If you use context labels, you will need 16 contexts since each context wil= l only hold 1M labels. Which label belongs to which context will be very ar= bitrary; If someone put a label in one context, it won't be wrong if anothe= r one put the same label in a different context. There is no semantic assoc= iation at all between contexts and labels, which is different from the situ= ation about contexts for upstream-assigned labels where one simply can't pu= t upstream-assigned labels in an arbitrary context. 4.=20 In this proposal, we only need two 32-bit entries for a "big label": the bi= g label indicator + big label value. The big label indicator is a reserved = label. We don't need three label entries in an MPLS packet. 5. With respect to the BGP protocol, the "big label" proposal has some scaling= benefits over the context-based solution. If you use context labels, you w= ill need to add 64 extra bits in BGP's NLRI: context label and a secondary = label. But if you use the big label proposal in this draft, you will only = need to add 32 bits: big label value. Saving the extra 32 bits to each VPN= route can be a big deal, especially when we are talking about up to 16M VP= Ns here for virtualized networks currently being standardized by NVO3/VXLAN= /NVGRE. 6. In the operating system and line cards, the "big label" proposal also has s= ome benefits over the context-based solution. If you use contexts, you have= to store the context label in conjunction with the VPN label. But if you u= se the big label proposal, you only need an attribute flag bit to mean the = VPN label is a big one. The same thing holds true in the forwarding softwar= e.=20 Regards, Richard -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Friday, July 05, 2013 11:50 PM To: William McCall Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) > What would this change alleviate that could not already be solved by=20 > adding another label to the stack? Excellent point. Please see also section 3 (especially the last paragraph) of RFC 5331 on "c= ontext labels". By using one label as a "context label" identifying a cont= ext in which the subsequent label is interpreted, one gets the effect of a = 40-bit label space, and the same mechanism can also be used to support upst= ream-assigned labels. It's also worth noting that the "big label" proposal would probably end up = using three label stack entries per big label: special purpose label indica= tor, big label indicator, big label value. The use of context labels will = require only two label stack entries. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Wed Jul 17 11:41:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51CA21F9D90 for ; Wed, 17 Jul 2013 11:41:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlk+OIfkJ7Zi for ; Wed, 17 Jul 2013 11:41:32 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81C9421F9D7E for ; Wed, 17 Jul 2013 11:41:32 -0700 (PDT) Received: from [10.9.208.55] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 17 Jul 2013 11:37:35 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 17 Jul 2013 11:39:41 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 17 Jul 2013 11:39:41 -0700 From: "Shahram Davari" To: "Nagendra Kumar (naikumar)" , "Richard Li" , "Eric Rosen (erosen)" , "William McCall" Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOeZdRrjYfUWttxE++askNKOtdLZlpiXQAgAAjwQD//5TyIA== Date: Wed, 17 Jul 2013 18:39:41 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DF83BE531W53039917-03-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:41:36 -0000 Hi Richard, I agree with Eric and Nagendra. What you want is achievable with context-ba= sed label. Please see my comments inline. Thanks Shahram=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Nag= endra Kumar (naikumar) Sent: Wednesday, July 17, 2013 10:46 AM To: Richard Li; Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi Richard, Is the proposal is to use the big label indicator only when the label size = is more than 20 bits?. If not, I think it is a trade off between label sta= ck size vs fwding semantic. With big label, any service like VPN will requi= re 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP labe= l and application label) which is equivalent to 4 labels. But with context = label, it is going to be 3 labels. While context label is explained in terms of upstream label for MP-LSP, I t= hink nothing stops its usage for unicast LSP.=20 -Nagendra -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ric= hard Li Sent: Wednesday, July 17, 2013 9:08 PM To: Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi! Thanks for the comments. And I am sorry for the late reply; I was on vacati= ons. Now let me clarify and explain why we need something like big labels. 1.=20 You do have a good point here. Yes, it is true that one can always get a bi= gger label space by stacking labels over labels. The combination of two "sm= all" labels may achieve what a "big" label can do. But their fundamental co= ncepts and the consequences will be totally different. Conceptually, a labe= l has four components: label value, BOS indicator, the EXP bits and the TT= L value. If you use two "small" labels to represent a "big" label, you will= run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You can sem= antically combine the two label values, but you can't combine other fields = such as TTL. If the two labels are collectively considered as ONE label, th= ey should have one TTL, one EXP, and one BOS since they should be treated a= nd processed as a single and inseparable entity. Having multiple TTLs/EXPs/= BOSes is conceptually counter-intuitive against the very idea of "a label".= =20 SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EXP fo= r both labels (redundant).=20 2.=20 Context was introduced in the context of upstream-assigned labels for multi= cast LSPs. It provides the concept of context, but it doesn't provide the c= oncept of "big labels". The label itself is still 20 bits in length. The la= bel space in a context is not expanded; it is still 1M.=20 SD> Multicast was one of the applications of context-based lookup. This can= be another application. The labels space with context is not 1M anymore. = It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit lookup. 3.=20 If you use context labels, you will need 16 contexts since each context wil= l only hold 1M labels. Which label belongs to which context will be very ar= bitrary; If someone put a label in one context, it won't be wrong if anothe= r one put the same label in a different context. There is no semantic assoc= iation at all between contexts and labels, which is different from the situ= ation about contexts for upstream-assigned labels where one simply can't pu= t upstream-assigned labels in an arbitrary context. SD> I think you have may not have understood the context label well. The co= ntext label tells you the meaning of the label under it. Think of it as 40 = bit label, that is how it works.=20 4.=20 In this proposal, we only need two 32-bit entries for a "big label": the bi= g label indicator + big label value. The big label indicator is a reserved = label. We don't need three label entries in an MPLS packet. SD> draft-ietf-mpls-special-purpose-labels-03.txt from now on requires usi= ng a special label indicator before the special big label indicator. So you= need 3 labels. 5. With respect to the BGP protocol, the "big label" proposal has some scaling= benefits over the context-based solution. If you use context labels, you w= ill need to add 64 extra bits in BGP's NLRI: context label and a secondary = label. But if you use the big label proposal in this draft, you will only = need to add 32 bits: big label value. Saving the extra 32 bits to each VPN= route can be a big deal, especially when we are talking about up to 16M VP= Ns here for virtualized networks currently being standardized by NVO3/VXLAN= /NVGRE. SD> BGP packet size is not an issue, after all it is just control packet. 6. In the operating system and line cards, the "big label" proposal also has s= ome benefits over the context-based solution. If you use contexts, you have= to store the context label in conjunction with the VPN label. But if you u= se the big label proposal, you only need an attribute flag bit to mean the = VPN label is a big one. The same thing holds true in the forwarding softwar= e.=20 SD> Also in big label you have to store a 32-bit label value instead of 20 = bit label. But the advantage of context-based method is that you won't need= new hardware. While for big label you will need new hardware. Regards, Richard -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Friday, July 05, 2013 11:50 PM To: William McCall Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) > What would this change alleviate that could not already be solved by=20 > adding another label to the stack? Excellent point. Please see also section 3 (especially the last paragraph) of RFC 5331 on "c= ontext labels". By using one label as a "context label" identifying a cont= ext in which the subsequent label is interpreted, one gets the effect of a = 40-bit label space, and the same mechanism can also be used to support upst= ream-assigned labels. It's also worth noting that the "big label" proposal would probably end up = using three label stack entries per big label: special purpose label indica= tor, big label indicator, big label value. The use of context labels will = require only two label stack entries. _______________________________________________ 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 Wed Jul 17 12:07:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F5721E808F for ; Wed, 17 Jul 2013 12:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBtRsidB-EsE for ; Wed, 17 Jul 2013 12:06:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4721E809C for ; Wed, 17 Jul 2013 12:06:55 -0700 (PDT) Received: from mail204-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 19:06:54 +0000 Received: from mail204-ch1 (localhost [127.0.0.1]) by mail204-ch1-R.bigfish.com (Postfix) with ESMTP id F3B7C4002E1 for ; Wed, 17 Jul 2013 19:06:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542I1432I1447Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail204-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=jdrake@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail204-ch1 (localhost.localdomain [127.0.0.1]) by mail204-ch1 (MessageSwitch) id 1374088012310753_16752; Wed, 17 Jul 2013 19:06:52 +0000 (UTC) Received: from CH1EHSMHS042.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail204-ch1.bigfish.com (Postfix) with ESMTP id 3B6F71E004A for ; Wed, 17 Jul 2013 19:06:52 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS042.bigfish.com (10.43.69.251) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 19:06:51 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Jul 2013 12:06:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Wed, 17 Jul 2013 12:06:50 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.206) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Jul 2013 12:19:59 -0700 Received: from mail23-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 19:06:48 +0000 Received: from mail23-am1 (localhost [127.0.0.1]) by mail23-am1-R.bigfish.com (Postfix) with ESMTP id 725A74A018A for ; Wed, 17 Jul 2013 19:06:48 +0000 (UTC) Received: from mail23-am1 (localhost.localdomain [127.0.0.1]) by mail23-am1 (MessageSwitch) id 1374088007425600_12500; Wed, 17 Jul 2013 19:06:47 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.226]) by mail23-am1.bigfish.com (Postfix) with ESMTP id 63985360047; Wed, 17 Jul 2013 19:06:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 19:06:47 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.14]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0329.000; Wed, 17 Jul 2013 19:06:46 +0000 From: John E Drake To: Shahram Davari , "Nagendra Kumar (naikumar)" , Richard Li , "Eric Rosen (erosen)" , William McCall Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOgwPkQSGQlxIYTEuA+vtQsT4FaplpJQMAgAAO9ICAAAak8A== Date: Wed, 17 Jul 2013 19:06:45 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E2073E65E@BL2PRD0510MB349.namprd05.prod.outlook.com> References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BROADCOM.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:07:01 -0000 Shahram, Your email, below, is excellent.=20 Yours Irrespectively, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Wednesday, July 17, 2013 11:40 AM > To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William > McCall > Cc: Mli; mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: > Review of draft-renwei-mpls-bgp-big-label-00) >=20 > Hi Richard, >=20 > I agree with Eric and Nagendra. What you want is achievable with > context-based label. Please see my comments inline. >=20 > Thanks > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Nagendra Kumar (naikumar) > Sent: Wednesday, July 17, 2013 10:46 AM > To: Richard Li; Eric Rosen (erosen); William McCall > Cc: Mli; mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: > Review of draft-renwei-mpls-bgp-big-label-00) >=20 > Hi Richard, >=20 > Is the proposal is to use the big label indicator only when the label > size is more than 20 bits?. If not, I think it is a trade off between > label stack size vs fwding semantic. With big label, any service like > VPN will require 2 big label indicator (each 32 bits) and 2 * 32 bits > big label (IGP label and application label) which is equivalent to 4 > labels. But with context label, it is going to be 3 labels. >=20 > While context label is explained in terms of upstream label for MP-LSP, > I think nothing stops its usage for unicast LSP. >=20 > -Nagendra >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Richard Li > Sent: Wednesday, July 17, 2013 9:08 PM > To: Eric Rosen (erosen); William McCall > Cc: Mli; mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: > Review of draft-renwei-mpls-bgp-big-label-00) >=20 > Hi! >=20 > Thanks for the comments. And I am sorry for the late reply; I was on > vacations. >=20 > Now let me clarify and explain why we need something like big labels. >=20 > 1. > You do have a good point here. Yes, it is true that one can always get > a bigger label space by stacking labels over labels. The combination of > two "small" labels may achieve what a "big" label can do. But their > fundamental concepts and the consequences will be totally different. > Conceptually, a label has four components: label value, BOS indicator, > the EXP bits and the TTL value. If you use two "small" labels to > represent a "big" label, you will run into TWO BOS indicators, TWO EXP > bits, and TWO TTL values. You can semantically combine the two label > values, but you can't combine other fields such as TTL. If the two > labels are collectively considered as ONE label, they should have one > TTL, one EXP, and one BOS since they should be treated and processed as > a single and inseparable entity. Having multiple TTLs/EXPs/BOSes is > conceptually counter-intuitive against the very idea of "a label". >=20 > SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and > EXP for both labels (redundant). >=20 > 2. > Context was introduced in the context of upstream-assigned labels for > multicast LSPs. It provides the concept of context, but it doesn't > provide the concept of "big labels". The label itself is still 20 bits > in length. The label space in a context is not expanded; it is still > 1M. >=20 > SD> Multicast was one of the applications of context-based lookup. This > can be another application. The labels space with context is not 1M > anymore. It is 1Mx1M. Because for context-based MPLS lookup does a 40- > bit lookup. >=20 > 3. > If you use context labels, you will need 16 contexts since each context > will only hold 1M labels. Which label belongs to which context will be > very arbitrary; If someone put a label in one context, it won't be > wrong if another one put the same label in a different context. There > is no semantic association at all between contexts and labels, which is > different from the situation about contexts for upstream-assigned > labels where one simply can't put upstream-assigned labels in an > arbitrary context. >=20 > SD> I think you have may not have understood the context label well. > The context label tells you the meaning of the label under it. Think of > it as 40 bit label, that is how it works. >=20 > 4. > In this proposal, we only need two 32-bit entries for a "big label": > the big label indicator + big label value. The big label indicator is a > reserved label. We don't need three label entries in an MPLS packet. >=20 > SD> draft-ietf-mpls-special-purpose-labels-03.txt from now on requires > using a special label indicator before the special big label indicator. > So you need 3 labels. >=20 > 5. > With respect to the BGP protocol, the "big label" proposal has some > scaling benefits over the context-based solution. If you use context > labels, you will need to add 64 extra bits in BGP's NLRI: context label > and a secondary label. But if you use the big label proposal in this > draft, you will only need to add 32 bits: big label value. Saving the > extra 32 bits to each VPN route can be a big deal, especially when we > are talking about up to 16M VPNs here for virtualized networks > currently being standardized by NVO3/VXLAN/NVGRE. >=20 > SD> BGP packet size is not an issue, after all it is just control > packet. >=20 > 6. > In the operating system and line cards, the "big label" proposal also > has some benefits over the context-based solution. If you use contexts, > you have to store the context label in conjunction with the VPN label. > But if you use the big label proposal, you only need an attribute flag > bit to mean the VPN label is a big one. The same thing holds true in > the forwarding software. >=20 > SD> Also in big label you have to store a 32-bit label value instead of > 20 bit label. But the advantage of context-based method is that you > won't need new hardware. While for big label you will need new > hardware. >=20 >=20 > Regards, >=20 >=20 > Richard >=20 >=20 >=20 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, July 05, 2013 11:50 PM > To: William McCall > Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: > Review of draft-renwei-mpls-bgp-big-label-00) >=20 >=20 > > What would this change alleviate that could not already be solved by > > adding another label to the stack? >=20 > Excellent point. >=20 > Please see also section 3 (especially the last paragraph) of RFC 5331 > on "context labels". By using one label as a "context label" > identifying a context in which the subsequent label is interpreted, one > gets the effect of a 40-bit label space, and the same mechanism can > also be used to support upstream-assigned labels. >=20 > It's also worth noting that the "big label" proposal would probably end > up using three label stack entries per big label: special purpose label > indicator, big label indicator, big label value. The use of context > labels will require only two label stack entries. >=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 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From alessandro.dalessandro@telecomitalia.it Wed Jul 17 12:22:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F021F9133 for ; Wed, 17 Jul 2013 12:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju+21D0DkQsq for ; Wed, 17 Jul 2013 12:22:35 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEEB21F9F1F for ; Wed, 17 Jul 2013 12:22:34 -0700 (PDT) Content-Type: multipart/mixed; boundary="_a43f8fc3-7c6e-4301-89e4-12c40def693f_" Received: from TELCAH003RM001.telecomitalia.local (10.19.10.106) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 17 Jul 2013 21:22:33 +0200 Received: from TELMBA002RM001.telecomitalia.local ([169.254.1.126]) by TELCAH003RM001.telecomitalia.local ([10.19.10.106]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 21:22:32 +0200 From: D'Alessandro Alessandro Gerardo To: "mpls@ietf.org" Thread-Topic: proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQg== Date: Wed, 17 Jul 2013 19:22:32 +0000 Message-ID: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.10.77] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:22:40 -0000 --_a43f8fc3-7c6e-4301-89e4-12c40def693f_ Content-Type: multipart/alternative; boundary="_000_22257C41A415324A984CD03D63344E271F1B7A8BTELMBA002RM001t_" --_000_22257C41A415324A984CD03D63344E271F1B7A8BTELMBA002RM001t_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all, we would like socializing the herebelow drafts that were submitted some mon= ths ago with the aim to align PSC protocol (RFC 6378) to ITU-T transport re= quirements. I would appreciate your comments about the proposed mechanisms = and behaviours. draft-rhd-mpls-tp-psc-priority-00 draft-cdh-mpls-tp-psc-non-revertive-00 draft-rhd-mpls-tp-psc-sd-00 draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 The above drafts cover most of items highlighted in ITU-T liaisons about PS= C and they propose solutions in line with MPLS-TP transport requirements. A list of main liaisons exchanged between ITU-T and IETF with the aim to al= ign PSC behavious with ITU-T transport requirements for linear protection a= re given below: https://datatracker.ietf.org/liaison/1162/ (June 2012) https://datatracker.ietf.org/liaison/1205/ (October 2012) https://datatracker.ietf.org/liaison/1229/ (January 2013) https://datatracker.ietf.org/liaison/1234/ (February 2013) https://datatracker.ietf.org/liaison/1256/ (May 2013) Some details abou the proposed drafts for align PSC behaviour with transpor= t requirements: draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities between = FS and SF-P (see section 4.3.2 of rfc6378). Among the others, behaviors that will be fixed with the proposed update are= : Use case A) At first, working path(WP) and protection path(PP) are normal. = Then, Forced Switch(FS) command is issued for maintenance on the WP and the= traffic moves from WP to PP. When Signal Fail occurs on PP, service canno= t recover and is interrupted. This could occur for example as a result of a= ccidentally un-plugging a PP fiber. Use case B) If there is an existing signal fail on a protection path (SF-P)= ,and FS command is issued by accident the traffic on WP will move to PP. T= his results in an interruption of service from which you will not automatic= ally recover, because PSC should not have switched the traffic from WP to P= P. Discussion about this draft led to the proposal to modify RFC 4427 that was= "written correctly though lacking in detail causing mis-interpretation" th= at led to the current PSC set of priority that the above draft is proposing= to modified and to align to the required transport behavior. draft-helvoor= t-ccamp-fs-priority-00 has been submitted to CCAMP for clarifying the defin= itions related to Manual Switch and Forced Switch and their usage relative = to priorities. The way this behavior has to be incorporated into the PSC has to be discuss= ed. The text proposes to replace the current behavior with the new one. If = there is consensus to procede in that way this can bring to a simple and ef= fective way to operate the protocol. ---------------------------------------------------------------------- draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378 to = change non-revertive operations to behaves in the same way irrespectively o= f the trigger of protection switching (fault or operator command FS, MS). = Consequently an operator command, Manual Switch to Working (MS-W) a.k.a =93= Manual switch-over for recovery LSP/span=94 is also added to enable this be= havior. From an operational point of view, MS to working path has also to b= e supported to be able to initially align at both sides in case of non-reve= rtive switching mode. MS to working path is defined in RFC 5654, requiremen= t 83. The proposed MS-W command is of equal priority to the existing MS-P command= , and there is text to handle the simultaneous or sequential occurrence of = two equal-priority commands. This behavior, already adopted in other transp= ort network protection switching protocol, can be used for other addition t= o the protocol in the future. ---------------------------------------------------------------------- draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state machine t= o handle Signal Degrade (SD). It does not define SD or provide scope aroun= d where or how SD may be used similarly as it already happen in the draft i= n handling other defects like SF (Signal Failure). In MPLS-TP survivability framework [RFC6372], a fault condition includes b= oth Signal Fail (SF) and Signal Degrade (SD) that can be used to trigger p= rotection switching. While the standardization lack of an SD definition and detection mechanisms= , the relevant behaviors in terms of protection actions may already be defi= ned. ---------------------------------------------------------------------- draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to test i= f the APS communication is operating correctly. In other words both APS pro= cess logic including state machine and APS channel on protection path, with= out service disruption and without affecting any protection operation, unle= ss the protection transport entity is in use. This command is documented in= R84 of [RFC5654] and it is part of ITU-T transport requirements. An alternative proposal is documented in the Appendix B of RFC6378 that uti= lizes the Lockout of Protection (LO) or Forced Switch (FS) in combination o= f OAM functionalities. However, it has some functional limitation and has a= potential risk of losing traffic as a signal failure might occur during th= e exercise operation. In that case, LO or FS has to be canceled to allow th= e PSC protocol to provide proper switching. A further alternative proposal is documented in draft-osborne-mpls-psc-aliv= e-00 that anyway show some functional limitations because cannot validate t= he PSC state machine status and probably the Local Request logic. The authors encourage the IETF experts to comment on these drafts, eventual= ly proposing other options/mechanisms that can satisfy the same requirement= s. Best regards, Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_22257C41A415324A984CD03D63344E271F1B7A8BTELMBA002RM001t_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear all,
we would like socializing the herebelow drafts that were submitted some mon= ths ago with the aim to align PSC protocol (RFC 6378) to ITU-T transport re= quirements. I would appreciate your comments about the proposed mechanisms = and behaviours.

draft-rhd-mpls-tp-psc-priority-00
draft-cdh-mpls-tp-psc-non-revertive-00
draft-rhd-mpls-tp-psc-sd-00
draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00

The above drafts cover most of items highlighted in ITU-T liaisons about PS= C and they propose solutions in line with MPLS-TP transport requirements. A list of main liaisons exchanged between ITU-T and IETF with the aim to al= ign PSC behavious with ITU-T transport requirements for linear protection a= re given below:
https://datatracker.ietf.org/liaison/1162/  (June 2012= )
ht= tps://datatracker.ietf.org/liaison/1205/  (October 2012)
ht= tps://datatracker.ietf.org/liaison/1229/   (January 2013)
ht= tps://datatracker.ietf.org/liaison/1234/   (February 2013) ht= tps://datatracker.ietf.org/liaison/1256/   (May 2013)
  
Some details abou the proposed drafts for align PSC behaviour with transpor= t requirements:

draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities b= etween FS and SF-P (see section 4.3.2 of rfc6378).
Among the others, behaviors that will be fixed with the proposed update are= :
Use case A) At first, working path(WP) and protection path(PP) are normal. = Then, Forced Switch(FS) command is issued for maintenance on the WP and the= traffic moves from WP to PP.  When Signal Fail occurs on PP, service = cannot recover and is interrupted. This could occur for example as a result of accidentally un-plugging a PP fiber= .
Use case B) If there is an existing signal fail on a protection path (SF-P)= ,and FS command is issued by accident  the traffic on WP will move to = PP. This results in an interruption of service from which you will not auto= matically recover, because PSC should not have switched the traffic from WP to PP.
Discussion about this draft led to the proposal to modify RFC 4427 that was= "written correctly though lacking in detail causing mis-interpretatio= n" that led to the current PSC set of priority that the above draft is= proposing to modified and to align to the required transport behavior. draft-helvoort-ccamp-fs-priority-00 has been submitted to= CCAMP for clarifying the definiti= ons related to Manual Switch and Forced Switch and their usag= e relative to priorities.
The way this behavior has = to be incorporated into the PSC has to be discussed. The text proposes to r= eplace the current behavior with the new one. If there is consensus to proc= ede in that way this can bring to a simple and effective way to operate the protocol.

----------------------------------------------------------------------
draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC63= 78  to change non-revertive operations to behaves in the same way irre= spectively of the trigger of protection switching (fault or operator comman= d FS, MS).  Consequently an operator command, Manual Switch to Working (MS-W) a.k.a =93Manual switch-over for r= ecovery LSP/span=94 is also added to enable this behavior. From an operatio= nal point of view, MS to working path has also to be supported to be able t= o initially align at both sides in case of non-revertive switching mode. MS to working path is defined in RFC 5654= , requirement 83.

The proposed MS-W command is of equal priority to the existing MS-P command= , and there is text to handle the simultaneous or sequential occurrence of = two equal-priority commands. This behavior, already adopted in other transp= ort network protection switching protocol, can be used for other addition to the protocol in the future.
----------------------------------------------------------------------
draft-rhd-mpls-tp-psc-sd-00  provides extensions to the PSC sta= te machine to handle Signal Degrade (SD).  It does not define SD or pr= ovide scope around where or how SD may be used similarly as it already happ= en in the draft in handling other defects like SF (Signal Failure).
In MPLS-TP survivability framework  [RFC6372], a fault condition inclu= des both Signal Fail (SF) and  Signal Degrade (SD) that can be used to= trigger protection switching.
While the standardization lack of an SD definition and detection mechanisms= , the relevant behaviors in terms of protection actions may already be defi= ned.

----------------------------------------------------------------------
draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to= test if the APS communication is operating correctly. In other words both = APS process logic including state machine and APS channel on protection pat= h, without service disruption and without affecting any protection operation, unless the protection transpor= t entity is in use. This command is documented in R84 of [RFC5654] and it i= s part of ITU-T transport requirements.
An alternative proposal is documented in the Appendix B of RFC6378 that uti= lizes the Lockout of Protection (LO) or Forced Switch (FS) in combination o= f OAM functionalities. However, it has some functional limitation and has a= potential risk of losing traffic as a signal failure might occur during the exercise operation. In that cas= e, LO or FS has to be canceled to allow the PSC protocol to provide proper = switching.
A further alternative proposal is documented in draft-osborne-mpls-psc-aliv= e-00 that anyway show some functional limitations because cannot validate t= he PSC state machine status and probably the Local Request logic.


The authors encourage the IETF experts to comment on these drafts, eventual= ly proposing other options/mechanisms that can satisfy the same requirement= s.
Best regards,
Alessandro, Huub, Jeong-dong, Taeksid
= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_22257C41A415324A984CD03D63344E271F1B7A8BTELMBA002RM001t_-- --_a43f8fc3-7c6e-4301-89e4-12c40def693f_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_a43f8fc3-7c6e-4301-89e4-12c40def693f_-- From sriganeshkini@gmail.com Wed Jul 17 12:43:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B2F11E80E7 for ; Wed, 17 Jul 2013 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khmEwQyoeQ9W for ; Wed, 17 Jul 2013 12:43:13 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A195711E80E6 for ; Wed, 17 Jul 2013 12:43:13 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so2335830pad.33 for ; Wed, 17 Jul 2013 12:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=lO8f72J1i/lENCkg8oFrcy7VhKl5ZrFtwuv4+4IyoBA=; b=o2WMkb4doxXez/mzc9+RiSL1Z768R10AXnj7+gWp9imxP4xxIvvaSrQuBCxhCSiFe+ MZAG4nTMttuv/U6zUv9GAM4cTfRtRcPqIsbRcRsKLKQLLuHQSyshpM52zsXlDRk4yR1n 4fnRblwRwUg2MjHMkMKj7XNxE8eZNqwyh/MwporwXLTBQ6HmRxd4Ja9rztI7dwhv0D2c trQbIYlGIRtxHrFltjSE6S77eeIERKBCqtSLQDc4n5sN3xJkFSNMVJHVK9tAzUPyJ3fl she2UtEM6Z5ha5O8mPPxFNOeNyy7qKXHOUQvISoQCrBHEAQNPjYoQMCFcVzRfdsZw5OP qgnQ== X-Received: by 10.66.218.74 with SMTP id pe10mr2513616pac.177.1374090193352; Wed, 17 Jul 2013 12:43:13 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Wed, 17 Jul 2013 12:42:43 -0700 (PDT) In-Reply-To: <51D40986.1040709@pi.nu> References: <51D40986.1040709@pi.nu> From: Sriganesh Kini Date: Wed, 17 Jul 2013 12:42:43 -0700 X-Google-Sender-Auth: AXkI62t0zoxCplrPRk1HoE_AFOE Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b5d9de9dd3eac04e1ba4dab Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:43:14 -0000 --047d7b5d9de9dd3eac04e1ba4dab Content-Type: text/plain; charset=UTF-8 Support making this WG doc One comment - RFC 4090 terminology is MP for Merge Point whereas this draft uses MPT. I prefer this terminology, so a comment that this obsoletes the older terminology would be helpful. - Sri On Wed, Jul 3, 2013 at 4:22 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-node-**protection as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends July 17, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/**ipr/1727/ > https://datatracker.ietf.org/**ipr/2116/ > > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --047d7b5d9de9dd3eac04e1ba4dab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support making this WG doc

One comment = - RFC 4090 terminology is MP for Merge Point whereas this draft uses MPT. I= prefer this terminology, so a comment that this obsoletes the older termin= ology would be helpful.

- Sri


On Wed, Jul 3= , 2013 at 4:22 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-wijnands-mpls-mldp-node-protection as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends July 17, 2013.

There are two IPR claims against this document:

https:= //datatracker.ietf.org/ipr/1727/
https:= //datatracker.ietf.org/ipr/2116/


The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b5d9de9dd3eac04e1ba4dab-- From mn1921@att.com Wed Jul 17 12:48:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646CA21F84AF for ; Wed, 17 Jul 2013 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb47T0aa3FWA for ; Wed, 17 Jul 2013 12:47:55 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 352AD21F9635 for ; Wed, 17 Jul 2013 12:47:55 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id be4f6e15.2aaaf1e42940.7718924.00-546.21426926.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 17 Jul 2013 19:47:55 +0000 (UTC) X-MXL-Hash: 51e6f4eb14dc01d3-cb385ce2f0b3926dff9829ec346a64e1c49cb8c1 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 7e4f6e15.0.7718877.00-473.21426775.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 17 Jul 2013 19:47:54 +0000 (UTC) X-MXL-Hash: 51e6f4ea54e1ba59-de61c072982f6ba0f21e74b1a17d43dbe7311cc5 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6HJloqJ007096; Wed, 17 Jul 2013 15:47:51 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6HJlbvh006679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 15:47:37 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 17 Jul 2013 19:47:12 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Wed, 17 Jul 2013 15:47:12 -0400 From: "NAPIERALA, MARIA H" To: Sriganesh Kini , Loa Andersson Thread-Topic: [mpls] draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOgyXN4hssZ9Vpr0WLFblxiQRFQ5lpRj4Q Date: Wed, 17 Jul 2013 19:47:12 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012049F7@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <51D40986.1040709@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.180.193] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E012049F7MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=lnWFydYcV9AA:10 a=VNXdgr54iuwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=ZKgFobdNV] X-AnalysisOut: [qQA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=x73GuZ4sbOuQt8Z] X-AnalysisOut: [bauAA:9 a=QEXdDO2ut3YA:10 a=kkUMZHjH4KkA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=sN3ty3zQUVB5FmAJ:21 a=TgspwFw91qZzAckO:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=l43ENmg3e7U0Anv-qQgA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=tXsnliwV7b4A:10 a=mfLFS83uRCG_PV56:21 a=19dJLGlu34h] X-AnalysisOut: [jOGvC:21 a=K_yRWHxAqo5DryEI:21] Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:48:01 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E012049F7MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYWRvcHRpb24gYXMgYSBXRyBkb2N1bWVudC4NCg0KTWFyaWENCg0KRnJvbTog bXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3JpZ2FuZXNoIEtpbmkNCg0KDQpPbiBXZWQsIEp1bCAzLCAyMDEzIGF0IDQ6MjIg QU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQpX b3JraW5nIEdyb3VwLA0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9w dGluZw0KZHJhZnQtd2lqbmFuZHMtbXBscy1tbGRwLW5vZGUtcHJvdGVjdGlvbiBhcyBhbiBNUExT IHdvcmtpbmcNCmdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChz dXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQpncm91cCBtYWlsaW5nIGxp c3QgKG1wbHMgYXQgaWV0Zi5vcmc8aHR0cDovL2lldGYub3JnPikuIFBsZWFzZSBnaXZlIGEgdGVj aG5pY2FsDQptb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFs bHkgaWYgeW91IHRoaW5rIHRoYXQNCnRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQg YXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpUaGlzIHBvbGwgZW5kcyBKdWx5IDE3LCAy MDEzLg0KDQpUaGVyZSBhcmUgdHdvIElQUiBjbGFpbXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50Og0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNzI3Lw0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMjExNi8NCg0KDQpUaGUgYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRo ZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2Yg YW55IG90aGVyIElQUiBjbGFpbXMgYWdhaW5zdCB0aGlzIGRyYWZ0Lg0KDQpIb3dldmVyIGlmIHlv dSBhcmUgb24gdGhlIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGFuZA0KYXdh cmUgb2YgSVBSIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9z ZQ0KdGhpcyBpcyBub3cuDQoNCi9Mb2ENCihtcGxzIHdnIGNvLWNoYWlyKQ0KLS0NCg0KDQpMb2Eg QW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2Vp LmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAg ICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1YXdl aSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0 ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQ+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E012049F7MISOUT7MSGUSR9I_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0IHRoZSBh ZG9wdGlvbiBhcyBhIFdHIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFyaWE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TcmlnYW5lc2gg S2luaTxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IEp1bCAzLCAyMDEzIGF0IDQ6MjIgQU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0 bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvcmtpbmcgR3JvdXAsPGJyPg0KPGJy Pg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gYWRvcHRpbmc8YnI+DQpkcmFm dC13aWpuYW5kcy1tcGxzLW1sZHAtbm9kZS1wcm90ZWN0aW9uIGFzIGFuIE1QTFMgd29ya2luZzxi cj4NCmdyb3VwIGRvY3VtZW50Ljxicj4NCjxicj4NClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMg KHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmc8YnI+DQpncm91cCBtYWls aW5nIGxpc3QgKG1wbHMgYXQgPGEgaHJlZj0iaHR0cDovL2lldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+aWV0Zi5vcmc8L2E+KS4gUGxlYXNlIGdpdmUgYSB0ZWNobmljYWw8YnI+DQptb3RpdmF0aW9u IGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91IHRoaW5rIHRo YXQ8YnI+DQp0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBn cm91cCBkb2N1bWVudC48YnI+DQo8YnI+DQpUaGlzIHBvbGwgZW5kcyBKdWx5IDE3LCAyMDEzLjxi cj4NCjxicj4NClRoZXJlIGFyZSB0d28gSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQ6 PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTcy Ny8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNzI3 LzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yMTE2 LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIxMTYv PC9hPjxicj4NCjxicj4NCjxicj4NClRoZSBhdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJyPg0KdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55 IG90aGVyIElQUiBjbGFpbXMgYWdhaW5zdCB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCkhvd2V2ZXIg aWYgeW91IGFyZSBvbiB0aGUgdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgYW5k PGJyPg0KYXdhcmUgb2YgSVBSIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0 byBkaXNjbG9zZTxicj4NCnRoaXMgaXMgbm93Ljxicj4NCjxicj4NCi9Mb2E8YnI+DQoobXBscyB3 ZyBjby1jaGFpcik8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9 ImhvZW56YiI+LS0gPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIi PkxvYSBBbmRlcnNzb24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbWFpbDogPGEgaHJlZj0i bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWww MS5odWF3ZWkuY29tPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5TZW5pb3Ig TVBMUyBFeHBlcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFp bHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT48L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImhvZW56YiI+SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgJm5i c3A7ICZuYnNwOyBwaG9uZTogPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0 IiB0YXJnZXQ9Il9ibGFuayI+DQomIzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImhvZW56YiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+bXBscyBtYWlsaW5n IGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PGEgaHJlZj0ibWFpbHRvOm1w bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1D70D757A2C9D54D83B4CBD7625FA80E012049F7MISOUT7MSGUSR9I_-- From skraza@cisco.com Wed Jul 17 12:48:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863F411E80E7 for ; Wed, 17 Jul 2013 12:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJWipHf3a6RM for ; Wed, 17 Jul 2013 12:48:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DAE8A21F84A8 for ; Wed, 17 Jul 2013 12:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8156; q=dns/txt; s=iport; t=1374090479; x=1375300079; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=VWYkGPr8wUahgKJ1sBckWjT6wmdgC7vEHItQSHGj6A8=; b=A0B0m2JJ0Ve7oelK3ZX+yDGeMe1otRhHPWFu7SQm+9sCBXmJqkZWpv0H bABPR5M9ZLpmq9SJ0EC5qDxrV1W40Ti+avFkyyDORRpzlwqE1mD1dhPA/ fRdpNhBub6n+lqZPjRH+AIHmm8dM+EgBnjJD6XXWuSnXXFEIjQmcinF9a Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAIPy5lGtJXG8/2dsb2JhbABagkJENFC4Qog9gREWdIIjAQEBBAEBAWgDCw4EAQgRAwECCx0iDAsUCQgCBAENBQiICAy2AgSONIERBRsNBAcJgwRuA5kFkCSBNYFdgXE3 X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208,217";a="236104006" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2013 19:47:51 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6HJlpxp010649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 19:47:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 14:47:50 -0500 From: "Kamran Raza (skraza)" To: Sriganesh Kini , Loa Andersson Thread-Topic: [mpls] draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOd9+qa49rFlH6mkiBt5gZHBtF4Zlpr62A//++WoA= Date: Wed, 17 Jul 2013 19:47:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [161.44.212.52] Content-Type: multipart/alternative; boundary="_000_CF38788834BFAD46A7D3AAF0BBB3F97F100A9E29xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:48:05 -0000 --_000_CF38788834BFAD46A7D3AAF0BBB3F97F100A9E29xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, we (authors) did not wanted to confuse a reader with regards to the us= e of "MP" (i.e refers to Multipoint or Merge Point ?), and hence used MPT f= or MergePoint and MP for Multipoint. We will add your comment as as side note in the next revision. Thx -- Kamran From: Sriganesh Kini > Date: Wednesday, 17 July, 2013 3:42 PM To: Loa Andersson > Cc: "mpls@ietf.org" >, "mpls-chairs@tools.ietf.org" >, "draft-wijnands= -mpls-mldp-node-protection@tools.ietf.org" > Subject: Re: [mpls] draft-wijnands-mpls-mldp-node-protection Support making this WG doc One comment - RFC 4090 terminology is MP for Merge Point whereas this draft= uses MPT. I prefer this terminology, so a comment that this obsoletes the = older terminology would be helpful. - Sri On Wed, Jul 3, 2013 at 4:22 AM, Loa Andersson >= wrote: Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-node-protection as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give a techn= ical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends July 17, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/1727/ https://datatracker.ietf.org/ipr/2116/ The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CF38788834BFAD46A7D3AAF0BBB3F97F100A9E29xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Yes, we (authors) did not wanted to confuse a reader with regards to t= he use of "MP" (i.e refers to Multipoint or Merge Point ?), and h= ence used MPT for MergePoint and MP for Multipoint.
We will add your comment as as side note in the next revision.

Thx
-- Kamran

From: Sriganesh Kini <sriganesh.kini@ericsson.com> Date: Wednesday, 17 July, 2013 3:42= PM
To: Loa Andersson <loa@pi.nu>
Cc: "mpls@ietf.org" <mpls@i= etf.org>, "mpls-c= hairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" &l= t;draft-wijnands-mpls-mldp-node-protection@tools.ietf.org>
Subject: Re: [mpls] draft-wijnands-= mpls-mldp-node-protection

Support making this WG doc

One comment - RFC 4090 terminology is MP for Merge Point whereas this = draft uses MPT. I prefer this terminology, so a comment that this obsoletes= the older terminology would be helpful.

- Sri


On Wed, Jul 3, 2013 at 4:22 AM, Loa Andersson <loa@pi.nu>= wrote:
Working Group,

This is to start a two week poll on adopting
draft-wijnands-mpls-mldp-node-protection as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends July 17, 2013.

There are two IPR claims against this document:

https:= //datatracker.ietf.org/ipr/1727/
https:= //datatracker.ietf.org/ipr/2116/


The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson                  = ;      email: loa@mail01.huawei.com
Senior MPLS Expert                 =          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 --_000_CF38788834BFAD46A7D3AAF0BBB3F97F100A9E29xmbalnx03ciscoc_-- From renwei.li@huawei.com Wed Jul 17 15:27:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFE421F9CDF for ; Wed, 17 Jul 2013 15:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP+8z1HXuZTL for ; Wed, 17 Jul 2013 15:27:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D24321F96A8 for ; Wed, 17 Jul 2013 15:27:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD49578; Wed, 17 Jul 2013 22:27:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 23:24:21 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 23:25:15 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 15:25:03 -0700 From: Richard Li To: "Nagendra Kumar (naikumar)" , "Eric Rosen (erosen)" , William McCall Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOeZgLPkhJY0+Kvke3sDwL13/hpJloipsggAEimAD//9d6sA== Date: Wed, 17 Jul 2013 22:25:02 +0000 Message-ID: References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:27:26 -0000 Hi Nagendra, Actually, only one big label indicator is needed. Not two. When you send packets from the customer side to the data center side, you n= eed three labels: transport label + big label indicator + big label value. When you send packets from the data center side to the customer side, you n= eed two labels as before: transport label + VPN label. Regards, Richard -----Original Message----- From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com]=20 Sent: Thursday, July 18, 2013 1:46 AM To: Richard Li; Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: RE: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi Richard, Is the proposal is to use the big label indicator only when the label size = is more than 20 bits?. If not, I think it is a trade off between label sta= ck size vs fwding semantic. With big label, any service like VPN will requi= re 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP labe= l and application label) which is equivalent to 4 labels. But with context = label, it is going to be 3 labels. While context label is explained in terms of upstream label for MP-LSP, I t= hink nothing stops its usage for unicast LSP.=20 -Nagendra -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ric= hard Li Sent: Wednesday, July 17, 2013 9:08 PM To: Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi! Thanks for the comments. And I am sorry for the late reply; I was on vacati= ons. Now let me clarify and explain why we need something like big labels. 1.=20 You do have a good point here. Yes, it is true that one can always get a bi= gger label space by stacking labels over labels. The combination of two "sm= all" labels may achieve what a "big" label can do. But their fundamental co= ncepts and the consequences will be totally different. Conceptually, a labe= l has four components: label value, BOS indicator, the EXP bits and the TT= L value. If you use two "small" labels to represent a "big" label, you will= run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You can sem= antically combine the two label values, but you can't combine other fields = such as TTL. If the two labels are collectively considered as ONE label, th= ey should have one TTL, one EXP, and one BOS since they should be treated a= nd processed as a single and inseparable entity. Having multiple TTLs/EXPs/= BOSes is conceptually counter-intuitive against the very idea of "a label".= =20 2.=20 Context was introduced in the context of upstream-assigned labels for multi= cast LSPs. It provides the concept of context, but it doesn't provide the c= oncept of "big labels". The label itself is still 20 bits in length. The la= bel space in a context is not expanded; it is still 1M.=20 3.=20 If you use context labels, you will need 16 contexts since each context wil= l only hold 1M labels. Which label belongs to which context will be very ar= bitrary; If someone put a label in one context, it won't be wrong if anothe= r one put the same label in a different context. There is no semantic assoc= iation at all between contexts and labels, which is different from the situ= ation about contexts for upstream-assigned labels where one simply can't pu= t upstream-assigned labels in an arbitrary context. 4.=20 In this proposal, we only need two 32-bit entries for a "big label": the bi= g label indicator + big label value. The big label indicator is a reserved = label. We don't need three label entries in an MPLS packet. 5. With respect to the BGP protocol, the "big label" proposal has some scaling= benefits over the context-based solution. If you use context labels, you w= ill need to add 64 extra bits in BGP's NLRI: context label and a secondary = label. But if you use the big label proposal in this draft, you will only = need to add 32 bits: big label value. Saving the extra 32 bits to each VPN= route can be a big deal, especially when we are talking about up to 16M VP= Ns here for virtualized networks currently being standardized by NVO3/VXLAN= /NVGRE. 6. In the operating system and line cards, the "big label" proposal also has s= ome benefits over the context-based solution. If you use contexts, you have= to store the context label in conjunction with the VPN label. But if you u= se the big label proposal, you only need an attribute flag bit to mean the = VPN label is a big one. The same thing holds true in the forwarding softwar= e.=20 Regards, Richard -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Friday, July 05, 2013 11:50 PM To: William McCall Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) > What would this change alleviate that could not already be solved by=20 > adding another label to the stack? Excellent point. Please see also section 3 (especially the last paragraph) of RFC 5331 on "c= ontext labels". By using one label as a "context label" identifying a cont= ext in which the subsequent label is interpreted, one gets the effect of a = 40-bit label space, and the same mechanism can also be used to support upst= ream-assigned labels. It's also worth noting that the "big label" proposal would probably end up = using three label stack entries per big label: special purpose label indica= tor, big label indicator, big label value. The use of context labels will = require only two label stack entries. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From renwei.li@huawei.com Wed Jul 17 16:05:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B58021E804D for ; Wed, 17 Jul 2013 16:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B78bs4U9+bIP for ; Wed, 17 Jul 2013 16:05:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93F7321F9E1E for ; Wed, 17 Jul 2013 16:05:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN73035; Wed, 17 Jul 2013 23:04:59 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 00:04:18 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 00:04:57 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 16:04:45 -0700 From: Richard Li To: Shahram Davari , "Nagendra Kumar (naikumar)" , "Eric Rosen (erosen)" , William McCall Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOeZgLPkhJY0+Kvke3sDwL13/hpJloipsggAEimACAAA70gP//0yHw Date: Wed, 17 Jul 2013 23:04:45 +0000 Message-ID: References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 23:05:06 -0000 In line with prefix... -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Thursday, July 18, 2013 2:40 AM To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William McC= all Cc: Mli; mpls@ietf.org Subject: RE: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi Richard, I agree with Eric and Nagendra. What you want is achievable with context-ba= sed label. Please see my comments inline. Thanks Shahram=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Nag= endra Kumar (naikumar) Sent: Wednesday, July 17, 2013 10:46 AM To: Richard Li; Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi Richard, Is the proposal is to use the big label indicator only when the label size = is more than 20 bits?. If not, I think it is a trade off between label sta= ck size vs fwding semantic. With big label, any service like VPN will requi= re 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP labe= l and application label) which is equivalent to 4 labels. But with context = label, it is going to be 3 labels. While context label is explained in terms of upstream label for MP-LSP, I t= hink nothing stops its usage for unicast LSP.=20 -Nagendra -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ric= hard Li Sent: Wednesday, July 17, 2013 9:08 PM To: Eric Rosen (erosen); William McCall Cc: Mli; mpls@ietf.org Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) Hi! Thanks for the comments. And I am sorry for the late reply; I was on vacati= ons. Now let me clarify and explain why we need something like big labels. 1.=20 You do have a good point here. Yes, it is true that one can always get a bi= gger label space by stacking labels over labels. The combination of two "sm= all" labels may achieve what a "big" label can do. But their fundamental co= ncepts and the consequences will be totally different. Conceptually, a labe= l has four components: label value, BOS indicator, the EXP bits and the TT= L value. If you use two "small" labels to represent a "big" label, you will= run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You can sem= antically combine the two label values, but you can't combine other fields = such as TTL. If the two labels are collectively considered as ONE label, th= ey should have one TTL, one EXP, and one BOS since they should be treated a= nd processed as a single and inseparable entity. Having multiple TTLs/EXPs/= BOSes is conceptually counter-intuitive against the very idea of "a label".= =20 SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EXP fo= r both labels (redundant).=20 Does user like to configure more or less? Is redundancy a good thing = or bad one? 2.=20 Context was introduced in the context of upstream-assigned labels for multi= cast LSPs. It provides the concept of context, but it doesn't provide the c= oncept of "big labels". The label itself is still 20 bits in length. The la= bel space in a context is not expanded; it is still 1M.=20 SD> Multicast was one of the applications of context-based lookup. This can= be another application. The labels space with context is not 1M anymore. = It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit lookup. I am talking about the concept here. In context-based label, there is = a sub-stack of two label entries.=20 3.=20 If you use context labels, you will need 16 contexts since each context wil= l only hold 1M labels. Which label belongs to which context will be very ar= bitrary; If someone put a label in one context, it won't be wrong if anothe= r one put the same label in a different context. There is no semantic assoc= iation at all between contexts and labels, which is different from the situ= ation about contexts for upstream-assigned labels where one simply can't pu= t upstream-assigned labels in an arbitrary context. SD> I think you have may not have understood the context label well. The co= ntext label tells you the meaning of the label under it. Think of it as 40 = bit label, that is how it works.=20 Please do a simple math. In order to achieve the 16M goal, how many co= ntext labels you will need? And how are you going to allocate those labels = in your implementation. 4.=20 In this proposal, we only need two 32-bit entries for a "big label": the bi= g label indicator + big label value. The big label indicator is a reserved = label. We don't need three label entries in an MPLS packet. SD> draft-ietf-mpls-special-purpose-labels-03.txt from now on requires usi= ng a special label indicator before the special big label indicator. So you= need 3 labels. 5. With respect to the BGP protocol, the "big label" proposal has some scaling= benefits over the context-based solution. If you use context labels, you w= ill need to add 64 extra bits in BGP's NLRI: context label and a secondary = label. But if you use the big label proposal in this draft, you will only = need to add 32 bits: big label value. Saving the extra 32 bits to each VPN= route can be a big deal, especially when we are talking about up to 16M VP= Ns here for virtualized networks currently being standardized by NVO3/VXLAN= /NVGRE. SD> BGP packet size is not an issue, after all it is just control packet. I am not sure if I should agree. Here we are dealing with a problem wi= th potentially 16M VPNs. When you add 32 bits to a BGP packet, you need to = read and write. For me, I have been always sensitive to the BGP reconvergen= ce time. 6. In the operating system and line cards, the "big label" proposal also has s= ome benefits over the context-based solution. If you use contexts, you have= to store the context label in conjunction with the VPN label. But if you u= se the big label proposal, you only need an attribute flag bit to mean the = VPN label is a big one. The same thing holds true in the forwarding softwar= e.=20 SD> Also in big label you have to store a 32-bit label value instead of 20 = bit label. But the advantage of context-based method is that you won't need= new hardware. While for big label you will need new hardware. It depends on your line card. If you use ASIC, perhaps you are right. = But if you use NP, you don't need new hardware. Actually, no matter you nee= d to store 20 bits or 32 bits, you always need a long integer in NP. Regards, Richard -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Friday, July 05, 2013 11:50 PM To: William McCall Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00) > What would this change alleviate that could not already be solved by=20 > adding another label to the stack? Excellent point. Please see also section 3 (especially the last paragraph) of RFC 5331 on "c= ontext labels". By using one label as a "context label" identifying a cont= ext in which the subsequent label is interpreted, one gets the effect of a = 40-bit label space, and the same mechanism can also be used to support upst= ream-assigned labels. It's also worth noting that the "big label" proposal would probably end up = using three label stack entries per big label: special purpose label indica= tor, big label indicator, big label value. The use of context labels will = require only two label stack entries. _______________________________________________ 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 william.mccall@gmail.com Wed Jul 17 22:40:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1021F9E39 for ; Wed, 17 Jul 2013 22:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOgyLfSUydxW for ; Wed, 17 Jul 2013 22:40:16 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 87F1721F9E1E for ; Wed, 17 Jul 2013 22:40:16 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so3268378obb.4 for ; Wed, 17 Jul 2013 22:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y8pMTOh/MGpDayymYIZMfzTGYBb4LD7MAAsS2jBWfzk=; b=ysGoZU1H6OrVuZkh4Nhs+8SsIOJlGbJzNY7a3sh4KlIBirNexP+auou2GcFMFS950x 9JERnRRD49UBpHiStNzG6oZ1KTJn3e8hBAhPAAsrcNV0CId+nFg9PaUgcv/ZkLCumTUn 5a0RDxCIF47mbWCB6O+9jXRZGSzItpcyL0y1Cr12EO4wM0r0AFTXlUtwRfafABLTyFWc Lo0cG0G1py6D3eYO2tOXynT2y5ohoSBxZmM3U5DhnDoJ3wWRkl53d2ti/0QcfF2+m50U 2X3QgNuiUwT+06pdLkXqkuDNluR2IM2hzHB5qVS+FV542MGqkcebqR3kk8wj2i+1mocZ bVbg== X-Received: by 10.60.47.41 with SMTP id a9mr11500267oen.78.1374126013886; Wed, 17 Jul 2013 22:40:13 -0700 (PDT) Received: from [10.10.0.56] (cpe-66-25-3-111.tx.res.rr.com. [66.25.3.111]) by mx.google.com with ESMTPSA id ps5sm13100361oeb.8.2013.07.17.22.40.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 22:40:13 -0700 (PDT) Message-ID: <51E77FBF.8050906@gmail.com> Date: Thu, 18 Jul 2013 00:40:15 -0500 From: William McCall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Li References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Mli , "mpls@ietf.org" , "Nagendra Kumar \(naikumar\)" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 05:40:18 -0000 My simpleton observations to the responses below tagged with . On 07/17/2013 06:04 PM, Richard Li wrote: > In line with prefix... > > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, July 18, 2013 2:40 AM > To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William= McCall > Cc: Mli;mpls@ietf.org > Subject: RE: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Revi= ew of draft-renwei-mpls-bgp-big-label-00) > > Hi Richard, > > I agree with Eric and Nagendra. What you want is achievable with contex= t-based label. Please see my comments inline. > > Thanks > Shahram > > -----Original Message----- > From:mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of= Nagendra Kumar (naikumar) > Sent: Wednesday, July 17, 2013 10:46 AM > To: Richard Li; Eric Rosen (erosen); William McCall > Cc: Mli;mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Revi= ew of draft-renwei-mpls-bgp-big-label-00) > > Hi Richard, > > Is the proposal is to use the big label indicator only when the label s= ize is more than 20 bits?. If not, I think it is a trade off between lab= el stack size vs fwding semantic. With big label, any service like VPN wi= ll require 2 big label indicator (each 32 bits) and 2 * 32 bits big label= (IGP label and application label) which is equivalent to 4 labels. But w= ith context label, it is going to be 3 labels. > > While context label is explained in terms of upstream label for MP-LSP,= I think nothing stops its usage for unicast LSP. > > -Nagendra > > -----Original Message----- > From:mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of= Richard Li > Sent: Wednesday, July 17, 2013 9:08 PM > To: Eric Rosen (erosen); William McCall > Cc: Mli;mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Revi= ew of draft-renwei-mpls-bgp-big-label-00) > > Hi! > > Thanks for the comments. And I am sorry for the late reply; I was on va= cations. > > Now let me clarify and explain why we need something like big labels. > > 1. > You do have a good point here. Yes, it is true that one can always get = a bigger label space by stacking labels over labels. The combination of t= wo "small" labels may achieve what a "big" label can do. But their fundam= ental concepts and the consequences will be totally different. Conceptual= ly, a label has four components: label value, BOS indicator, the EXP bit= s and the TTL value. If you use two "small" labels to represent a "big" l= abel, you will run into TWO BOS indicators, TWO EXP bits, and TWO TTL val= ues. You can semantically combine the two label values, but you can't com= bine other fields such as TTL. If the two labels are collectively conside= red as ONE label, they should have one TTL, one EXP, and one BOS since th= ey should be treated and processed as a single and inseparable entity. Ha= ving multiple TTLs/EXPs/BOSes is conceptually counter-intuitive against t= he very idea of "a label". > > SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EX= P for both labels (redundant). > > Does user like to configure more or less? Is redundancy a good th= ing or bad one? > Maybe there should be clarification on the appropriate way to do=20 this in context labels. I haven't found anything that clarifies this,=20 but I reckon it isn't the biggest problem anyway. > 2. > Context was introduced in the context of upstream-assigned labels for m= ulticast LSPs. It provides the concept of context, but it doesn't provide= the concept of "big labels". The label itself is still 20 bits in length= =2E The label space in a context is not expanded; it is still 1M. > > SD> Multicast was one of the applications of context-based lookup. This= can be another application. The labels space with context is not 1M any= more. It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit lo= okup. > > I am talking about the concept here. In context-based label, there= is a sub-stack of two label entries. I don't get this point at all. It's two 32 bit values anyway. Either = two labels or a standard label and a 32 bit label (and IRL, probably 2=20 standard labels per #4 below). And bits are wasted in the standard=20 label. The context label and the next label can mean whatever the PE=20 wants it to mean as far as I can tell. > 3. > If you use context labels, you will need 16 contexts since each context= will only hold 1M labels. Which label belongs to which context will be v= ery arbitrary; If someone put a label in one context, it won't be wrong i= f another one put the same label in a different context. There is no sema= ntic association at all between contexts and labels, which is different f= rom the situation about contexts for upstream-assigned labels where one s= imply can't put upstream-assigned labels in an arbitrary context. > > SD> I think you have may not have understood the context label well. Th= e context label tells you the meaning of the label under it. Think of it = as 40 bit label, that is how it works. > > Please do a simple math. In order to achieve the 16M goal, how man= y context labels you will need? And how are you going to allocate those l= abels in your implementation. > The allocations can be done however the PE pleases. "Context" is, in = my simple mind, a misnomer. It is just another way of saying "if you see = this label here, it means read the next label too and make it into one=20 big label," however the implementation defines it. And it's=20 interpretation is local to the PE, so I see no need for any other nodes=20 to care nor for the specific implementations to be much of a driver in a = comparison in the standards process. > 4. > In this proposal, we only need two 32-bit entries for a "big label": th= e big label indicator + big label value. The big label indicator is a res= erved label. We don't need three label entries in an MPLS packet. > > SD> draft-ietf-mpls-special-purpose-labels-03.txt from now on requires= using a special label indicator before the special big label indicator. = So you need 3 labels. This alone makes the idea a deal breaker for my opinion unless there = is agreement to hook this up with a reserved label. Furthermore, I think = using a reserved label for this is a bad idea. > 5. > With respect to the BGP protocol, the "big label" proposal has some sca= ling benefits over the context-based solution. If you use context labels,= you will need to add 64 extra bits in BGP's NLRI: context label and a se= condary label. But if you use the big label proposal in this draft, you = will only need to add 32 bits: big label value. Saving the extra 32 bits= to each VPN route can be a big deal, especially when we are talking abou= t up to 16M VPNs here for virtualized networks currently being standardiz= ed by NVO3/VXLAN/NVGRE. > > SD> BGP packet size is not an issue, after all it is just control packe= t. > > I am not sure if I should agree. Here we are dealing with a proble= m with potentially 16M VPNs. When you add 32 bits to a BGP packet, you ne= ed to read and write. For me, I have been always sensitive to the BGP rec= onvergence time. Maybe. But does it justify having to upgrade every PE's/RR's BGPd=20 out there to support this? I can put a label stack in NLRI today without = having to jump through software upgrade hoops and the associated=20 entities screaming about having to do the upgrade. Personally, I would=20 prefer to avoid playing with BGP code more than I have to. > 6. > In the operating system and line cards, the "big label" proposal also h= as some benefits over the context-based solution. If you use contexts, yo= u have to store the context label in conjunction with the VPN label. But = if you use the big label proposal, you only need an attribute flag bit to= mean the VPN label is a big one. The same thing holds true in the forwar= ding software. > > SD> Also in big label you have to store a 32-bit label value instead of= 20 bit label. But the advantage of context-based method is that you won'= t need new hardware. While for big label you will need new hardware. > > It depends on your line card. If you use ASIC, perhaps you are rig= ht. But if you use NP, you don't need new hardware. Actually, no matter y= ou need to store 20 bits or 32 bits, you always need a long integer in NP= =2E This is my main concern: that this idea will break in ASICs. Too=20 many are deployed today. You deploy a 32 bit label and distribute it to=20 a PE with ASICs that cannot support this. Are we going to now punt to=20 rewrite the packet? That would be pretty awful. I think most of them=20 will be fine with an old school label stack though. Someone may show me=20 to be wrong on this though. > Regards, > > > Richard > > > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, July 05, 2013 11:50 PM > To: William McCall > Cc:mpls@ietf.org; Richard Li; Mli;erosen@cisco.com > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Revi= ew of draft-renwei-mpls-bgp-big-label-00) > > >> What would this change alleviate that could not already be solved by >> adding another label to the stack? > Excellent point. > > Please see also section 3 (especially the last paragraph) of RFC 5331 o= n "context labels". By using one label as a "context label" identifying = a context in which the subsequent label is interpreted, one gets the effe= ct of a 40-bit label space, and the same mechanism can also be used to su= pport upstream-assigned labels. > > It's also worth noting that the "big label" proposal would probably end= up using three label stack entries per big label: special purpose label = indicator, big label indicator, big label value. The use of context labe= ls will require only two label stack entries. > > > _______________________________________________ > 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 manav.bhatia@alcatel-lucent.com Wed Jul 17 22:48:02 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169FC21F943C; Wed, 17 Jul 2013 22:48:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euz7-Z6+wJHC; Wed, 17 Jul 2013 22:47:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4121F8E1F; Wed, 17 Jul 2013 22:47:54 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6I5lncR010696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jul 2013 00:47:50 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r6I5llgB008246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 01:47:49 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 18 Jul 2013 01:47:48 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 13:47:41 +0800 From: "Bhatia, Manav (Manav)" To: Yaakov Stein , "tictoc@ietf.org" Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gK4nndg Date: Thu, 18 Jul 2013 05:47:41 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C30815B6@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "mpls@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 05:48:02 -0000 Hi, Support this draft. Cheers, Manav=20 > -----Original Message----- > From: tictoc-bounces@ietf.org=20 > [mailto:tictoc-bounces@ietf.org] On Behalf Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:51 PM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for=20 > draft-ietf-tictoc-1588overmpls (see=20 > http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). >=20 > Please send indications of support, as well as any remaining=20 > technical comments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also=20 > being sent to the MPLS WG, but please conduct all discussion=20 > on the TICTOC working group mailing list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > = From chengwq@gmail.com Wed Jul 17 23:37:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2432321E8084; Wed, 17 Jul 2013 23:37:21 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNK7N5IXcOrq; Wed, 17 Jul 2013 23:37:20 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id BB50121E809D; Wed, 17 Jul 2013 23:37:11 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so1540275qab.11 for ; Wed, 17 Jul 2013 23:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4TA/O4zH9L1zetzHRWzluqL0Bz5m2MDzFb91nTtI+Jo=; b=rwWtCUALE2J6nmuXLFydnVlH7n2t6gCpI7NzuCRve+/5u31gh2uLC7iZlXu7byzP2z RAokt0DFzcBmWY3ZFbmztev5NDLvL/A0AJ7EW6IMl1BV8aau0FZxmwVn/oEEqph8LG2E zItlxH1RO7V3RsY2fO/n32wNVulI1/BQ+MiWs76nUWttsIfXxUBLWfj5nNdsJzflzovU pp2A65d+dgLgG0MPPNu7Mzh5YFEy/tsTf/cKZvFBylndNjXfm46R6jUONxF6yxybzuut EMAABduWrYyLEjYHayjT48tEL7ZXDy1qe2E6wOdDKUHC0s0Eg5mWptGR8F7rOu6DPUYW Bpjw== MIME-Version: 1.0 X-Received: by 10.229.147.199 with SMTP id m7mr2650783qcv.67.1374129431213; Wed, 17 Jul 2013 23:37:11 -0700 (PDT) Received: by 10.224.72.16 with HTTP; Wed, 17 Jul 2013 23:37:11 -0700 (PDT) In-Reply-To: <20211F91F544D247976D84C5D778A4C30815B6@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <20211F91F544D247976D84C5D778A4C30815B6@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 18 Jul 2013 14:37:11 +0800 Message-ID: From: weiqiang cheng To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=e89a8f5029369f81cd04e1c37091 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:37:21 -0000 --e89a8f5029369f81cd04e1c37091 Content-Type: text/plain; charset=ISO-8859-1 Hi, Support. It is useful for 1588 time synchronization in mobile backhaul application scenarios. Cheng Weiqiang Research Institute of China Mobile 2013/7/18 Bhatia, Manav (Manav) > Hi, > > Support this draft. > > Cheers, Manav > > > -----Original Message----- > > From: tictoc-bounces@ietf.org > > [mailto:tictoc-bounces@ietf.org] On Behalf Of Yaakov Stein > > Sent: Thursday, July 04, 2013 2:51 PM > > To: tictoc@ietf.org > > Cc: mpls@ietf.org > > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls > > > > We hereby announce a TICTOC working group last call for > > draft-ietf-tictoc-1588overmpls (see > > http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). > > > > Please send indications of support, as well as any remaining > > technical comments, to the list. > > > > Due to the MPLS aspects of this draft this email is also > > being sent to the MPLS WG, but please conduct all discussion > > on the TICTOC working group mailing list. > > > > This working group last call will end on July 19, 2013. > > > > Y(J)S > > > > _______________________________________________ > > TICTOC mailing list > > TICTOC@ietf.org > > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --e89a8f5029369f81cd04e1c37091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
Support.
=A0
It is=A0useful for 1588 time synchronization in mobile backhaul app= lication scenarios.=A0
Cheng Weiqiang
Research Institu= te of China Mobile


2013/7/18 Bhatia, Manav (Manav) <<= a href=3D"mailto:manav.bhatia@alcatel-lucent.com" target=3D"_blank">manav.b= hatia@alcatel-lucent.com>
Hi,

Support this draft.

Cheers, Manav

> -----Original Message-----
> From: tictoc-bounces@ietf.o= rg
> [mailto:tictoc-bounces@ietf= .org] On Behalf Of Yaakov Stein
> Sent: Thursday, July 04, 2013 2:51 PM > To: tictoc@ietf.org
> Cc: mpls@ietf.org
> Subject: [TICTOC] TICTOC WG LC for draf= t-ietf-tictoc-1588overmpls
>
> We hereby announce a TICTOC working group last call for
> draft-ietf-tictoc-1588overmpls (see
> http://tools.ietf.org/html/draft-ietf-tictoc-1588overm= pls-05).
>
> Please send indications of support, as well as any remaining
> technical comments, to the list.
>
> Due to the MPLS aspects of this draft this email is also
> being sent to the MPLS WG, but please conduct all discussion
> on the TICTOC working group mailing list.
>
> This working group last call will end on July 19, 2013.
>
> Y(J)S
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>
_____________________________= __________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--e89a8f5029369f81cd04e1c37091-- From renwei.li@huawei.com Thu Jul 18 01:02:18 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA64421F9FC8 for ; Thu, 18 Jul 2013 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZmMqWBvUL6S for ; Thu, 18 Jul 2013 01:02:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1621F9D8F for ; Thu, 18 Jul 2013 01:02:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD84563; Thu, 18 Jul 2013 08:02:10 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 09:00:55 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 09:01:51 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 01:01:40 -0700 From: Richard Li To: William McCall Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 Thread-Index: AQHOg3lLjt/SV50sZEaBtaD4n5UF35lqDZkA Date: Thu, 18 Jul 2013 08:01:39 +0000 Message-ID: References: Your message of Fri, 05 Jul 2013 05:34:03 -0500. <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> <51E77FBF.8050906@gmail.com> In-Reply-To: <51E77FBF.8050906@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Mli , "mpls@ietf.org" , "Nagendra Kumar \(naikumar\)" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 08:02:18 -0000 Hi Bill, Thanks for comments. In line with prefix. > SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EXP = for both labels (redundant). > > Does user like to configure more or less? Is redundancy a good thin= g or bad one? > Maybe there should be clarification on the appropriate way to do this i= n context labels. I haven't found anything that clarifies this, but I recko= n it isn't the biggest problem anyway. I always believe that to have more config and redundancy is something = we should avoid. Maybe I am too biased. > SD> Multicast was one of the applications of context-based lookup. This c= an be another application. The labels space with context is not 1M anymore= . It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit lookup. > > I am talking about the concept here. In context-based label, there i= s a sub-stack of two label entries. I don't get this point at all. It's two 32 bit values anyway. Either tw= o labels or a standard label and a 32 bit label (and IRL, probably 2 standa= rd labels per #4 below). And bits are wasted in the standard label. The con= text label and the next label can mean whatever the PE wants it to mean as = far as I can tell. Their interpretations are different, and thus they will yield to diffe= rent consequences. For the context approach, there are two labels. For the = big label approach, there is only one label. And thus, for the context appr= oach the BGP needs to carry two labels, while for the big label approach th= e BGP carries only one label. > SD> I think you have may not have understood the context label well. The = context label tells you the meaning of the label under it. Think of it as 4= 0 bit label, that is how it works. > > Please do a simple math. In order to achieve the 16M goal, how many = context labels you will need? And how are you going to allocate those label= s in your implementation. > The allocations can be done however the PE pleases. "Context" is, in my= simple mind, a misnomer. It is just another way of saying "if you see this= label here, it means read the next label too and make it into one big labe= l," however the implementation defines it. And it's interpretation is local= to the PE, so I see no need for any other nodes to care nor for the specif= ic implementations to be much of a driver in a comparison in the standards = process. Actually context was not a misnomer when it was proposed. It was a per= fect name. But now when it is used (or misused) to attempt to achieve the e= ffect of big labels, it becomes a misnomer. For the upstream-assigned label= s, all of them are in the same context. But now VPN labels can't be in the = same context. Isn't it weird and counter-intuitive? > > SD> BGP packet size is not an issue, after all it is just control packet. > > I am not sure if I should agree. Here we are dealing with a problem = with potentially 16M VPNs. When you add 32 bits to a BGP packet, you need t= o read and write. For me, I have been always sensitive to the BGP reconverg= ence time. Maybe. But does it justify having to upgrade every PE's/RR's BGPd out t= here to support this? I can put a label stack in NLRI today without having = to jump through software upgrade hoops and the associated entities screamin= g about having to do the upgrade. Personally, I would prefer to avoid playi= ng with BGP code more than I have to. No matter if you use context or big label, you will have to change BGP= codes. I haven't seen any commercial BGP software to carry context + vpn l= abel for L3VPN. Actually, the changes are very minimal. > > SD> Also in big label you have to store a 32-bit label value instead of 2= 0 bit label. But the advantage of context-based method is that you won't ne= ed new hardware. While for big label you will need new hardware. > > It depends on your line card. If you use ASIC, perhaps you are right= . But if you use NP, you don't need new hardware. Actually, no matter you n= eed to store 20 bits or 32 bits, you always need a long integer in NP. This is my main concern: that this idea will break in ASICs. Too many a= re deployed today. You deploy a 32 bit label and distribute it to a PE with= ASICs that cannot support this. Are we going to now punt to rewrite the pa= cket? That would be pretty awful. I think most of them will be fine with an= old school label stack though. Someone may show me to be wrong on this tho= ugh. Even for context labels, I believe you still need to change your ASICs= since you have to let your ASICs to take 40 bits as a whole.=20 Regards, Richard From sebastien.jobert@orange.com Thu Jul 18 01:04:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C530221F938E; Thu, 18 Jul 2013 01:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abNrbhAKC8Du; Thu, 18 Jul 2013 01:04:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DF30621F937E; Thu, 18 Jul 2013 01:04:45 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6B7503B42B2; Thu, 18 Jul 2013 10:04:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 44DBA4C06F; Thu, 18 Jul 2013 10:04:44 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 18 Jul 2013 10:04:43 +0200 From: To: Shahram Davari Thread-Topic: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOfkYcnR6ysw913kqs7UWvMFFaBZlf/wSggAASeYCAAKpT8IAAmZ3wgAjDexA= Date: Thu, 18 Jul 2013 08:04:42 +0000 Message-ID: <25665_1374134684_51E7A19C_25665_3691_1_7F67B91079F7C74F9DAB55FC7872661E148C20@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <7347100B5761DC41A166AC17F22DF1121B4C7E6C@eusaamb103.ericsson.se>, <3373_1373529934_51DE674E_3373_9320_1_7F67B91079F7C74F9DAB55FC7872661E14329B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <396B1C2B-013C-4E6C-9DF0-359D220163EF@broadcom.com> <17365_1373580614_51DF2D46_17365_10736_1_7F67B91079F7C74F9DAB55FC7872661E143FA5@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4A6CE49E6084B141B15C0713B8993F281BE85AD7@SJEXCHMB12.corp.ad.broadcom.com> <28095_1373644779_51E027EB_28095_890_1_7F67B91079F7C74F9DAB55FC7872661E144BDE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4A6CE49E6084B141B15C0713B8993F281BE86987@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE86987@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.18.72117 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 08:04:50 -0000 Hi Shahram, (sorry for the late reply, just going back from Geneva ITU-T meeting...) It seems that we identified where we disagree. I wonder if some points are = mainly a matter of terminology? (e.g. terminate/regenerate). As an example, you said: "For end-to-end TC you must not terminate and rege= nerate PTP messages, otherwise you are going to incur huge PDV" The forwarding function (i.e. finding the relevant output port) is for me u= ncorrelated to the PTP treatment (i.e. updating properly the correction fie= ld for a TC, or updating the local time reference for a BC). Therefore, I d= o not understand why in your opinion, TC with termination/regeneration nece= ssarily leads to PDV; in my opinion, if the TC is properly implemented (i.e= . proper update of the correction field based on HW timestamping), then the= re should be almost no PDV, whatever the way to perform the forwarding func= tion (SW-based or HW-based). Anyway, I agree with you that, in order to avoid PDV and so on, new HW is a= bsolutely required, independently of the type of encapsulation. The two topics seem not directly related. It was useful discussion. But still, I remain skeptical about the usefulnes= s of the MPLS encapsulation...=20 - for full timing support scenario: I believe that there are other simpler= ways to perform the same thing (it is what we discussed, although we disag= ree on some points). - for partial timing support scenario: if there is no PTP treatment in som= e MPLS nodes, then there is no need for identifying them among the rest of = the traffic... "Soft prioritization" to minimize the PDV can still be possi= ble in this case using DSCP marking. Thanks! BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: vendredi 12 juillet 2013 20:10 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastien, Pls see inline. Thx SD -----Original Message----- From: sebastien.jobert@orange.com [mailto:sebastien.jobert@orange.com]=20 Sent: Friday, July 12, 2013 9:00 AM To: Shahram Davari Cc: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Shahram, Thanks for the reply. I copied your text below in order to give some more feedback, to make it mo= re readable: "SD> So you agree that you need some interworking function which can conver= t Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, et= c. I am sure you don't want to do this interworking in the CPU, do you?" S=E9bastien: If such IWF occurs, it would involve several different physica= l ports. Then, I assume that some specific PTP HW would have to be supporte= d by the various ports involved for HW timestamping purposes, which may rel= y on different mappings if needed. But then, I assume that the relevant PTP= information is recovered from the PTP packets, and transmitted to the cent= ral clock in the equipment, without information about the mapping initially= used, which is at the end a transport facility only. I am then not sure wh= y such IWF is really needed in HW: the PTP packets may simply use different= mappings at the ingress and at the egress, as far as the relevant informat= ion has been processed inside the device; the IWF is at the end realized by= the entire device, not at a single place. This may look however more like = a BC-model only, but my assumption is that it should be possible to design = a TC with a similar model in which the PTP messages are terminated and proc= essed (again, refer to the draft that we presented in Paris). I don't see a= ny particular IWF problem then from the HW perspective (that being said, I = recognized that I am not expert in this field, so your feedback is really w= elcomed). SD> If all links are Ethernet, and if your switch can do Ethernet bridging = then there is no issue. But if all links are not Ethernet then as you said = you need to convert from Ethernet to say IP. This can off course be done in= CPU, but then it will add significant PDV that makes it useless. So you wo= uld need new HW. Also if all links are Ethernet, based on your own draft, you still want to = use special forwarding for PTP packets, which means new HW. "So you need new HW. Basically what you are saying is that carry 1588 over = the server layer such as Ethernet or OTN, etc. The problem as you figured o= ut yourself is that the span of the server layer is not the same span as th= e LSP. Therefore you either need to terminate the 1588 and regenerate it (B= C), or as you said you need service interworking." S=E9bastien: OK, I see where we diverge then. First, my assumption is that = we can build a TC-model in which the PTP messages are terminated and proces= sed (it is even better IMHO, as it avoids the layer violation problem, plea= se refer again to our draft from Paris). Second, my understanding is that y= our mechanism is really only for a TC-model used over an MPLS layer that "d= oes not terminate the PTP messages" (which I think is not a good model for = telecoms), and not really for a BC system. The layer violation problem of T= Cs should not be under-estimated IMHO; IEEE has delivered to ITU-T a very c= lear message that such architectural problems should be avoided. SD> This is exactly where we disagree. For end-to-end TC you must not termi= nate and regenerate PTP messages, otherwise you are going to incur huge PDV= .=20 "SD> I haven't seen that. Could you please email that to me." S=E9bastien: draft from Paris =3D> http://tools.ietf.org/html/draft-jobert-= tictoc-ptp-link-local-00=20 SD> Thanks. It seems in order to avoid layer violation you have gone to gre= at length. But what you are doing is the same just calling it terminate and= regenerate.=20 "SD> There are networks that don't do IP routing. PTN networks that are bas= ed on MPLS-TP don't do IP routing at all. You can refer to come of the Chin= a and Japan carriers. I agree that Synch can be uncorrelated to data, but = you the issue is that the logically out-of-band network you are referring t= o in most cases has short span (such as one link)" S=E9bastien: such networks do not have to do IP *routing* (or Ethernet swit= ching) in the model that I propose, because in all the cases, the PTP messa= ges are terminated and processed. The IP or Ethernet layers are only used a= s "encapsulations", not for routing (otherwise, the layer violation is ther= e).=20 SD> Again, The termination and regeneration must be done somewhere. If it i= s done in CPU then it won't work for TC since the PDV is high. If it is don= e in HW then logically you are doing IP routing in HW, although you are not= calling it that way. But this would need new HW that doesn't exist. "SD> While the model that you describe where a Transit provider also provid= es reference clock is possible, but it require 1588 protocol exchange betwe= en Operator and the service provider that leases from operator. And I thin= k it is not embraced in the industry (as of yet). But 1588 transparency is = simple and does not require 1588 protocol exchange between operator and ser= vice provider." S=E9bastien: I really disagree: the model where the carrier operator delive= rs his timing reference as part of the service exists today in many cases (= I have several examples in mind for frequency synchronization). However, th= e "timing transparency" model in which the network operator puts very speci= fic HW in his equipment to ensure transparency to the mobile operator is re= ally a scenario that I have never seen, and that I really doubt will happen= one day (perhaps the only exception is SyncE timing transparency over OTN,= which implies specific mappings, but I consider this as different, because= there is no other way to carry timing over OTN than transparency to the cl= ient signals, so the carrier operator has anyway to implement such new mapp= ing for his own purpose - it is not a feature dedicated to the mobile opera= tor). SD> I disagree, the model that the provider provides ToD service to the oth= er operator requires interworking of PTP protocol stack between operators, = while Transparent PTP transport is simple and doesn't require protocol inte= rworking. In conclusion, from my perspective: - I think we have now identified the points that we do not agree: - PTP clock that terminates the PTP messages vs PTP clock that does not (a= nd layer violation implications) - Real need for "timing transparency" as far as PTP is concerned - These points are not related to issues with regards to the solution that = you propose, but to the need for this solution. Depending on the perspectiv= e, the MPLS layer may not need to be used to carry PTP messages over networ= ks that operate the MPLS layer. - So, my understanding is that the solution presented in your draft would b= e applicable only to an operator who would built a network with TC everywhe= re based on the MPLS layer, in order to provide timing transparency capabil= ity to other operators. Given that this timing transparency is subject to d= ebate, I wonder if there are operators having such requirements? - I wonder if your solution really makes sense for a BC-model? SD> Yes it does when the two BC nodes are many MPLS hops away from each oth= er.=20 Thanks for the interesting discussion. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: vendredi 12 juillet 2013 01:06 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastien, Please see my response inline. Thank Shahram -----Original Message----- From: sebastien.jobert@orange.com [mailto:sebastien.jobert@orange.com]=20 Sent: Thursday, July 11, 2013 3:10 PM To: Shahram Davari Cc: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Shahram, Thanks for your reply and explanations. See some comments below in your tex= t. It is interesting discussion. Thanks. BR, S=E9bastien -----Message d'origine----- De=A0: Shahram Davari [mailto:davari@broadcom.com]=20 Envoy=E9=A0: jeudi 11 juillet 2013 16:51 =C0=A0: JOBERT Sebastien OLNC/OLN Cc=A0: Gregory Mirsky; Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Objet=A0: Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sebastian, Thanks for your comments. This draft is an IETF working draft and was accep= ted as such based on IETF consensus. [JOBERT Sebastien RD-CORE-LAN] Absolutely, and this is not something that I= dispute. However, since it has been asked to the mailing list to indicate = support and provide comments, I do not feel that giving an opinion was outs= ide the IETF process. The group may or may not consider this input at the e= nd. Are you saying there is no need to carry 1588 in the networks that use MPLS= or are you saying there are other methods which are simpler?=20 [JOBERT Sebastien RD-CORE-LAN] Of course, there is a need to carry PTP mess= ages over networks that operate the MPLS layer; what I am saying is simply = that, over such networks, I do not think that carrying these PTP messages i= nside an MPLS layer is required. Other existing encapsulations are fine and= probably simpler, indeed. If you mean the former, then I disagree and I can give you examples from Ch= ina mobile, China Telecom, NTT, KDDI, etc where their mobile Backhaul acce= ss and aggregation network are MPLS and they wang to use 1588 at the cell s= ite. [JOBERT Sebastien RD-CORE-LAN] Of course, we agree on this point: MPLS netw= orks are widely deployed. It is on the method to carry PTP messages that we= have different views, I think. If you mean the later one then I disagree as well. [JOBERT Sebastien RD-CORE-LAN] OK, let's discuss then to see where the diff= erent views are. If you are proposing to use Ethernet encapsulation for 1588 without MPLS, t= hen the problem is that not all links are Ethernet.=20 [JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only o= ne possibility, as IP mapping is also possible, see below), the links that = use an Ethernet mapping for the PTP messages must obviously support Etherne= t. That being said: 1- not all the links must use this mapping, it is possi= ble to mix different mappings (e.g. Ethernet and IP) and allow some kind of= interworking mechanisms;=20 SD> So you agree that you need some interworking function which can convert= Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA, etc= . I am sure you don't want to do this interworking in the CPU, do you? So y= ou need new HW. Basically what you are saying is that carry 1588 over the s= erver layer such as Ethernet or OTN, etc. The problem as you figured out yo= urself is that the span of the server layer is not the same span as the LSP= . Therefore you either need to terminate the 1588 and regenerate it (BC), o= r as you said you need service interworking. 2- it is not because the PTP messages are carried over Ethernet that the en= tire traffic must also be carried over Ethernet, it is fully possible to en= visage that only the "synchronization plane" be over Ethernet, and the data= and control planes be over MPLS if desirable. Do we agree on this? SD> Yes. But as I said the issue is that the span of server layer may not b= e the same as the LSP. Even when all links are Ethernet, Ethernet is just used for P2P link and is= not switched in routers.=20 [JOBERT Sebastien RD-CORE-LAN] Some routers may also implement a L2... SD> yes some do L2 switching, but some don't. This means you can only do BC in such cases.=20 [JOBERT Sebastien RD-CORE-LAN] No, there are ways to build a TC system with= Ethernet encapsulation (we actually presented a draft in Paris providing o= ne possible solution). SD> I haven't seen that. Could you please email that to me. If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then= this is exactly what we do in this draft. [JOBERT Sebastien RD-CORE-LAN] Indeed, but this is not what I am proposing = ;-) If you are proposing to use IP encapsulation for 1588, then you are either = proposing to use IP without MPLS encapsulation, which doesn't work since ob= viously many networks such as MPLS-TP can't perform IP routing.=20 [JOBERT Sebastien RD-CORE-LAN] This is probably the main point where we do = not agree. I can hardly imagine personally a network operating an MPLS laye= r where everything is carried over MPLS. As mentioned before, there is no p= roblem in having the data and control planes over MPLS if desirable (althou= gh I doubt that the control plane be always over MPLS, but it is a differen= t debate), and the "synchronization plane" over IP. Synchronization is gene= rally uncorrelated from the other planes: consider for instance Synchronous= Ethernet, it is a layer 1 mechanism, which is totally uncorrelated from th= e way the data plane is transported. Correlating these layers is not necess= ary. SD> There are networks that don't do IP routing. PTN networks that are base= d on MPLS-TP don't do IP routing at all. You can refer to come of the China= and Japan carriers. I agree that Synch can be uncorrelated to data, but y= ou the issue is that the logically out-of-band network you are referring to= in most cases has short span (such as one link) and therefore can't suppor= t 1588 end-to-end TC. Or you are proposing to use IP with MPLS encapsulation, which is exactly wh= at we are doing in this draft. [JOBERT Sebastien RD-CORE-LAN] No, as I mentioned, I do not think that such= encapsulation is required. The other issue is assume a service provider who is using say Ethernet enca= psulation to carry 1588, leases some connections from another network opera= tor. The network operator needs to carry these 1588 messages without termin= ating them but also needs to do TC on them.=20 [JOBERT Sebastien RD-CORE-LAN] Another point where we also probably disagre= e, I believe. TC is one possible solution, but there are many other ways to= enable "timing transparency" (for instance, without going into the details= : differential methods, "network TC" concept, etc.). However, the real ques= tion seems to be: is timing transparency a real requirement? My opinion is = that this is not a strong requirement, because at the end, for mobile appli= cations, one has to deliver some sort of UTC traceable signal. Hence, where= the synchronization reference is coming from is not really important, as l= ong as the synchronization requirements are met, because the ultimate sourc= e is at the end the same for everyone: UTC. Future applications do not real= ly have plesiochronous requirements anymore. I really believe that a scenar= io where the carrier operator is providing the reference to the mobile oper= ator, in case of leased lines, is what will occur. Otherwise, this will be = a scenario where the carrier operator does not provide any support at all f= or PTP and where the mobile operator is on its own to get rid of the PDV an= d asymmetry generated by the network. I cannot imagine why the carrier oper= ator would like to spend money on hardware support such as TC in every sing= le NEs simply to provide to other operators some kind of timing transparenc= y not really required; the carrier operator would better spend his money bu= ilding a robust network enabling to deliver very accurate synchronization, = and provide his own timing reference, with possible guarantees, as part of = the leased line offer. SD> While the model that you describe where a Transit provider also provide= s reference clock is possible, but it require 1588 protocol exchange betwee= n Operator and the service provider that leases from operator. And I think= it is not embraced in the industry (as of yet). But 1588 transparency is s= imple and does not require 1588 protocol exchange between operator and serv= ice provider. Using flat Ethernet switching is not possible since the operator network is= carrying traffic from many other customers and his network is virtualized. SD> I agree with you that if the entire network is built out of Switch-Rout= ers and all links are Ethernet then you probably don't need this draft and = can do 1588 over Ethernet end-to-end. I suggest you reading the draft first. [JOBERT Sebastien RD-CORE-LAN] Good suggestion indeed ;-) I'll do this for = my own education; however, still, I believe that the use cases that this dr= aft tries to address are subject to discussion. Regards, Shahram On Jul 11, 2013, at 1:05 AM, "sebastien.jobert@orange.com" wrote: > Hi, >=20 > In general, I do not support this document, mainly because I don't think = that the problem statement it tries to address really exists. > That being said, I did not check more in details its content, so I cannot= judge whether or not what it proposes is correct. > I just think that there is no use case for this mechanism. >=20 > "There is a need to transport Timing messages over MPLS networks while su= pporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock= (OC) functionality in the LER and LSRs in the MPLS network." =3D> this sta= tement is not supported by any argumentation, and each time that the point = has been raised on the mailing list, no clear answer or use case was provid= ed in my opinion. As mentioned several times, I do not think that there is = a real need to involve the MPLS layer to transport PTP messages; using the = existing mappings defined in IEEE 1588-2008 is sufficient for all the use c= ases that I can imagine. And I have not heard any other use case from other= industries than telecoms. >=20 > Operators are requesting Ethernet encapsulation for PTP (full timing supp= ort from the network scenario) or IP mapping (partial timing support from t= he network scenario and no timing support scenario), but not MPLS encapsula= tion... >=20 > A quick feedback from an operator monitoring this topic from the beginnin= g. >=20 > Thanks for considering (or not) this input. >=20 > BR, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De : tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] De la part = de Gregory Mirsky > Envoy=E9 : vendredi 5 juillet 2013 18:47 > =C0 : Yaakov Stein; tictoc@ietf.org > Cc : mpls@ietf.org > Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > Do not support > - As document describing Transporting Timing messages over MPLS Networks = it comes short in justification of complexity of PTP LSP for non-1588 proto= cols; > - I do believe that even for IEEE 1588 distribution through MPLS-TP domai= n PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnec= ting ports that support IEEE 1588 (new capability advertised in IGP-TE) is = architectually clean and sufficient. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf = Of Yaakov Stein > Sent: Thursday, July 04, 2013 2:21 AM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >=20 > We hereby announce a TICTOC working group last call for draft-ietf-tictoc= -1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-05). >=20 > Please send indications of support, as well as any remaining technical co= mments, to the list. >=20 > Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS WG, but please conduct all discussion on the TICTOC working group ma= iling list. >=20 > This working group last call will end on July 19, 2013. >=20 > Y(J)S=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From xuxiaohu@huawei.com Thu Jul 18 02:55:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428B711E8111; Thu, 18 Jul 2013 02:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[AWL=2.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJytRLm7-3Ek; Thu, 18 Jul 2013 02:55:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9FF021E80B3; Thu, 18 Jul 2013 02:55:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD97060; Thu, 18 Jul 2013 09:55:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 10:53:53 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 10:54:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 17:54:44 +0800 From: Xuxiaohu To: "nvo3@ietf.org" , L3VPN , "l2vpn@ietf.org" , "mpls@ietf.org" Thread-Topic: The possibility of using global MPLS labels as VNIs Thread-Index: Ac6DnNMgHvnlcn9VTo6g3UrBJiTzlQ== Date: Thu, 18 Jul 2013 09:54:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] The possibility of using global MPLS labels as VNIs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 09:55:21 -0000 Hi all, Till now, it seem that the only remaining technical reason for some people = to prefer VXLAN/NVGRE encapsulation format to MAC-in-MPLS-in-IP encapsulati= on format for network virtualization overlay is the former has global VNIs = while the latter doesn't have. If this reason is true, why can't we conside= r the possibility of using global MPLS labels to achieve the same goal? In fact, there are multiple possible ways to achieve global MPLS labels: 1) the first way is to allocate a label block from the existing label space= and use it as a global label space from which VPN labels are assigned. In = this way, the VPN label of a given VN is set to the corresponding VNI. This= approach doesn't require any change to the data plane. 2) the second way is to allocate a separate protocol type code for the glob= al MPLS label so as to distinguish global labels from downstream-assigned a= nd upstream-assigned labels. This approach requires some change to the data= plane of PE routers. 3) the third way is to reserve a special purpose label to indicate that the= label below such special purpose label is a global label. This approach re= quires some change to the data plane of PE routers as well. In case 2) and 3), the global label space mentioned above could be a label = space dedicated for VNI or a label space which is shared with other applica= tions (e.g., segment routing).=20 Any comments? Best regards, Xiaohu From Alexander.Vainshtein@ecitele.com Thu Jul 18 03:15:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C5521E80BD for ; Thu, 18 Jul 2013 03:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRCU0AllgBfb for ; Thu, 18 Jul 2013 03:15:09 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.250]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0521E80B5 for ; Thu, 18 Jul 2013 03:15:07 -0700 (PDT) Received: from [85.158.143.35:17979] by server-3.bemta-4.messagelabs.com id CB/15-29480-A20C7E15; Thu, 18 Jul 2013 10:15:06 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1374142496!654546!7 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4410 invoked from network); 18 Jul 2013 10:15:06 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jul 2013 10:15:06 -0000 X-AuditID: 93eaf2e7-b7fab6d000000add-4f-51e7c028095d Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 59.20.02781.820C7E15; Thu, 18 Jul 2013 13:15:05 +0300 (IDT) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 13:15:04 +0300 From: Alexander Vainshtein To: Yaakov Stein , "tictoc@ietf.org" Thread-Topic: TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gLBHC6Q Date: Thu, 18 Jul 2013 10:15:03 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZ/OrTF13NA88DDTomCVjcWrqS1eJD1w9W ByaPJUt+MnlMWpsWwBTVwGiTmJeXX5JYkqqQklqcbKsUUJRZlphcqaSQmWKrZKikUJCTmJya m5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9dS0sTC11DZXs1JQNja25QjIy ixVSdXMTM3MUclOLixPTUxWAIglbmDPeHzvAXHBFouL45vvMDYxdIl2MnBwSAiYSB9t2MEPY YhIX7q1n62Lk4hASOMgosWbBabCEkMBRRomp3ZEgNpuArcSm1XfZQGwRAQ+Jq5MmMHUxcnAw CyhLnLorAxIWFrCRmL1yGQtEia3Er66XjBC2kcT7ba+ZQcpZBFQlvrfFgYR5BQIk3r69wASx yUuis2s5K4jNKeAt8XLdFLA4I9Bp30+tAbOZBcQlbj2ZzwRxsoDEkj3noc4XlXj5+B8rhC0n 8eTJKRaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hMWiHpJiYMrbrBMYBSfhWTFLCTts5C0z0LS voCRZRWjaGZOQUlSbrqBoV5qcmZJak6qXnJ+7iZGSAJ5voPx13yVQ4yuQG9PZJbiTs4HJqC8 knhjAwPcHCVx3uUN4f5CAunAVJOdmlqQWhRfVJqTWnyIkYmDU6qBUe+1uLiKxOQtXB9VmjoM 9WwD42bfm/WyqO7RsthldxMNuJZxeE79G7jH+9uNeeLZ9+ZNTl/p8si7WOTRvU9OWtdaAhP1 9dwu9dXVmS1iVbVVUbtz1HPBzGs3zRKjhLkXFUxJk198xM3GY+GRbkZh47W2jKfajKzrK38w 5a14y+K3+sha1wUblFiKMxINtZiLihMB8n0wXRgDAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 10:15:15 -0000 Hi all, I do not support this draft in its present form. IMHO and FWIW the idea of setting up dedicated "timing LSPs" for carrying ju= st the PTP messages does not match the MPLS data plane architecture as descr= ibed in RFC 3031. To the best of my understanding, the proper way to request any kind of speci= al processing (including the processing required for accurate synchronizatio= n) in MPLS is by defining a suitable "alert label". Such a label could be pu= shed on top of the label stack by the LSR that is the originator of the pack= et that requires special processing. The LER that receives a packet with suc= h an alert label would: - treat this label as a request for special processing - use the remainder of the label stack to define the forwarding disposition= of the packet - if the packet were to be forwarded as a labeled packet, the same "alert la= bel" would be pushed on top of the label stack at egress. (This behavior has been defined for the "router alert" label in RFC 3032). I am not sure if the WG has ever considered such an alternative. I believe (= but I may be wrong) that it has been mentioned in some private discussions,= but rejected due to the fact that reserved labels were considered a scarce= resource so that the chances to obtain one from the IANA were slim. The situation is hopefully going to change with the advance of an extended s= pace of "special purpose" labels as defined in http://tools.ietf.org/html/dr= aft-ietf-mpls-special-purpose-labels-03. With at least 240 special purpose l= abels available for the Standards Action, it would be easy to obtain a "Sync= hronization Alert" label that would indicate the need for the corresponding= special processing without creation and maintenance of dedicated "timing LS= Ps", providing dedicated protection schemes for such LSPs etc. It would only= greatly simplify the HW design because the packets requiring special proces= sing would be easily identifiable without any special configuration (the "Sy= nchronization Alert" label would follow the "Extension Label" indicator and= have a fixed IANA-allocated value). My 2c, Sasha > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f > Yaakov Stein > Sent: Thursday, July 04, 2013 12:21 PM > To: tictoc@ietf.org > Cc: mpls@ietf.org > Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls > > We hereby announce a TICTOC working group last call for draft-ietf-tictoc- > 1588overmpls > (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). > > Please send indications of support, as well as any remaining technical > comments, to the list. > > Due to the MPLS aspects of this draft this email is also being sent to the= MPLS > WG, > but please conduct all discussion on the TICTOC working group mailing list= . > > This working group last call will end on July 19, 2013. > > Y(J)S > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc 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 jdrake@juniper.net Thu Jul 18 04:49:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0880921F9971 for ; Thu, 18 Jul 2013 04:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVDqABgG-gOU for ; Thu, 18 Jul 2013 04:49:53 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F411E812B for ; Thu, 18 Jul 2013 04:49:52 -0700 (PDT) Received: from mail153-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 11:49:52 +0000 Received: from mail153-tx2 (localhost [127.0.0.1]) by mail153-tx2-R.bigfish.com (Postfix) with ESMTP id 2FE2210032D for ; Thu, 18 Jul 2013 11:49:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz9371I936eI542Iec9I1432I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail153-tx2: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=jdrake@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail153-tx2 (localhost.localdomain [127.0.0.1]) by mail153-tx2 (MessageSwitch) id 1374148189396669_12290; Thu, 18 Jul 2013 11:49:49 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.252]) by mail153-tx2.bigfish.com (Postfix) with ESMTP id 512401E0057 for ; Thu, 18 Jul 2013 11:49:49 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.50) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Jul 2013 11:49:49 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 04:49:48 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Thu, 18 Jul 2013 04:49:48 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 04:54:24 -0700 Received: from mail13-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 11:49:47 +0000 Received: from mail13-ch1 (localhost [127.0.0.1]) by mail13-ch1-R.bigfish.com (Postfix) with ESMTP id 18FE72C0336 for ; Thu, 18 Jul 2013 11:49:47 +0000 (UTC) Received: from mail13-ch1 (localhost.localdomain [127.0.0.1]) by mail13-ch1 (MessageSwitch) id 1374148184826671_31310; Thu, 18 Jul 2013 11:49:44 +0000 (UTC) Received: from CH1EHSMHS038.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail13-ch1.bigfish.com (Postfix) with ESMTP id C5D2E20004A; Thu, 18 Jul 2013 11:49:44 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS038.bigfish.com (10.43.69.247) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 11:49:38 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.14]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0329.000; Thu, 18 Jul 2013 11:49:38 +0000 From: John E Drake To: Richard Li , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt Thread-Index: AQHOdd+A3aiwC4A4oU2RIaGDkUi0fplpG3SggAFP5HA= Date: Thu, 18 Jul 2013 11:49:38 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E2073EF8E@BL2PRD0510MB349.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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, 18 Jul 2013 11:49:59 -0000 Richard, If one wanted to support leaf-initiated join, why wouldn't one simply have = the leaf send a notification (e.g., Notify) to the root requesting it to ex= tend the p2mp tree to the leaf using the existing P2MP procedures? The aut= hors of RFC4875 expected an application level notification to produce exact= ly this behavior. Yours Irrespectively, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Richard Li > Sent: Wednesday, July 17, 2013 8:39 AM > To: mpls@ietf.org > Subject: [mpls] FW: New Version Notification for draft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03.txt >=20 > Hi All! >=20 > We have updated our receiver-driven RSVP-TE draft. Your comments will > be highly appreciated. >=20 > Regards, >=20 > Richard >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 01, 2013 6:17 AM > To: Telus Communications; Christian Jacquenet; Eduard Metz; Boris > Zhang; Quintin zhao; Richard Li > Subject: New Version Notification for draft-lzj-mpls-receiver-driven- > multicast-rsvp-te-03.txt >=20 >=20 > A new version of I-D, draft-lzj-mpls-receiver-driven-multicast-rsvp-te- > 03.txt > has been successfully submitted by Renwei Li and posted to the IETF > repository. >=20 > Filename: draft-lzj-mpls-receiver-driven-multicast-rsvp-te > Revision: 03 > Title: Receiver-Driven Multicast Traffic-Engineered Label- > Switched Paths > Creation date: 2013-07-01 > Group: Individual Submission > Number of pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03.txt > Status: http://datatracker.ietf.org/doc/draft-lzj-mpls- > receiver-driven-multicast-rsvp-te > Htmlized: http://tools.ietf.org/html/draft-lzj-mpls-receiver- > driven-multicast-rsvp-te-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03 >=20 > Abstract: > This document describes extensions to Resource Reservation Protocol > - > Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven > Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to- > multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol > Label > Switching (MPLS) and Generalized MPLS (GMPLS)networks. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From davarish@yahoo.com Thu Jul 18 09:11:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08F711E818B for ; Thu, 18 Jul 2013 09:11:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-4fD23vA68W for ; Thu, 18 Jul 2013 09:11:28 -0700 (PDT) Received: from nm26-vm7.bullet.mail.gq1.yahoo.com (nm26-vm7.bullet.mail.gq1.yahoo.com [98.136.216.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8259511E80FC for ; Thu, 18 Jul 2013 09:11:28 -0700 (PDT) Received: from [98.137.12.188] by nm26.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jul 2013 16:11:27 -0000 Received: from [208.71.42.209] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jul 2013 16:11:27 -0000 Received: from [127.0.0.1] by smtp220.mail.gq1.yahoo.com with NNFMP; 18 Jul 2013 16:11:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1374163887; bh=fWLmulPT7TXnIOWYZaTiMh2hQcvRJoPZfGwt3fpIQes=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=KUZe0LC7R6+uZ2a8aTBN1FOEea6iDTqs//s+OR1JmEbUW3ak3HzGJ8+tDvei/8G9D0fDK2ngiusU/OvRvFkB8pg4Pl2vJTwy8Z8r7ZRox0sAmdxC5hg3MAWlhywIrA74Tj7QlI9cv7KznJLpRfPo8yxzu5TPwzBtrK+c53MSnIk= X-Yahoo-Newman-Id: 371031.88070.bm@smtp220.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: e8PeZPQVM1mhtzJoLcIwChVb.A1uDW_yN7sWyB6hZhgQS9A .VdpQaxobgOF1JwOo5P73xj1eI_g7DNMjVWvTwHZ7xqeictxLVVkBEZcMUBQ AUa2a5Z3PKwbI3V0YKCJnU5jLWRcBduGAGfohJ6G2DOseUyxoIWzPMyyjJV5 cnyUEJV6p2..eLikWYVZw2KiOQvgYh_m7_bkKFVroD.5qFhsjEyhH.M6X9Fg HoDV0L6wmm_sz883QRpRVjifk_anbrNkxcpwEerLLKzhUehtYeoXO6OEnmpn tSVSiAI42f7RYJmk2duTT3hBYALnFUb1ZgjyWuvA0pg7i.8WUv_Lfuse483E nc2xm20OqpXGMS77cSnrhXXPUIkX84M0j4F3XJvMLuhKvR_G7nKvNWHLITaL i9GYFQ83db_qasF.hoYXZn41YKoDYY2cqTVrXHnd2hWBXTiFG6ZVFtWMv.Yy JlIyHTp_OxbWb3AI3InJfC1lcQMIr8hmBBGVigKa0JBn4KwDCQ3k0zoqd6fn HqbTD7aZQOPw5f2CmCZjewgBWR0u6pYZm_t.u67NZ9w-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [10.245.212.235] (davarish@166.137.215.196 with ) by smtp220.mail.gq1.yahoo.com with SMTP; 18 Jul 2013 16:11:27 +0000 UTC References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Thu, 18 Jul 2013 09:11:25 -0700 To: Alexander Vainshtein Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:11:35 -0000 Hi Sasha, We had considered using a reserved label and it was rejected. Perhaps we sho= uld have documented it in the draft.=20 The issues are: 1) reserved label is not backward compatible with existing routers. One of t= he requirements is that routers that are not PTP aware can just switch the p= acket normally. Using a reserved label can't achieve this requirement, sinc= e routers that don't understand it will drop it or sent it to CPU. 2) there are multiple encapsulations for PTP such as Ethernet with optional V= LAN or UDP/IP. An intermediate LSR doesn't know the whether the payload is I= P or Ethernet or VLAN. This means for each PTP encapsulation type you probab= ly need a different reserved label. 3) the area director has asked us to create a more generalized way of carryi= ng timing over MPLS to be usable with new timing protocols that need TC. Usi= ng reserved label would require different reserved label for each new timing= protocol. 4) the extended reserved label draft is fairly new and didn't exist when thi= s draft was progressing. Regards, Shahram On Jul 18, 2013, at 3:15 AM, Alexander Vainshtein wrote: > Hi all, > I do not support this draft in its present form. > IMHO and FWIW the idea of setting up dedicated "timing LSPs" for carrying j= ust the PTP messages does not match the MPLS data plane architecture as desc= ribed in RFC 3031. >=20 > To the best of my understanding, the proper way to request any kind of spe= cial processing (including the processing required for accurate synchronizat= ion) in MPLS is by defining a suitable "alert label". Such a label could be p= ushed on top of the label stack by the LSR that is the originator of the pac= ket that requires special processing. The LER that receives a packet with su= ch an alert label would: > - treat this label as a request for special processing > - use the remainder of the label stack to define the forwarding dispositio= n of the packet > - if the packet were to be forwarded as a labeled packet, the same "alert l= abel" would be pushed on top of the label stack at egress. >=20 > (This behavior has been defined for the "router alert" label in RFC 3032).= >=20 > I am not sure if the WG has ever considered such an alternative. I believe= (but I may be wrong) that it has been mentioned in some private discussion= s, but rejected due to the fact that reserved labels were considered a scarc= e resource so that the chances to obtain one from the IANA were slim. >=20 > The situation is hopefully going to change with the advance of an extended= space of "special purpose" labels as defined in http://tools.ietf.org/html/= draft-ietf-mpls-special-purpose-labels-03. With at least 240 special purpose= labels available for the Standards Action, it would be easy to obtain a "Sy= nchronization Alert" label that would indicate the need for the correspondin= g special processing without creation and maintenance of dedicated "timing L= SPs", providing dedicated protection schemes for such LSPs etc. It would onl= y greatly simplify the HW design because the packets requiring special proce= ssing would be easily identifiable without any special configuration (the "S= ynchronization Alert" label would follow the "Extension Label" indicator and= have a fixed IANA-allocated value). >=20 > My 2c, > Sasha >=20 >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f >> Yaakov Stein >> Sent: Thursday, July 04, 2013 12:21 PM >> To: tictoc@ietf.org >> Cc: mpls@ietf.org >> Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >>=20 >> We hereby announce a TICTOC working group last call for draft-ietf-tictoc= - >> 1588overmpls >> (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). >>=20 >> Please send indications of support, as well as any remaining technical >> comments, to the list. >>=20 >> Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS >> WG, >> but please conduct all discussion on the TICTOC working group mailing lis= t. >>=20 >> This working group last call will end on July 19, 2013. >>=20 >> Y(J)S >>=20 >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >=20 >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If y= ou have received this transmission in error, please inform us by e-mail, pho= ne or fax, and then delete the original and all copies thereof. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pabloisnot@gmail.com Thu Jul 18 10:25:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797DD11E81A2 for ; Thu, 18 Jul 2013 10:25:00 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTdMQNjN937b for ; Thu, 18 Jul 2013 10:24:58 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D059B21E8142 for ; Thu, 18 Jul 2013 10:24:47 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x14so2573327vbb.34 for ; Thu, 18 Jul 2013 10:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=83Cce8JvCw9L+BDxtGQxIjsHZjvFct0F7plb13KjUFs=; b=OqFwUmInzy8BwrOIgHh82SQ2RreYGLO2+j9+AOqmuTLFn3QZxMC9sycBBnogMapfOL J6Rh/ENjEl73cqdU53QkX00c9RN8D9hBMTRaMLzyq/rPv3YESn5zx33P8Z62w1XuSAqd +w3suvScc2Li90xzAJ+BUwoZqRftM0p5pkclOHaFxoe/pXuke5FSJKR0PkuTjmmb+z6K FDN4eCujMneZfduSd/8cuBUb6/sNq6XaoRJLQ8wZq5J1mwySGVd4i2Azf/btx3WW+DaN dDAtH0bWxhVZ1bFvW6n5jwBqG4HzBeMOejGr8Pot9/E3hHyzDaud+q8v7vP6m5Ao4KVU oi+A== MIME-Version: 1.0 X-Received: by 10.52.164.16 with SMTP id ym16mr3643912vdb.32.1374168286115; Thu, 18 Jul 2013 10:24:46 -0700 (PDT) Received: by 10.52.20.75 with HTTP; Thu, 18 Jul 2013 10:24:46 -0700 (PDT) In-Reply-To: References: <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> Date: Thu, 18 Jul 2013 13:24:46 -0400 Message-ID: From: Pablo Frank To: Richard Li Content-Type: multipart/alternative; boundary=001a11c22e588e3e9704e1cc7c18 Cc: "mpls@ietf.org" , Mli , "Nagendra Kumar \(naikumar\)" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:25:03 -0000 --001a11c22e588e3e9704e1cc7c18 Content-Type: text/plain; charset=ISO-8859-1 No matter how you look at it, it's a fundamentally different forwarding paradigm. It won't be implementable in some existing and deployed hardware. Sure, NPU-based or FPGA-based forwarding hardware could implement it but the reason that there are ASICs out there with hard MPLS dataplanes is because the MPLS dataplane is mature and has been a de facto standard for a long time. Now, if you want to make the case for some kind of "MPLSv6", maybe you'll find others willing to embark on that scary adventure... On Wed, Jul 17, 2013 at 7:04 PM, Richard Li wrote: > In line with prefix... > > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, July 18, 2013 2:40 AM > To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William > McCall > Cc: Mli; mpls@ietf.org > Subject: RE: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review > of draft-renwei-mpls-bgp-big-label-00) > > Hi Richard, > > I agree with Eric and Nagendra. What you want is achievable with > context-based label. Please see my comments inline. > > Thanks > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Nagendra Kumar (naikumar) > Sent: Wednesday, July 17, 2013 10:46 AM > To: Richard Li; Eric Rosen (erosen); William McCall > Cc: Mli; mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review > of draft-renwei-mpls-bgp-big-label-00) > > Hi Richard, > > Is the proposal is to use the big label indicator only when the label size > is more than 20 bits?. If not, I think it is a trade off between label > stack size vs fwding semantic. With big label, any service like VPN will > require 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP > label and application label) which is equivalent to 4 labels. But with > context label, it is going to be 3 labels. > > While context label is explained in terms of upstream label for MP-LSP, I > think nothing stops its usage for unicast LSP. > > -Nagendra > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Richard Li > Sent: Wednesday, July 17, 2013 9:08 PM > To: Eric Rosen (erosen); William McCall > Cc: Mli; mpls@ietf.org > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review > of draft-renwei-mpls-bgp-big-label-00) > > Hi! > > Thanks for the comments. And I am sorry for the late reply; I was on > vacations. > > Now let me clarify and explain why we need something like big labels. > > 1. > You do have a good point here. Yes, it is true that one can always get a > bigger label space by stacking labels over labels. The combination of two > "small" labels may achieve what a "big" label can do. But their fundamental > concepts and the consequences will be totally different. Conceptually, a > label has four components: label value, BOS indicator, the EXP bits and > the TTL value. If you use two "small" labels to represent a "big" label, > you will run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You > can semantically combine the two label values, but you can't combine other > fields such as TTL. If the two labels are collectively considered as ONE > label, they should have one TTL, one EXP, and one BOS since they should be > treated and processed as a single and inseparable entity. Having multiple > TTLs/EXPs/BOSes is conceptually counter-intuitive against the very idea of > "a label". > > SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EXP > for both labels (redundant). > > Does user like to configure more or less? Is redundancy a good thing > or bad one? > > > > 2. > Context was introduced in the context of upstream-assigned labels for > multicast LSPs. It provides the concept of context, but it doesn't provide > the concept of "big labels". The label itself is still 20 bits in length. > The label space in a context is not expanded; it is still 1M. > > SD> Multicast was one of the applications of context-based lookup. This > can be another application. The labels space with context is not 1M > anymore. It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit > lookup. > > I am talking about the concept here. In context-based label, there is > a sub-stack of two label entries. > > > 3. > If you use context labels, you will need 16 contexts since each context > will only hold 1M labels. Which label belongs to which context will be very > arbitrary; If someone put a label in one context, it won't be wrong if > another one put the same label in a different context. There is no semantic > association at all between contexts and labels, which is different from the > situation about contexts for upstream-assigned labels where one simply > can't put upstream-assigned labels in an arbitrary context. > > SD> I think you have may not have understood the context label well. The > context label tells you the meaning of the label under it. Think of it as > 40 bit label, that is how it works. > > Please do a simple math. In order to achieve the 16M goal, how many > context labels you will need? And how are you going to allocate those > labels in your implementation. > > > > > 4. > In this proposal, we only need two 32-bit entries for a "big label": the > big label indicator + big label value. The big label indicator is a > reserved label. We don't need three label entries in an MPLS packet. > > SD> draft-ietf-mpls-special-purpose-labels-03.txt from now on requires > using a special label indicator before the special big label indicator. So > you need 3 labels. > > 5. > With respect to the BGP protocol, the "big label" proposal has some > scaling benefits over the context-based solution. If you use context > labels, you will need to add 64 extra bits in BGP's NLRI: context label and > a secondary label. But if you use the big label proposal in this draft, > you will only need to add 32 bits: big label value. Saving the extra 32 > bits to each VPN route can be a big deal, especially when we are talking > about up to 16M VPNs here for virtualized networks currently being > standardized by NVO3/VXLAN/NVGRE. > > SD> BGP packet size is not an issue, after all it is just control packet. > > I am not sure if I should agree. Here we are dealing with a problem > with potentially 16M VPNs. When you add 32 bits to a BGP packet, you need > to read and write. For me, I have been always sensitive to the BGP > reconvergence time. > > > > 6. > In the operating system and line cards, the "big label" proposal also has > some benefits over the context-based solution. If you use contexts, you > have to store the context label in conjunction with the VPN label. But if > you use the big label proposal, you only need an attribute flag bit to mean > the VPN label is a big one. The same thing holds true in the forwarding > software. > > SD> Also in big label you have to store a 32-bit label value instead of 20 > bit label. But the advantage of context-based method is that you won't need > new hardware. While for big label you will need new hardware. > > It depends on your line card. If you use ASIC, perhaps you are right. > But if you use NP, you don't need new hardware. Actually, no matter you > need to store 20 bits or 32 bits, you always need a long integer in NP. > > > Regards, > > > Richard > > > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, July 05, 2013 11:50 PM > To: William McCall > Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com > Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review > of draft-renwei-mpls-bgp-big-label-00) > > > > What would this change alleviate that could not already be solved by > > adding another label to the stack? > > Excellent point. > > Please see also section 3 (especially the last paragraph) of RFC 5331 on > "context labels". By using one label as a "context label" identifying a > context in which the subsequent label is interpreted, one gets the effect > of a 40-bit label space, and the same mechanism can also be used to support > upstream-assigned labels. > > It's also worth noting that the "big label" proposal would probably end up > using three label stack entries per big label: special purpose label > indicator, big label indicator, big label value. The use of context labels > will require only two label stack entries. > > > _______________________________________________ > 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 > --001a11c22e588e3e9704e1cc7c18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No matter how you look at it, it's a fundamentally dif= ferent forwarding paradigm. =A0It won't be implementable in some existi= ng and deployed hardware. =A0Sure, NPU-based or FPGA-based forwarding hardw= are could implement it but the reason that there are ASICs out there with h= ard MPLS dataplanes is because the MPLS dataplane is mature and has been a = de facto standard for a long time. =A0Now, if you want to make the case for= some kind of "MPLSv6", maybe you'll find others willing to e= mbark on that scary adventure...


On Wed,= Jul 17, 2013 at 7:04 PM, Richard Li <renwei.li@huawei.com> wrote:
In line with <RL> prefix...

-----Original Message-----
From: Shahram Davari [mailto:davari@= broadcom.com]
Sent: Thursday, July 18, 2013 2:40 AM
To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William McC= all
Cc: Mli; mpls@ietf.org
Subject: RE: [mpls] Review of draft-renwei-mpl= s-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi Richard,

I agree with Eric and Nagendra. What you want is achievable with context-ba= sed label. Please see my comments inline.

Thanks
Shahram

-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Nagendra Kumar (naikumar)
Sent: Wednesday, July 17, 2013 10:46 AM
To: Richard Li; Eric Rosen (erosen); William McCall
Cc: Mli; mpls@ietf.org
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00)

Hi Richard,

Is the proposal is to use the big label indicator only when the label size = is more than 20 bits?. =A0If not, I think it is a trade off between label s= tack size vs fwding semantic. With big label, any service like VPN will req= uire 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP la= bel and application label) which is equivalent to 4 labels. But with contex= t label, it is going to be 3 labels.

While context label is explained in terms of upstream label for MP-LSP, I t= hink nothing stops its usage for unicast LSP.

-Nagendra

-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Richard Li
Sent: Wednesday, July 17, 2013 9:08 PM
To: Eric Rosen (erosen); William McCall
Cc: Mli; mpls@ietf.org
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00)

Hi!

Thanks for the comments. And I am sorry for the late reply; I was on vacati= ons.

Now let me clarify and explain why we need something like big labels.

1.
You do have a good point here. Yes, it is true that one can always get a bi= gger label space by stacking labels over labels. The combination of two &qu= ot;small" labels may achieve what a "big" label can do. But = their fundamental concepts and the consequences will be totally different. = Conceptually, a label has four components: =A0label value, BOS indicator, t= he EXP bits and the TTL value. If you use two "small" labels to r= epresent a "big" label, you will run into TWO BOS indicators, TWO= EXP bits, and TWO TTL values. You can semantically combine the two label v= alues, but you can't combine other fields such as TTL. If the two label= s are collectively considered as ONE label, they should have one TTL, one E= XP, and one BOS since they should be treated and processed as a single and = inseparable entity. Having multiple TTLs/EXPs/BOSes is conceptually counter= -intuitive against the very idea of "a label".

SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EXP= for both labels (redundant).

<RL> =A0Does user like to configure more or less? Is redu= ndancy a good thing or bad one?



2.
Context was introduced in the context of upstream-assigned labels for multi= cast LSPs. It provides the concept of context, but it doesn't provide t= he concept of "big labels". The label itself is still 20 bits in = length. The label space in a context is not expanded; it is still 1M.

SD> Multicast was one of the applications of context-based lookup. This = can be another application. =A0The labels space with context is not 1M anym= ore. It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit looku= p.

<RL> I am talking about the concept here. In context-based labe= l, there is a sub-stack of two label entries.


3.
If you use context labels, you will need 16 contexts since each context wil= l only hold 1M labels. Which label belongs to which context will be very ar= bitrary; If someone put a label in one context, it won't be wrong if an= other one put the same label in a different context. There is no semantic a= ssociation at all between contexts and labels, which is different from the = situation about contexts for upstream-assigned labels where one simply can&= #39;t put upstream-assigned labels in an arbitrary context.

SD> I think you have may not have understood the context label well. The= context label tells you the meaning of the label under it. Think of it as = 40 bit label, that is how it works.

<RL> Please do a simple math. In order to achieve the 16M goal,= how many context labels you will need? And how are you going to allocate t= hose labels in your implementation.




4.
In this proposal, we only need two 32-bit entries for a "big label&quo= t;: the big label indicator + big label value. The big label indicator is a= reserved label. We don't need three label entries in an MPLS packet.
SD> =A0draft-ietf-mpls-special-purpose-labels-03.txt from now on require= s using a special label indicator before the special big label indicator. S= o you need 3 labels.

5.
With respect to the BGP protocol, the "big label" proposal has so= me scaling benefits over the context-based solution. If you use context lab= els, you will need to add 64 extra bits in BGP's NLRI: context label an= d a secondary label. =A0But if you use the big label proposal in this draft= , you will only need to add 32 bits: =A0big label value. Saving the extra 3= 2 bits to each VPN route can be a big deal, especially when we are talking = about up to 16M VPNs here for virtualized networks currently being standard= ized by NVO3/VXLAN/NVGRE.

SD> BGP packet size is not an issue, after all it is just control packet= .

<RL> I am not sure if I should agree. Here we are dealing with = a problem with potentially 16M VPNs. When you add 32 bits to a BGP packet, = you need to read and write. For me, I have been always sensitive to the BGP= reconvergence time.



6.
In the operating system and line cards, the "big label" proposal = also has some benefits over the context-based solution. If you use contexts= , you have to store the context label in conjunction with the VPN label. Bu= t if you use the big label proposal, you only need an attribute flag bit to= mean the VPN label is a big one. The same thing holds true in the forwardi= ng software.

SD> Also in big label you have to store a 32-bit label value instead of = 20 bit label. But the advantage of context-based method is that you won'= ;t need new hardware. While for big label you will need new hardware.

<RL> It depends on your line card. If you use ASIC, perhaps you= are right. But if you use NP, you don't need new hardware. Actually, n= o matter you need to store 20 bits or 32 bits, you always need a long integ= er in NP.


Regards,


Richard



-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.c= om]
Sent: Friday, July 05, 2013 11:50 PM
To: William McCall
Cc: mpls@ietf.org; Richard Li; Mli; erosen@cisco.com
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review o= f draft-renwei-mpls-bgp-big-label-00)


> What would this change alleviate that could not already be solved by > adding another label to the stack?

Excellent point.

Please see also section 3 (especially the last paragraph) of RFC 5331 on &q= uot;context labels". =A0By using one label as a "context label&qu= ot; identifying a context in which the subsequent label is interpreted, one= gets the effect of a 40-bit label space, and the same mechanism can also b= e used to support upstream-assigned labels.

It's also worth noting that the "big label" proposal would pr= obably end up using three label stack entries per big label: special purpos= e label indicator, big label indicator, big label value. =A0The use of cont= ext labels will require only two label stack entries.


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

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

--001a11c22e588e3e9704e1cc7c18-- From saku@ytti.fi Thu Jul 18 10:40:02 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF2211E81B1 for ; Thu, 18 Jul 2013 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWB9PzBEt99t for ; Thu, 18 Jul 2013 10:39:57 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id A44CA11E81B6 for ; Thu, 18 Jul 2013 10:39:57 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so3966465obb.36 for ; Thu, 18 Jul 2013 10:39:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eGZxnXIafGv2k5KultEBN+saMBxHF2q68Reujuuz02s=; b=ZkRHnz4eyfvPqdV1/kso8PkJBaba+0IucY2ytp3I8upx9cI7MDt5k3ExSn3pZLDYn2 Atyz1d8HgyS8UcIai/Ssoq01/HoksQ2oq/1K123UM7Xhz562Di7PhMWCDg/mWQxNLlcX YRHnvxra0ATepGyrAO/4mtQpN6Edp1mWUqgPkcViukVPTDq/QCXJPlgSx2mr/9NX+624 Js8sZwzwG4Lz4r6vFWAh4o8p+4wMsi5ORLO18uJkN+9M0mPX6rXmcpqjcOYX1Yj9qDlH z39Sb00/yM+y2SHDikd4q2MUM+pohANdiDWaNdrLcNFjI8JOJ4tT6hxluf+tyhOnhPsT EaRQ== MIME-Version: 1.0 X-Received: by 10.182.241.101 with SMTP id wh5mr8960400obc.49.1374169195722; Thu, 18 Jul 2013 10:39:55 -0700 (PDT) Received: by 10.182.45.105 with HTTP; Thu, 18 Jul 2013 10:39:55 -0700 (PDT) In-Reply-To: References: <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> Date: Thu, 18 Jul 2013 20:39:55 +0300 Message-ID: From: Saku Ytti To: Pablo Frank Content-Type: multipart/alternative; boundary=001a11c31ca2c5cb8604e1ccb249 X-Gm-Message-State: ALoCoQnBBb5O0W0bdSJAWn96AvuNJqazYZ3NM5jtFb1fELknmd+imWOiykocPqeufdJp+Fug/zJU Cc: Mli , "mpls@ietf.org" , "Nagendra Kumar \(naikumar\)" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:40:03 -0000 --001a11c31ca2c5cb8604e1ccb249 Content-Type: text/plain; charset=UTF-8 On 18 July 2013 20:24, Pablo Frank wrote: > No matter how you look at it, it's a fundamentally different forwarding > paradigm. It won't be implementable in some existing and deployed > hardware. Sure, NPU-based or FPGA-based forwarding hardware could > implement it but the reason that there are ASICs out there with hard MPLS > dataplanes is because the MPLS dataplane is mature and has been a de facto > standard for a long time. Now, if you want to make the case for some kind > of "MPLSv6", maybe you'll find others willing to embark on that scary > adventure... > I've been worrying about this same thing very often lately. I have same issue with several other new MPLS enhancements which essentially mean when magic label is hit, your behavior changes. I understand rationale why many of the enhancements are needed, but I wonder if doing 'MPLSv2' would be in the end be cleaner solution. If you cannot support old ASIC platforms and you essentially need NPU based platform, then you might as well be bit more progressive? -- ++ytti --001a11c31ca2c5cb8604e1ccb249 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 18 July 2013 20:24, Pablo Frank <pabloisnot@gmail.com>= wrote:
No matter how you look at i= t, it's a fundamentally different forwarding paradigm. =C2=A0It won'= ;t be implementable in some existing and deployed hardware. =C2=A0Sure, NPU= -based or FPGA-based forwarding hardware could implement it but the reason = that there are ASICs out there with hard MPLS dataplanes is because the MPL= S dataplane is mature and has been a de facto standard for a long time. =C2= =A0Now, if you want to make the case for some kind of "MPLSv6", m= aybe you'll find others willing to embark on that scary adventure...

I've been worr= ying about this same thing very often lately. I have same issue with severa= l other new MPLS enhancements which essentially mean when magic label is hi= t, your behavior changes.

I understan= d rationale why many of the enhancements are needed, but I wonder if doing = 'MPLSv2' would be in the end be cleaner solution. If you cannot sup= port old ASIC platforms and you essentially need NPU based platform, then y= ou might as well be bit more progressive?

--
=C2= =A0 ++ytti
--001a11c31ca2c5cb8604e1ccb249-- From renwei.li@huawei.com Thu Jul 18 16:58:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878D921E818A for ; Thu, 18 Jul 2013 16:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhfJHpoIlXWQ for ; Thu, 18 Jul 2013 16:57:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6091521E8148 for ; Thu, 18 Jul 2013 16:57:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVE46565; Thu, 18 Jul 2013 23:57:56 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 00:56:56 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 00:57:54 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 16:57:47 -0700 From: Richard Li To: Saku Ytti , Pablo Frank Thread-Topic: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) Thread-Index: AQHOeZgLPkhJY0+Kvke3sDwL13/hpJloipsggAEimACAAA70gP//0yHwgAGqRgCAAAQ7gP//8oOg Date: Thu, 18 Jul 2013 23:57:45 +0000 Message-ID: References: <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.162] Content-Type: multipart/alternative; boundary="_000_F061CEB6876F904F8EA6D6B92877731C2FB40B9Cdfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Mli , "mpls@ietf.org" , "Nagendra Kumar \(naikumar\)" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 23:58:03 -0000 --_000_F061CEB6876F904F8EA6D6B92877731C2FB40B9Cdfweml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FrdSwNCg0KSSBhbSB2ZXJ5IGludGVyZXN0ZWQgaW4ga25vd2luZyB3aGF0IGFyZSB0aG9z ZSBuZXcgTVBMUyBlbmhhbmNlbWVudHMgeW91IGFyZSBoYXZpbmcgaXNzdWVzIHdpdGguIENhbiB5 b3Ugc2hhcmUgdGhlbSB3aXRoIHRoaXMgY29tbXVuaXR5Pw0KDQpNUExTIGhhcyBiZWVuIGFsaXZl IGZvciBhYm91dCAxNSB5ZWFycy4gQSB0ZWVuYWdlciBvZnRlbiBjaGFuZ2VzIGFuZCBpcyBkaWZm ZXJlbnQgZnJvbSB3aGVuIGl0IHdhcyBib3JuLg0KDQoNClRoYW5rcywNCg0KUmljaGFyZA0KDQoN Cg0KRnJvbTogU2FrdSBZdHRpIFttYWlsdG86c2FrdUB5dHRpLmZpXQ0KU2VudDogRnJpZGF5LCBK dWx5IDE5LCAyMDEzIDE6NDAgQU0NClRvOiBQYWJsbyBGcmFuaw0KQ2M6IFJpY2hhcmQgTGk7IG1w bHNAaWV0Zi5vcmc7IE1saTsgTmFnZW5kcmEgS3VtYXIgKG5haWt1bWFyKQ0KU3ViamVjdDogUmU6 IFttcGxzXSBSZXZpZXcgb2YgZHJhZnQtcmVud2VpLW1wbHMtYmlnLWxhYmVsLTAwICh3YXM6IFJl dmlldyBvZiBkcmFmdC1yZW53ZWktbXBscy1iZ3AtYmlnLWxhYmVsLTAwKQ0KDQoNCk9uIDE4IEp1 bHkgMjAxMyAyMDoyNCwgUGFibG8gRnJhbmsgPHBhYmxvaXNub3RAZ21haWwuY29tPG1haWx0bzpw YWJsb2lzbm90QGdtYWlsLmNvbT4+IHdyb3RlOg0KTm8gbWF0dGVyIGhvdyB5b3UgbG9vayBhdCBp dCwgaXQncyBhIGZ1bmRhbWVudGFsbHkgZGlmZmVyZW50IGZvcndhcmRpbmcgcGFyYWRpZ20uICBJ dCB3b24ndCBiZSBpbXBsZW1lbnRhYmxlIGluIHNvbWUgZXhpc3RpbmcgYW5kIGRlcGxveWVkIGhh cmR3YXJlLiAgU3VyZSwgTlBVLWJhc2VkIG9yIEZQR0EtYmFzZWQgZm9yd2FyZGluZyBoYXJkd2Fy ZSBjb3VsZCBpbXBsZW1lbnQgaXQgYnV0IHRoZSByZWFzb24gdGhhdCB0aGVyZSBhcmUgQVNJQ3Mg b3V0IHRoZXJlIHdpdGggaGFyZCBNUExTIGRhdGFwbGFuZXMgaXMgYmVjYXVzZSB0aGUgTVBMUyBk YXRhcGxhbmUgaXMgbWF0dXJlIGFuZCBoYXMgYmVlbiBhIGRlIGZhY3RvIHN0YW5kYXJkIGZvciBh IGxvbmcgdGltZS4gIE5vdywgaWYgeW91IHdhbnQgdG8gbWFrZSB0aGUgY2FzZSBmb3Igc29tZSBr aW5kIG9mICJNUExTdjYiLCBtYXliZSB5b3UnbGwgZmluZCBvdGhlcnMgd2lsbGluZyB0byBlbWJh cmsgb24gdGhhdCBzY2FyeSBhZHZlbnR1cmUuLi4NCg0KSSd2ZSBiZWVuIHdvcnJ5aW5nIGFib3V0 IHRoaXMgc2FtZSB0aGluZyB2ZXJ5IG9mdGVuIGxhdGVseS4gSSBoYXZlIHNhbWUgaXNzdWUgd2l0 aCBzZXZlcmFsIG90aGVyIG5ldyBNUExTIGVuaGFuY2VtZW50cyB3aGljaCBlc3NlbnRpYWxseSBt ZWFuIHdoZW4gbWFnaWMgbGFiZWwgaXMgaGl0LCB5b3VyIGJlaGF2aW9yIGNoYW5nZXMuDQoNCkkg dW5kZXJzdGFuZCByYXRpb25hbGUgd2h5IG1hbnkgb2YgdGhlIGVuaGFuY2VtZW50cyBhcmUgbmVl ZGVkLCBidXQgSSB3b25kZXIgaWYgZG9pbmcgJ01QTFN2Micgd291bGQgYmUgaW4gdGhlIGVuZCBi ZSBjbGVhbmVyIHNvbHV0aW9uLiBJZiB5b3UgY2Fubm90IHN1cHBvcnQgb2xkIEFTSUMgcGxhdGZv cm1zIGFuZCB5b3UgZXNzZW50aWFsbHkgbmVlZCBOUFUgYmFzZWQgcGxhdGZvcm0sIHRoZW4geW91 IG1pZ2h0IGFzIHdlbGwgYmUgYml0IG1vcmUgcHJvZ3Jlc3NpdmU/DQoNCi0tDQogICsreXR0aQ0K --_000_F061CEB6876F904F8EA6D6B92877731C2FB40B9Cdfweml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU2Fr dSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYW0gdmVyeSBpbnRlcmVzdGVkIGluIGtub3dpbmcgd2hhdCBhcmUgdGhv c2UgbmV3IE1QTFMgZW5oYW5jZW1lbnRzIHlvdSBhcmUgaGF2aW5nIGlzc3VlcyB3aXRoLiBDYW4g eW91IHNoYXJlIHRoZW0gd2l0aCB0aGlzIGNvbW11bml0eT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1QTFMgaGFzIGJl ZW4gYWxpdmUgZm9yIGFib3V0IDE1IHllYXJzLiBBIHRlZW5hZ2VyIG9mdGVuIGNoYW5nZXMgYW5k IGlzIGRpZmZlcmVudCBmcm9tIHdoZW4gaXQgd2FzIGJvcm4uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmljaGFyZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTYWt1IFl0dGkgW21haWx0bzpzYWt1QHl0dGkuZmld DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE5LCAyMDEzIDE6NDAgQU08YnI+DQo8 Yj5Ubzo8L2I+IFBhYmxvIEZyYW5rPGJyPg0KPGI+Q2M6PC9iPiBSaWNoYXJkIExpOyBtcGxzQGll dGYub3JnOyBNbGk7IE5hZ2VuZHJhIEt1bWFyIChuYWlrdW1hcik8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFttcGxzXSBSZXZpZXcgb2YgZHJhZnQtcmVud2VpLW1wbHMtYmlnLWxhYmVsLTAwICh3 YXM6IFJldmlldyBvZiBkcmFmdC1yZW53ZWktbXBscy1iZ3AtYmlnLWxhYmVsLTAwKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE4IEp1bHkgMjAxMyAy MDoyNCwgUGFibG8gRnJhbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpwYWJsb2lzbm90QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnBhYmxvaXNub3RAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8gbWF0dGVyIGhvdyB5 b3UgbG9vayBhdCBpdCwgaXQncyBhIGZ1bmRhbWVudGFsbHkgZGlmZmVyZW50IGZvcndhcmRpbmcg cGFyYWRpZ20uICZuYnNwO0l0IHdvbid0IGJlIGltcGxlbWVudGFibGUgaW4gc29tZSBleGlzdGlu ZyBhbmQgZGVwbG95ZWQgaGFyZHdhcmUuICZuYnNwO1N1cmUsIE5QVS1iYXNlZCBvciBGUEdBLWJh c2VkIGZvcndhcmRpbmcgaGFyZHdhcmUgY291bGQgaW1wbGVtZW50IGl0IGJ1dCB0aGUgcmVhc29u IHRoYXQNCiB0aGVyZSBhcmUgQVNJQ3Mgb3V0IHRoZXJlIHdpdGggaGFyZCBNUExTIGRhdGFwbGFu ZXMgaXMgYmVjYXVzZSB0aGUgTVBMUyBkYXRhcGxhbmUgaXMgbWF0dXJlIGFuZCBoYXMgYmVlbiBh IGRlIGZhY3RvIHN0YW5kYXJkIGZvciBhIGxvbmcgdGltZS4gJm5ic3A7Tm93LCBpZiB5b3Ugd2Fu dCB0byBtYWtlIHRoZSBjYXNlIGZvciBzb21lIGtpbmQgb2YgJnF1b3Q7TVBMU3Y2JnF1b3Q7LCBt YXliZSB5b3UnbGwgZmluZCBvdGhlcnMgd2lsbGluZyB0byBlbWJhcmsgb24gdGhhdCBzY2FyeQ0K IGFkdmVudHVyZS4uLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQpJJ3ZlIGJlZW4gd29ycnlpbmcgYWJvdXQgdGhpcyBzYW1lIHRoaW5n IHZlcnkgb2Z0ZW4gbGF0ZWx5LiBJIGhhdmUgc2FtZSBpc3N1ZSB3aXRoIHNldmVyYWwgb3RoZXIg bmV3IE1QTFMgZW5oYW5jZW1lbnRzIHdoaWNoIGVzc2VudGlhbGx5IG1lYW4gd2hlbiBtYWdpYyBs YWJlbCBpcyBoaXQsIHlvdXIgYmVoYXZpb3IgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0YW5kIHJhdGlvbmFsZSB3 aHkgbWFueSBvZiB0aGUgZW5oYW5jZW1lbnRzIGFyZSBuZWVkZWQsIGJ1dCBJIHdvbmRlciBpZiBk b2luZyAnTVBMU3YyJyB3b3VsZCBiZSBpbiB0aGUgZW5kIGJlIGNsZWFuZXIgc29sdXRpb24uIElm IHlvdSBjYW5ub3Qgc3VwcG9ydCBvbGQgQVNJQyBwbGF0Zm9ybXMgYW5kIHlvdSBlc3NlbnRpYWxs eSBuZWVkIE5QVSBiYXNlZCBwbGF0Zm9ybSwgdGhlbiB5b3UgbWlnaHQNCiBhcyB3ZWxsIGJlIGJp dCBtb3JlIHByb2dyZXNzaXZlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQombmJzcDsgJiM0MzsmIzQzO3l0dGkgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F061CEB6876F904F8EA6D6B92877731C2FB40B9Cdfweml510mbxchi_-- From renwei.li@huawei.com Thu Jul 18 17:25:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF8521E818E for ; Thu, 18 Jul 2013 17:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+XR8nl-DNH3 for ; Thu, 18 Jul 2013 17:25:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE921E818D for ; Thu, 18 Jul 2013 17:25:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO68868; Fri, 19 Jul 2013 00:24:57 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:23:58 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:24:55 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 17:24:51 -0700 From: Richard Li To: John E Drake , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt Thread-Index: AQHOg62nTIvk9ocqRkmfJtVas//WRJlrInMQ Date: Fri, 19 Jul 2013 00:24:51 +0000 Message-ID: References: <0182DEA5604B3A44A2EE61F3EE3ED69E2073EF8E@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E2073EF8E@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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: Fri, 19 Jul 2013 00:25:05 -0000 Hi John, Technically you certainly can do it that way. But if you do so, you would e= ither need a new protocol or change an existing protocol for the purpose of= notification.=20 On the other hand, in IP/PIM it is well and widely accepted that multicast = distribution trees are built up from the leaf to root. But in MPLS, the mul= ticast distribution tree (LSP) are built in a totally different ordering. I= am always struggling with why MPLS should be doing it in a different way f= rom PIM. If would be nice if MPLS could unify with PIM with respect to MDT = build-ups. In addition, the receiver-driven RSVP-TE also has additional benefits with = respect to MP2MP. Otherwise one need a full-meshed P2MP trees to implement = MP2MP. Regards, Richard -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, July 18, 2013 7:50 PM To: Richard Li; mpls@ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-lzj-mpls-receive= r-driven-multicast-rsvp-te-03.txt Richard, If one wanted to support leaf-initiated join, why wouldn't one simply have = the leaf send a notification (e.g., Notify) to the root requesting it to ex= tend the p2mp tree to the leaf using the existing P2MP procedures? The aut= hors of RFC4875 expected an application level notification to produce exact= ly this behavior. Yours Irrespectively, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Richard Li > Sent: Wednesday, July 17, 2013 8:39 AM > To: mpls@ietf.org > Subject: [mpls] FW: New Version Notification for draft-lzj-mpls-=20 > receiver-driven-multicast-rsvp-te-03.txt >=20 > Hi All! >=20 > We have updated our receiver-driven RSVP-TE draft. Your comments will=20 > be highly appreciated. >=20 > Regards, >=20 > Richard >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 01, 2013 6:17 AM > To: Telus Communications; Christian Jacquenet; Eduard Metz; Boris=20 > Zhang; Quintin zhao; Richard Li > Subject: New Version Notification for draft-lzj-mpls-receiver-driven-=20 > multicast-rsvp-te-03.txt >=20 >=20 > A new version of I-D,=20 > draft-lzj-mpls-receiver-driven-multicast-rsvp-te- > 03.txt > has been successfully submitted by Renwei Li and posted to the IETF=20 > repository. >=20 > Filename: draft-lzj-mpls-receiver-driven-multicast-rsvp-te > Revision: 03 > Title: Receiver-Driven Multicast Traffic-Engineered Label- > Switched Paths > Creation date: 2013-07-01 > Group: Individual Submission > Number of pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03.txt > Status: http://datatracker.ietf.org/doc/draft-lzj-mpls- > receiver-driven-multicast-rsvp-te > Htmlized: http://tools.ietf.org/html/draft-lzj-mpls-receiver- > driven-multicast-rsvp-te-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03 >=20 > Abstract: > This document describes extensions to Resource Reservation Protocol > - > Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven > Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to- > multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol=20 > Label > Switching (MPLS) and Generalized MPLS (GMPLS)networks. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From xuxiaohu@huawei.com Thu Jul 18 20:43:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FAE21F9C32; Thu, 18 Jul 2013 20:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87sV4Oje7Es0; Thu, 18 Jul 2013 20:43:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF2E411E8176; Thu, 18 Jul 2013 20:43:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVF06182; Fri, 19 Jul 2013 03:42:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 04:42:15 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 04:42:56 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 11:42:50 +0800 From: Xuxiaohu To: "nvo3@ietf.org" , L3VPN , "l2vpn@ietf.org" , "mpls@ietf.org" Thread-Topic: The possibility of using global MPLS labels as VNIs Thread-Index: Ac6DnNMgHvnlcn9VTo6g3UrBJiTzlQAkGO8Q Date: Fri, 19 Jul 2013 03:42:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6F4B@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] The possibility of using global MPLS labels as VNIs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 03:43:05 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IFh1eGlhb2h1DQo+ILeiy83K sbzkOiAyMDEzxOo31MIxOMjVIDE3OjU1DQo+IMrVvP7IyzogbnZvM0BpZXRmLm9yZzsgTDNWUE47 IGwydnBuQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+INb3zOI6IFtudm8zXSBUaGUgcG9zc2li aWxpdHkgb2YgdXNpbmcgZ2xvYmFsIE1QTFMgbGFiZWxzIGFzIFZOSXMNCj4gDQo+IEhpIGFsbCwN Cj4gDQo+IFRpbGwgbm93LCBpdCBzZWVtIHRoYXQgdGhlIG9ubHkgcmVtYWluaW5nIHRlY2huaWNh bCByZWFzb24gZm9yIHNvbWUgcGVvcGxlIHRvDQo+IHByZWZlciBWWExBTi9OVkdSRSBlbmNhcHN1 bGF0aW9uIGZvcm1hdCB0byBNQUMtaW4tTVBMUy1pbi1JUA0KPiBlbmNhcHN1bGF0aW9uIGZvcm1h dCBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGlzIHRoZSBmb3JtZXIgaGFzIGds b2JhbA0KPiBWTklzIHdoaWxlIHRoZSBsYXR0ZXIgZG9lc24ndCBoYXZlLiBJZiB0aGlzIHJlYXNv biBpcyB0cnVlLCB3aHkgY2FuJ3Qgd2UgY29uc2lkZXINCg0KT3IgdGhlIHJlYXNvbiBmb3IgcmVx dWlyaW5nIGdsb2JhbCBWTkkgaW4gdGhlIGRhdGEgcGFja2V0IGl0c2VsZiBpcyBmYWtlIG9yIGlu c2lnbmlmaWNhbnQ/IEkganVzdCBub3RpY2VkIHRoYXQgdGhlIE5WbzMgZGF0YSBwbGFuZSByZXF1 aXJlbWVudCBkb2MganVzdCBtZW50aW9uZWQgIi4uLlRoaXMgZmllbGQgTUFZIGJlIGFuIGV4cGxp Y2l0LCB1bmlxdWUgKHRvIHRoZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4pIHZpcnR1YWwgbmV0d29y ayBpZGVudGlmaWVyIChWTklEKSBvciBNQVkgZXhwcmVzcyB0aGUgbmVjZXNzYXJ5IGNvbnRleHQg aW5mb3JtYXRpb24gaW4gb3RoZXIgd2F5cyAoZS5nLiBhIGxvY2FsbHkgc2lnbmlmaWNhbnQgaWRl bnRpZmllcikuLi4iIEkgaGF2ZW4ndCBmb3VuZCBhbnkgZGVzY3JpcHRpb24gYWJvdXQgdGhlIHJl YXNvbiBmb3IgcmVxdWlyaW5nIGdsb2JhbCBWTkkgaW4gdGhlIGRhdGEgY2VudGVyIHBhY2tldCBp biB0aGUgTlZPMyByZWxhdGVkIGRvY3MuIFNob3VsZG4ndCB0aGUgcmVhc29uIGZvciByZXF1aXJp bmcgZ2xvYmFsIFZOSSBpbiB0aGUgZGF0YSBwYWNrZXQgYmUgaW52ZXN0aWdhdGVkIGJ5IE5WbzMg V0c/IFNpbmNlIGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gdGhlIGdhcCBhbmFseXNpcyB3b3Jr IHdoaWNoIHdvdWxkIGJlIHBlcmZvcm1lZCBvbiB0aGUgZXhpc3RpbmcgU1RBTkRBUkRJWkVEIGNh bmRpZGF0ZSBtZWNoYW5pc21zLCBJTUhPLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiB0 aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgZ2xvYmFsIE1QTFMgbGFiZWxzIHRvIGFjaGlldmUgdGhl IHNhbWUgZ29hbD8NCg0KPiBJbiBmYWN0LCB0aGVyZSBhcmUgbXVsdGlwbGUgcG9zc2libGUgd2F5 cyB0byBhY2hpZXZlIGdsb2JhbCBNUExTIGxhYmVsczoNCj4gDQo+IDEpIHRoZSBmaXJzdCB3YXkg aXMgdG8gYWxsb2NhdGUgYSBsYWJlbCBibG9jayBmcm9tIHRoZSBleGlzdGluZyBsYWJlbCBzcGFj ZSBhbmQgdXNlDQo+IGl0IGFzIGEgZ2xvYmFsIGxhYmVsIHNwYWNlIGZyb20gd2hpY2ggVlBOIGxh YmVscyBhcmUgYXNzaWduZWQuIEluIHRoaXMgd2F5LCB0aGUNCj4gVlBOIGxhYmVsIG9mIGEgZ2l2 ZW4gVk4gaXMgc2V0IHRvIHRoZSBjb3JyZXNwb25kaW5nIFZOSS4gVGhpcyBhcHByb2FjaCBkb2Vz bid0DQo+IHJlcXVpcmUgYW55IGNoYW5nZSB0byB0aGUgZGF0YSBwbGFuZS4NCj4gMikgdGhlIHNl Y29uZCB3YXkgaXMgdG8gYWxsb2NhdGUgYSBzZXBhcmF0ZSBwcm90b2NvbCB0eXBlIGNvZGUgZm9y IHRoZSBnbG9iYWwNCj4gTVBMUyBsYWJlbCBzbyBhcyB0byBkaXN0aW5ndWlzaCBnbG9iYWwgbGFi ZWxzIGZyb20gZG93bnN0cmVhbS1hc3NpZ25lZCBhbmQNCj4gdXBzdHJlYW0tYXNzaWduZWQgbGFi ZWxzLiBUaGlzIGFwcHJvYWNoIHJlcXVpcmVzIHNvbWUgY2hhbmdlIHRvIHRoZSBkYXRhDQo+IHBs YW5lIG9mIFBFIHJvdXRlcnMuDQo+IDMpIHRoZSB0aGlyZCB3YXkgaXMgdG8gcmVzZXJ2ZSBhIHNw ZWNpYWwgcHVycG9zZSBsYWJlbCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBsYWJlbA0KPiBiZWxvdyBz dWNoIHNwZWNpYWwgcHVycG9zZSBsYWJlbCBpcyBhIGdsb2JhbCBsYWJlbC4gVGhpcyBhcHByb2Fj aCByZXF1aXJlcyBzb21lDQo+IGNoYW5nZSB0byB0aGUgZGF0YSBwbGFuZSBvZiBQRSByb3V0ZXJz IGFzIHdlbGwuDQo+IA0KPiBJbiBjYXNlIDIpIGFuZCAzKSwgdGhlIGdsb2JhbCBsYWJlbCBzcGFj ZSBtZW50aW9uZWQgYWJvdmUgY291bGQgYmUgYSBsYWJlbCBzcGFjZQ0KPiBkZWRpY2F0ZWQgZm9y IFZOSSBvciBhIGxhYmVsIHNwYWNlIHdoaWNoIGlzIHNoYXJlZCB3aXRoIG90aGVyIGFwcGxpY2F0 aW9ucyAoZS5nLiwNCj4gc2VnbWVudCByb3V0aW5nKS4NCj4gDQo+IEFueSBjb21tZW50cz8NCj4g DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From Alexander.Vainshtein@ecitele.com Fri Jul 19 01:01:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A077121E810E for ; Fri, 19 Jul 2013 01:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGybt+4HPHDp for ; Fri, 19 Jul 2013 01:01:52 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.170]) by ietfa.amsl.com (Postfix) with ESMTP id DAA1921E811F for ; Fri, 19 Jul 2013 01:01:51 -0700 (PDT) Received: from [85.158.137.99:27801] by server-10.bemta-3.messagelabs.com id 97/96-02530-E62F8E15; Fri, 19 Jul 2013 08:01:50 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1374220895!14989397!5 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16113 invoked from network); 19 Jul 2013 08:01:50 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jul 2013 08:01:50 -0000 X-AuditID: 93eaf2e7-b7f186d000003872-4e-51e8f26d4181 Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id C0.97.14450.D62F8E15; Fri, 19 Jul 2013 11:01:49 +0300 (IDT) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 11:01:48 +0300 From: Alexander Vainshtein To: "S. Davari" Thread-Topic: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gLBHC6QAAcCVIAAJx6oWg== Date: Fri, 19 Jul 2013 08:01:48 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42KZ/OrTF93cTy8CDY5OkbY4+LyJ0eLW0pWs DkweS5b8ZPKYNeswUwBTVAOjTWJeXn5JYkmqQkpqcbKtUkBRZllicqWSQmaKrZKhkkJBTmJy am5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3VfIM9te1sDC11DVUslNTNjS25grJ yCxWSNXNTczMUchNLS5OTE9VAIokbGHOeLLyJ1PBfr2Kh72trA2Md1S7GDk5JARMJFZem88O YYtJXLi3nq2LkYtDSOAgo8SaFT1MIAkhgaOMEvdmpoHYbAK2EptW32UDsUUEVCSWbl/KAmIz C2RLzJs/lbWLkYNDWMBZ4v+yOogSF4kPs48yQ9hOEs929YONZBFQlfj+uJUVxOYVCJD4ensS E8TeQ4wSn7+uA5vJCbSr7eVxsOMYgY77fmoNE8QucYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQ trzE5q2PWSHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gg6iUlDq64wTKBUXwWkhWzkLTPQtI+ C0n7AkaWVYyimTkFJUm56QaGeqnJmSWpOal6yfm5mxghaeT5DsZf81UOMboCPT6RWYo7OR+Y hvJK4o0NDHBzlMR5lzeE+wsJpAPTTXZqakFqUXxRaU5q8SFGJg5OqQZG03WO/5kirviwPjP8 nML613jFwQLNdeLrH90Nm3Eu+TpL7h3/xW+PFbSH3dPrSz2opdqzjOVw4NffkutEnF5XvF+T 1LNuapT+PcEna+uEFdc/CfrIVPNDWuWVPueV7Dvs08xueq7w9pYOevh8xoMTehWyy4Rdnx5e sjAgeuf2Hz/TMidf8DcqV2Ipzkg01GIuKk4EAGL0fE8bAwAA Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 08:01:57 -0000 Shahram hi! Lots of thanks for a prompt and informative response. Please see some comments inline below. Regards, Sasha ________________________________________ From: S. Davari [davarish@yahoo.com] Sent: Thursday, July 18, 2013 6:11 PM To: Alexander Vainshtein Cc: Yaakov Stein; tictoc@ietf.org; mpls@ietf.org Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Hi Sasha, We had considered using a reserved label and it was rejected. Perhaps we sho= uld have documented it in the draft. [[Sasha]] Yes, indeed. The issues are: 1) reserved label is not backward compatible with existing routers. One of t= he requirements is that routers that are not PTP aware can just switch the p= acket normally. Using a reserved label can't achieve this requirement, sinc= e routers that don't understand it will drop it or sent it to CPU. [[Sasha]] Is not this concern applicable to any new reserved label? And ro= uters that use network processors as forwarding engines could easily overcom= e this issue by upgrading their microcode. But I agree that this is a valid concern. 2) there are multiple encapsulations for PTP such as Ethernet with optional= VLAN or UDP/IP. An intermediate LSR doesn't know the whether the payload is= IP or Ethernet or VLAN. This means for each PTP encapsulation type you prob= ably need a different reserved label. [[Sasha]] IMHO and FWIW support of PTP over UDP/IP would suffice in the abso= lute majority of cases. 3) the area director has asked us to create a more generalized way of carryi= ng timing over MPLS to be usable with new timing protocols that need TC. Usi= ng reserved label would require different reserved label for each new timing= protocol. [[Sasha]] I do not think so. "New timing protocols" would be hopefully still= run on top of UDP/IP and hence could be easily identifiable by looking at t= he appropriate UDP port. 4) the extended reserved label draft is fairly new and didn't exist when thi= s draft was progressing. [[Sasha]] This is definitelt true. But it does not justify (for me) setting= up dedicated LSPs for timing distribution. Regards, Shahram On Jul 18, 2013, at 3:15 AM, Alexander Vainshtein wrote: > Hi all, > I do not support this draft in its present form. > IMHO and FWIW the idea of setting up dedicated "timing LSPs" for carrying= just the PTP messages does not match the MPLS data plane architecture as de= scribed in RFC 3031. > > To the best of my understanding, the proper way to request any kind of spe= cial processing (including the processing required for accurate synchronizat= ion) in MPLS is by defining a suitable "alert label". Such a label could be= pushed on top of the label stack by the LSR that is the originator of the p= acket that requires special processing. The LER that receives a packet with= such an alert label would: > - treat this label as a request for special processing > - use the remainder of the label stack to define the forwarding dispositio= n of the packet > - if the packet were to be forwarded as a labeled packet, the same "alert= label" would be pushed on top of the label stack at egress. > > (This behavior has been defined for the "router alert" label in RFC 3032). > > I am not sure if the WG has ever considered such an alternative. I believe= (but I may be wrong) that it has been mentioned in some private discussion= s, but rejected due to the fact that reserved labels were considered a scarc= e resource so that the chances to obtain one from the IANA were slim. > > The situation is hopefully going to change with the advance of an extended= space of "special purpose" labels as defined in http://tools.ietf.org/html/= draft-ietf-mpls-special-purpose-labels-03. With at least 240 special purpose= labels available for the Standards Action, it would be easy to obtain a "Sy= nchronization Alert" label that would indicate the need for the correspondin= g special processing without creation and maintenance of dedicated "timing L= SPs", providing dedicated protection schemes for such LSPs etc. It would onl= y greatly simplify the HW design because the packets requiring special proce= ssing would be easily identifiable without any special configuration (the "S= ynchronization Alert" label would follow the "Extension Label" indicator and= have a fixed IANA-allocated value). > > My 2c, > Sasha > >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf= Of >> Yaakov Stein >> Sent: Thursday, July 04, 2013 12:21 PM >> To: tictoc@ietf.org >> Cc: mpls@ietf.org >> Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls >> >> We hereby announce a TICTOC working group last call for draft-ietf-tictoc= - >> 1588overmpls >> (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05). >> >> Please send indications of support, as well as any remaining technical >> comments, to the list. >> >> Due to the MPLS aspects of this draft this email is also being sent to th= e MPLS >> WG, >> but please conduct all discussion on the TICTOC working group mailing lis= t. >> >> This working group last call will end on July 19, 2013. >> >> Y(J)S >> >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc > > > This e-mail message is intended for the recipient only and contains inform= ation 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 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 saku@ytti.fi Fri Jul 19 01:02:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D1A11E8249 for ; Fri, 19 Jul 2013 01:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNKmEaOSqDcK for ; Fri, 19 Jul 2013 01:02:54 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 09AED11E8246 for ; Fri, 19 Jul 2013 01:02:49 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so5617950oag.30 for ; Fri, 19 Jul 2013 01:02:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2nf2ZP1lI3bVtYk+EILEc4q2aeyfDjqPldXPLWxduvg=; b=Ik+aZI5JjcpmWURCgegAxo3ZikDmZ8B3ohNGKJtKOisqqmuALKdx3PV9sx7MY5Awu1 gGfz2hKKU4A+X+MQJjqi6iWNVCdKFse5xLhY04vp7Bx7xAJ1ZAtpHfdZREdgN7kUnF69 +CeimcFQUoP1RUGiRbaNgGJa/eO9OCu5MufoKPgm7FdxvbcPvcBQC6l07N3pewVhfUaW aF/AUXiSqEIoDW6aPDscWLzcw4N3TatyIw1ikp4eU/iRM97POiGd+QhLrB7wxsK7QMaD zRYTHx9y83ovuqhvNRiG/TK61IZf44XhUj2lUVpd8XZt9yNbYd/K+Zn8Yy5vZtW2Fdc9 eZew== MIME-Version: 1.0 X-Received: by 10.60.125.100 with SMTP id mp4mr16970662oeb.60.1374220964953; Fri, 19 Jul 2013 01:02:44 -0700 (PDT) Received: by 10.182.45.105 with HTTP; Fri, 19 Jul 2013 01:02:44 -0700 (PDT) In-Reply-To: References: <51D6A11B.2010708@gmail.com> <30677.1373039405@erosen-linux> <47E76F08F1BCF5458111C1939C7B9C46102640E3@xmb-rcd-x03.cisco.com> <4A6CE49E6084B141B15C0713B8993F281BE8D17E@SJEXCHMB12.corp.ad.broadcom.com> Date: Fri, 19 Jul 2013 11:02:44 +0300 Message-ID: From: Saku Ytti To: Richard Li Content-Type: multipart/alternative; boundary=047d7b3a83d675f24904e1d8c0d6 X-Gm-Message-State: ALoCoQmpKNtuW6S8RblowhhyO/j+u6WbHu5km8psXrrlBmmft41k0fG80h1GsSYlNoJyW591ImOD Cc: Mli , "mpls@ietf.org" , "Nagendra Kumar \(naikumar\)" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:02:59 -0000 --047d7b3a83d675f24904e1d8c0d6 Content-Type: text/plain; charset=UTF-8 On 19 July 2013 02:57, Richard Li wrote: Hello Richard, I am very interested in knowing what are those new MPLS enhancements you > are having issues with. Can you share them with this community? > Top of my head draft-ietf-mpls-special-purpose-labels and this draft-renwei-mpls-big-label. > MPLS has been alive for about 15 years. A teenager often changes and is > different from when it was born. > Absolutely, I don't disagree that the drafts don't solve real issue. To me, inability to capitalize on the new features on old ASIC gear and the fact that deployed NPU plaforms (Huawei NE/CX, Cisco ASR9k, Juniper MX, Alcatel SR etc) all could today support pretty much arbitrary half-sane wire-format for MPLS, seems to indicate that it might be useful to review what would be benefits of more progressive changes to wire-format. Some issues I'd like to handle: a) retaining label history b) low byte overhead (this is MPLS's major selling point against IP tunnels. Our TTL and COS are redundant repeated information for majority of use-cases) c) remove need for transit P duck-typing/guessing payload (this makes P more complex than it must be) d) extendable by design (today we essentially need 8B for every 1-4B we want to add) e) increased label space f) coexistance with MPLSv1 for gradual/partial deployment -- ++ytti --047d7b3a83d675f24904e1d8c0d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 19 July 2013 02:57, Richard Li <renwei.li@huawei.com> = wrote:

Hello Richa= rd,

I am very interested in knowing what are those new MPLS enhancem= ents you are having issues with. Can you share them with this community?

Top of my head =C2=A0draft-ietf-mpls-special-purpose-labe= ls and this=C2=A0draft-renwei-mpls-big-label.

MPLS has been alive for about 15 years. A teenager often changes= and is different from when it was born.

Absolutely, I don't disagree that the drafts don't solve real= issue.=C2=A0

To me, inability to capitalize on the new features on old ASIC gear= and the fact that deployed NPU plaforms (Huawei NE/CX, Cisco ASR9k, Junipe= r MX, Alcatel SR etc) all could today support pretty much arbitrary half-sa= ne wire-format for MPLS, seems to indicate that it might be useful to revie= w what would be benefits of more progressive changes to wire-format.

Some issues= I'd like to handle:

a) retaining label history
b) low byte overhead (this is MPLS's major selling point against IP tun= nels. Our TTL and COS are redundant repeated information for majority of us= e-cases)
c) remove need for transit P duck-= typing/guessing payload (this makes P more complex than it must be)
d) extendable by design (today we essentially ne= ed 8B for every 1-4B we want to add)
e) inc= reased label space
f) coexistance with MPLS= v1 for gradual/partial deployment


--
=C2=A0 ++ytti
--047d7b3a83d675f24904e1d8c0d6-- From manav.bhatia@alcatel-lucent.com Fri Jul 19 01:11:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8241721F9684; Fri, 19 Jul 2013 01:11:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELZluUtnJIFm; Fri, 19 Jul 2013 01:11:44 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1333E21E80F2; Fri, 19 Jul 2013 01:11:43 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6J8Besq019775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Jul 2013 03:11:41 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r6J8BdS8000783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 04:11:39 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 19 Jul 2013 04:11:39 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Fri, 19 Jul 2013 16:11:36 +0800 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein , "S. Davari" Thread-Topic: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9QwI7T5dRkJik6LxjKI9Ots/gLBHC6QAAcCVIAAJx6oWgAAXkAw Date: Fri, 19 Jul 2013 08:11:35 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 08:11:53 -0000 Hi Sasha, > 1) reserved label is not backward compatible with existing routers. One > of the requirements is that routers that are not PTP aware can just > switch the packet normally. Using a reserved label can't achieve this > requirement, since routers that don't understand it will drop it or > sent it to CPU. > [[Sasha]] Is not this concern applicable to any new reserved label? > And routers that use network processors as forwarding engines could > easily overcome this issue by upgrading their microcode. > But I agree that this is a valid concern. This is a huge concern because not all routers use network processors that = can be reprogrammed. The current solution works with any router that can set up an MPLS path. >=20 > 2) there are multiple encapsulations for PTP such as Ethernet with > optional VLAN or UDP/IP. An intermediate LSR doesn't know the whether > the payload is IP or Ethernet or VLAN. This means for each PTP > encapsulation type you probably need a different reserved label. > [[Sasha]] IMHO and FWIW support of PTP over UDP/IP would suffice in the > absolute majority of cases. >=20 > 3) the area director has asked us to create a more generalized way of > carrying timing over MPLS to be usable with new timing protocols that > need TC. Using reserved label would require different reserved label > for each new timing protocol. > [[Sasha]] I do not think so. "New timing protocols" would be hopefully > still run on top of UDP/IP and hence could be easily identifiable by > looking at the appropriate UDP port. That's bordering on speculation. The current solution is oblivious to a new= timing protocol. Today it can be used for both PTP and NTP. With reserved = labels, we will need a new label (and a firmware upgrade) each time a new p= rotocol needs to be supported.=20 >=20 > 4) the extended reserved label draft is fairly new and didn't exist > when this draft was progressing. > [[Sasha]] This is definitelt true. But it does not justify (for me) > setting up dedicated LSPs for timing distribution. No offence, am trying to understand - whats the problem that you see with s= etting up a dedicated LSP for timing distribution? Cheers, Manav From mach.chen@huawei.com Fri Jul 19 02:08:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A476D21F8468; Fri, 19 Jul 2013 02:08:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHH31pmZ3zol; Fri, 19 Jul 2013 02:08:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9E11E82A4; Fri, 19 Jul 2013 02:08:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATP02904; Fri, 19 Jul 2013 09:08:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 10:07:17 +0100 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 10:07:59 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 17:06:39 +0800 From: Mach Chen To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-chen-mpls-source-label-00.txt Thread-Index: AQHOgUHklRFn2eN2B02kHgmIfuCDN5lrRdWQ Date: Fri, 19 Jul 2013 09:06:39 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "status@ietf.org" Subject: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-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, 19 Jul 2013 09:08:11 -0000 SGkgTVBMU2VycywNCg0KV2UganVzdCB1cGxvYWRlZCBhIGRyYWZ0IHRoYXQgaW50cm9kdWNlcyBh IGNvbmNlcHQgb2YgTVBMUyBTb3VyY2UgTGFiZWwgKFNMKSwgdGhlIHNvdXJjZSBsYWJlbCBpcyBl bmNvZGVkIGluIHRoZSBsYWJlbCBzdGFjayAoaW1tZWRpYXRlbHkgZm9sbG93cyBhIHNwZWNpYWwg cHVycG9zZSBsYWJlbCApIGFuZCB1c2VkIHRvIGlkZW50aWZ5IHRoZSBpbmdyZXNzIExTUiBvZiBh biBMU1AuIFRoZSBzb3VyY2UgbGFiZWwgYXBwbGllcyB0byB0aGUgc2NlbmFyaW9zIHdoZXJlIHNv dXJjZSBpZGVudGlmaWNhdGlvbiBpcyByZXF1aXJlZCAoZS5nLiwgaW4gb3JkZXIgZm9yIGNvdW50 aW5nIGFuZCBiaWxsaW5nKS4gRm9yIGV4YW1wbGUsIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IGZv ciBNUExTIG5ldHdvcmssIFRyYWZmaWMgTWF0cml4IG1lYXN1cmVtZW50IGFuZCBjb2xsZWN0aW9u LCBldGMuDQoNCldlJ2QgYXBwcmVjaWF0ZSB0aGF0IHlvdSBjb3VsZCB0YWtlIGEgbG9vayBhdCB0 aGUgZHJhZnQuIEFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbiBhcmUgd2VsY29tZSENCg0KQlRX LCBJIGNjIHRoZSBTVEFUVVMgbGlzdCBmb3IgdGhlIHBlb3BsZSB3aG8gbWF5IGhhdmUgaW50ZXJl c3QsIHNpbmNlIHRoZSBzZWdtZW50IHJvdXRpbmcgcmVxdWlyZXMgdG8gcHJlc2VydmUgdGhlIGlu Z3Jlc3MgdG8gYSBkb21haW4gZm9yIGFjY291bnRpbmcgYW5kIGJpbGxpbmcgcHVycG9zZSwgdGhl IHNvdXJjZSBsYWJlbCBjYW4gaGVscCBoZXJlLiANCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAx NSwgMjAxMyA1OjU4IFBNDQpUbzogTGl6aGVuYmluOyBNYWNoIENoZW47IFh1eGlhb2h1OyBYdXhp YW9odTsgTHV5dWFuIEZhbmc7IE1hY2ggQ2hlbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsLTAwLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsLTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNYWNoKEd1b3lpKSBDaGVuIGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtY2hlbi1tcGxz LXNvdXJjZS1sYWJlbA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgTXVsdGlQcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgKE1QTFMpIFNvdXJjZSBMYWJlbA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDct MTUNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0K VVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1jaGVuLW1wbHMtc291cmNlLWxhYmVsLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tbXBscy1zb3VyY2UtbGFiZWwNCkh0 bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1tcGxz LXNvdXJjZS1sYWJlbC0wMA0KDQoNCkFic3RyYWN0Og0KICAgQW4gTXVsdGlQcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgKE1QTFMpIGxhYmVsIGlzIG9yaWdpbmFsbHkgZGVmaW5lZA0KICAgdG8gaWRl bnRpZnkgYSBGb3J3YXJkaW5nIEVxdWl2YWxlbmNlIENsYXNzIChGRUMpLCBhIHBhY2tldCBpcw0K ICAgYXNzaWduZWQgdG8gYSBzcGVjaWZpYyBGRUMgYmFzZWQgb24gaXRzIG5ldHdvcmsgbGF5ZXIg ZGVzdGluYXRpb24NCiAgIGFkZHJlc3MuICBJdCdzIGRpZmZpY3VsdCBvciBldmVuIGltcG9zc2li bGUgdG8gZGVyaXZlIHRoZSBzb3VyY2UNCiAgIGluZm9ybWF0aW9uIGZyb20gdGhlIGxhYmVsLiAg Rm9yIHNvbWUgYXBwbGljYXRpb25zLCBzb3VyY2UNCiAgIGlkZW50aWZpY2F0aW9uIGlzIGEgY3Jp dGljYWwgcmVxdWlyZW1lbnQuICBGb3IgZXhhbXBsZSwgcGVyZm9ybWFuY2UNCiAgIG1vbml0b3Jp bmcsIHRyYWZmaWMgbWF0cml4IG1lYXN1cmVtZW50IGFuZCBjb2xsZWN0aW9uLCB3aGVyZSB0aGUN CiAgIG1vbml0b3Jpbmcgbm9kZSBuZWVkcyB0byBpZGVudGlmeSB3aGVyZSBhIHBhY2tldCB3YXMg c2VudCBmcm9tLg0KDQogICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIGNvbmNlcHQgb2Yg U291cmNlIExhYmVsIChTTCkgdGhhdCBpcw0KICAgY2FycmllZCBpbiB0aGUgbGFiZWwgc3RhY2sg YW5kIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGluZ3Jlc3MgTGFiZWwNCiAgIFN3aXRjaGluZyBSb3V0 ZXIgKExTUikgb2YgYW4gTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKS4NCg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From stbryant@cisco.com Fri Jul 19 03:33:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A835111E8106; Fri, 19 Jul 2013 03:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw1yyh0s3OvU; Fri, 19 Jul 2013 03:32:52 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9611E8108; Fri, 19 Jul 2013 03:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=934; q=dns/txt; s=iport; t=1374229960; x=1375439560; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kbLTsOiA/6mYyEfmhU0e+mF9JzHHEaZn4xDb/NE9uA4=; b=f6g3IZ4qldvIdlimGAuZl7u9YsDKMxiM3qT1g2xWzKbmMxWSUfpKwpQ7 1/4tfG66b52cTFa1rNT8HUlm4/yR6eWdF7EdSjw18trGxiLZXlF2l90QX xKheelagXZb2sCSK8iwOtaAId+NmX+921WQ9YQcTXdt1uS7ByZYqyWK4y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADAV6VGQ/khR/2dsb2JhbABagwa+VIJ2gREWdIIkAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQEXh3W2S45qgSUHg3wDl12RTYMTgWk X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="16066535" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 19 Jul 2013 10:32:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6JAWXh0025905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 10:32:34 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6JAWV6X012099; Fri, 19 Jul 2013 11:32:32 +0100 (BST) Message-ID: <51E915BF.6020308@cisco.com> Date: Fri, 19 Jul 2013 11:32:31 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls 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, 19 Jul 2013 10:33:01 -0000 On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: > Hi Sasha, > >> 1) reserved label is not backward compatible with existing routers. One >> of the requirements is that routers that are not PTP aware can just >> switch the packet normally. Using a reserved label can't achieve this >> requirement, since routers that don't understand it will drop it or >> sent it to CPU. >> [[Sasha]] Is not this concern applicable to any new reserved label? >> And routers that use network processors as forwarding engines could >> easily overcome this issue by upgrading their microcode. >> But I agree that this is a valid concern. > This is a huge concern because not all routers use network processors that can be reprogrammed. > > The current solution works with any router that can set up an MPLS path. Really? Surely the LSR needs to know that on seeing a label in the FEC it needs to timestamp the packet. Stewart From gregory.mirsky@ericsson.com Fri Jul 19 04:27:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E600A11E8104; Fri, 19 Jul 2013 04:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK5KkCLQgs9t; Fri, 19 Jul 2013 04:27:33 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABA511E8105; Fri, 19 Jul 2013 04:27:28 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-69-51e9229ec68b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E1.1F.31362.E9229E15; Fri, 19 Jul 2013 13:27:27 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 07:27:26 -0400 From: Gregory Mirsky To: Mach Chen , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-00.txt Thread-Index: AQHOgUHklRFn2eN2B02kHgmIfuCDN5lrRdWQgACViyA= Date: Fri, 19 Jul 2013 11:27:26 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6A0122@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B6A0122eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPrO58pZeBBq8WSlhcWCtscWvpSlaL 180XmRyYPVqOvGX1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxvNZN5kKvoVU/P37nL2BcalHFyMn h4SAicSOa0+ZIWwxiQv31rOB2EICRxklDuzk6GLkArKXM0pcOboJLMEmYCTxYmMPO4gtIuAq MWfjZlYQm1lAXWJhaxMTiC0sECVx+H8XC0RNtMThs3OZIGwrib/PJgLN4eBgEVCV+DK9ACTM K+ArsW3JUiaIvaESm/Z9ZAcp4RQIk3iw3x4kzAh02vdTa5ggNolL3HoynwniZAGJJXvOQ50v KvHy8T9WCFtZ4vucRywQ9fkS99Z/YINYJShxcuYTlgmMorOQjJqFpGwWkjKIuI7Egt2f2CBs bYllC18zw9hnDjxmQhZfwMi+ipGjtDi1LDfdyHATIzCyjkmwOe5gXPDJ8hCjNAeLkjjvBr0z gUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYBY4fv13+Y3Xj0oy4e8Uudv9bBLU05rj/+h+y PnXL12q743nBqjzHdgv9kFuVvd14ReUKkyx38T8/714+ft4lLo29S5A31XDj9PrNnd7MGR+1 CzZzy7Ikz+j4lGtvr999WcZpgp+MAhfXiR+1+0wvrN/5aeqFbQvu1l06y3r2YUCFsw3XCp5A JZbijERDLeai4kQAJ+osxnoCAAA= Cc: "status@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-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, 19 Jul 2013 11:27:39 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B6A0122eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, authors and et. al, very interesting idea, please find my comments and questions below: * I think that you propose SL for MPLS networks that permit label mer= ge. But even for such networks, as I think, we could use MEP ID TLV in OAM = packets to identify the source. Yes, that would not help much with passive = OAM but will work for active PM. * Since SL being defined with scope of a single administrative domain= MS-PW example in section 1 might not be applicable as SL would not be of m= uch help. * I don't think that RFC 6374 and its LM in particular are specifical= ly targetted towards passive method of PM. * I don't think that PM measurement at intermeddiate LSR can be effec= tively used to avoid congested path. Consider that LSR is downstream of a c= ongested segment and would need to notify the upstream LSR or LER about ide= ntified congestion (ECN) in order to take any action. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mac= h Chen Sent: Friday, July 19, 2013 2:07 AM To: mpls@ietf.org Cc: status@ietf.org Subject: [mpls] FW: New Version Notification for draft-chen-mpls-source-lab= el-00.txt Hi MPLSers, We just uploaded a draft that introduces a concept of MPLS Source Label (SL= ), the source label is encoded in the label stack (immediately follows a sp= ecial purpose label ) and used to identify the ingress LSR of an LSP. The s= ource label applies to the scenarios where source identification is require= d (e.g., in order for counting and billing). For example, Performance Measu= rement for MPLS network, Traffic Matrix measurement and collection, etc. We'd appreciate that you could take a look at the draft. Any comments and s= uggestion are welcome! BTW, I cc the STATUS list for the people who may have interest, since the s= egment routing requires to preserve the ingress to a domain for accounting = and billing purpose, the source label can help here. Best regards, Mach -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 15, 2013 5:58 PM To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen Subject: New Version Notification for draft-chen-mpls-source-label-00.txt A new version of I-D, draft-chen-mpls-source-label-00.txt has been successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. Filename: draft-chen-mpls-source-label Revision: 00 Title: MultiProtocol Label Switching (MPLS) Source Label Creation date: 2013-07-15 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-chen-mpls-source= -label-00.txt Status: http://datatracker.ietf.org/doc/draft-chen-mpls-source-lab= el Htmlized: http://tools.ietf.org/html/draft-chen-mpls-source-label-00 Abstract: An MultiProtocol Label Switching (MPLS) label is originally defined to identify a Forwarding Equivalence Class (FEC), a packet is assigned to a specific FEC based on its network layer destination address. It's difficult or even impossible to derive the source information from the label. For some applications, source identification is a critical requirement. For example, performance monitoring, traffic matrix measurement and collection, where the monitoring node needs to identify where a packet was sent from. This document introduces the concept of Source Label (SL) that is carried in the label stack and used to identify the ingress Label Switching Router (LSR) of an Label Switched Path (LSP). The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B6A0122eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mach, authors and et. al,
very interesting idea, please find my comments and questions below:
  • I think that you propose SL for MPLS networks that permit label merge. = But even for such networks, as I think, we could use MEP ID TLV in OAM pack= ets to identify the source. Yes, that would not help much with passive OAM = but will work for active PM.
  • Since SL being defined with scope of a= single administrative domain MS-PW example in section 1 might not be appli= cable as SL would not be of much help.
  • I don't think that RFC 6374 = and its LM in particular are specifically targetted towards passive method = of PM.
  • I don't think that PM measurement at intermeddiate LSR can b= e effectively used to avoid congested path. Consider that LSR is downstream= of a congested segment and would need to notify the upstream LSR or LER ab= out identified congestion (ECN) in order to take any action.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On Beh= alf Of Mach Chen
Sent: Friday, July 19, 2013 2:07 AM
To: mpls@ietf.org
Cc: status@ietf.org
Subject: [mpls] FW: New Version Notification for draft-chen-mpls-sourc= e-label-00.txt
 
Hi MPLSers,
 
We just uploaded a draft that introduces a concept of MPLS Source Labe= l (SL), the source label is encoded in the label stack (immediately follows= a special purpose label ) and used to identify the ingress LSR of an LSP. = The source label applies to the scenarios where source identification is required (e.g., in order for count= ing and billing). For example, Performance Measurement for MPLS network, Tr= affic Matrix measurement and collection, etc.
 
We'd appreciate that you could take a look at the draft. Any comments = and suggestion are welcome!
 
BTW, I cc the STATUS list for the people who may have interest, since = the segment routing requires to preserve the ingress to a domain for accoun= ting and billing purpose, the source label can help here.
 
Best regards,
Mach
 
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 15, 2013 5:58 PM
To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen
Subject: New Version Notification for draft-chen-mpls-source-label-00.= txt
 
 
A new version of I-D, draft-chen-mpls-source-label-00.txt
has been successfully submitted by Mach(Guoyi) Chen and posted to the<= /div>
IETF repository.
 
Filename:        draft-chen-mpls-so= urce-label
Revision:        00
Title:           Mul= tiProtocol Label Switching (MPLS) Source Label
Creation date:   2013-07-15
Group:           Ind= ividual Submission
Number of pages: 12
 
 
Abstract:
   An MultiProtocol Label Switching (MPLS) label is original= ly defined
   to identify a Forwarding Equivalence Class (FEC), a packe= t is
   assigned to a specific FEC based on its network layer des= tination
   address.  It's difficult or even impossible to deriv= e the source
   information from the label.  For some applications, = source
   identification is a critical requirement.  For examp= le, performance
   monitoring, traffic matrix measurement and collection, wh= ere the
   monitoring node needs to identify where a packet was sent= from.
 
   This document introduces the concept of Source Label (SL)= that is
   carried in the label stack and used to identify the ingre= ss Label
   Switching Router (LSR) of an Label Switched Path (LSP).
 
 
 
 
 
The IETF Secretariat
 
_______________________________________________
mpls mailing list
mpls@ietf.org
 
 --_000_7347100B5761DC41A166AC17F22DF1121B6A0122eusaamb103erics_-- From jdrake@juniper.net Fri Jul 19 06:12:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C6C21E808B for ; Fri, 19 Jul 2013 06:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwTDqcGB28ov for ; Fri, 19 Jul 2013 06:12:43 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 75D5921E80AB for ; Fri, 19 Jul 2013 06:12:43 -0700 (PDT) Received: from mail93-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE039.bigfish.com (10.243.66.104) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 13:12:42 +0000 Received: from mail93-co1 (localhost [127.0.0.1]) by mail93-co1-R.bigfish.com (Postfix) with ESMTP id BA7FFA001BB for ; Fri, 19 Jul 2013 13:12:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz9371I936eI542Iec9I1432I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail93-co1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=jdrake@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail93-co1 (localhost.localdomain [127.0.0.1]) by mail93-co1 (MessageSwitch) id 1374239560178932_14148; Fri, 19 Jul 2013 13:12:40 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.242]) by mail93-co1.bigfish.com (Postfix) with ESMTP id 26FCE4C0048 for ; Fri, 19 Jul 2013 13:12:40 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.53) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 13:12:39 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 19 Jul 2013 06:12:38 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Fri, 19 Jul 2013 06:12:38 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.14) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 19 Jul 2013 06:17:12 -0700 Received: from mail171-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 13:12:37 +0000 Received: from mail171-tx2 (localhost [127.0.0.1]) by mail171-tx2-R.bigfish.com (Postfix) with ESMTP id DCC644C01EC for ; Fri, 19 Jul 2013 13:12:36 +0000 (UTC) Received: from mail171-tx2 (localhost.localdomain [127.0.0.1]) by mail171-tx2 (MessageSwitch) id 1374239554329726_20806; Fri, 19 Jul 2013 13:12:34 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.235]) by mail171-tx2.bigfish.com (Postfix) with ESMTP id 3BC03240052; Fri, 19 Jul 2013 13:12:34 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Jul 2013 13:12:29 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.14]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0329.000; Fri, 19 Jul 2013 13:12:28 +0000 From: John E Drake To: Richard Li , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt Thread-Index: AQHOdd+A3aiwC4A4oU2RIaGDkUi0fplpG3SggAFP5HCAANWtgIAA04aA Date: Fri, 19 Jul 2013 13:12:27 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E2074351A@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <0182DEA5604B3A44A2EE61F3EE3ED69E2073EF8E@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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: Fri, 19 Jul 2013 13:12:49 -0000 Yours Irrespectively, John > -----Original Message----- > From: Richard Li [mailto:renwei.li@huawei.com] > Sent: Thursday, July 18, 2013 5:25 PM > To: John E Drake; mpls@ietf.org > Subject: RE: [mpls] FW: New Version Notification for draft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03.txt >=20 > Hi John, >=20 > Technically you certainly can do it that way. But if you do so, you > would either need a new protocol or change an existing protocol for the > purpose of notification. JD: Okay, so we agree that your draft is unnecessary. Further, Notify is = not a new protocol whereas you are actually proposing two new protocols. V= iz, the one documented in your draft, which is the complete antithesis of s= tandard RSVP-TE, and the undocumented one, which is how the receivers learn= about the P2MP session in the first place. >=20 > On the other hand, in IP/PIM it is well and widely accepted that > multicast distribution trees are built up from the leaf to root. But in > MPLS, the multicast distribution tree (LSP) are built in a totally > different ordering. I am always struggling with why MPLS should be > doing it in a different way from PIM. If would be nice if MPLS could > unify with PIM with respect to MDT build-ups. JD: As you agreed, the notification message would provide this synthesis.= =20 >=20 > In addition, the receiver-driven RSVP-TE also has additional benefits > with respect to MP2MP. Otherwise one need a full-meshed P2MP trees to > implement MP2MP. JD: From my reading of the draft, MP2MP support appears to be an assertion= . >=20 > Regards, >=20 > Richard >=20 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, July 18, 2013 7:50 PM > To: Richard Li; mpls@ietf.org > Subject: RE: [mpls] FW: New Version Notification for draft-lzj-mpls- > receiver-driven-multicast-rsvp-te-03.txt >=20 > Richard, >=20 > If one wanted to support leaf-initiated join, why wouldn't one simply > have the leaf send a notification (e.g., Notify) to the root requesting > it to extend the p2mp tree to the leaf using the existing P2MP > procedures? The authors of RFC4875 expected an application level > notification to produce exactly this behavior. >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Richard Li > > Sent: Wednesday, July 17, 2013 8:39 AM > > To: mpls@ietf.org > > Subject: [mpls] FW: New Version Notification for draft-lzj-mpls- > > receiver-driven-multicast-rsvp-te-03.txt > > > > Hi All! > > > > We have updated our receiver-driven RSVP-TE draft. Your comments will > > be highly appreciated. > > > > Regards, > > > > Richard > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, July 01, 2013 6:17 AM > > To: Telus Communications; Christian Jacquenet; Eduard Metz; Boris > > Zhang; Quintin zhao; Richard Li > > Subject: New Version Notification for draft-lzj-mpls-receiver-driven- > > multicast-rsvp-te-03.txt > > > > > > A new version of I-D, > > draft-lzj-mpls-receiver-driven-multicast-rsvp-te- > > 03.txt > > has been successfully submitted by Renwei Li and posted to the IETF > > repository. > > > > Filename: draft-lzj-mpls-receiver-driven-multicast-rsvp-te > > Revision: 03 > > Title: Receiver-Driven Multicast Traffic-Engineered Label- > > Switched Paths > > Creation date: 2013-07-01 > > Group: Individual Submission > > Number of pages: 24 > > URL: http://www.ietf.org/internet-drafts/draft-lzj-mpls- > > receiver-driven-multicast-rsvp-te-03.txt > > Status: http://datatracker.ietf.org/doc/draft-lzj-mpls- > > receiver-driven-multicast-rsvp-te > > Htmlized: http://tools.ietf.org/html/draft-lzj-mpls-receiver- > > driven-multicast-rsvp-te-03 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-lzj-mpls- > > receiver-driven-multicast-rsvp-te-03 > > > > Abstract: > > This document describes extensions to Resource Reservation > Protocol > > - > > Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven > > Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to- > > multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol > > Label > > Switching (MPLS) and Generalized MPLS (GMPLS)networks. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 >=20 From davari@broadcom.com Fri Jul 19 06:19:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E90021E80B9; Fri, 19 Jul 2013 06:19:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T46wABqJv7ml; Fri, 19 Jul 2013 06:19:45 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0175521E80AB; Fri, 19 Jul 2013 06:19:44 -0700 (PDT) Received: from [10.9.208.57] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 19 Jul 2013 06:13:33 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 19 Jul 2013 06:19:32 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 19 Jul 2013 06:19:32 -0700 From: "Shahram Davari" To: "" Thread-Topic: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gLBHC6QABv2v4AAITEXAAAAV3iAAATsC4D//7lR1w== Date: Fri, 19 Jul 2013 13:19:32 +0000 Message-ID: <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <51E915BF.6020308@cisco.com> In-Reply-To: <51E915BF.6020308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7DF7E4F71R045962309-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "Bhatia, Manav \(Manav\)" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 13:19:49 -0000 Hi Stewart, Not necessarily. It is ok if some of the routers in the path are not timing= aware. That is the whole idea. We have tested cases in which 5-7 hops are = not 1588 aware and still we can recover the time correctly. Regards, Shahram On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" wrote: > On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: >> Hi Sasha, >>=20 >>> 1) reserved label is not backward compatible with existing routers. One >>> of the requirements is that routers that are not PTP aware can just >>> switch the packet normally. Using a reserved label can't achieve this >>> requirement, since routers that don't understand it will drop it or >>> sent it to CPU. >>> [[Sasha]] Is not this concern applicable to any new reserved label? >>> And routers that use network processors as forwarding engines could >>> easily overcome this issue by upgrading their microcode. >>> But I agree that this is a valid concern. >> This is a huge concern because not all routers use network processors th= at can be reprogrammed. >>=20 >> The current solution works with any router that can set up an MPLS path. > Really? >=20 > Surely the LSR needs to know that on seeing a label in the FEC it needs > to timestamp the packet. >=20 > Stewart > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc >=20 From stbryant@cisco.com Fri Jul 19 09:08:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B13D11E816F; Fri, 19 Jul 2013 09:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-6VR6hsmYsL; Fri, 19 Jul 2013 09:08:09 -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 42DE021F89D8; Fri, 19 Jul 2013 09:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2008; q=dns/txt; s=iport; t=1374250074; x=1375459674; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fRNS/zagDOUR/ZkHM109mDG/KrEvGdMXbmK3ejcNlAs=; b=eXH8ba+HRBKCDExQuuYfmcYVJXiKox8ZSQ83DM2B0Ops/hwWXoi4c2T5 gJpXjWStXleg3cpLmI+4/Pim59CZ3u53GZYTTGlE/dTnNmvjumK5LFQGu iRdXfLuQqb8YWgXsUV1qNFWr0SgbAbCpVCswYX/W50cun0JjaCFgoq2/+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEVj6VGQ/khM/2dsb2JhbABbgwY1wRmBEBZ0giQBAQEEAQEBNTYKARALGAkWDwkDAgECARUwBg0BBQIBAReHdQy3Bo5qgSUHg34Dl12RTYMTgWk X-IronPort-AV: E=Sophos;i="4.89,702,1367971200"; d="scan'208";a="157085621" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Jul 2013 16:07:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JG7j6J031126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 16:07:46 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6JG7heN006512; Fri, 19 Jul 2013 17:07:44 +0100 (BST) Message-ID: <51E9644F.8060100@cisco.com> Date: Fri, 19 Jul 2013 17:07:43 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Shahram Davari References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <51E915BF.6020308@cisco.com> <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> In-Reply-To: <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "Bhatia, Manav \(Manav\)" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls 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, 19 Jul 2013 16:08:14 -0000 Shahram That then poses two interesting question: 1) Do you ever need to go more than 7 hops? In the work we did on IPFRR the core was normally 8 hops across so most of the traffic in a single routing domain went less that 8 hops. 2) What happens when there is an underlying packet transport network which will introduce hidden hops? Stewart On 19/07/2013 14:19, Shahram Davari wrote: > Hi Stewart, > > Not necessarily. It is ok if some of the routers in the path are not timing aware. That is the whole idea. We have tested cases in which 5-7 hops are not 1588 aware and still we can recover the time correctly. > > Regards, > Shahram > > > On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" wrote: > >> On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: >>> Hi Sasha, >>> >>>> 1) reserved label is not backward compatible with existing routers. One >>>> of the requirements is that routers that are not PTP aware can just >>>> switch the packet normally. Using a reserved label can't achieve this >>>> requirement, since routers that don't understand it will drop it or >>>> sent it to CPU. >>>> [[Sasha]] Is not this concern applicable to any new reserved label? >>>> And routers that use network processors as forwarding engines could >>>> easily overcome this issue by upgrading their microcode. >>>> But I agree that this is a valid concern. >>> This is a huge concern because not all routers use network processors that can be reprogrammed. >>> >>> The current solution works with any router that can set up an MPLS path. >> Really? >> >> Surely the LSR needs to know that on seeing a label in the FEC it needs >> to timestamp the packet. >> >> Stewart >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From davari@broadcom.com Fri Jul 19 10:13:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DEF11E8163; Fri, 19 Jul 2013 10:13: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er0wRMhpXeb6; Fri, 19 Jul 2013 10:13:03 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id C0F2C11E8185; Fri, 19 Jul 2013 10:13:03 -0700 (PDT) Received: from [10.9.208.55] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 19 Jul 2013 10:03:10 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 19 Jul 2013 10:12:48 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 19 Jul 2013 10:12:48 -0700 From: "Shahram Davari" To: "stbryant@cisco.com" Thread-Topic: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gLBHC6QABv2v4AAITEXAAAAV3iAAATsC4D//7lR14AApFaAgABkOfA= Date: Fri, 19 Jul 2013 17:12:48 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE8F310@SJEXCHMB12.corp.ad.broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <51E915BF.6020308@cisco.com> <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> <51E9644F.8060100@cisco.com> In-Reply-To: <51E9644F.8060100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DF7AEC42L850265045-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "Bhatia, Manav \(Manav\)" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 17:13:07 -0000 Hi Stewart, Good question. It depends on the Servo algorithms used. The more hops the m= ore complex algorithms with longer convergence time. Any queuing point is p= otentially one hop that can introduce PDV. The 5-7 hops I mentioned is the = best proprietory servo algorithm I have seen, but the convergence time is v= ery long (many minutes). Thanks Shahram -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Friday, July 19, 2013 9:08 AM To: Shahram Davari Cc: Bhatia, Manav (Manav); mpls@ietf.org; tictoc@ietf.org; S. Davari Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpl= s Shahram That then poses two interesting question: 1) Do you ever need to go more than 7 hops? In the work we did on IPFRR the core was normally 8 hops across so most of the traffic in a single routing domain went less that 8 hops. 2) What happens when there is an underlying packet transport network which will introduce hidden hops? Stewart On 19/07/2013 14:19, Shahram Davari wrote: > Hi Stewart, > > Not necessarily. It is ok if some of the routers in the path are not timi= ng aware. That is the whole idea. We have tested cases in which 5-7 hops ar= e not 1588 aware and still we can recover the time correctly. > > Regards, > Shahram > > > On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" wrote: > >> On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: >>> Hi Sasha, >>> >>>> 1) reserved label is not backward compatible with existing routers. On= e >>>> of the requirements is that routers that are not PTP aware can just >>>> switch the packet normally. Using a reserved label can't achieve this >>>> requirement, since routers that don't understand it will drop it or >>>> sent it to CPU. >>>> [[Sasha]] Is not this concern applicable to any new reserved label? >>>> And routers that use network processors as forwarding engines could >>>> easily overcome this issue by upgrading their microcode. >>>> But I agree that this is a valid concern. >>> This is a huge concern because not all routers use network processors t= hat can be reprogrammed. >>> >>> The current solution works with any router that can set up an MPLS path= . >> Really? >> >> Surely the LSR needs to know that on seeing a label in the FEC it needs >> to timestamp the packet. >> >> Stewart >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >> > . > --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From eosborne@cisco.com Fri Jul 19 10:48:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2011E8142 for ; Fri, 19 Jul 2013 10:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4yvyiQGC-ig for ; Fri, 19 Jul 2013 10:48:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 39E4E21E80B8 for ; Fri, 19 Jul 2013 10:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9375; q=dns/txt; s=iport; t=1374256086; x=1375465686; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6gnAo/QIsZgARQgdDISAzu39rPjSZAEBtT9ryrNBmPs=; b=FwSuWm5DRUzD2xuxGN0CTsV92rj24QSOx90BQf9xZfWVW+GlJWVl1G2z MEV/0ZIX98IoHKGP3J9eh/BlR9k7nWo26LltBVhkWnTteCHRfA4j2rJx9 r7A2PO1nm5ZZ4bRkTmyyZIKiMTefD7BL+uFbQDsz7gOk/UBYefxRzDihO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAK566VGtJV2a/2dsb2JhbABbgwY1UMBJgRAWdIIkAQEBBGsODAQCAQgRBAEBCxkEByERFAkIAQEEAQ0FCBOHYwMPDK4XDYhaBI0jgR8bgQExBwaDCm4DiHCNBI4QhSaBWYE5gWgCAgUXBhw X-IronPort-AV: E=Sophos;i="4.89,703,1367971200"; d="scan'208";a="237005165" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jul 2013 17:48:05 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JHm5i9013994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 17:48:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 12:48:04 -0500 From: "Eric Osborne (eosborne)" To: "D'Alessandro Alessandro Gerardo" , "mpls@ietf.org" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQ Date: Fri, 19 Jul 2013 17:48:03 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> In-Reply-To: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.71] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 17:48:11 -0000 Hi Alessandro- Thanks for this; the threads I started some time back seem to have died do= wn, it's good to get them going again. I have two things I never quite understood, can you clarify them for me? i) can you explain EXER at a higher level? I'm not looking for a descripti= on of the state machine changes, and I'm not looking for the one line "It a= llows the FSM to be tested". We have all of that in the draft and in the e= quivalent ITU specs. What I'd like to understand about EXER is where it came from. The ITU spec= s that define it are pretty hard to follow, they seem to assume the reader = already knows what EXER is and what problem it solves. It feels very much = like a mechanism used to catch a very specific implementation bug, back whe= n transport gear was far less debuggable than what we have today. =20 No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, ISIS)= have explicit signaling in them just to ask the neighbor whether it *would= * be broken if if were, in the future, to be given a particular input. Par= t of my reluctance to get behind EXER has been that I don't feel comfortabl= e with the idea of keeping a 30-year-old workaround in a protocol. Is ther= e more to it than that? Have I misread and misunderstood EXER? Does moder= n transport gear ever actually detect a problem via EXER/RR that wasn't obv= ious to the operator using other means? ii) Why the push to standardize the SD state changes before we've defined S= D? I certainly agree that handling signal degrade is a good idea, but comi= ng up with a definition for it has been challenging. What happens if we ch= ange the FSM to handle it, then come up with something more sophisticated (= say, multiple levels of SD) that doesn't quite fit with the FSM changes? =20 thanks! eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > D'Alessandro Alessandro Gerardo > Sent: Wednesday, July 17, 2013 3:23 PM > To: mpls@ietf.org > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear > protection protocol to transport requirements >=20 > Dear all, > we would like socializing the herebelow drafts that were submitted some > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T > transport requirements. I would appreciate your comments about the > proposed mechanisms and behaviours. >=20 > draft-rhd-mpls-tp-psc-priority-00 > draft-cdh-mpls-tp-psc-non-revertive-00 > draft-rhd-mpls-tp-psc-sd-00 > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 >=20 > The above drafts cover most of items highlighted in ITU-T liaisons about > PSC and they propose solutions in line with MPLS-TP transport > requirements. > A list of main liaisons exchanged between ITU-T and IETF with the aim to > align PSC behavious with ITU-T transport requirements for linear > protection are given below: > https://datatracker.ietf.org/liaison/1162/ (June 2012) > https://datatracker.ietf.org/liaison/1205/ > (October 2012) > https://datatracker.ietf.org/liaison/1229/ > (January 2013) > https://datatracker.ietf.org/liaison/1234/ > (February 2013) > https://datatracker.ietf.org/liaison/1256/ > (May 2013) >=20 > Some details abou the proposed drafts for align PSC behaviour with > transport requirements: >=20 > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities > between FS and SF-P (see section 4.3.2 of rfc6378). > Among the others, behaviors that will be fixed with the proposed update > are: > Use case A) At first, working path(WP) and protection path(PP) are > normal. Then, Forced Switch(FS) command is issued for maintenance on the > WP and the traffic moves from WP to PP. When Signal Fail occurs on PP, > service cannot recover and is interrupted. This could occur for example > as a result of accidentally un-plugging a PP fiber. > Use case B) If there is an existing signal fail on a protection path > (SF-P),and FS command is issued by accident the traffic on WP will move > to PP. This results in an interruption of service from which you will > not automatically recover, because PSC should not have switched the > traffic from WP to PP. > Discussion about this draft led to the proposal to modify RFC 4427 that > was "written correctly though lacking in detail causing mis- > interpretation" that led to the current PSC set of priority that the > above draft is proposing to modified and to align to the required > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been > submitted to CCAMP for clarifying the definitions related to Manual > Switch and Forced Switch and their usage relative to priorities. > The way this behavior has to be incorporated into the PSC has to be > discussed. The text proposes to replace the current behavior with the > new one. If there is consensus to procede in that way this can bring to > a simple and effective way to operate the protocol. >=20 > ---------------------------------------------------------------------- > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378 > to change non-revertive operations to behaves in the same way > irrespectively of the trigger of protection switching (fault or operator > command FS, MS). Consequently an operator command, Manual Switch to > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is also > added to enable this behavior. From an operational point of view, MS to > working path has also to be supported to be able to initially align at > both sides in case of non-revertive switching mode. MS to working path > is defined in RFC 5654, requirement 83. >=20 > The proposed MS-W command is of equal priority to the existing MS-P > command, and there is text to handle the simultaneous or sequential > occurrence of two equal-priority commands. This behavior, already > adopted in other transport network protection switching protocol, can be > used for other addition to the protocol in the future. >=20 > ---------------------------------------------------------------------- > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state > machine to handle Signal Degrade (SD). It does not define SD or provide > scope around where or how SD may be used similarly as it already happen > in the draft in handling other defects like SF (Signal Failure). > In MPLS-TP survivability framework [RFC6372], a fault condition > includes both Signal Fail (SF) and Signal Degrade (SD) that can be used > to trigger protection switching. > While the standardization lack of an SD definition and detection > mechanisms, the relevant behaviors in terms of protection actions may > already be defined. >=20 > ---------------------------------------------------------------------- > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to > test if the APS communication is operating correctly. In other words > both APS process logic including state machine and APS channel on > protection path, without service disruption and without affecting any > protection operation, unless the protection transport entity is in use. > This command is documented in R84 of [RFC5654] and it is part of ITU-T > transport requirements. > An alternative proposal is documented in the Appendix B of RFC6378 that > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in > combination of OAM functionalities. However, it has some functional > limitation and has a potential risk of losing traffic as a signal > failure might occur during the exercise operation. In that case, LO or > FS has to be canceled to allow the PSC protocol to provide proper > switching. > A further alternative proposal is documented in draft-osborne-mpls-psc- > alive-00 that anyway show some functional limitations because cannot > validate the PSC state machine status and probably the Local Request > logic. >=20 >=20 > The authors encourage the IETF experts to comment on these drafts, > eventually proposing other options/mechanisms that can satisfy the same > requirements. > Best regards, > Alessandro, Huub, Jeong-dong, Taeksid > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is unauthorised. > If you are not the intended recipient, please delete this message and > any attachments and advise the sender by return e-mail, Thanks. >=20 > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non > =E8 necessario. From kevin.gross@avanw.com Fri Jul 19 10:35:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FDC11E8147 for ; Fri, 19 Jul 2013 10:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdtuhFtwmBNg for ; Fri, 19 Jul 2013 10:34:55 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9011E80FD for ; Fri, 19 Jul 2013 10:34:55 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 2GXu1m00816AWCUA8HavjH; Fri, 19 Jul 2013 17:34:55 +0000 Received: from mail-oa0-f53.google.com ([209.85.219.53]) by omta06.emeryville.ca.mail.comcast.net with comcast id 2HYu1m00b19jAmh8SHYuls; Fri, 19 Jul 2013 17:32:55 +0000 Received: by mail-oa0-f53.google.com with SMTP id k14so6511608oag.12 for ; Fri, 19 Jul 2013 10:32:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uer1530jVwiztaeioUajpDxv1qIR45Y/0UnPtXKc6mY=; b=mwO7H1eneahb9xwSMaZGuYB6ExK3wGeead1S8CxaobpAhFaldquGG6klCKWAC2e4s5 3xC8DBmCshpI9d/K1DTTQp6q//OcLxdRPl3sq3OyS8tfLSnDI+qaHvNV97SU0DfZJxkT 7UFIfotBIHjcL02KlCRgvP0xN2Y6NxeiviiLoZBGd0M0AbvfNJ4flKq+bfdbQF3jk0Ac oYoZXUhDFYlbqxxswyzEZU7NFoBGft31QECQUDC2PzOgqrI0y1LXIx+ltpUWVODn5ulC Vt2RQQ5tme3dkyrZXBGcHU7wRw2Ml04QvpxLu7sf+Sifk1xq36qQ6+4qyF71NuqUM3aO xd/Q== MIME-Version: 1.0 X-Received: by 10.60.131.171 with SMTP id on11mr18802332oeb.71.1374255174252; Fri, 19 Jul 2013 10:32:54 -0700 (PDT) Received: by 10.182.33.234 with HTTP; Fri, 19 Jul 2013 10:32:54 -0700 (PDT) In-Reply-To: <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> <51E915BF.6020308@cisco.com> <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> Date: Fri, 19 Jul 2013 11:32:54 -0600 Message-ID: From: Kevin Gross To: Shahram Davari Content-Type: multipart/alternative; boundary=047d7b471da47e036104e1e0b794 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374255295; bh=uer1530jVwiztaeioUajpDxv1qIR45Y/0UnPtXKc6mY=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=EjLO2RAvhyP+ajEw6slxxDhy+f+r3HJmELG7Bk2zmPKkgxe/7U62QTEeKRum74K2v +F2Aivy710QYY/QqL7QREhWHvuZ3quW4lIbAONco1RtZr/6OiUYScZJGA5ISdFHmAD PAIYEG9YH+j7W5d1M7fgH/UI23yVykR4NG6xSVPkaoWDqO0YpTsP45tyeEG8hyeCPF s6JyjI07e97dqef/PW3jD2v3BbPBn9T7+xgHJo2XUrBqaKu5m3YlXIpk4SCwImJhuZ ZWWduvgdz1hejK1zsygLQruTcXeZrp0YBonSM6ISAHQo/jTfxIFNsQAhydkhHRj42G sbLERFIvqSqrA== X-Mailman-Approved-At: Fri, 19 Jul 2013 10:51:55 -0700 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Jul 2013 17:35:06 -0000 --047d7b471da47e036104e1e0b794 Content-Type: text/plain; charset=ISO-8859-1 You need to specify what you mean by "recover the time correctly." Everytime you pass through a piece of equipment that is not timing aware, you introduce noise into the timing signal. More hops, more noise. Noise reduces synchronization accuracy. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Fri, Jul 19, 2013 at 7:19 AM, Shahram Davari wrote: > Hi Stewart, > > Not necessarily. It is ok if some of the routers in the path are not > timing aware. That is the whole idea. We have tested cases in which 5-7 > hops are not 1588 aware and still we can recover the time correctly. > > Regards, > Shahram > > > On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" wrote: > > > On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: > >> Hi Sasha, > >> > >>> 1) reserved label is not backward compatible with existing routers. One > >>> of the requirements is that routers that are not PTP aware can just > >>> switch the packet normally. Using a reserved label can't achieve this > >>> requirement, since routers that don't understand it will drop it or > >>> sent it to CPU. > >>> [[Sasha]] Is not this concern applicable to any new reserved label? > >>> And routers that use network processors as forwarding engines could > >>> easily overcome this issue by upgrading their microcode. > >>> But I agree that this is a valid concern. > >> This is a huge concern because not all routers use network processors > that can be reprogrammed. > >> > >> The current solution works with any router that can set up an MPLS path. > > Really? > > > > Surely the LSR needs to know that on seeing a label in the FEC it needs > > to timestamp the packet. > > > > Stewart > > _______________________________________________ > > TICTOC mailing list > > TICTOC@ietf.org > > https://www.ietf.org/mailman/listinfo/tictoc > > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > --047d7b471da47e036104e1e0b794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You need to specify what you mean by "recover the time correctly." Everytime you pass thro= ugh a=A0piece=A0of equipment that is not timing aware, you introduce noise = into the timing signal. More hops, more noise. Noise reduces synchronizatio= n accuracy.

Kevin Gross
+1-30= 3-447-0517
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Fri, Jul 19, 2013 at 7:19 AM, Shahram= Davari <davari@broadcom.com> wrote:
Hi Stewart,

Not necessarily. It is ok if some of the routers in the path are not timing= aware. That is the whole idea. We have tested cases in which 5-7 hops are = not =A0 1588 aware and still we can recover the time correctly.

Regards,
Shahram


On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" <stbryant@cisco.com> wrote:

> On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote:
>> Hi Sasha,
>>
>>> 1) reserved label is not backward compatible with existing rou= ters. One
>>> of the requirements is that routers that are not PTP aware can= just
>>> switch the packet normally. =A0Using a reserved label can'= t achieve this
>>> requirement, since routers that don't understand it will d= rop it or
>>> sent it to CPU.
>>> [[Sasha]] =A0Is not this concern =A0applicable to any new rese= rved label?
>>> And routers that use network processors as forwarding engines = could
>>> easily overcome this issue by upgrading their microcode.
>>> But I agree that this is a valid concern.
>> This is a huge concern because not all routers use network process= ors that can be reprogrammed.
>>
>> The current solution works with any router that can set up an MPLS= path.
> Really?
>
> Surely the LSR needs to know that on seeing a label in the FEC it need= s
> to timestamp the packet.
>
> Stewart
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
= https://www.ietf.org/mailman/listinfo/tictoc

--047d7b471da47e036104e1e0b794-- From erosen@cisco.com Fri Jul 19 11:29:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0511E8197 for ; Fri, 19 Jul 2013 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.388 X-Spam-Level: X-Spam-Status: No, score=-9.388 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG7M1bf5kaLl for ; Fri, 19 Jul 2013 11:29:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E321F9EAF for ; Fri, 19 Jul 2013 11:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3059; q=dns/txt; s=iport; t=1374258545; x=1375468145; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=sTxMUUoi6yUwnREdZcz/V1kC9/lE/qi2CnrBAwcJQ1Y=; b=Nb/utTwoVD9wZeVpkyigFva/I/IQ/oOIWpXLcKy6MfRxm7SGaIZv1aFZ Rh2/ig82ftcx2LT5DtcpjGzMMIDW5LM7LxXo/1vjDk+EYK4CdeEd58IRW Y3wE6m5h7Mj3Aa2j/N9OOgRS2904g0ltyc5/xmKw4W3u4ozdkDVa3Bqx3 s=; X-IronPort-AV: E=Sophos;i="4.89,703,1367971200"; d="scan'208";a="234046562" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2013 18:29:05 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6JIT3Fu023143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 18:29:03 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 r6JIT2G4014914; Fri, 19 Jul 2013 14:29:02 -0400 From: Eric Rosen To: Richard Li In-reply-to: Your message of Wed, 17 Jul 2013 15:38:12 -0000. Date: Fri, 19 Jul 2013 14:29:02 -0400 Message-ID: <14913.1374258542@erosen-linux> Cc: Mli , "mpls@ietf.org" Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:29:10 -0000 > If you use two "small" labels to represent a "big" label, you will run > into TWO BOS indicators, TWO EXP bits, and TWO TTL values ... Having > multiple TTLs/EXPs/BOSes is conceptually counter-intuitive This seems like something that is of no consequence (no practical import). That is, this doesn't seem to be a technical argument. > The label space in a context is not expanded; it is still 1M. Per context label. > Which label belongs to which context will be very arbitrary; If someone > put a label in one context, it won't be wrong if another one put the same > label in a different context. One of the characteristics of MPLS is that the label value that gets bound to a given FEC by a given LSR is arbitrary. If you use a pair of labels to represent a given FEC, of course the value of the label pair is arbitrary. > There is no semantic association at all between contexts and labels, which > is different from the situation about contexts for upstream-assigned > labels where one simply can't put upstream-assigned labels in an arbitrary > context. The only requirement on the use of labels is that the LSR imposing the label (or label pair) and the LSR interpreting the label (or label pair) have a common understanding of the FEC that is represented by that label (or label pair). MPLS requires no other "semantic associations". > In this proposal, we only need two 32-bit entries for a "big label": the > big label indicator + big label value. The big label indicator is a > reserved label. We don't need three label entries in an MPLS packet. As others have pointed out, the "big label indicator" may itself require two label stack entries. > If you use context labels, you will need to add 64 extra bits in BGP's > NLRI: context label and a secondary label. But if you use the big label > proposal in this draft, you will only need to add 32 bits: This is a "red herring". The encoding technique used to represent a label in BGP is unrelated to the representation of the labels in the data plane. > In the operating system and line cards, the "big label" proposal also has > some benefits over the context-based solution. If you use contexts, you > have to store the context label in conjunction with the VPN label. But if > you use the big label proposal, you only need an attribute flag bit to > mean the VPN label is a big one. The same thing holds true in the > forwarding software. This doesn't seem like a very thorough analysis of implementation techniques. Context labels are really just a technique that allows MPLS to support (a) upstream-assigned labels, (b) downstream-assigned labels that are only valid when preceded by a particular "context label", and (c) larger than 20-bit label space. The "big label" proposal only does (c), not (a) or (b). To argue for the "big label" proposal, one would have to argue that it has implementation advantages in the forwarding plane (ASICs, NPUs) that outweigh the fact that it provides less functionality. From erosen@cisco.com Fri Jul 19 12:02:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DBA11E82B9 for ; Fri, 19 Jul 2013 12:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.724 X-Spam-Level: X-Spam-Status: No, score=-9.724 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liM13jFHgAP1 for ; Fri, 19 Jul 2013 12:02:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD1811E82B5 for ; Fri, 19 Jul 2013 12:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1114; q=dns/txt; s=iport; t=1374260534; x=1375470134; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=/LlaSkljCdg2r+2i0wPiQ9uAL5tVYZQIr3g+sGYQqEo=; b=V0tj363DN3C5vINlMfRg/+4cip/tRfY7LNKISlEc71ipGTxHXMovXS+n 1kPGTwjzWMWXf4RbCVIGqhrtC62fkjixbURGgHM63sKnhvIM5TZdbyZuS 3UVsJtiQp3BDETleSO+sfmf/BSS6MftJJQMZdyLccRx/W5z6uTqVRoMRG k=; X-IronPort-AV: E=Sophos;i="4.89,703,1367971200"; d="scan'208";a="237086522" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jul 2013 19:02:14 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JJ2DU4010571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 19:02:14 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 r6JJ2C0w016360; Fri, 19 Jul 2013 15:02:12 -0400 From: Eric Rosen To: Richard Li In-reply-to: Your message of Fri, 19 Jul 2013 00:24:51 -0000. Date: Fri, 19 Jul 2013 15:02:12 -0400 Message-ID: <16359.1374260532@erosen-linux> Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:02:38 -0000 > But in MPLS, the multicast distribution tree (LSP) are built in a totally > different ordering. I am always struggling with why MPLS should be doing > it in a different way from PIM. If would be nice if MPLS could unify with > PIM with respect to MDT build-ups. Please see RFC 6388 (mLDP), which explains how to do receiver-driven tree setup for MPLS. The advantage of receiver-driven tree setup protocols is that they scale independently of the number of receivers that join the tree. That's because each node on the tree knows only about the nodes that are one hop away. This is the design center of PIM-SM -- the number of receivers joining the tree can increase without bound. The advantage of a head-end-driven tree setup protocol (like RSVP-TE P2MP) is that the head-end knows all the nodes on the tree, and thus can set up a more optimal tree. You probably wouldn't do this in an environment where the number of receivers can increase without bound. In that light, a receiver-driven version of RSVP-TE just doesn't seem to make much sense. What problem does it actually solve? From Alexander.Vainshtein@ecitele.com Sat Jul 20 07:53:42 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FE721F9AA3 for ; Sat, 20 Jul 2013 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.452 X-Spam-Level: X-Spam-Status: No, score=-4.452 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EygNzniOV26V for ; Sat, 20 Jul 2013 07:53:37 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.108]) by ietfa.amsl.com (Postfix) with ESMTP id D773121F91BF for ; Sat, 20 Jul 2013 07:53:35 -0700 (PDT) Received: from [193.109.254.147:43653] by server-4.bemta-14.messagelabs.com id 7A/C2-27904-E64AAE15; Sat, 20 Jul 2013 14:53:34 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1374332006!928814!4 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22361 invoked from network); 20 Jul 2013 14:53:33 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jul 2013 14:53:33 -0000 X-AuditID: 93eaf2e7-b7f636d000006656-f9-51eaa46bf2b2 Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 82.78.26198.B64AAE15; Sat, 20 Jul 2013 17:53:31 +0300 (IDT) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Sat, 20 Jul 2013 17:53:31 +0300 From: Alexander Vainshtein To: Kevin Gross , Shahram Davari Thread-Topic: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOhKZTqlqJIIKddUKix8fzrDoZZ5ltp4jW Date: Sat, 20 Jul 2013 14:53:31 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> <51E915BF.6020308@cisco.com> <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02150E7E77ILPTWPVEXMB02ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUy+dWnL7o5S14FGjw9xmyxvtfT4sWhdjaL W0tXsjowe/y7up3ZY9b9s2weS5b8ZApgjmpgtEnMy8svSSxJVUhJLU62VQooyixLTK5UUshM sVUyVFIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5yfkpmXnptkqewf66FhamlrqG SnZqyobG1lwhGZnFCqm6uYmZOQq5qcXFiempCkCRhC3MGat2TGUq2OBQcf76atYGxsNmXYyc HBICJhIN11+wQdhiEhfurQeyuTiEBA4ySnzds5MdJCEkcJRR4sWTUhCbTcBWYtPqu2ANIgK+ Eo0f9jB2MXJwMAvkSMxqEgYxhQV8JH6cVAUxQSoeLeGAKDaSmNnTA9bIIqAq8XzCBVYQm1cg QOLQyYnMEFu/MUs8unkfLMEpECix+NZcsAZGoNO+n1rDBGIzC4hL3HoynwniZAGJJXvOM0PY ohIvH/9jhbDlJTZvfcwKUZ8vMWMXxMW8AoISJ2c+YYGokZQ4uOIGywRGsVlIxs5C0jILSQtE XE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKJqZU1CSlJtuYKiXmpxZkpqTqpecn7uJ EZKEnu9g/DVf5RBjEDBAJjJLcSfnA5NYXkm8sYEBkRwlcd7lDeH+QgLpwKSVnZpakFoUX1Sa k1p8iJGJg1OqgfGyw4GT60tvnPj5ZYp8SPccVqtTm1suZMVMNXmk4HPxid424bfrS1v2rNFv rhG6OVHzNU9VwKHIA1euzPSK1pLRM35SaLIwdxffCY5ptZovOf53LtbakDwl78K3WY28x5c9 OdsdduT1h+6lfpevd16e5RNauLL3l/i937oCG+KmR7RzSGjYXzRQYinOSDTUYi4qTgQAEWkj 20cDAAA= Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Jul 2013 14:53:42 -0000 --_000_F9336571731ADE42A5397FC831CEAA02150E7E77ILPTWPVEXMB02ec_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Kevin, Shahram and all, I do not actively follow the developments in the ITU-T SG 15, but I believe= that investigation of partial on-path support for PTP (which would be the c= ase if some LERs on the path were not PTP-aware) has just began there, and i= t is not clear what (if anything) could be achieved and under what condition= s. Did I miss something important here? My 2c, Sasha ________________________________ From: tictoc-bounces@ietf.org [tictoc-bounces@ietf.org] on behalf of Kevin G= ross [kevin.gross@avanw.com] Sent: Friday, July 19, 2013 7:32 PM To: Shahram Davari Cc: mpls@ietf.org; S. Davari; tictoc@ietf.org Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls You need to specify what you mean by "recover the time correctly." Everytime= you pass through a piece of equipment that is not timing aware, you introdu= ce noise into the timing signal. More hops, more noise. Noise reduces synchr= onization accuracy. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com, www.X192.org On Fri, Jul 19, 2013 at 7:19 AM, Shahram Davari > wrote: Hi Stewart, Not necessarily. It is ok if some of the routers in the path are not timing= aware. That is the whole idea. We have tested cases in which 5-7 hops are n= ot 1588 aware and still we can recover the time correctly. Regards, Shahram On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" > wrote: > On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: >> Hi Sasha, >> >>> 1) reserved label is not backward compatible with existing routers. One >>> of the requirements is that routers that are not PTP aware can just >>> switch the packet normally. Using a reserved label can't achieve this >>> requirement, since routers that don't understand it will drop it or >>> sent it to CPU. >>> [[Sasha]] Is not this concern applicable to any new reserved label? >>> And routers that use network processors as forwarding engines could >>> easily overcome this issue by upgrading their microcode. >>> But I agree that this is a valid concern. >> This is a huge concern because not all routers use network processors tha= t can be reprogrammed. >> >> The current solution works with any router that can set up an MPLS path. > Really? > > Surely the LSR needs to know that on seeing a label in the FEC it needs > to timestamp the packet. > > Stewart > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc 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_F9336571731ADE42A5397FC831CEAA02150E7E77ILPTWPVEXMB02ec_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Kevin, Shahram and all,

I do not actively follow the developments in the ITU-T SG 15,= but I believe that investigation of partial on-path support for PTP (which= would be the case if some LERs on the path were not PTP-aware) has just beg= an there, and it is not clear what (if anything) could be achieved and under what conditions.

 

 

Did I miss something important here?

 

My 2c,

     Sasha

From: tictoc-bounces@ietf.org [tictoc-bounce= s@ietf.org] on behalf of Kevin Gross [kevin.gross@avanw.com]
Sent: Friday, July 19, 2013 7:32 PM
To: Shahram Davari
Cc: mpls@ietf.org; S. Davari; tictoc@ietf.org
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588o= vermpls

You need to specify what you mean by "recover the time correctly." Everytime you pass throug= h a piece of equipment that is not timing aware, you introduce noi= se into the timing signal. More hops, more noise. Noise reduces synchronization accuracy.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, w= ww.X192.org


On Fri, Jul 19, 2013 at 7:19 AM, Shahram Davari <= span dir=3D"ltr"> <davari@broadcom= .com> wrote:
Hi Stewart,

Not necessarily. It is ok if some of the routers in the path are not timing= aware. That is the whole idea. We have tested cases in which 5-7 hops are n= ot   1588 aware and still we can recover the time correctly.

Regards,
Shahram


On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" <stbryant@cisco.com> wrote:
> On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote:
>> Hi Sasha,
>>
>>> 1) reserved label is not backward compatible with existing rout= ers. One
>>> of the requirements is that routers that are not PTP aware can= just
>>> switch the packet normally.  Using a reserved label can't= achieve this
>>> requirement, since routers that don't understand it will drop i= t or
>>> sent it to CPU.
>>> [[Sasha]]  Is not this concern  applicable to any new= reserved label?
>>> And routers that use network processors as forwarding engines c= ould
>>> easily overcome this issue by upgrading their microcode.
>>> But I agree that this is a valid concern.
>> This is a huge concern because not all routers use network processo= rs that can be reprogrammed.
>>
>> The current solution works with any router that can set up an MPLS= path.
> Really?
>
> Surely the LSR needs to know that on seeing a label in the FEC it needs=
> to timestamp the packet.
>
> Stewart
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/tictoc

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_F9336571731ADE42A5397FC831CEAA02150E7E77ILPTWPVEXMB02ec_-- From Alexander.Vainshtein@ecitele.com Sun Jul 21 01:45:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A39311E812E; Sun, 21 Jul 2013 01:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyFznh-gbce4; Sun, 21 Jul 2013 01:45:31 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.106]) by ietfa.amsl.com (Postfix) with ESMTP id 805C721F9D71; Sun, 21 Jul 2013 01:45:29 -0700 (PDT) Received: from [193.109.254.147:48310] by server-2.bemta-14.messagelabs.com id C0/A8-18376-9AF9BE15; Sun, 21 Jul 2013 08:45:29 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1374396327!981841!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1141 invoked from network); 21 Jul 2013 08:45:28 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2013 08:45:28 -0000 X-AuditID: 93eaf2e7-b7fed6d000001626-65-51eb9fa6b321 Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 64.09.05670.6AF9BE15; Sun, 21 Jul 2013 11:45:26 +0300 (IDT) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Sun, 21 Jul 2013 11:45:26 +0300 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Thread-Topic: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gLBHC6QAAcCVIAAJx6oWv//00+A//ykm1A= Date: Sun, 21 Jul 2013 08:45:25 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42KZ/OrTF93l818HGnS8YrK4tXQlq8Xf5h52 ByaPJUt+MgUwRjUw2iTm5eWXJJakKqSkFifbKgUUZZYlJlcqKWSm2CoZKikU5CQmp+am5pXY KiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9dCwtTS11DJTs1ZUNja66QjMxihVTd 3MTMHIXc1OLixPRUBaBIwhbmjN/L/jAXzFes2Pm3toHxpFQXIyeHhICJxMuOG4wQtpjEhXvr 2UBsIYGDjBLzV0p2MXIB2UcZJU7svwuWYBOwldi0GsIWAbKfb97FAmIzC+RINP5cBRTn4BAW cJb4v6wOosRF4sPso8wQtp/EiSu7wUpYBFQl3rwVBAnzCgRIbLu9nQli1V0miXdb17OCJDgF oiWOXdsINp4R6Lbvp9YwQawSl7j1ZD4TxM0CEkv2nGeGsEUlXj7+xwphy0k8eXIK6jQdiQW7 P7FB2NoSyxa+ZoZYLChxcuYTFoh6SYmDK26wTGAUn4VkxSwk7bOQtM9C0r6AkWUVo2hmTkFJ Um66gaFeanJmSWpOql5yfu4mRkjieL6D8dd8lUOMrkB/T2SW4k7OByaevJJ4YwMD3Bwlcd7l DeH+QgLpwFSTnZpakFoUX1Sak1p8iJGJg1OqgbHiOpNe08/ljIZb0mQfPQ7QC/+dYbpb8fmW bks/zZ8WgsITMrrCN0T/5Uq+9iut2iFK4OOdn0U5Rn9Mp3tKdCUuyD5Uyl3aYn6Mvebj63an bTlTkrctEttya9qqg6p/eutEG/ctSZTmOPk0wOermwzbNKV8F9en1iyBj/6tZDla7Ca4pu3b JyWW4oxEQy3mouJEAOr3I84UAwAA Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Jul 2013 08:45:37 -0000 Manay, Please see some answers inline below. Regards, Sasha > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, July 19, 2013 11:12 AM > To: Alexander Vainshtein; S. Davari > Cc: mpls@ietf.org; tictoc@ietf.org > Subject: RE: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls > > Hi Sasha, > > > 1) reserved label is not backward compatible with existing routers. One > > of the requirements is that routers that are not PTP aware can just > > switch the packet normally. Using a reserved label can't achieve this > > requirement, since routers that don't understand it will drop it or > > sent it to CPU. > > [[Sasha]] Is not this concern applicable to any new reserved label? > > And routers that use network processors as forwarding engines could > > easily overcome this issue by upgrading their microcode. > > But I agree that this is a valid concern. > > This is a huge concern because not all routers use network processors that= can > be reprogrammed. > > The current solution works with any router that can set up an MPLS path. > > > [[[Sasha]]] I have already stated that backward compatibility of the soluti= on is a valid concern. However, I do not believe this concern is really huge. I suspect that presence of routers that are not capable for providing on-pat= h support for PTP represents a problem by and of itself when it comes to acc= urate recovery of ToD. I defer to ITU-T SG15 that is now working on "partial= on-path support for PTP" to decide what - and under what restrictions - one= could expect in this scenario. Meanwhile, as you say, the routers that do not support extended special purp= ose labels would most probably send the packets with such labels on top of t= he label stack for SW processing; and SW usually is upgradeable. So the outc= ome would be additional unaccounted for delay generated by non-compliant rou= ters - but it would be there in any case, right? >> > > 2) there are multiple encapsulations for PTP such as Ethernet with > > optional VLAN or UDP/IP. An intermediate LSR doesn't know the whether > > the payload is IP or Ethernet or VLAN. This means for each PTP > > encapsulation type you probably need a different reserved label. > > [[Sasha]] IMHO and FWIW support of PTP over UDP/IP would suffice in the > > absolute majority of cases. > > > > 3) the area director has asked us to create a more generalized way of > > carrying timing over MPLS to be usable with new timing protocols that > > need TC. Using reserved label would require different reserved label > > for each new timing protocol. > > [[Sasha]] I do not think so. "New timing protocols" would be hopefully > > still run on top of UDP/IP and hence could be easily identifiable by > > looking at the appropriate UDP port. > > That's bordering on speculation. The current solution is oblivious to a ne= w > timing protocol. Today it can be used for both PTP and NTP. With reserved > labels, we will need a new label (and a firmware upgrade) each time a new > protocol needs to be supported. > [[[Sasha]]] I do not understand this statement. On-path support has to be aw= are of the specific clock distribution protocol for which it provides suppor= t to be of any use in "transit" nodes (e.g., it should now where the "correc= tion field" or its analog sits within the packet). If you want this support to be multi-protocol, then your HW has to be multi-= protocol as well, and some form of protocol identification is required. > > > > 4) the extended reserved label draft is fairly new and didn't exist > > when this draft was progressing. > > [[Sasha]] This is definitelt true. But it does not justify (for me) > > setting up dedicated LSPs for timing distribution. > > No offence, am trying to understand - whats the problem that you see with > setting up a dedicated LSP for timing distribution? > [[[Sasha]]] One use case (which i see as a real one) is clock distribution a= cross a BGP/MPLS VPN instance that combines delivery of traffic to/from eNod= eB (mobile backhaul) with delivery of ToD to these nodes. > Cheers, Manav 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 loa@pi.nu Sun Jul 21 10:56:27 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A075211E80F6 for ; Sun, 21 Jul 2013 10:56:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M-EYG-e+SvB for ; Sun, 21 Jul 2013 10:56:23 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE8E21F9D71 for ; Sun, 21 Jul 2013 10:56:22 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E27741801274; Sun, 21 Jul 2013 19:56:21 +0200 (CEST) Message-ID: <51EC20C5.8030006@pi.nu> Date: Sun, 21 Jul 2013 19:56:21 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: erosen@cisco.com, "mpls@ietf.org" References: <14913.1374258542@erosen-linux> In-Reply-To: <14913.1374258542@erosen-linux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 17:56:27 -0000 Eric, correct me if I'm wrong but I think that your response below is a bit off the mark. For the TC field (four years since we changed name), you you are in control of the field for both the labels when you create the packet and can set them to whatever you want (given any normal rules applicable in your network). RFC 3443 allow you to make the TTL behave as a single TLL for the entire label stack or for a set of labels within the stack if you want to do that. So not only of no consequence, but also a solved "problem". /Loa On 2013-07-19 20:29, Eric Rosen wrote: >> If you use two "small" labels to represent a "big" label, you will run >> into TWO BOS indicators, TWO EXP bits, and TWO TTL values ... Having >> multiple TTLs/EXPs/BOSes is conceptually counter-intuitive > > This seems like something that is of no consequence (no practical import). > That is, this doesn't seem to be a technical argument. > >> The label space in a context is not expanded; it is still 1M. > > Per context label. > >> Which label belongs to which context will be very arbitrary; If someone >> put a label in one context, it won't be wrong if another one put the same >> label in a different context. > > One of the characteristics of MPLS is that the label value that gets bound > to a given FEC by a given LSR is arbitrary. If you use a pair of labels to > represent a given FEC, of course the value of the label pair is arbitrary. > >> There is no semantic association at all between contexts and labels, which >> is different from the situation about contexts for upstream-assigned >> labels where one simply can't put upstream-assigned labels in an arbitrary >> context. > > The only requirement on the use of labels is that the LSR imposing the label > (or label pair) and the LSR interpreting the label (or label pair) have a > common understanding of the FEC that is represented by that label (or label > pair). MPLS requires no other "semantic associations". > >> In this proposal, we only need two 32-bit entries for a "big label": the >> big label indicator + big label value. The big label indicator is a >> reserved label. We don't need three label entries in an MPLS packet. > > As others have pointed out, the "big label indicator" may itself require two > label stack entries. > >> If you use context labels, you will need to add 64 extra bits in BGP's >> NLRI: context label and a secondary label. But if you use the big label >> proposal in this draft, you will only need to add 32 bits: > > This is a "red herring". The encoding technique used to represent a label > in BGP is unrelated to the representation of the labels in the data plane. > >> In the operating system and line cards, the "big label" proposal also has >> some benefits over the context-based solution. If you use contexts, you >> have to store the context label in conjunction with the VPN label. But if >> you use the big label proposal, you only need an attribute flag bit to >> mean the VPN label is a big one. The same thing holds true in the >> forwarding software. > > This doesn't seem like a very thorough analysis of implementation > techniques. > > Context labels are really just a technique that allows MPLS to support (a) > upstream-assigned labels, (b) downstream-assigned labels that are only valid > when preceded by a particular "context label", and (c) larger than 20-bit > label space. The "big label" proposal only does (c), not (a) or (b). To > argue for the "big label" proposal, one would have to argue that it has > implementation advantages in the forwarding plane (ASICs, NPUs) that > outweigh the fact that it provides less functionality. > > > > > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From mach.chen@huawei.com Sun Jul 21 20:57:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EB21F8459; Sun, 21 Jul 2013 20:57:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJpD4vYZzkj3; Sun, 21 Jul 2013 20:57:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E03F321F843F; Sun, 21 Jul 2013 20:57:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ73332; Mon, 22 Jul 2013 03:57:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 04:56:14 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 04:57:04 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 11:57:00 +0800 From: Mach Chen To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-00.txt Thread-Index: AQHOhHMJ5nvFWzgHSU2oGH0zpaoNdplwB4KAgAAANVA= Date: Mon, 22 Jul 2013 03:57:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "status@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-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, 22 Jul 2013 03:57:50 -0000 Hi Greg, Many thanks for comments and questions! Please see my reply inline... Best regards, Mach > -----Original Message----- > From: Mach Chen > Sent: Monday, July 22, 2013 11:05 AM > To: Mach Chen > Subject: FW: [mpls] FW: New Version Notification for > draft-chen-mpls-source-label-00.txt >=20 >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Gregory Mirsky > Sent: Friday, July 19, 2013 7:27 PM > To: Mach Chen; mpls@ietf.org > Cc: status@ietf.org > Subject: Re: [mpls] FW: New Version Notification for > draft-chen-mpls-source-label-00.txt >=20 > Hi Mach, authors and et. al, > very interesting idea, please find my comments and questions below: > . I think that you propose SL for MPLS networks that permit label merge. = But > even for such networks, as I think, we could use MEP ID TLV in OAM packet= s to > identify the source. Yes, that would not help much with passive OAM but w= ill > work for active PM. For PM scenario, the SL solution is mainly designed for passive PM; and tec= hnically, both the SL solution and Source MEP ID TLV can apply to active PM= . The SL solution does not preclude to use MEP ID TLV in OAM packets. The S= L is mainly used in service packets, it can use in OAM packets as well. > . Since SL being defined with scope of a single administrative domain MS-= PW > example in section 1 might not be applicable as SL would not be of much h= elp. The draft said: "In its function as a Source Label (ingress node identifier), it MUST be un= ique within a domain. In cases where a Source Label is used across domains = it MUST be unique within the scope it is used." So, it does not preclude to use SL across domains if the SL can be unique a= cross the domains. =20 > . I don't think that RFC 6374 and its LM in particular are specifically t= argetted > towards passive method of PM. If my memory is right, for LM, RFC 6374 supports both (it calls inferred an= d direct measurement). I think you may refer to the DM that belongs to acti= ve measurement.=20 > . I don't think that PM measurement at intermeddiate LSR can be effective= ly > used to avoid congested path. Consider that LSR is downstream of a conges= ted > segment and would need to notify the upstream LSR or LER about identified > congestion (ECN) in order to take any action. IMHO, there are two use cases to measure at the intermediate LSRs, one is f= or fault localization.=20 The other is like this, hierarchy model : LSP1 S11-------------------------D11 LSP2 S21-----D22 LSP1 is over LSP2 (there may be many LSPs over LSP2), it may need to measur= e and collect the traffic matrix at S21 (to measure the throughput of each = LSP that is over on LSP2), then based on some conditions, it could steer so= me LSPs to other tunnels, or move other LSPs to this tunnel.=20 Best regards, Mach >=20 > =A0=A0=A0=A0=A0=A0=A0 Regards, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Mach Chen > Sent: Friday, July 19, 2013 2:07 AM > To: mpls@ietf.org > Cc: status@ietf.org > Subject: [mpls] FW: New Version Notification for > draft-chen-mpls-source-label-00.txt >=20 > Hi MPLSers, >=20 > We just uploaded a draft that introduces a concept of MPLS Source Label (= SL), the > source label is encoded in the label stack (immediately follows a special= purpose > label ) and used to identify the ingress LSR of an LSP. The source label = applies to > the scenarios where source identification is required (e.g., in order for= counting > and billing). For example, Performance Measurement for MPLS network, Traf= fic > Matrix measurement and collection, etc. >=20 > We'd appreciate that you could take a look at the draft. Any comments and > suggestion are welcome! >=20 > BTW, I cc the STATUS list for the people who may have interest, since the > segment routing requires to preserve the ingress to a domain for accounti= ng and > billing purpose, the source label can help here. >=20 > Best regards, > Mach >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 15, 2013 5:58 PM > To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen > Subject: New Version Notification for draft-chen-mpls-source-label-00.txt >=20 >=20 > A new version of I-D, draft-chen-mpls-source-label-00.txt > has been successfully submitted by Mach(Guoyi) Chen and posted to the IET= F > repository. >=20 > Filename:=A0=A0=A0=A0=A0=A0=A0 draft-chen-mpls-source-label > Revision:=A0=A0=A0=A0=A0=A0=A0 00 > Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MultiProtocol Label Switching (MPLS)= Source Label Creation > date:=A0=A0 2013-07-15 > Group:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Individual Submission > Number of pages: 12 > URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-dra= fts/draft-chen-mpls-sou > rce-label-00.txt > Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://datatracker.ietf.org/doc/draft-= chen-mpls-source-lab > el > Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-chen-mpls= -source-label-00 >=20 >=20 > Abstract: > =A0=A0 An MultiProtocol Label Switching (MPLS) label is originally define= d > =A0=A0 to identify a Forwarding Equivalence Class (FEC), a packet is > =A0=A0 assigned to a specific FEC based on its network layer destination > =A0=A0 address.=A0 It's difficult or even impossible to derive the source > =A0=A0 information from the label.=A0 For some applications, source > =A0=A0 identification is a critical requirement.=A0 For example, performa= nce > =A0=A0 monitoring, traffic matrix measurement and collection, where the > =A0=A0 monitoring node needs to identify where a packet was sent from. >=20 > =A0=A0 This document introduces the concept of Source Label (SL) that is > =A0=A0 carried in the label stack and used to identify the ingress Label > =A0=A0 Switching Router (LSR) of an Label Switched Path (LSP). >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From ryoo@etri.re.kr Mon Jul 22 01:52:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D7421E8056 for ; Mon, 22 Jul 2013 01:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FxJWAVBrrWH for ; Mon, 22 Jul 2013 01:50:02 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1021E8089 for ; Mon, 22 Jul 2013 01:21:20 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Jul 2013 17:14:57 +0900 Received: from SMTP2.etri.info ([169.254.2.217]) by SMTP3.etri.info ([169.254.4.37]) with mapi id 14.01.0355.002; Mon, 22 Jul 2013 17:14:56 +0900 From: "Ryoo, Jeong-dong" To: "Eric Osborne (eosborne)" , D'Alessandro Alessandro Gerardo , "mpls@ietf.org" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQ= Date: Mon, 22 Jul 2013 08:14:56 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276800CASMTP2etriinfo_" MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 08:52:38 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276800CASMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEVyaWMuDQoNCkxldCBtZSBhbnN3ZXIgeW91ciAybmQgcXVlc3Rpb24gb24gU0QuDQoNClNE IGRldGVjdGlvbiBtZXRob2RzIGRlZmluZWQgb3IgcHJvcG9zZWQgZm9yIHBhY2tldCB0cmFuc3Bv cnQgbmV0d29ya3MgY2FuIGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czoNCi0gQnkgT0FNIHBlcmZv cm1hbmNlIG1vbml0b3JpbmcgdG9vbDoNCiAgU0QgaXMgcmFpc2VkIGlmIHBhY2tldCBsb3NzIHJh dGlvIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5nIGEgbWVhc3VyZW1lbnQgcGVyaW9kLg0KICBU aHJlc2hvbGQgdmFsdWUgYW5kIG1lYXN1cmVtZW50IHBlcmlvZCBhcmUgY29uZmlndXJlZCBieSBh biBuZXR3b3JrIG9wZXJhdG9yLg0KICBUaGlzIGRldGVjdGlvbiBtZXRob2QgaXMgYWxyZWFkeSBk ZWZpbmVkIGluIElUVS1UIEcuODAyMSAoRXRoZXJuZXQgZXF1aXBtZW50IHNwZWMuKQ0KICBhbmQg dGhlIGVxdWlwbWVudCBzcGVjIGZvciBNUExTLVRQIGNhbiBlYXNpbHkgZm9sbG93IHRoZSBzYW1l IGRlZmluaXRpb24uDQotIEJ5IHNlcnZlciBsYXllciBpbmRpY2F0aW9uOg0KICBTRCBpcyByYWlz ZWQgaWYgYSBzZXJ2ZXIgbGF5ZXIgYmVsb3cgTVBMUy1UUCByZXBvcnRzIFNEIGNvbmRpdGlvbiBv biBpdHMgb3duIGxheWVyLg0KLSBCeSBDQ00gcGFja2V0IGNvdW50aW5nOg0KICBTRCBpcyByYWlz ZWQgaWYgdGhlIGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhjZWVkcyBhIHRocmVzaG9sZCBk dXJpbmcgYSBtZWFzdXJlbWVudCBwZXJpb2QuDQoNClJlZ2FyZGxlc3Mgb2YgaG93IHRvIGRldGVj dCBTRCwgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50cyBzaG91bGQgZGVzY3JpYmUg dGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9wZXJhdGlvbiBvbmNlIHN1Y2ggYSBTRCBpcyBkZWNs YXJlZC4NCg0KVGhlIHByb3Bvc2VkIGRyYWZ0IGNvdmVycyBTRC10cmlnZ2VyZWQgcHJvdGVjdGlv biBubyBtYXR0ZXIgd2hhdCBraW5kcyBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBhcmUgdXNlZC4N Cg0KUmVnYXJkaW5nIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgU0Q6DQpJdCBpcyBjZXJ0YWlubHkg cG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC4NCkJ1dCwgYXMgZmFyIGFz IHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjb25jZXJuZWQsIGl0IGp1c3QgbmVlZHMgdG8g a25vdyBpZiBTRCBpcyBzaWduYWxlZCB0byBwcm90ZWN0aW9uIHN3aXRjaGluZyBwcm9jZXNzIG9y IG5vdC4NCkl0IHdvdWxkIGJlIGEgbmV0d29yayBvcGVyYXRvcidzIGNob2ljZSBhdCB3aGF0IGxl dmVsIG9mIFNEIGhlIHdhbnRzIGhpcyBuZXR3b3JrIHByb3RlY3Rpb24gdG8gc3dpdGNob3Zlci4N CkluIG90aGVyIHdvcmRzLCB3aGF0IHRyaWdnZXJzIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIFNE IG9yIG5vIFNELiBJdCBpcyB5ZXMgb3Igbm8gZGVjaXNpb24uDQoNClNGIGNhbiBhbHNvIGJlIHZp ZXdlZCBhcyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFzIHRoZSBuZXR3b3JrIG9wZXJh dG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ00g bWVzc2FnZXMuDQpJZiBDQ00gaXMgZGlzYWJsZWQsIEFJUyBmcm9tIGEgc2VydmVyIGxheWVyIGNh biBiZSB1c2VkIGFzIGEgdHJpZ2dlciBmb3IgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIFNvIGFuZCBz byBmb3J0aC4NCkhvd2V2ZXIsIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90 IGRlZmluZSBob3cgdG8gZGV0ZWN0IFNGIGluIGFueXdoZXJlLg0KU2ltaWxhcnksIHByb3RlY3Rp b24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgbWFudWFsIHN3aXRjaCBh bmQgZm9yY2VkIHN3aXRjaCBjb21tYW5kcw0KYXJlIGluaXRpYXRlZCBpbiBhIG1hbmFnZW1lbnQg c3lzdGVtIGFuZCBzaWduYWxlZCB0byBwcm90ZWN0aW9uIHN3aXRjaGluZyBwcm9jZXNzLg0KDQpB Z2FpbiwgaW4gbXkgb3BpbmlvbiwgdGhlIGRyYWZ0IG9uIFNEIHByb3RlY3Rpb24gY2FuIGFjY29t bW9kYXRlIGFueSBTRCBkZXRlY3Rpb24gbWV0aG9kcy4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9u Zy1kb25nDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bSA6ICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4NClNlbnQg OiAyMDEzLTA3LTIwIDAyOjQ4OjI4ICggKzA5OjAwICkNClRvIDogRCdBbGVzc2FuZHJvIEFsZXNz YW5kcm8gR2VyYXJkbyA8YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0Piwg bXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4NCkNjIDogSHV1YiBoZWx2b29ydCAoaHV1Yi52 YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSkgPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+LCBo dXViYXR3b3JrQGdtYWlsLmNvbSA8aHV1YmF0d29ya0BnbWFpbC5jb20+DQpTdWJqZWN0IDogUmU6 IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhciBw cm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCg0KDQpIaSBBbGVz c2FuZHJvLQ0KDQpUaGFua3MgZm9yIHRoaXM7IHRoZSB0aHJlYWRzIEkgc3RhcnRlZCBzb21lIHRp bWUgYmFjayBzZWVtIHRvIGhhdmUgZGllZCBkb3duLCBpdCdzIGdvb2QgdG8gZ2V0IHRoZW0gZ29p bmcgYWdhaW4uDQpJIGhhdmUgdHdvIHRoaW5ncyBJIG5ldmVyIHF1aXRlIHVuZGVyc3Rvb2QsIGNh biB5b3UgY2xhcmlmeSB0aGVtIGZvciBtZT8NCg0KaSkgY2FuIHlvdSBleHBsYWluIEVYRVIgYXQg YSBoaWdoZXIgbGV2ZWw/IEknbSBub3QgbG9va2luZyBmb3IgYSBkZXNjcmlwdGlvbiBvZiB0aGUg c3RhdGUgbWFjaGluZSBjaGFuZ2VzLCBhbmQgSSdtIG5vdCBsb29raW5nIGZvciB0aGUgb25lIGxp bmUgIkl0IGFsbG93cyB0aGUgRlNNIHRvIGJlIHRlc3RlZCIuIFdlIGhhdmUgYWxsIG9mIHRoYXQg aW4gdGhlIGRyYWZ0IGFuZCBpbiB0aGUgZXF1aXZhbGVudCBJVFUgc3BlY3MuDQoNCldoYXQgSSdk IGxpa2UgdG8gdW5kZXJzdGFuZCBhYm91dCBFWEVSIGlzIHdoZXJlIGl0IGNhbWUgZnJvbS4gVGhl IElUVSBzcGVjcyB0aGF0IGRlZmluZSBpdCBhcmUgcHJldHR5IGhhcmQgdG8gZm9sbG93LCB0aGV5 IHNlZW0gdG8gYXNzdW1lIHRoZSByZWFkZXIgYWxyZWFkeSBrbm93cyB3aGF0IEVYRVIgaXMgYW5k IHdoYXQgcHJvYmxlbSBpdCBzb2x2ZXMuIEl0IGZlZWxzIHZlcnkgbXVjaCBsaWtlIGEgbWVjaGFu aXNtIHVzZWQgdG8gY2F0Y2ggYSB2ZXJ5IHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGJ1ZywgYmFj ayB3aGVuIHRyYW5zcG9ydCBnZWFyIHdhcyBmYXIgbGVzcyBkZWJ1Z2dhYmxlIHRoYW4gd2hhdCB3 ZSBoYXZlIHRvZGF5Lg0KDQpObyBvdGhlciBzdGF0ZSBtYWNoaW5lcyB0aGF0IEknbSBmYW1pbGlh ciB3aXRoIChSU1ZQLCBMRFAsIEJHUCwgT1NQRiwgSVNJUykgaGF2ZSBleHBsaWNpdCBzaWduYWxp bmcgaW4gdGhlbSBqdXN0IHRvIGFzayB0aGUgbmVpZ2hib3Igd2hldGhlciBpdCAqd291bGQqIGJl IGJyb2tlbiBpZiBpZiB3ZXJlLCBpbiB0aGUgZnV0dXJlLCB0byBiZSBnaXZlbiBhIHBhcnRpY3Vs YXIgaW5wdXQuIFBhcnQgb2YgbXkgcmVsdWN0YW5jZSB0byBnZXQgYmVoaW5kIEVYRVIgaGFzIGJl ZW4gdGhhdCBJIGRvbid0IGZlZWwgY29tZm9ydGFibGUgd2l0aCB0aGUgaWRlYSBvZiBrZWVwaW5n IGEgMzAteWVhci1vbGQgd29ya2Fyb3VuZCBpbiBhIHByb3RvY29sLiBJcyB0aGVyZSBtb3JlIHRv IGl0IHRoYW4gdGhhdD8gSGF2ZSBJIG1pc3JlYWQgYW5kIG1pc3VuZGVyc3Rvb2QgRVhFUj8gRG9l cyBtb2Rlcm4gdHJhbnNwb3J0IGdlYXIgZXZlciBhY3R1YWxseSBkZXRlY3QgYSBwcm9ibGVtIHZp YSBFWEVSL1JSIHRoYXQgd2Fzbid0IG9idmlvdXMgdG8gdGhlIG9wZXJhdG9yIHVzaW5nIG90aGVy IG1lYW5zPw0KDQoNCmlpKSBXaHkgdGhlIHB1c2ggdG8gc3RhbmRhcmRpemUgdGhlIFNEIHN0YXRl IGNoYW5nZXMgYmVmb3JlIHdlJ3ZlIGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQg aGFuZGxpbmcgc2lnbmFsIGRlZ3JhZGUgaXMgYSBnb29kIGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0 aCBhIGRlZmluaXRpb24gZm9yIGl0IGhhcyBiZWVuIGNoYWxsZW5naW5nLiBXaGF0IGhhcHBlbnMg aWYgd2UgY2hhbmdlIHRoZSBGU00gdG8gaGFuZGxlIGl0LCB0aGVuIGNvbWUgdXAgd2l0aCBzb21l dGhpbmcgbW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRpcGxlIGxldmVscyBvZiBTRCkgdGhh dCBkb2Vzbid0IHF1aXRlIGZpdCB3aXRoIHRoZSBGU00gY2hhbmdlcz8NCg0KDQoNCnRoYW5rcyEN Cg0KDQoNCg0KDQplcmljDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZg0KPiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvDQo+IFNlbnQ6IFdl ZG5lc2RheSwgSnVseSAxNywgMjAxMyAzOjIzIFBNDQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IENj OiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tKTsgaHV1YmF0d29y a0BnbWFpbC5jb20NCj4gU3ViamVjdDogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p bmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0 IHJlcXVpcmVtZW50cw0KPg0KPiBEZWFyIGFsbCwNCj4gd2Ugd291bGQgbGlrZSBzb2NpYWxpemlu ZyB0aGUgaGVyZWJlbG93IGRyYWZ0cyB0aGF0IHdlcmUgc3VibWl0dGVkIHNvbWUNCj4gbW9udGhz IGFnbyB3aXRoIHRoZSBhaW0gdG8gYWxpZ24gUFNDIHByb3RvY29sIChSRkMgNjM3OCkgdG8gSVRV LVQNCj4gdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgY29t bWVudHMgYWJvdXQgdGhlDQo+IHByb3Bvc2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91cnMuDQo+ DQo+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMA0KPiBkcmFmdC1jZGgtbXBscy10 cC1wc2Mtbm9uLXJldmVydGl2ZS0wMA0KPiBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDANCj4g ZHJhZnQtZGotbXBscy10cC1leGVyLXBzYy0wMSAvIGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtYWxp dmUtMDANCj4NCj4gVGhlIGFib3ZlIGRyYWZ0cyBjb3ZlciBtb3N0IG9mIGl0ZW1zIGhpZ2hsaWdo dGVkIGluIElUVS1UIGxpYWlzb25zIGFib3V0DQo+IFBTQyBhbmQgdGhleSBwcm9wb3NlIHNvbHV0 aW9ucyBpbiBsaW5lIHdpdGggTVBMUy1UUCB0cmFuc3BvcnQNCj4gcmVxdWlyZW1lbnRzLg0KPiBB IGxpc3Qgb2YgbWFpbiBsaWFpc29ucyBleGNoYW5nZWQgYmV0d2VlbiBJVFUtVCBhbmQgSUVURiB3 aXRoIHRoZSBhaW0gdG8NCj4gYWxpZ24gUFNDIGJlaGF2aW91cyB3aXRoIElUVS1UIHRyYW5zcG9y dCByZXF1aXJlbWVudHMgZm9yIGxpbmVhcg0KPiBwcm90ZWN0aW9uIGFyZSBnaXZlbiBiZWxvdzoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzExNjIvIChKdW5lIDIwMTIp DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjA1Lw0KPiAoT2N0b2Jl ciAyMDEyKQ0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIyOS8NCj4g KEphbnVhcnkgMjAxMykNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEy MzQvDQo+IChGZWJydWFyeSAyMDEzKQ0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xp YWlzb24vMTI1Ni8NCj4gKE1heSAyMDEzKQ0KPg0KPiBTb21lIGRldGFpbHMgYWJvdSB0aGUgcHJv cG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQU0MgYmVoYXZpb3VyIHdpdGgNCj4gdHJhbnNwb3J0IHJl cXVpcmVtZW50czoNCj4NCj4gZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwIHByb3Bv c2VzIHN3YXBwaW5nIHRoZSBwcmlvcml0aWVzDQo+IGJldHdlZW4gRlMgYW5kIFNGLVAgKHNlZSBz ZWN0aW9uIDQuMy4yIG9mIHJmYzYzNzgpLg0KPiBBbW9uZyB0aGUgb3RoZXJzLCBiZWhhdmlvcnMg dGhhdCB3aWxsIGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkIHVwZGF0ZQ0KPiBhcmU6DQo+IFVz ZSBjYXNlIEEpIEF0IGZpcnN0LCB3b3JraW5nIHBhdGgoV1ApIGFuZCBwcm90ZWN0aW9uIHBhdGgo UFApIGFyZQ0KPiBub3JtYWwuIFRoZW4sIEZvcmNlZCBTd2l0Y2goRlMpIGNvbW1hbmQgaXMgaXNz dWVkIGZvciBtYWludGVuYW5jZSBvbiB0aGUNCj4gV1AgYW5kIHRoZSB0cmFmZmljIG1vdmVzIGZy b20gV1AgdG8gUFAuIFdoZW4gU2lnbmFsIEZhaWwgb2NjdXJzIG9uIFBQLA0KPiBzZXJ2aWNlIGNh bm5vdCByZWNvdmVyIGFuZCBpcyBpbnRlcnJ1cHRlZC4gVGhpcyBjb3VsZCBvY2N1ciBmb3IgZXhh bXBsZQ0KPiBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJl ci4NCj4gVXNlIGNhc2UgQikgSWYgdGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFsIGZhaWwgb24g YSBwcm90ZWN0aW9uIHBhdGgNCj4gKFNGLVApLGFuZCBGUyBjb21tYW5kIGlzIGlzc3VlZCBieSBh Y2NpZGVudCB0aGUgdHJhZmZpYyBvbiBXUCB3aWxsIG1vdmUNCj4gdG8gUFAuIFRoaXMgcmVzdWx0 cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9tIHdoaWNoIHlvdSB3aWxsDQo+IG5v dCBhdXRvbWF0aWNhbGx5IHJlY292ZXIsIGJlY2F1c2UgUFNDIHNob3VsZCBub3QgaGF2ZSBzd2l0 Y2hlZCB0aGUNCj4gdHJhZmZpYyBmcm9tIFdQIHRvIFBQLg0KPiBEaXNjdXNzaW9uIGFib3V0IHRo aXMgZHJhZnQgbGVkIHRvIHRoZSBwcm9wb3NhbCB0byBtb2RpZnkgUkZDIDQ0MjcgdGhhdA0KPiB3 YXMgIndyaXR0ZW4gY29ycmVjdGx5IHRob3VnaCBsYWNraW5nIGluIGRldGFpbCBjYXVzaW5nIG1p cy0NCj4gaW50ZXJwcmV0YXRpb24iIHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBzZXQgb2Yg cHJpb3JpdHkgdGhhdCB0aGUNCj4gYWJvdmUgZHJhZnQgaXMgcHJvcG9zaW5nIHRvIG1vZGlmaWVk IGFuZCB0byBhbGlnbiB0byB0aGUgcmVxdWlyZWQNCj4gdHJhbnNwb3J0IGJlaGF2aW9yLiBkcmFm dC1oZWx2b29ydC1jY2FtcC1mcy1wcmlvcml0eS0wMCBoYXMgYmVlbg0KPiBzdWJtaXR0ZWQgdG8g Q0NBTVAgZm9yIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0ZWQgdG8gTWFudWFsDQo+ IFN3aXRjaCBhbmQgRm9yY2VkIFN3aXRjaCBhbmQgdGhlaXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJp b3JpdGllcy4NCj4gVGhlIHdheSB0aGlzIGJlaGF2aW9yIGhhcyB0byBiZSBpbmNvcnBvcmF0ZWQg aW50byB0aGUgUFNDIGhhcyB0byBiZQ0KPiBkaXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRv IHJlcGxhY2UgdGhlIGN1cnJlbnQgYmVoYXZpb3Igd2l0aCB0aGUNCj4gbmV3IG9uZS4gSWYgdGhl cmUgaXMgY29uc2Vuc3VzIHRvIHByb2NlZGUgaW4gdGhhdCB3YXkgdGhpcyBjYW4gYnJpbmcgdG8N Cj4gYSBzaW1wbGUgYW5kIGVmZmVjdGl2ZSB3YXkgdG8gb3BlcmF0ZSB0aGUgcHJvdG9jb2wuDQo+ DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUt MDAgY29udGFpbnMgdGhlIHVwZGF0ZXMgdG8gUkZDNjM3OA0KPiB0byBjaGFuZ2Ugbm9uLXJldmVy dGl2ZSBvcGVyYXRpb25zIHRvIGJlaGF2ZXMgaW4gdGhlIHNhbWUgd2F5DQo+IGlycmVzcGVjdGl2 ZWx5IG9mIHRoZSB0cmlnZ2VyIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIChmYXVsdCBvciBvcGVy YXRvcg0KPiBjb21tYW5kIEZTLCBNUykuIENvbnNlcXVlbnRseSBhbiBvcGVyYXRvciBjb21tYW5k LCBNYW51YWwgU3dpdGNoIHRvDQo+IFdvcmtpbmcgKE1TLVcpIGEuay5hICJNYW51YWwgc3dpdGNo LW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIiBpcyBhbHNvDQo+IGFkZGVkIHRvIGVuYWJsZSB0 aGlzIGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcsIE1TIHRvDQo+ IHdvcmtpbmcgcGF0aCBoYXMgYWxzbyB0byBiZSBzdXBwb3J0ZWQgdG8gYmUgYWJsZSB0byBpbml0 aWFsbHkgYWxpZ24gYXQNCj4gYm90aCBzaWRlcyBpbiBjYXNlIG9mIG5vbi1yZXZlcnRpdmUgc3dp dGNoaW5nIG1vZGUuIE1TIHRvIHdvcmtpbmcgcGF0aA0KPiBpcyBkZWZpbmVkIGluIFJGQyA1NjU0 LCByZXF1aXJlbWVudCA4My4NCj4NCj4gVGhlIHByb3Bvc2VkIE1TLVcgY29tbWFuZCBpcyBvZiBl cXVhbCBwcmlvcml0eSB0byB0aGUgZXhpc3RpbmcgTVMtUA0KPiBjb21tYW5kLCBhbmQgdGhlcmUg aXMgdGV4dCB0byBoYW5kbGUgdGhlIHNpbXVsdGFuZW91cyBvciBzZXF1ZW50aWFsDQo+IG9jY3Vy cmVuY2Ugb2YgdHdvIGVxdWFsLXByaW9yaXR5IGNvbW1hbmRzLiBUaGlzIGJlaGF2aW9yLCBhbHJl YWR5DQo+IGFkb3B0ZWQgaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcgcHJvdG9jb2wsIGNhbiBiZQ0KPiB1c2VkIGZvciBvdGhlciBhZGRpdGlvbiB0byB0aGUg cHJvdG9jb2wgaW4gdGhlIGZ1dHVyZS4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBkcmFmdC1yaGQt bXBscy10cC1wc2Mtc2QtMDAgcHJvdmlkZXMgZXh0ZW5zaW9ucyB0byB0aGUgUFNDIHN0YXRlDQo+ IG1hY2hpbmUgdG8gaGFuZGxlIFNpZ25hbCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmlu ZSBTRCBvciBwcm92aWRlDQo+IHNjb3BlIGFyb3VuZCB3aGVyZSBvciBob3cgU0QgbWF5IGJlIHVz ZWQgc2ltaWxhcmx5IGFzIGl0IGFscmVhZHkgaGFwcGVuDQo+IGluIHRoZSBkcmFmdCBpbiBoYW5k bGluZyBvdGhlciBkZWZlY3RzIGxpa2UgU0YgKFNpZ25hbCBGYWlsdXJlKS4NCj4gSW4gTVBMUy1U UCBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBbUkZDNjM3Ml0sIGEgZmF1bHQgY29uZGl0aW9uDQo+ IGluY2x1ZGVzIGJvdGggU2lnbmFsIEZhaWwgKFNGKSBhbmQgU2lnbmFsIERlZ3JhZGUgKFNEKSB0 aGF0IGNhbiBiZSB1c2VkDQo+IHRvIHRyaWdnZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQo+IFdo aWxlIHRoZSBzdGFuZGFyZGl6YXRpb24gbGFjayBvZiBhbiBTRCBkZWZpbml0aW9uIGFuZCBkZXRl Y3Rpb24NCj4gbWVjaGFuaXNtcywgdGhlIHJlbGV2YW50IGJlaGF2aW9ycyBpbiB0ZXJtcyBvZiBw cm90ZWN0aW9uIGFjdGlvbnMgbWF5DQo+IGFscmVhZHkgYmUgZGVmaW5lZC4NCj4NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0 aGUgRVhFUi9SUiBjb21tYW5kcyB0bw0KPiB0ZXN0IGlmIHRoZSBBUFMgY29tbXVuaWNhdGlvbiBp cyBvcGVyYXRpbmcgY29ycmVjdGx5LiBJbiBvdGhlciB3b3Jkcw0KPiBib3RoIEFQUyBwcm9jZXNz IGxvZ2ljIGluY2x1ZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBUFMgY2hhbm5lbCBvbg0KPiBwcm90 ZWN0aW9uIHBhdGgsIHdpdGhvdXQgc2VydmljZSBkaXNydXB0aW9uIGFuZCB3aXRob3V0IGFmZmVj dGluZyBhbnkNCj4gcHJvdGVjdGlvbiBvcGVyYXRpb24sIHVubGVzcyB0aGUgcHJvdGVjdGlvbiB0 cmFuc3BvcnQgZW50aXR5IGlzIGluIHVzZS4NCj4gVGhpcyBjb21tYW5kIGlzIGRvY3VtZW50ZWQg aW4gUjg0IG9mIFtSRkM1NjU0XSBhbmQgaXQgaXMgcGFydCBvZiBJVFUtVA0KPiB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzLg0KPiBBbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGlu IHRoZSBBcHBlbmRpeCBCIG9mIFJGQzYzNzggdGhhdA0KPiB1dGlsaXplcyB0aGUgTG9ja291dCBv ZiBQcm90ZWN0aW9uIChMTykgb3IgRm9yY2VkIFN3aXRjaCAoRlMpIGluDQo+IGNvbWJpbmF0aW9u IG9mIE9BTSBmdW5jdGlvbmFsaXRpZXMuIEhvd2V2ZXIsIGl0IGhhcyBzb21lIGZ1bmN0aW9uYWwN Cj4gbGltaXRhdGlvbiBhbmQgaGFzIGEgcG90ZW50aWFsIHJpc2sgb2YgbG9zaW5nIHRyYWZmaWMg YXMgYSBzaWduYWwNCj4gZmFpbHVyZSBtaWdodCBvY2N1ciBkdXJpbmcgdGhlIGV4ZXJjaXNlIG9w ZXJhdGlvbi4gSW4gdGhhdCBjYXNlLCBMTyBvcg0KPiBGUyBoYXMgdG8gYmUgY2FuY2VsZWQgdG8g YWxsb3cgdGhlIFBTQyBwcm90b2NvbCB0byBwcm92aWRlIHByb3Blcg0KPiBzd2l0Y2hpbmcuDQo+ IEEgZnVydGhlciBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIGRyYWZ0LW9z Ym9ybmUtbXBscy1wc2MtDQo+IGFsaXZlLTAwIHRoYXQgYW55d2F5IHNob3cgc29tZSBmdW5jdGlv bmFsIGxpbWl0YXRpb25zIGJlY2F1c2UgY2Fubm90DQo+IHZhbGlkYXRlIHRoZSBQU0Mgc3RhdGUg bWFjaGluZSBzdGF0dXMgYW5kIHByb2JhYmx5IHRoZSBMb2NhbCBSZXF1ZXN0DQo+IGxvZ2ljLg0K Pg0KPg0KPiBUaGUgYXV0aG9ycyBlbmNvdXJhZ2UgdGhlIElFVEYgZXhwZXJ0cyB0byBjb21tZW50 IG9uIHRoZXNlIGRyYWZ0cywNCj4gZXZlbnR1YWxseSBwcm9wb3Npbmcgb3RoZXIgb3B0aW9ucy9t ZWNoYW5pc21zIHRoYXQgY2FuIHNhdGlzZnkgdGhlIHNhbWUNCj4gcmVxdWlyZW1lbnRzLg0KPiBC ZXN0IHJlZ2FyZHMsDQo+IEFsZXNzYW5kcm8sIEh1dWIsIEplb25nLWRvbmcsIFRhZWtzaWQNCj4g UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1 c2l2YW1lbnRlIGFsbGUNCj4gcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEg byBxdWFsc2lhc2kgYWx0cmEgYXppb25lDQo+IGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRp IHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlDQo+IHZpZXRhdGUuIFF1YWxv cmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUNCj4g Y29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwg bWl0dGVudGUgZSBkaQ0KPiBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUu DQo+DQo+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFu ZCBtYXkgY29udGFpbg0KPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUg YWRkcmVzc2VlKHMpIG9ubHkuDQo+IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9y IHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLg0KPiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQNCj4g YW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBU aGFua3MuDQo+DQo+IHJpc3BldHRhIGwnYW1iaWVudGVSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uDQo+IMOoIG5lY2Vzc2FyaW8uDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlz dA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276800CASMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5IaSwgRXJpYy48L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij5MZXQgbWUgYW5zd2VyJm5ic3A7eW91ciAybmQgcXVlc3Rpb24gb24gU0QuPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+U0QgZGV0ZWN0aW9uIG1ldGhvZHMgZGVmaW5lZCBvciBwcm9w b3NlZCBmb3IgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcyBjYW4gYmUgc3VtbWFyaXplZCBhcyBm b2xsb3dzOjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPi0gQnkgT0FNIHBl cmZvcm1hbmNlIG1vbml0b3JpbmcgdG9vbDombmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij4mbmJzcDsgU0QgaXMmbmJzcDtyYWlzZWQgaWYgcGFja2V0IGxvc3MgcmF0 aW8gZXhjZWVkcyBhIHRocmVzaG9sZCBkdXJpbmcgYSBtZWFzdXJlbWVudCBwZXJpb2QuDQo8L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDsgVGhyZXNob2xkIHZhbHVl IGFuZCBtZWFzdXJlbWVudCBwZXJpb2QgYXJlIGNvbmZpZ3VyZWQgYnkgYW4gbmV0d29yayBvcGVy YXRvci48YnI+DQombmJzcDsgVGhpcyBkZXRlY3Rpb24gbWV0aG9kIGlzIGFscmVhZHkgZGVmaW5l ZCBpbiBJVFUtVCBHLjgwMjEgKEV0aGVybmV0IGVxdWlwbWVudCBzcGVjLikNCjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOyBhbmQgdGhlIGVxdWlwbWVudCBzcGVj IGZvciBNUExTLVRQIGNhbiBlYXNpbHkgZm9sbG93IHRoZSBzYW1lIGRlZmluaXRpb24uPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+LSBCeSBzZXJ2ZXIgbGF5ZXIgaW5kaWNh dGlvbjo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDtTRCBpcyByYWlzZWQgaWYgYSBz ZXJ2ZXIgbGF5ZXIgYmVsb3cgTVBMUy1UUCByZXBvcnRzIFNEIGNvbmRpdGlvbiBvbiBpdHMgb3du IGxheWVyLjwvZGl2Pg0KPGRpdj4tIEJ5IENDTSBwYWNrZXQgY291bnRpbmc6PC9kaXY+DQo8ZGl2 PiZuYnNwOyBTRCBpcyByYWlzZWQgaWYgdGhlIGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhj ZWVkcyBhIHRocmVzaG9sZCBkdXJpbmcgYSBtZWFzdXJlbWVudCBwZXJpb2QuPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRsZXNzIG9mIGhvdyB0byBkZXRlY3QgU0QsIGFueSBw cm90ZWN0aW9uJm5ic3A7c3dpdGNoaW5nIGRvY3VtZW50cyBzaG91bGQgZGVzY3JpYmUgdGhlIHBy b3RlY3Rpb24gc3dpdGNoaW5nIG9wZXJhdGlvbiBvbmNlIHN1Y2ggYSBTRCBpcyBkZWNsYXJlZC48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBwcm9wb3NlZCBkcmFmdCBjb3ZlcnMg U0QtdHJpZ2dlcmVkIHByb3RlY3Rpb24gbm8gbWF0dGVyIHdoYXQga2luZHMgb2YgU0QgZGV0ZWN0 aW9uIG1ldGhvZHMgYXJlIHVzZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdh cmRpbmcgdGhlIG11bHRpcGxlIGxldmVscyBvZiBTRDo8L2Rpdj4NCjxkaXY+SXQgaXMmbmJzcDtj ZXJ0YWlubHkgcG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC48L2Rpdj4N CjxkaXY+QnV0LCBhcyBmYXIgYXMgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGNvbmNlcm5l ZCwmbmJzcDtpdCZuYnNwO2p1c3QgbmVlZHMgdG8ga25vdyBpZiZuYnNwO1NEIGlzJm5ic3A7c2ln bmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2VzcyBvciBub3QuJm5ic3A7PC9kaXY+ DQo8ZGl2Pkl0IHdvdWxkIGJlIGEgbmV0d29yayBvcGVyYXRvcidzIGNob2ljZSZuYnNwO2F0IHdo YXQgbGV2ZWwgb2YgU0QgaGUgd2FudHMmbmJzcDtoaXMmbmJzcDtuZXR3b3JrIHByb3RlY3Rpb24m bmJzcDt0byBzd2l0Y2hvdmVyLjwvZGl2Pg0KPGRpdj5JbiBvdGhlciB3b3Jkcywgd2hhdCB0cmln Z2VycyBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBTRCZuYnNwO29yIG5vIFNELiBJdCBpcyB5ZXMg b3Igbm8gZGVjaXNpb24uPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TRiBjYW4gYWxz byBiZSB2aWV3ZWQgYXMgaGF2aW5nIG11bHRpcGxlIGxldmVscyBvZiBTRiBhcyZuYnNwO3RoZSBu ZXR3b3JrIG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2UmbmJzcDtvbiB0aGUgcGVyaW9k L2ludGVydmFsIG9mIENDTSBtZXNzYWdlcy48L2Rpdj4NCjxkaXY+SWYgQ0NNIGlzIGRpc2FibGVk LCBBSVMgZnJvbSBhIHNlcnZlciBsYXllciBjYW4gYmUgdXNlZCBhcyBhIHRyaWdnZXIgZm9yIHBy b3RlY3Rpb24gc3dpdGNoaW5nLiBTbyBhbmQgc28gZm9ydGguPC9kaXY+DQo8ZGl2Pkhvd2V2ZXIs IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgdG8gZGV0 ZWN0IFNGIGluIGFueXdoZXJlLjwvZGl2Pg0KPGRpdj5TaW1pbGFyeSwgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGhvdyBtYW51YWwgc3dpdGNoJm5ic3A7YW5k Jm5ic3A7Zm9yY2VkIHN3aXRjaCZuYnNwO2NvbW1hbmRzDQo8L2Rpdj4NCjxkaXY+YXJlIGluaXRp YXRlZCBpbiBhIG1hbmFnZW1lbnQgc3lzdGVtIGFuZCBzaWduYWxlZCB0byBwcm90ZWN0aW9uIHN3 aXRjaGluZyBwcm9jZXNzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWdhaW4sIGlu IG15IG9waW5pb24sIHRoZSBkcmFmdCBvbiBTRCBwcm90ZWN0aW9uIGNhbiBhY2NvbW1vZGF0ZSBh bnkgU0QgZGV0ZWN0aW9uIG1ldGhvZHMuJm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5KZW9uZy1k b25nPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7RXJpYyBPc2Jv cm5lIChlb3Nib3JuZSkmcXVvdDsgJmx0O2Vvc2Jvcm5lQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5T ZW50IDogPC9iPjIwMTMtMDctMjAgMDI6NDg6MjggKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6 IDwvYj5EJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvICZsdDthbGVzc2FuZHJvLmRhbGVz c2FuZHJvQHRlbGVjb21pdGFsaWEuaXQmZ3Q7LCBtcGxzQGlldGYub3JnICZsdDttcGxzQGlldGYu b3JnJmd0Ozxicj4NCjxiPkNjIDogPC9iPkh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0 QGh1YXdlaS5jb20pICZsdDtodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tJmd0OywgaHV1YmF0 d29ya0BnbWFpbC5jb20gJmx0O2h1dWJhdHdvcmtAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1Ympl Y3QgOiA8L2I+UmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAg UFNDIGxpbmVhciBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHM8 YnI+DQo8YnI+DQo8YnI+DQpIaSBBbGVzc2FuZHJvLTxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhp czsgdGhlIHRocmVhZHMgSSBzdGFydGVkIHNvbWUgdGltZSBiYWNrIHNlZW0gdG8gaGF2ZSBkaWVk IGRvd24sIGl0J3MgZ29vZCB0byBnZXQgdGhlbSBnb2luZyBhZ2Fpbi48YnI+DQpJIGhhdmUgdHdv IHRoaW5ncyBJIG5ldmVyIHF1aXRlIHVuZGVyc3Rvb2QsIGNhbiB5b3UgY2xhcmlmeSB0aGVtIGZv ciBtZT88YnI+DQo8YnI+DQppKSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBsZXZl bD8gSSdtIG5vdCBsb29raW5nIGZvciBhIGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5l IGNoYW5nZXMsIGFuZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZSBvbmUgbGluZSAmcXVvdDtJdCBh bGxvd3MgdGhlIEZTTSB0byBiZSB0ZXN0ZWQmcXVvdDsuIFdlIGhhdmUgYWxsIG9mIHRoYXQgaW4g dGhlIGRyYWZ0IGFuZCBpbiB0aGUgZXF1aXZhbGVudCBJVFUgc3BlY3MuPGJyPg0KPGJyPg0KV2hh dCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9t LiBUaGUgSVRVIHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3cs IHRoZXkgc2VlbSB0byBhc3N1bWUgdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBp cyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQgZmVlbHMgdmVyeSBtdWNoIGxpa2UgYSBt ZWNoYW5pc20gdXNlZCB0byBjYXRjaCBhIHZlcnkNCiBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBi dWcsIGJhY2sgd2hlbiB0cmFuc3BvcnQgZ2VhciB3YXMgZmFyIGxlc3MgZGVidWdnYWJsZSB0aGFu IHdoYXQgd2UgaGF2ZSB0b2RheS4NCjxicj4NCjxicj4NCk5vIG90aGVyIHN0YXRlIG1hY2hpbmVz IHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwgQkdQLCBPU1BGLCBJU0lTKSBoYXZl IGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvciB3aGV0 aGVyIGl0ICp3b3VsZCogYmUgYnJva2VuIGlmIGlmIHdlcmUsIGluIHRoZSBmdXR1cmUsIHRvIGJl IGdpdmVuIGEgcGFydGljdWxhciBpbnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBi ZWhpbmQNCiBFWEVSIGhhcyBiZWVuIHRoYXQgSSBkb24ndCBmZWVsIGNvbWZvcnRhYmxlIHdpdGgg dGhlIGlkZWEgb2Yga2VlcGluZyBhIDMwLXllYXItb2xkIHdvcmthcm91bmQgaW4gYSBwcm90b2Nv bC4gSXMgdGhlcmUgbW9yZSB0byBpdCB0aGFuIHRoYXQ/IEhhdmUgSSBtaXNyZWFkIGFuZCBtaXN1 bmRlcnN0b29kIEVYRVI/IERvZXMgbW9kZXJuIHRyYW5zcG9ydCBnZWFyIGV2ZXIgYWN0dWFsbHkg ZGV0ZWN0IGEgcHJvYmxlbSB2aWEgRVhFUi9SUiB0aGF0IHdhc24ndA0KIG9idmlvdXMgdG8gdGhl IG9wZXJhdG9yIHVzaW5nIG90aGVyIG1lYW5zPzxicj4NCjxicj4NCjxicj4NCmlpKSBXaHkgdGhl IHB1c2ggdG8gc3RhbmRhcmRpemUgdGhlIFNEIHN0YXRlIGNoYW5nZXMgYmVmb3JlIHdlJ3ZlIGRl ZmluZWQgU0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxpbmcgc2lnbmFsIGRlZ3JhZGUg aXMgYSBnb29kIGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0aCBhIGRlZmluaXRpb24gZm9yIGl0IGhh cyBiZWVuIGNoYWxsZW5naW5nLiBXaGF0IGhhcHBlbnMgaWYgd2UgY2hhbmdlIHRoZSBGU00gdG8g aGFuZGxlIGl0LCB0aGVuIGNvbWUNCiB1cCB3aXRoIHNvbWV0aGluZyBtb3JlIHNvcGhpc3RpY2F0 ZWQgKHNheSwgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEKSB0aGF0IGRvZXNuJ3QgcXVpdGUgZml0IHdp dGggdGhlIEZTTSBjaGFuZ2VzPw0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KdGhhbmtzITxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCmVyaWM8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZjxicj4N CiZndDsgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzxicj4NCiZndDsgU2VudDogV2Vk bmVzZGF5LCBKdWx5IDE3LCAyMDEzIDM6MjMgUE08YnI+DQomZ3Q7IFRvOiBtcGxzQGlldGYub3Jn PGJyPg0KJmd0OyBDYzogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNv bSk7IGh1dWJhdHdvcmtAZ21haWwuY29tPGJyPg0KJmd0OyBTdWJqZWN0OiBbbXBsc10gcHJvcG9z ZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXI8YnI+DQomZ3Q7IHByb3Rl Y3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50czxicj4NCiZndDsgPGJyPg0K Jmd0OyBEZWFyIGFsbCw8YnI+DQomZ3Q7IHdlIHdvdWxkIGxpa2Ugc29jaWFsaXppbmcgdGhlIGhl cmViZWxvdyBkcmFmdHMgdGhhdCB3ZXJlIHN1Ym1pdHRlZCBzb21lPGJyPg0KJmd0OyBtb250aHMg YWdvIHdpdGggdGhlIGFpbSB0byBhbGlnbiBQU0MgcHJvdG9jb2wgKFJGQyA2Mzc4KSB0byBJVFUt VDxicj4NCiZndDsgdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRlIHlv dXIgY29tbWVudHMgYWJvdXQgdGhlPGJyPg0KJmd0OyBwcm9wb3NlZCBtZWNoYW5pc21zIGFuZCBi ZWhhdmlvdXJzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJp b3JpdHktMDA8YnI+DQomZ3Q7IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAw PGJyPg0KJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDA8YnI+DQomZ3Q7IGRyYWZ0LWRq LW1wbHMtdHAtZXhlci1wc2MtMDEgLyBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLWFsaXZlLTAwPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBhYm92ZSBkcmFmdHMgY292ZXIgbW9zdCBvZiBpdGVtcyBo aWdobGlnaHRlZCBpbiBJVFUtVCBsaWFpc29ucyBhYm91dDxicj4NCiZndDsgUFNDIGFuZCB0aGV5 IHByb3Bvc2Ugc29sdXRpb25zIGluIGxpbmUgd2l0aCBNUExTLVRQIHRyYW5zcG9ydDxicj4NCiZn dDsgcmVxdWlyZW1lbnRzLjxicj4NCiZndDsgQSBsaXN0IG9mIG1haW4gbGlhaXNvbnMgZXhjaGFu Z2VkIGJldHdlZW4gSVRVLVQgYW5kIElFVEYgd2l0aCB0aGUgYWltIHRvPGJyPg0KJmd0OyBhbGln biBQU0MgYmVoYXZpb3VzIHdpdGggSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBmb3IgbGlu ZWFyPGJyPg0KJmd0OyBwcm90ZWN0aW9uIGFyZSBnaXZlbiBiZWxvdzo8YnI+DQomZ3Q7IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMTYyLyAoSnVuZSAyMDEyKTxicj4NCiZn dDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMDUvPGJyPg0KJmd0OyA8 SFRUUFM6IGRhdGF0cmFja2VyLmlldGYub3JnbGlhaXNvbjExNjI9IiIgLz4oT2N0b2JlciAyMDEy KTxicj4NCiZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMjkvPGJy Pg0KJmd0OyA8SFRUUFM6IGRhdGF0cmFja2VyLmlldGYub3JnbGlhaXNvbjExNjI9IiIgLz4oSmFu dWFyeSAyMDEzKTxicj4NCiZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u LzEyMzQvPGJyPg0KJmd0OyA8SFRUUFM6IGRhdGF0cmFja2VyLmlldGYub3JnbGlhaXNvbjExNjI9 IiIgLz4oRmVicnVhcnkgMjAxMyk8YnI+DQomZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbGlhaXNvbi8xMjU2Lzxicj4NCiZndDsgPEhUVFBTOiBkYXRhdHJhY2tlci5pZXRmLm9yZ2xp YWlzb24xMTYyPSIiIC8+KE1heSAyMDEzKTxicj4NCiZndDsgPGJyPg0KJmd0OyBTb21lIGRldGFp bHMgYWJvdSB0aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQU0MgYmVoYXZpb3VyIHdpdGg8 YnI+DQomZ3Q7IHRyYW5zcG9ydCByZXF1aXJlbWVudHM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGRy YWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMCBwcm9wb3NlcyBzd2FwcGluZyB0aGUgcHJp b3JpdGllczxicj4NCiZndDsgYmV0d2VlbiBGUyBhbmQgU0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIg b2YgcmZjNjM3OCkuPGJyPg0KJmd0OyBBbW9uZyB0aGUgb3RoZXJzLCBiZWhhdmlvcnMgdGhhdCB3 aWxsIGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkIHVwZGF0ZTxicj4NCiZndDsgYXJlOjxicj4N CiZndDsgVXNlIGNhc2UgQSkgQXQgZmlyc3QsIHdvcmtpbmcgcGF0aChXUCkgYW5kIHByb3RlY3Rp b24gcGF0aChQUCkgYXJlPGJyPg0KJmd0OyBub3JtYWwuIFRoZW4sIEZvcmNlZCBTd2l0Y2goRlMp IGNvbW1hbmQgaXMgaXNzdWVkIGZvciBtYWludGVuYW5jZSBvbiB0aGU8YnI+DQomZ3Q7IFdQIGFu ZCB0aGUgdHJhZmZpYyBtb3ZlcyBmcm9tIFdQIHRvIFBQLiBXaGVuIFNpZ25hbCBGYWlsIG9jY3Vy cyBvbiBQUCw8YnI+DQomZ3Q7IHNlcnZpY2UgY2Fubm90IHJlY292ZXIgYW5kIGlzIGludGVycnVw dGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvciBleGFtcGxlPGJyPg0KJmd0OyBhcyBhIHJlc3VsdCBv ZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci48YnI+DQomZ3Q7IFVzZSBjYXNl IEIpIElmIHRoZXJlIGlzIGFuIGV4aXN0aW5nIHNpZ25hbCBmYWlsIG9uIGEgcHJvdGVjdGlvbiBw YXRoPGJyPg0KJmd0OyAoU0YtUCksYW5kIEZTIGNvbW1hbmQgaXMgaXNzdWVkIGJ5IGFjY2lkZW50 IHRoZSB0cmFmZmljIG9uIFdQIHdpbGwgbW92ZTxicj4NCiZndDsgdG8gUFAuIFRoaXMgcmVzdWx0 cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9tIHdoaWNoIHlvdSB3aWxsPGJyPg0K Jmd0OyBub3QgYXV0b21hdGljYWxseSByZWNvdmVyLCBiZWNhdXNlIFBTQyBzaG91bGQgbm90IGhh dmUgc3dpdGNoZWQgdGhlPGJyPg0KJmd0OyB0cmFmZmljIGZyb20gV1AgdG8gUFAuPGJyPg0KJmd0 OyBEaXNjdXNzaW9uIGFib3V0IHRoaXMgZHJhZnQgbGVkIHRvIHRoZSBwcm9wb3NhbCB0byBtb2Rp ZnkgUkZDIDQ0MjcgdGhhdDxicj4NCiZndDsgd2FzICZxdW90O3dyaXR0ZW4gY29ycmVjdGx5IHRo b3VnaCBsYWNraW5nIGluIGRldGFpbCBjYXVzaW5nIG1pcy08YnI+DQomZ3Q7IGludGVycHJldGF0 aW9uJnF1b3Q7IHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBzZXQgb2YgcHJpb3JpdHkgdGhh dCB0aGU8YnI+DQomZ3Q7IGFib3ZlIGRyYWZ0IGlzIHByb3Bvc2luZyB0byBtb2RpZmllZCBhbmQg dG8gYWxpZ24gdG8gdGhlIHJlcXVpcmVkPGJyPg0KJmd0OyB0cmFuc3BvcnQgYmVoYXZpb3IuIGRy YWZ0LWhlbHZvb3J0LWNjYW1wLWZzLXByaW9yaXR5LTAwIGhhcyBiZWVuPGJyPg0KJmd0OyBzdWJt aXR0ZWQgdG8gQ0NBTVAgZm9yIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0ZWQgdG8g TWFudWFsPGJyPg0KJmd0OyBTd2l0Y2ggYW5kIEZvcmNlZCBTd2l0Y2ggYW5kIHRoZWlyIHVzYWdl IHJlbGF0aXZlIHRvIHByaW9yaXRpZXMuPGJyPg0KJmd0OyBUaGUgd2F5IHRoaXMgYmVoYXZpb3Ig aGFzIHRvIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBQU0MgaGFzIHRvIGJlPGJyPg0KJmd0OyBk aXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRvIHJlcGxhY2UgdGhlIGN1cnJlbnQgYmVoYXZp b3Igd2l0aCB0aGU8YnI+DQomZ3Q7IG5ldyBvbmUuIElmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBw cm9jZWRlIGluIHRoYXQgd2F5IHRoaXMgY2FuIGJyaW5nIHRvPGJyPg0KJmd0OyBhIHNpbXBsZSBh bmQgZWZmZWN0aXZlIHdheSB0byBvcGVyYXRlIHRoZSBwcm90b2NvbC48YnI+DQomZ3Q7IDxicj4N CiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1y ZXZlcnRpdmUtMDAgY29udGFpbnMgdGhlIHVwZGF0ZXMgdG8gUkZDNjM3ODxicj4NCiZndDsgdG8g Y2hhbmdlIG5vbi1yZXZlcnRpdmUgb3BlcmF0aW9ucyB0byBiZWhhdmVzIGluIHRoZSBzYW1lIHdh eTxicj4NCiZndDsgaXJyZXNwZWN0aXZlbHkgb2YgdGhlIHRyaWdnZXIgb2YgcHJvdGVjdGlvbiBz d2l0Y2hpbmcgKGZhdWx0IG9yIG9wZXJhdG9yPGJyPg0KJmd0OyBjb21tYW5kIEZTLCBNUykuIENv bnNlcXVlbnRseSBhbiBvcGVyYXRvciBjb21tYW5kLCBNYW51YWwgU3dpdGNoIHRvPGJyPg0KJmd0 OyBXb3JraW5nIChNUy1XKSBhLmsuYSAmcXVvdDtNYW51YWwgc3dpdGNoLW92ZXIgZm9yIHJlY292 ZXJ5IExTUC9zcGFuJnF1b3Q7IGlzIGFsc288YnI+DQomZ3Q7IGFkZGVkIHRvIGVuYWJsZSB0aGlz IGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcsIE1TIHRvPGJyPg0K Jmd0OyB3b3JraW5nIHBhdGggaGFzIGFsc28gdG8gYmUgc3VwcG9ydGVkIHRvIGJlIGFibGUgdG8g aW5pdGlhbGx5IGFsaWduIGF0PGJyPg0KJmd0OyBib3RoIHNpZGVzIGluIGNhc2Ugb2Ygbm9uLXJl dmVydGl2ZSBzd2l0Y2hpbmcgbW9kZS4gTVMgdG8gd29ya2luZyBwYXRoPGJyPg0KJmd0OyBpcyBk ZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My48YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhlIHByb3Bvc2VkIE1TLVcgY29tbWFuZCBpcyBvZiBlcXVhbCBwcmlvcml0eSB0byB0aGUgZXhp c3RpbmcgTVMtUDxicj4NCiZndDsgY29tbWFuZCwgYW5kIHRoZXJlIGlzIHRleHQgdG8gaGFuZGxl IHRoZSBzaW11bHRhbmVvdXMgb3Igc2VxdWVudGlhbDxicj4NCiZndDsgb2NjdXJyZW5jZSBvZiB0 d28gZXF1YWwtcHJpb3JpdHkgY29tbWFuZHMuIFRoaXMgYmVoYXZpb3IsIGFscmVhZHk8YnI+DQom Z3Q7IGFkb3B0ZWQgaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsgcHJvdGVjdGlvbiBzd2l0Y2hp bmcgcHJvdG9jb2wsIGNhbiBiZTxicj4NCiZndDsgdXNlZCBmb3Igb3RoZXIgYWRkaXRpb24gdG8g dGhlIHByb3RvY29sIGluIHRoZSBmdXR1cmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMCBwcm92aWRlcyBleHRl bnNpb25zIHRvIHRoZSBQU0Mgc3RhdGU8YnI+DQomZ3Q7IG1hY2hpbmUgdG8gaGFuZGxlIFNpZ25h bCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmluZSBTRCBvciBwcm92aWRlPGJyPg0KJmd0 OyBzY29wZSBhcm91bmQgd2hlcmUgb3IgaG93IFNEIG1heSBiZSB1c2VkIHNpbWlsYXJseSBhcyBp dCBhbHJlYWR5IGhhcHBlbjxicj4NCiZndDsgaW4gdGhlIGRyYWZ0IGluIGhhbmRsaW5nIG90aGVy IGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZhaWx1cmUpLjxicj4NCiZndDsgSW4gTVBMUy1UUCBz dXJ2aXZhYmlsaXR5IGZyYW1ld29yayBbUkZDNjM3Ml0sIGEgZmF1bHQgY29uZGl0aW9uPGJyPg0K Jmd0OyBpbmNsdWRlcyBib3RoIFNpZ25hbCBGYWlsIChTRikgYW5kIFNpZ25hbCBEZWdyYWRlIChT RCkgdGhhdCBjYW4gYmUgdXNlZDxicj4NCiZndDsgdG8gdHJpZ2dlciBwcm90ZWN0aW9uIHN3aXRj aGluZy48YnI+DQomZ3Q7IFdoaWxlIHRoZSBzdGFuZGFyZGl6YXRpb24gbGFjayBvZiBhbiBTRCBk ZWZpbml0aW9uIGFuZCBkZXRlY3Rpb248YnI+DQomZ3Q7IG1lY2hhbmlzbXMsIHRoZSByZWxldmFu dCBiZWhhdmlvcnMgaW4gdGVybXMgb2YgcHJvdGVjdGlvbiBhY3Rpb25zIG1heTxicj4NCiZndDsg YWxyZWFkeSBiZSBkZWZpbmVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KJmd0OyBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0aGUg RVhFUi9SUiBjb21tYW5kcyB0bzxicj4NCiZndDsgdGVzdCBpZiB0aGUgQVBTIGNvbW11bmljYXRp b24gaXMgb3BlcmF0aW5nIGNvcnJlY3RseS4gSW4gb3RoZXIgd29yZHM8YnI+DQomZ3Q7IGJvdGgg QVBTIHByb2Nlc3MgbG9naWMgaW5jbHVkaW5nIHN0YXRlIG1hY2hpbmUgYW5kIEFQUyBjaGFubmVs IG9uPGJyPg0KJmd0OyBwcm90ZWN0aW9uIHBhdGgsIHdpdGhvdXQgc2VydmljZSBkaXNydXB0aW9u IGFuZCB3aXRob3V0IGFmZmVjdGluZyBhbnk8YnI+DQomZ3Q7IHByb3RlY3Rpb24gb3BlcmF0aW9u LCB1bmxlc3MgdGhlIHByb3RlY3Rpb24gdHJhbnNwb3J0IGVudGl0eSBpcyBpbiB1c2UuPGJyPg0K Jmd0OyBUaGlzIGNvbW1hbmQgaXMgZG9jdW1lbnRlZCBpbiBSODQgb2YgW1JGQzU2NTRdIGFuZCBp dCBpcyBwYXJ0IG9mIElUVS1UPGJyPg0KJmd0OyB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzLjxicj4N CiZndDsgQW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiB0aGUgQXBwZW5k aXggQiBvZiBSRkM2Mzc4IHRoYXQ8YnI+DQomZ3Q7IHV0aWxpemVzIHRoZSBMb2Nrb3V0IG9mIFBy b3RlY3Rpb24gKExPKSBvciBGb3JjZWQgU3dpdGNoIChGUykgaW48YnI+DQomZ3Q7IGNvbWJpbmF0 aW9uIG9mIE9BTSBmdW5jdGlvbmFsaXRpZXMuIEhvd2V2ZXIsIGl0IGhhcyBzb21lIGZ1bmN0aW9u YWw8YnI+DQomZ3Q7IGxpbWl0YXRpb24gYW5kIGhhcyBhIHBvdGVudGlhbCByaXNrIG9mIGxvc2lu ZyB0cmFmZmljIGFzIGEgc2lnbmFsPGJyPg0KJmd0OyBmYWlsdXJlIG1pZ2h0IG9jY3VyIGR1cmlu ZyB0aGUgZXhlcmNpc2Ugb3BlcmF0aW9uLiBJbiB0aGF0IGNhc2UsIExPIG9yPGJyPg0KJmd0OyBG UyBoYXMgdG8gYmUgY2FuY2VsZWQgdG8gYWxsb3cgdGhlIFBTQyBwcm90b2NvbCB0byBwcm92aWRl IHByb3Blcjxicj4NCiZndDsgc3dpdGNoaW5nLjxicj4NCiZndDsgQSBmdXJ0aGVyIGFsdGVybmF0 aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gZHJhZnQtb3Nib3JuZS1tcGxzLXBzYy08YnI+ DQomZ3Q7IGFsaXZlLTAwIHRoYXQgYW55d2F5IHNob3cgc29tZSBmdW5jdGlvbmFsIGxpbWl0YXRp b25zIGJlY2F1c2UgY2Fubm90PGJyPg0KJmd0OyB2YWxpZGF0ZSB0aGUgUFNDIHN0YXRlIG1hY2hp bmUgc3RhdHVzIGFuZCBwcm9iYWJseSB0aGUgTG9jYWwgUmVxdWVzdDxicj4NCiZndDsgbG9naWMu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGF1dGhvcnMgZW5jb3VyYWdlIHRo ZSBJRVRGIGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFmdHMsPGJyPg0KJmd0OyBldmVu dHVhbGx5IHByb3Bvc2luZyBvdGhlciBvcHRpb25zL21lY2hhbmlzbXMgdGhhdCBjYW4gc2F0aXNm eSB0aGUgc2FtZTxicj4NCiZndDsgcmVxdWlyZW1lbnRzLjxicj4NCiZndDsgQmVzdCByZWdhcmRz LDxicj4NCiZndDsgQWxlc3NhbmRybywgSHV1YiwgSmVvbmctZG9uZywgVGFla3NpZDxicj4NCiZn dDsgUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVz Y2x1c2l2YW1lbnRlIGFsbGU8YnI+DQomZ3Q7IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lv bmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZTxicj4NCiZndDsgZGVyaXZhbnRlIGRh bGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGU8 YnI+DQomZ3Q7IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l bnRvIHBlciBlcnJvcmUgc2lldGU8YnI+DQomZ3Q7IGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRh cm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGk8YnI+DQomZ3Q7IHBy b3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS48YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluPGJyPg0KJmd0OyBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0 aGUgYWRkcmVzc2VlKHMpIG9ubHkuPGJyPg0KJmd0OyBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBw cmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC48YnI+DQomZ3Q7 IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZDxicj4NCiZndDsgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHJpc3Bl dHRhIGwnYW1iaWVudGVSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1h aWwgc2Ugbm9uPGJyPg0KJmd0OyDDqCBuZWNlc3NhcmlvLjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxp c3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276800CASMTP2etriinfo_-- From davarish@yahoo.com Mon Jul 22 03:06:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E7721F9A51 for ; Mon, 22 Jul 2013 03:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzT2Craqamj9 for ; Mon, 22 Jul 2013 03:05:53 -0700 (PDT) Received: from nm2-vm6.bullet.mail.ne1.yahoo.com (nm2-vm6.bullet.mail.ne1.yahoo.com [98.138.91.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADB921F848A for ; Mon, 22 Jul 2013 03:05:48 -0700 (PDT) Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2013 10:05:46 -0000 Received: from [98.138.84.39] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2013 10:05:46 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 22 Jul 2013 10:05:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1374487546; bh=lvAoucJP/tGr5VzL8yYbHKLFp5TQjXvr1Y3yuIpwTZ0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=u0Oo3nr+XOsZCNddYlPn6ueWr/OJfYt2PAwjNtKo9x6FiDMGDYyiRqzi8sTa/JGOyIPhmLJ1ftx8faQrHduheICTm4wh228sZAW7DYCxeuQYD/pLQomFpcp1qrjWRG9reoXPLbjxHrJwslEaVLk5oaPCgmT79q9vQOYpP7cNhFY= X-Yahoo-Newman-Id: 472409.4888.bm@smtp107.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gndJrioVM1npsjx9foe_5PikFHOmArt59dWAmz8xVLlB_IY _9ILa_HGVoks_8HHc2AWQTIE5RMYcNknur2iy0tMx7dDuBnokzq79RRM_oK8 ygpo8qtYLvzqDV6608uzWziSnPsRvPyEtsclvpF_nlEZb5UhqpQspajDCrMi MRPdhoi.GxIgfWvRN8JCDz7aHyotqb08.qiWwK7BoFMW4pT7ikdsP4SSVola LBqQUz1TVji1a8ccCSR3hNETpcKul6HDoKcp_CyP9V1PChjGXUWODJosug8q ogJPVM2RBKEXqfGt5Y2ru_OQ0Mh1uYnKRLk.RrvBOnTrAOzXvzaxHPpZIWby .L7lSIkccYQc7cWXG3aqNBOqHvnC6_8cYOloNJ.5Sb9Do02r23._iv4vOM00 PVupeHx1W75ugcWTtwxwMOUB3cxWuzx8pWarCUPf3MeHu8kEVpw43HPn1.KO 7PkWX5glviuJwXY7Lr_Qr7VR7A11pSy0ZnAULNMb_4cgCSPxUsES6cHZDUTx fbZ8fLLY2Z_wYWOgR.a_2YS0- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [10.174.164.17] (davarish@166.147.111.106 with ) by smtp107.mail.ne1.yahoo.com with SMTP; 22 Jul 2013 03:05:46 -0700 PDT References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> Mime-Version: 1.0 (1.0) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> Content-Type: multipart/alternative; boundary=Apple-Mail-AA1E2AE8-28CC-4DC3-9241-797E7364E423 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Mon, 22 Jul 2013 12:05:18 +0200 To: "Ryoo, Jeong-dong" Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 10:06:00 -0000 --Apple-Mail-AA1E2AE8-28CC-4DC3-9241-797E7364E423 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=20 Couple of points. The SD trigger for protection and requires you to run Perf= ormance measurement on all LSPs and PWs, which is not scalable. Also there is no standard method defined to count CCM or BFD packets.=20 Regards, Shahram On Jul 22, 2013, at 10:14 AM, "Ryoo, Jeong-dong" wrote: > Hi, Eric. > =20 > Let me answer your 2nd question on SD. > =20 > SD detection methods defined or proposed for packet transport networks can= be summarized as follows: > - By OAM performance monitoring tool:=20 > SD is raised if packet loss ratio exceeds a threshold during a measureme= nt period. > Threshold value and measurement period are configured by an network oper= ator. > This detection method is already defined in ITU-T G.8021 (Ethernet equip= ment spec.) > and the equipment spec for MPLS-TP can easily follow the same definition= . > - By server layer indication: > SD is raised if a server layer below MPLS-TP reports SD condition on its= own layer. > - By CCM packet counting: > SD is raised if the loss ratio of CCM packets exceeds a threshold during= a measurement period. > =20 > Regardless of how to detect SD, any protection switching documents should d= escribe the protection switching operation once such a SD is declared. > =20 > The proposed draft covers SD-triggered protection no matter what kinds of S= D detection methods are used. > =20 > Regarding the multiple levels of SD: > It is certainly possible to define multiple levels of SD. > But, as far as the protection switching is concerned, it just needs to kno= w if SD is signaled to protection switching process or not.=20 > It would be a network operator's choice at what level of SD he wants his n= etwork protection to switchover. > In other words, what triggers protection switching is SD or no SD. It is y= es or no decision. > =20 > SF can also be viewed as having multiple levels of SF as the network opera= tor can also make a choice on the period/interval of CCM messages. > If CCM is disabled, AIS from a server layer can be used as a trigger for p= rotection switching. So and so forth. > However, protection switching document does not define how to detect SF in= anywhere. > Similary, protection switching document does not define how manual switch a= nd forced switch commands > are initiated in a management system and signaled to protection switching p= rocess. > =20 > Again, in my opinion, the draft on SD protection can accommodate any SD de= tection methods.=20 > =20 > Best regards, > =20 > Jeong-dong > =20 > =20 > =20 > =20 > =20 >=20 > =46rom : "Eric Osborne (eosborne)" > Sent : 2013-07-20 02:48:28 ( +09:00 ) > To : D'Alessandro Alessandro Gerardo , mpls@ietf.org > Cc : Huub helvoort (huub.van.helvoort@huawei.com) , huubatwork@gmail.com > Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear prote= ction protocol to transport requirements >=20 >=20 > Hi Alessandro- >=20 > Thanks for this; the threads I started some time back seem to have died do= wn, it's good to get them going again. > I have two things I never quite understood, can you clarify them for me? >=20 > i) can you explain EXER at a higher level? I'm not looking for a descripti= on of the state machine changes, and I'm not looking for the one line "It al= lows the FSM to be tested". We have all of that in the draft and in the equi= valent ITU specs. >=20 > What I'd like to understand about EXER is where it came from. The ITU spec= s that define it are pretty hard to follow, they seem to assume the reader a= lready knows what EXER is and what problem it solves. It feels very much lik= e a mechanism used to catch a very specific implementation bug, back when tr= ansport gear was far less debuggable than what we have today.=20 >=20 > No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, ISIS= ) have explicit signaling in them just to ask the neighbor whether it *would= * be broken if if were, in the future, to be given a particular input. Part o= f my reluctance to get behind EXER has been that I don't feel comfortable wi= th the idea of keeping a 30-year-old workaround in a protocol. Is there more= to it than that? Have I misread and misunderstood EXER? Does modern transpo= rt gear ever actually detect a problem via EXER/RR that wasn't obvious to th= e operator using other means? >=20 >=20 > ii) Why the push to standardize the SD state changes before we've defined S= D? I certainly agree that handling signal degrade is a good idea, but coming= up with a definition for it has been challenging. What happens if we change= the FSM to handle it, then come up with something more sophisticated (say, m= ultiple levels of SD) that doesn't quite fit with the FSM changes?=20 >=20 >=20 >=20 > thanks! >=20 >=20 >=20 >=20 >=20 > eric >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > D'Alessandro Alessandro Gerardo > > Sent: Wednesday, July 17, 2013 3:23 PM > > To: mpls@ietf.org > > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com > > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear > > protection protocol to transport requirements > >=20 > > Dear all, > > we would like socializing the herebelow drafts that were submitted some > > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T > > transport requirements. I would appreciate your comments about the > > proposed mechanisms and behaviours. > >=20 > > draft-rhd-mpls-tp-psc-priority-00 > > draft-cdh-mpls-tp-psc-non-revertive-00 > > draft-rhd-mpls-tp-psc-sd-00 > > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 > >=20 > > The above drafts cover most of items highlighted in ITU-T liaisons about= > > PSC and they propose solutions in line with MPLS-TP transport > > requirements. > > A list of main liaisons exchanged between ITU-T and IETF with the aim to= > > align PSC behavious with ITU-T transport requirements for linear > > protection are given below: > > https://datatracker.ietf.org/liaison/1162/ (June 2012) > > https://datatracker.ietf.org/liaison/1205/ > > (October 2012) > > https://datatracker.ietf.org/liaison/1229/ > > (January 2013) > > https://datatracker.ietf.org/liaison/1234/ > > (February 2013) > > https://datatracker.ietf.org/liaison/1256/ > > (May 2013) > >=20 > > Some details abou the proposed drafts for align PSC behaviour with > > transport requirements: > >=20 > > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities > > between FS and SF-P (see section 4.3.2 of rfc6378). > > Among the others, behaviors that will be fixed with the proposed update > > are: > > Use case A) At first, working path(WP) and protection path(PP) are > > normal. Then, Forced Switch(FS) command is issued for maintenance on the= > > WP and the traffic moves from WP to PP. When Signal Fail occurs on PP, > > service cannot recover and is interrupted. This could occur for example > > as a result of accidentally un-plugging a PP fiber. > > Use case B) If there is an existing signal fail on a protection path > > (SF-P),and FS command is issued by accident the traffic on WP will move > > to PP. This results in an interruption of service from which you will > > not automatically recover, because PSC should not have switched the > > traffic from WP to PP. > > Discussion about this draft led to the proposal to modify RFC 4427 that > > was "written correctly though lacking in detail causing mis- > > interpretation" that led to the current PSC set of priority that the > > above draft is proposing to modified and to align to the required > > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been > > submitted to CCAMP for clarifying the definitions related to Manual > > Switch and Forced Switch and their usage relative to priorities. > > The way this behavior has to be incorporated into the PSC has to be > > discussed. The text proposes to replace the current behavior with the > > new one. If there is consensus to procede in that way this can bring to > > a simple and effective way to operate the protocol. > >=20 > > ---------------------------------------------------------------------- > > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378 > > to change non-revertive operations to behaves in the same way > > irrespectively of the trigger of protection switching (fault or operator= > > command FS, MS). Consequently an operator command, Manual Switch to > > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is also > > added to enable this behavior. =46rom an operational point of view, MS t= o > > working path has also to be supported to be able to initially align at > > both sides in case of non-revertive switching mode. MS to working path > > is defined in RFC 5654, requirement 83. > >=20 > > The proposed MS-W command is of equal priority to the existing MS-P > > command, and there is text to handle the simultaneous or sequential > > occurrence of two equal-priority commands. This behavior, already > > adopted in other transport network protection switching protocol, can be= > > used for other addition to the protocol in the future. > >=20 > > ---------------------------------------------------------------------- > > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state > > machine to handle Signal Degrade (SD). It does not define SD or provide > > scope around where or how SD may be used similarly as it already happen > > in the draft in handling other defects like SF (Signal Failure). > > In MPLS-TP survivability framework [RFC6372], a fault condition > > includes both Signal Fail (SF) and Signal Degrade (SD) that can be used > > to trigger protection switching. > > While the standardization lack of an SD definition and detection > > mechanisms, the relevant behaviors in terms of protection actions may > > already be defined. > >=20 > > ---------------------------------------------------------------------- > > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to > > test if the APS communication is operating correctly. In other words > > both APS process logic including state machine and APS channel on > > protection path, without service disruption and without affecting any > > protection operation, unless the protection transport entity is in use. > > This command is documented in R84 of [RFC5654] and it is part of ITU-T > > transport requirements. > > An alternative proposal is documented in the Appendix B of RFC6378 that > > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in > > combination of OAM functionalities. However, it has some functional > > limitation and has a potential risk of losing traffic as a signal > > failure might occur during the exercise operation. In that case, LO or > > FS has to be canceled to allow the PSC protocol to provide proper > > switching. > > A further alternative proposal is documented in draft-osborne-mpls-psc- > > alive-00 that anyway show some functional limitations because cannot > > validate the PSC state machine status and probably the Local Request > > logic. > >=20 > >=20 > > The authors encourage the IETF experts to comment on these drafts, > > eventually proposing other options/mechanisms that can satisfy the same > > requirements. > > Best regards, > > Alessandro, Huub, Jeong-dong, Taeksid > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > > persone indicate. La diffusione, copia o qualsiasi altra azione > > derivante dalla conoscenza di queste informazioni sono rigorosamente > > vietate. Qualora abbiate ricevuto questo documento per errore siete > > cortesemente pregati di darne immediata comunicazione al mittente e di > > provvedere alla sua distruzione, Grazie. > >=20 > > This e-mail and any attachments is confidential and may contain > > privileged information intended for the addressee(s) only. > > Dissemination, copying, printing or use by anybody else is unauthorised.= > > If you are not the intended recipient, please delete this message and > > any attachments and advise the sender by return e-mail, Thanks. > >=20 > > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non > > =C3=A8 necessario. >=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 --Apple-Mail-AA1E2AE8-28CC-4DC3-9241-797E7364E423 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi, 

Cou= ple of points. The SD trigger for protection and requires you to run Perform= ance measurement on all LSPs and PWs, which is not scalable.

<= /div>
Also there is no standard method defined to count CCM or BFD packe= ts. 

Regards,
Shahram


On J= ul 22, 2013, at 10:14 AM, "Ryoo, Jeong-dong" <ryoo@etri.re.kr> wrote:

Hi, Eric.
 
Let me answer your 2nd question on SD.=
 
SD detection methods defined or proposed fo= r packet transport networks can be summarized as follows:
- By OAM performance monitoring tool: =
  SD is raised if packet loss rat= io exceeds a threshold during a measurement period.
  Threshold value and measurement peri= od are configured by an network operator.
  This detection method is already defined in ITU-T G.8021 (Ethernet eq= uipment spec.)
  and the equipment spec for MPLS-TP c= an easily follow the same definition.
- By server layer indication:
  SD is raised if a server layer below MPLS-TP reports SD con= dition on its own layer.
- By CCM packet counting:
  SD is raised if the loss ratio of CCM packets exceeds a threshol= d during a measurement period.
 
Regardless of how to detect SD, any protection switching documents= should describe the protection switching operation once such a SD is declar= ed.
 
The proposed draft covers SD-triggered protection no matter what kinds o= f SD detection methods are used.
 
Regarding the multiple levels of SD:
It is certainly possible to define multiple levels of SD.
But, as far as the protection switching is concerned, it just= needs to know if SD is signaled to protection switching process o= r not. 
It would be a network operator's choice at what level of SD he wan= ts his network protection to switchover.
In other words, what triggers protection switching is SD or no SD.= It is yes or no decision.
 
SF can also be viewed as having multiple levels of SF as the netwo= rk operator can also make a choice on the period/interval of CCM messag= es.
If CCM is disabled, AIS from a server layer can be used as a trigger fo= r protection switching. So and so forth.
However, protection switching document does not define how to detect SF= in anywhere.
Similary, protection switching document does not define how manual swit= ch and forced switch commands
are initiated in a management system and signaled to protection switchi= ng process.
 
Again, in my opinion, the draft on SD protection can accommodate any SD= detection methods. 
 
Best regards,
 
Jeong-dong
  
 
 
 
 

=46rom : "Eric Osborne (eosborne)" &= lt;eosborne@cisco.com>
Sent : 2013-07-20 02:48:28 ( +09:00 )
To : D'Alessandro Alessandro Gerardo <alessandro.dalessandro@telecomitalia.it&g= t;, mpls@ietf.org <mpls@ietf.org>
Cc : Huub helvoort (h= uub.van.helvoort@huawei.com) <huub.van.helvoort@huawei.com>, huubatwork@gmail.com <huubatwork@gmail.com>
Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear p= rotection protocol to transport requirements


Hi Alessandro-

Thanks for this; the threads I started some time back seem to have died down= , it's good to get them going again.
I have two things I never quite understood, can you clarify them for me?
=
i) can you explain EXER at a higher level? I'm not looking for a description= of the state machine changes, and I'm not looking for the one line "It allo= ws the FSM to be tested". We have all of that in the draft and in the equiva= lent ITU specs.

What I'd like to understand about EXER is where it came from. The ITU specs t= hat define it are pretty hard to follow, they seem to assume the reader alre= ady knows what EXER is and what problem it solves. It feels very much like a= mechanism used to catch a very specific implementation bug, back when transport gear was far less debuggab= le than what we have today.

No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, ISIS) h= ave explicit signaling in them just to ask the neighbor whether it *would* b= e broken if if were, in the future, to be given a particular input. Part of m= y reluctance to get behind EXER has been that I don't feel comfortable with the idea of keeping a 30-y= ear-old workaround in a protocol. Is there more to it than that? Have I misr= ead and misunderstood EXER? Does modern transport gear ever actually detect a= problem via EXER/RR that wasn't obvious to the operator using other means?


ii) Why the push to standardize the SD state changes before we've defined SD= ? I certainly agree that handling signal degrade is a good idea, but coming u= p with a definition for it has been challenging. What happens if we change t= he FSM to handle it, then come up with something more sophisticated (say, multiple levels of SD) that does= n't quite fit with the FSM changes?



thanks!





eric


> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org= ] On Behalf Of
> D'Alessandro Alessandro Gerardo
> Sent: Wednesday, July 17, 2013 3:23 PM
> To: mpls@ietf.org
> Cc: Huub helvoort (huub= .van.helvoort@huawei.com); huuba= twork@gmail.com
> Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
>
> Dear all,
> we would like socializing the herebelow drafts that were submitted some=
> months ago with the aim to align PSC protocol (RFC 6378) to ITU-T
> transport requirements. I would appreciate your comments about the
> proposed mechanisms and behaviours.
>
> draft-rhd-mpls-tp-psc-priority-00
> draft-cdh-mpls-tp-psc-non-revertive-00
> draft-rhd-mpls-tp-psc-sd-00
> draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00
>
> The above drafts cover most of items highlighted in ITU-T liaisons abou= t
> PSC and they propose solutions in line with MPLS-TP transport
> requirements.
> A list of main liaisons exchanged between ITU-T and IETF with the aim t= o
> align PSC behavious with ITU-T transport requirements for linear
> protection are given below:
> https://datatrac= ker.ietf.org/liaison/1162/ (June 2012)
> https://datatrac= ker.ietf.org/liaison/1205/
> (October 2012)
> https://datatrac= ker.ietf.org/liaison/1229/
> (January 2013)
> https://datatrac= ker.ietf.org/liaison/1234/
> (February 2013)
> https://datatrac= ker.ietf.org/liaison/1256/
> (May 2013)
>
> Some details abou the proposed drafts for align PSC behaviour with
> transport requirements:
>
> draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities
> between FS and SF-P (see section 4.3.2 of rfc6378).
> Among the others, behaviors that will be fixed with the proposed update=
> are:
> Use case A) At first, working path(WP) and protection path(PP) are
> normal. Then, Forced Switch(FS) command is issued for maintenance on th= e
> WP and the traffic moves from WP to PP. When Signal Fail occurs on PP,<= br> > service cannot recover and is interrupted. This could occur for example=
> as a result of accidentally un-plugging a PP fiber.
> Use case B) If there is an existing signal fail on a protection path > (SF-P),and FS command is issued by accident the traffic on WP will move=
> to PP. This results in an interruption of service from which you will > not automatically recover, because PSC should not have switched the
= > traffic from WP to PP.
> Discussion about this draft led to the proposal to modify RFC 4427 that=
> was "written correctly though lacking in detail causing mis-
> interpretation" that led to the current PSC set of priority that the > above draft is proposing to modified and to align to the required
> transport behavior. draft-helvoort-ccamp-fs-priority-00 has been
> submitted to CCAMP for clarifying the definitions related to Manual
= > Switch and Forced Switch and their usage relative to priorities.
> The way this behavior has to be incorporated into the PSC has to be
= > discussed. The text proposes to replace the current behavior with the > new one. If there is consensus to procede in that way this can bring to=
> a simple and effective way to operate the protocol.
>
> ----------------------------------------------------------------------<= br> > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378<= br> > to change non-revertive operations to behaves in the same way
> irrespectively of the trigger of protection switching (fault or operato= r
> command FS, MS). Consequently an operator command, Manual Switch to
= > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is also=
> added to enable this behavior. =46rom an operational point of view, MS t= o
> working path has also to be supported to be able to initially align at<= br> > both sides in case of non-revertive switching mode. MS to working path<= br> > is defined in RFC 5654, requirement 83.
>
> The proposed MS-W command is of equal priority to the existing MS-P
= > command, and there is text to handle the simultaneous or sequential
= > occurrence of two equal-priority commands. This behavior, already
> adopted in other transport network protection switching protocol, can b= e
> used for other addition to the protocol in the future.
>
> ----------------------------------------------------------------------<= br> > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state
> machine to handle Signal Degrade (SD). It does not define SD or provide=
> scope around where or how SD may be used similarly as it already happen=
> in the draft in handling other defects like SF (Signal Failure).
> In MPLS-TP survivability framework [RFC6372], a fault condition
> includes both Signal Fail (SF) and Signal Degrade (SD) that can be used=
> to trigger protection switching.
> While the standardization lack of an SD definition and detection
> mechanisms, the relevant behaviors in terms of protection actions may > already be defined.
>
> ----------------------------------------------------------------------<= br> > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to > test if the APS communication is operating correctly. In other words > both APS process logic including state machine and APS channel on
> protection path, without service disruption and without affecting any > protection operation, unless the protection transport entity is in use.=
> This command is documented in R84 of [RFC5654] and it is part of ITU-T<= br> > transport requirements.
> An alternative proposal is documented in the Appendix B of RFC6378 that=
> utilizes the Lockout of Protection (LO) or Forced Switch (FS) in
> combination of OAM functionalities. However, it has some functional
= > limitation and has a potential risk of losing traffic as a signal
> failure might occur during the exercise operation. In that case, LO or<= br> > FS has to be canceled to allow the PSC protocol to provide proper
> switching.
> A further alternative proposal is documented in draft-osborne-mpls-psc-=
> alive-00 that anyway show some functional limitations because cannot > validate the PSC state machine status and probably the Local Request > logic.
>
>
> The authors encourage the IETF experts to comment on these drafts,
> eventually proposing other options/mechanisms that can satisfy the same=
> requirements.
> Best regards,
> Alessandro, Huub, Jeong-dong, Taeksid
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle=
> persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete
= > cortesemente pregati di darne immediata comunicazione al mittente e di<= br> > provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised= .
> If you are not the intended recipient, please delete this message and > any attachments and advise the sender by return e-mail, Thanks.
>
> rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non=
> =C3=A8 necessario.

_______________________________________________
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
= --Apple-Mail-AA1E2AE8-28CC-4DC3-9241-797E7364E423-- From ryoo@etri.re.kr Mon Jul 22 03:37:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9521E8056 for ; Mon, 22 Jul 2013 03:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnGaIM7MbkmZ for ; Mon, 22 Jul 2013 03:36:53 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id BE07521F8F78 for ; Mon, 22 Jul 2013 03:22:29 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Jul 2013 19:22:27 +0900 Received: from SMTP2.etri.info ([169.254.2.217]) by SMTP1.etri.info ([169.254.1.31]) with mapi id 14.01.0355.002; Mon, 22 Jul 2013 19:22:21 +0900 From: "Ryoo, Jeong-dong" To: "S. Davari" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAT//5h6AIAAl5Xk Date: Mon, 22 Jul 2013 10:22:21 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2768034D@SMTP2.etri.info> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2768034DSMTP2etriinfo_" MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 10:37:06 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2768034DSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwgU2hhaHJhbS4NCg0KVGhlcmUgYXJlIHByb3MgYW5kIGNvbnMgZm9yIGVhY2ggZGV0ZWN0 aW9uIG1ldGhvZC4NClRoZXJlIGhhdmUgYmVlbiBhIGxvdCBvZiBkaXNjdXNzaW9ucyBhbmQgYXJn dWVtZW50cyBhcm91bmQgdGhlIFNEIGRldGVjdGlvbi4NClBlb3BsZSBjYW4gY29udGludWUgdGhl IGRpc2N1c3Npb25zIGFuZCBkZWZpbmUgYW55IGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBpbiBhbnkg cmVsZXZhbnQgc3RhbmRhcmRzIGxhdGVyIG9uLg0KDQpGcm9tIHRoZSB2aWV3cG9pbnQgb2YgcHJv dGVjdGlvbiBzd2l0Y2hpbmcsIHdoYXQgbWF0dGVycyBpcyBob3cgdG8gcHJvdmlkZSBwcm90ZWN0 aW9uIHN3aXRjaGluZyBhZ2FpbnN0IFNEIHdoZW4gaXQgb2NjdXJzLg0KDQpCZXN0IHJlZ2FyZHMs DQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tIDogIlMuIERhdmFyaSIgPGRhdmFyaXNoQHlhaG9vLmNvbT4NClNlbnQgOiAyMDEzLTA3LTIy IDE5OjA2OjExICggKzA5OjAwICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJl LmtyPg0KQ2MgOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSA8ZW9zYm9ybmVAY2lzY28uY29tPiwg RCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyA8YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0 ZWxlY29taXRhbGlhLml0PiwgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIEh1dWIgaGVs dm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pIDxodXViLnZhbi5oZWx2b29ydEBo dWF3ZWkuY29tPiwgaHV1YmF0d29ya0BnbWFpbC5jb20gPGh1dWJhdHdvcmtAZ21haWwuY29tPg0K U3ViamVjdCA6IFJlOiBbbXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQ IFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRz DQoNCkhpLA0KDQpDb3VwbGUgb2YgcG9pbnRzLiBUaGUgU0QgdHJpZ2dlciBmb3IgcHJvdGVjdGlv biBhbmQgcmVxdWlyZXMgeW91IHRvIHJ1biBQZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBvbiBhbGwg TFNQcyBhbmQgUFdzLCB3aGljaCBpcyBub3Qgc2NhbGFibGUuDQoNCkFsc28gdGhlcmUgaXMgbm8g c3RhbmRhcmQgbWV0aG9kIGRlZmluZWQgdG8gY291bnQgQ0NNIG9yIEJGRCBwYWNrZXRzLg0KDQpS ZWdhcmRzLA0KU2hhaHJhbQ0KDQoNCk9uIEp1bCAyMiwgMjAxMywgYXQgMTA6MTQgQU0sICJSeW9v LCBKZW9uZy1kb25nIiA8cnlvb0BldHJpLnJlLmtyPG1haWx0bzpyeW9vQGV0cmkucmUua3I+PiB3 cm90ZToNCg0KSGksIEVyaWMuDQoNCkxldCBtZSBhbnN3ZXIgeW91ciAybmQgcXVlc3Rpb24gb24g U0QuDQoNClNEIGRldGVjdGlvbiBtZXRob2RzIGRlZmluZWQgb3IgcHJvcG9zZWQgZm9yIHBhY2tl dCB0cmFuc3BvcnQgbmV0d29ya3MgY2FuIGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czoNCi0gQnkg T0FNIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdG9vbDoNCiAgU0QgaXMgcmFpc2VkIGlmIHBhY2tl dCBsb3NzIHJhdGlvIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5nIGEgbWVhc3VyZW1lbnQgcGVy aW9kLg0KICBUaHJlc2hvbGQgdmFsdWUgYW5kIG1lYXN1cmVtZW50IHBlcmlvZCBhcmUgY29uZmln dXJlZCBieSBhbiBuZXR3b3JrIG9wZXJhdG9yLg0KICBUaGlzIGRldGVjdGlvbiBtZXRob2QgaXMg YWxyZWFkeSBkZWZpbmVkIGluIElUVS1UIEcuODAyMSAoRXRoZXJuZXQgZXF1aXBtZW50IHNwZWMu KQ0KICBhbmQgdGhlIGVxdWlwbWVudCBzcGVjIGZvciBNUExTLVRQIGNhbiBlYXNpbHkgZm9sbG93 IHRoZSBzYW1lIGRlZmluaXRpb24uDQotIEJ5IHNlcnZlciBsYXllciBpbmRpY2F0aW9uOg0KICBT RCBpcyByYWlzZWQgaWYgYSBzZXJ2ZXIgbGF5ZXIgYmVsb3cgTVBMUy1UUCByZXBvcnRzIFNEIGNv bmRpdGlvbiBvbiBpdHMgb3duIGxheWVyLg0KLSBCeSBDQ00gcGFja2V0IGNvdW50aW5nOg0KICBT RCBpcyByYWlzZWQgaWYgdGhlIGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhjZWVkcyBhIHRo cmVzaG9sZCBkdXJpbmcgYSBtZWFzdXJlbWVudCBwZXJpb2QuDQoNClJlZ2FyZGxlc3Mgb2YgaG93 IHRvIGRldGVjdCBTRCwgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50cyBzaG91bGQg ZGVzY3JpYmUgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9wZXJhdGlvbiBvbmNlIHN1Y2ggYSBT RCBpcyBkZWNsYXJlZC4NCg0KVGhlIHByb3Bvc2VkIGRyYWZ0IGNvdmVycyBTRC10cmlnZ2VyZWQg cHJvdGVjdGlvbiBubyBtYXR0ZXIgd2hhdCBraW5kcyBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBh cmUgdXNlZC4NCg0KUmVnYXJkaW5nIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgU0Q6DQpJdCBpcyBj ZXJ0YWlubHkgcG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC4NCkJ1dCwg YXMgZmFyIGFzIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjb25jZXJuZWQsIGl0IGp1c3Qg bmVlZHMgdG8ga25vdyBpZiBTRCBpcyBzaWduYWxlZCB0byBwcm90ZWN0aW9uIHN3aXRjaGluZyBw cm9jZXNzIG9yIG5vdC4NCkl0IHdvdWxkIGJlIGEgbmV0d29yayBvcGVyYXRvcidzIGNob2ljZSBh dCB3aGF0IGxldmVsIG9mIFNEIGhlIHdhbnRzIGhpcyBuZXR3b3JrIHByb3RlY3Rpb24gdG8gc3dp dGNob3Zlci4NCkluIG90aGVyIHdvcmRzLCB3aGF0IHRyaWdnZXJzIHByb3RlY3Rpb24gc3dpdGNo aW5nIGlzIFNEIG9yIG5vIFNELiBJdCBpcyB5ZXMgb3Igbm8gZGVjaXNpb24uDQoNClNGIGNhbiBh bHNvIGJlIHZpZXdlZCBhcyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFzIHRoZSBuZXR3 b3JrIG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZh bCBvZiBDQ00gbWVzc2FnZXMuDQpJZiBDQ00gaXMgZGlzYWJsZWQsIEFJUyBmcm9tIGEgc2VydmVy IGxheWVyIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlciBmb3IgcHJvdGVjdGlvbiBzd2l0Y2hpbmcu IFNvIGFuZCBzbyBmb3J0aC4NCkhvd2V2ZXIsIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50 IGRvZXMgbm90IGRlZmluZSBob3cgdG8gZGV0ZWN0IFNGIGluIGFueXdoZXJlLg0KU2ltaWxhcnks IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgbWFudWFs IHN3aXRjaCBhbmQgZm9yY2VkIHN3aXRjaCBjb21tYW5kcw0KYXJlIGluaXRpYXRlZCBpbiBhIG1h bmFnZW1lbnQgc3lzdGVtIGFuZCBzaWduYWxlZCB0byBwcm90ZWN0aW9uIHN3aXRjaGluZyBwcm9j ZXNzLg0KDQpBZ2FpbiwgaW4gbXkgb3BpbmlvbiwgdGhlIGRyYWZ0IG9uIFNEIHByb3RlY3Rpb24g Y2FuIGFjY29tbW9kYXRlIGFueSBTRCBkZXRlY3Rpb24gbWV0aG9kcy4NCg0KQmVzdCByZWdhcmRz LA0KDQpKZW9uZy1kb25nDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbSA6ICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNv bTxtYWlsdG86ZW9zYm9ybmVAY2lzY28uY29tPj4NClNlbnQgOiAyMDEzLTA3LTIwIDAyOjQ4OjI4 ICggKzA5OjAwICkNClRvIDogRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyA8YWxlc3Nh bmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0PG1haWx0bzphbGVzc2FuZHJvLmRhbGVz c2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ+PiwgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4gPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pg0KQ2MgOiBIdXViIGhl bHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPG1haWx0bzpodXViLnZhbi5oZWx2 b29ydEBodWF3ZWkuY29tPikgPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb208bWFpbHRvOmh1 dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+PiwgaHV1YmF0d29ya0BnbWFpbC5jb208bWFpbHRv Omh1dWJhdHdvcmtAZ21haWwuY29tPiA8aHV1YmF0d29ya0BnbWFpbC5jb208bWFpbHRvOmh1dWJh dHdvcmtAZ21haWwuY29tPj4NClN1YmplY3QgOiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBm b3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJh bnNwb3J0IHJlcXVpcmVtZW50cw0KDQoNCkhpIEFsZXNzYW5kcm8tDQoNClRoYW5rcyBmb3IgdGhp czsgdGhlIHRocmVhZHMgSSBzdGFydGVkIHNvbWUgdGltZSBiYWNrIHNlZW0gdG8gaGF2ZSBkaWVk IGRvd24sIGl0J3MgZ29vZCB0byBnZXQgdGhlbSBnb2luZyBhZ2Fpbi4NCkkgaGF2ZSB0d28gdGhp bmdzIEkgbmV2ZXIgcXVpdGUgdW5kZXJzdG9vZCwgY2FuIHlvdSBjbGFyaWZ5IHRoZW0gZm9yIG1l Pw0KDQppKSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBsZXZlbD8gSSdtIG5vdCBs b29raW5nIGZvciBhIGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGNoYW5nZXMsIGFu ZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZSBvbmUgbGluZSAiSXQgYWxsb3dzIHRoZSBGU00gdG8g YmUgdGVzdGVkIi4gV2UgaGF2ZSBhbGwgb2YgdGhhdCBpbiB0aGUgZHJhZnQgYW5kIGluIHRoZSBl cXVpdmFsZW50IElUVSBzcGVjcy4NCg0KV2hhdCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0 IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9tLiBUaGUgSVRVIHNwZWNzIHRoYXQgZGVmaW5lIGl0 IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3csIHRoZXkgc2VlbSB0byBhc3N1bWUgdGhlIHJlYWRl ciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBpcyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4g SXQgZmVlbHMgdmVyeSBtdWNoIGxpa2UgYSBtZWNoYW5pc20gdXNlZCB0byBjYXRjaCBhIHZlcnkg c3BlY2lmaWMgaW1wbGVtZW50YXRpb24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2Fz IGZhciBsZXNzIGRlYnVnZ2FibGUgdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuDQoNCk5vIG90aGVy IHN0YXRlIG1hY2hpbmVzIHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwgQkdQLCBP U1BGLCBJU0lTKSBoYXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRo ZSBuZWlnaGJvciB3aGV0aGVyIGl0ICp3b3VsZCogYmUgYnJva2VuIGlmIGlmIHdlcmUsIGluIHRo ZSBmdXR1cmUsIHRvIGJlIGdpdmVuIGEgcGFydGljdWxhciBpbnB1dC4gUGFydCBvZiBteSByZWx1 Y3RhbmNlIHRvIGdldCBiZWhpbmQgRVhFUiBoYXMgYmVlbiB0aGF0IEkgZG9uJ3QgZmVlbCBjb21m b3J0YWJsZSB3aXRoIHRoZSBpZGVhIG9mIGtlZXBpbmcgYSAzMC15ZWFyLW9sZCB3b3JrYXJvdW5k IGluIGEgcHJvdG9jb2wuIElzIHRoZXJlIG1vcmUgdG8gaXQgdGhhbiB0aGF0PyBIYXZlIEkgbWlz cmVhZCBhbmQgbWlzdW5kZXJzdG9vZCBFWEVSPyBEb2VzIG1vZGVybiB0cmFuc3BvcnQgZ2VhciBl dmVyIGFjdHVhbGx5IGRldGVjdCBhIHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3YXNuJ3Qgb2J2 aW91cyB0byB0aGUgb3BlcmF0b3IgdXNpbmcgb3RoZXIgbWVhbnM/DQoNCg0KaWkpIFdoeSB0aGUg cHVzaCB0byBzdGFuZGFyZGl6ZSB0aGUgU0Qgc3RhdGUgY2hhbmdlcyBiZWZvcmUgd2UndmUgZGVm aW5lZCBTRD8gSSBjZXJ0YWlubHkgYWdyZWUgdGhhdCBoYW5kbGluZyBzaWduYWwgZGVncmFkZSBp cyBhIGdvb2QgaWRlYSwgYnV0IGNvbWluZyB1cCB3aXRoIGEgZGVmaW5pdGlvbiBmb3IgaXQgaGFz IGJlZW4gY2hhbGxlbmdpbmcuIFdoYXQgaGFwcGVucyBpZiB3ZSBjaGFuZ2UgdGhlIEZTTSB0byBo YW5kbGUgaXQsIHRoZW4gY29tZSB1cCB3aXRoIHNvbWV0aGluZyBtb3JlIHNvcGhpc3RpY2F0ZWQg KHNheSwgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEKSB0aGF0IGRvZXNuJ3QgcXVpdGUgZml0IHdpdGgg dGhlIEZTTSBjaGFuZ2VzPw0KDQoNCg0KdGhhbmtzIQ0KDQoNCg0KDQoNCmVyaWMNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDM6MjMgUE0NCj4gVG86IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2 b29ydEBodWF3ZWkuY29tPG1haWx0bzpodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPik7IGh1 dWJhdHdvcmtAZ21haWwuY29tPG1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4NCj4gU3ViamVj dDogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFy DQo+IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPg0KPiBE ZWFyIGFsbCwNCj4gd2Ugd291bGQgbGlrZSBzb2NpYWxpemluZyB0aGUgaGVyZWJlbG93IGRyYWZ0 cyB0aGF0IHdlcmUgc3VibWl0dGVkIHNvbWUNCj4gbW9udGhzIGFnbyB3aXRoIHRoZSBhaW0gdG8g YWxpZ24gUFNDIHByb3RvY29sIChSRkMgNjM3OCkgdG8gSVRVLVQNCj4gdHJhbnNwb3J0IHJlcXVp cmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYWJvdXQgdGhlDQo+IHBy b3Bvc2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91cnMuDQo+DQo+IGRyYWZ0LXJoZC1tcGxzLXRw LXBzYy1wcmlvcml0eS0wMA0KPiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0w MA0KPiBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDANCj4gZHJhZnQtZGotbXBscy10cC1leGVy LXBzYy0wMSAvIGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtYWxpdmUtMDANCj4NCj4gVGhlIGFib3Zl IGRyYWZ0cyBjb3ZlciBtb3N0IG9mIGl0ZW1zIGhpZ2hsaWdodGVkIGluIElUVS1UIGxpYWlzb25z IGFib3V0DQo+IFBTQyBhbmQgdGhleSBwcm9wb3NlIHNvbHV0aW9ucyBpbiBsaW5lIHdpdGggTVBM Uy1UUCB0cmFuc3BvcnQNCj4gcmVxdWlyZW1lbnRzLg0KPiBBIGxpc3Qgb2YgbWFpbiBsaWFpc29u cyBleGNoYW5nZWQgYmV0d2VlbiBJVFUtVCBhbmQgSUVURiB3aXRoIHRoZSBhaW0gdG8NCj4gYWxp Z24gUFNDIGJlaGF2aW91cyB3aXRoIElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMgZm9yIGxp bmVhcg0KPiBwcm90ZWN0aW9uIGFyZSBnaXZlbiBiZWxvdzoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9saWFpc29uLzExNjIvIChKdW5lIDIwMTIpDQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjA1Lw0KPiAoT2N0b2JlciAyMDEyKQ0KPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIyOS8NCj4gKEphbnVhcnkgMjAxMykNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvDQo+IChGZWJydWFyeSAyMDEz KQ0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni8NCj4gKE1heSAy MDEzKQ0KPg0KPiBTb21lIGRldGFpbHMgYWJvdSB0aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGln biBQU0MgYmVoYXZpb3VyIHdpdGgNCj4gdHJhbnNwb3J0IHJlcXVpcmVtZW50czoNCj4NCj4gZHJh ZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwIHByb3Bvc2VzIHN3YXBwaW5nIHRoZSBwcmlv cml0aWVzDQo+IGJldHdlZW4gRlMgYW5kIFNGLVAgKHNlZSBzZWN0aW9uIDQuMy4yIG9mIHJmYzYz NzgpLg0KPiBBbW9uZyB0aGUgb3RoZXJzLCBiZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdp dGggdGhlIHByb3Bvc2VkIHVwZGF0ZQ0KPiBhcmU6DQo+IFVzZSBjYXNlIEEpIEF0IGZpcnN0LCB3 b3JraW5nIHBhdGgoV1ApIGFuZCBwcm90ZWN0aW9uIHBhdGgoUFApIGFyZQ0KPiBub3JtYWwuIFRo ZW4sIEZvcmNlZCBTd2l0Y2goRlMpIGNvbW1hbmQgaXMgaXNzdWVkIGZvciBtYWludGVuYW5jZSBv biB0aGUNCj4gV1AgYW5kIHRoZSB0cmFmZmljIG1vdmVzIGZyb20gV1AgdG8gUFAuIFdoZW4gU2ln bmFsIEZhaWwgb2NjdXJzIG9uIFBQLA0KPiBzZXJ2aWNlIGNhbm5vdCByZWNvdmVyIGFuZCBpcyBp bnRlcnJ1cHRlZC4gVGhpcyBjb3VsZCBvY2N1ciBmb3IgZXhhbXBsZQ0KPiBhcyBhIHJlc3VsdCBv ZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci4NCj4gVXNlIGNhc2UgQikgSWYg dGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFsIGZhaWwgb24gYSBwcm90ZWN0aW9uIHBhdGgNCj4g KFNGLVApLGFuZCBGUyBjb21tYW5kIGlzIGlzc3VlZCBieSBhY2NpZGVudCB0aGUgdHJhZmZpYyBv biBXUCB3aWxsIG1vdmUNCj4gdG8gUFAuIFRoaXMgcmVzdWx0cyBpbiBhbiBpbnRlcnJ1cHRpb24g b2Ygc2VydmljZSBmcm9tIHdoaWNoIHlvdSB3aWxsDQo+IG5vdCBhdXRvbWF0aWNhbGx5IHJlY292 ZXIsIGJlY2F1c2UgUFNDIHNob3VsZCBub3QgaGF2ZSBzd2l0Y2hlZCB0aGUNCj4gdHJhZmZpYyBm cm9tIFdQIHRvIFBQLg0KPiBEaXNjdXNzaW9uIGFib3V0IHRoaXMgZHJhZnQgbGVkIHRvIHRoZSBw cm9wb3NhbCB0byBtb2RpZnkgUkZDIDQ0MjcgdGhhdA0KPiB3YXMgIndyaXR0ZW4gY29ycmVjdGx5 IHRob3VnaCBsYWNraW5nIGluIGRldGFpbCBjYXVzaW5nIG1pcy0NCj4gaW50ZXJwcmV0YXRpb24i IHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBzZXQgb2YgcHJpb3JpdHkgdGhhdCB0aGUNCj4g YWJvdmUgZHJhZnQgaXMgcHJvcG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBhbGlnbiB0byB0aGUg cmVxdWlyZWQNCj4gdHJhbnNwb3J0IGJlaGF2aW9yLiBkcmFmdC1oZWx2b29ydC1jY2FtcC1mcy1w cmlvcml0eS0wMCBoYXMgYmVlbg0KPiBzdWJtaXR0ZWQgdG8gQ0NBTVAgZm9yIGNsYXJpZnlpbmcg dGhlIGRlZmluaXRpb25zIHJlbGF0ZWQgdG8gTWFudWFsDQo+IFN3aXRjaCBhbmQgRm9yY2VkIFN3 aXRjaCBhbmQgdGhlaXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJpb3JpdGllcy4NCj4gVGhlIHdheSB0 aGlzIGJlaGF2aW9yIGhhcyB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDIGhhcyB0byBi ZQ0KPiBkaXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRvIHJlcGxhY2UgdGhlIGN1cnJlbnQg YmVoYXZpb3Igd2l0aCB0aGUNCj4gbmV3IG9uZS4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHBy b2NlZGUgaW4gdGhhdCB3YXkgdGhpcyBjYW4gYnJpbmcgdG8NCj4gYSBzaW1wbGUgYW5kIGVmZmVj dGl2ZSB3YXkgdG8gb3BlcmF0ZSB0aGUgcHJvdG9jb2wuDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g ZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAgY29udGFpbnMgdGhlIHVwZGF0 ZXMgdG8gUkZDNjM3OA0KPiB0byBjaGFuZ2Ugbm9uLXJldmVydGl2ZSBvcGVyYXRpb25zIHRvIGJl aGF2ZXMgaW4gdGhlIHNhbWUgd2F5DQo+IGlycmVzcGVjdGl2ZWx5IG9mIHRoZSB0cmlnZ2VyIG9m IHByb3RlY3Rpb24gc3dpdGNoaW5nIChmYXVsdCBvciBvcGVyYXRvcg0KPiBjb21tYW5kIEZTLCBN UykuIENvbnNlcXVlbnRseSBhbiBvcGVyYXRvciBjb21tYW5kLCBNYW51YWwgU3dpdGNoIHRvDQo+ IFdvcmtpbmcgKE1TLVcpIGEuay5hICJNYW51YWwgc3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExT UC9zcGFuIiBpcyBhbHNvDQo+IGFkZGVkIHRvIGVuYWJsZSB0aGlzIGJlaGF2aW9yLiBGcm9tIGFu IG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcsIE1TIHRvDQo+IHdvcmtpbmcgcGF0aCBoYXMgYWxz byB0byBiZSBzdXBwb3J0ZWQgdG8gYmUgYWJsZSB0byBpbml0aWFsbHkgYWxpZ24gYXQNCj4gYm90 aCBzaWRlcyBpbiBjYXNlIG9mIG5vbi1yZXZlcnRpdmUgc3dpdGNoaW5nIG1vZGUuIE1TIHRvIHdv cmtpbmcgcGF0aA0KPiBpcyBkZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My4NCj4N Cj4gVGhlIHByb3Bvc2VkIE1TLVcgY29tbWFuZCBpcyBvZiBlcXVhbCBwcmlvcml0eSB0byB0aGUg ZXhpc3RpbmcgTVMtUA0KPiBjb21tYW5kLCBhbmQgdGhlcmUgaXMgdGV4dCB0byBoYW5kbGUgdGhl IHNpbXVsdGFuZW91cyBvciBzZXF1ZW50aWFsDQo+IG9jY3VycmVuY2Ugb2YgdHdvIGVxdWFsLXBy aW9yaXR5IGNvbW1hbmRzLiBUaGlzIGJlaGF2aW9yLCBhbHJlYWR5DQo+IGFkb3B0ZWQgaW4gb3Ro ZXIgdHJhbnNwb3J0IG5ldHdvcmsgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdG9jb2wsIGNhbiBi ZQ0KPiB1c2VkIGZvciBvdGhlciBhZGRpdGlvbiB0byB0aGUgcHJvdG9jb2wgaW4gdGhlIGZ1dHVy ZS4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDAgcHJv dmlkZXMgZXh0ZW5zaW9ucyB0byB0aGUgUFNDIHN0YXRlDQo+IG1hY2hpbmUgdG8gaGFuZGxlIFNp Z25hbCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmluZSBTRCBvciBwcm92aWRlDQo+IHNj b3BlIGFyb3VuZCB3aGVyZSBvciBob3cgU0QgbWF5IGJlIHVzZWQgc2ltaWxhcmx5IGFzIGl0IGFs cmVhZHkgaGFwcGVuDQo+IGluIHRoZSBkcmFmdCBpbiBoYW5kbGluZyBvdGhlciBkZWZlY3RzIGxp a2UgU0YgKFNpZ25hbCBGYWlsdXJlKS4NCj4gSW4gTVBMUy1UUCBzdXJ2aXZhYmlsaXR5IGZyYW1l d29yayBbUkZDNjM3Ml0sIGEgZmF1bHQgY29uZGl0aW9uDQo+IGluY2x1ZGVzIGJvdGggU2lnbmFs IEZhaWwgKFNGKSBhbmQgU2lnbmFsIERlZ3JhZGUgKFNEKSB0aGF0IGNhbiBiZSB1c2VkDQo+IHRv IHRyaWdnZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQo+IFdoaWxlIHRoZSBzdGFuZGFyZGl6YXRp b24gbGFjayBvZiBhbiBTRCBkZWZpbml0aW9uIGFuZCBkZXRlY3Rpb24NCj4gbWVjaGFuaXNtcywg dGhlIHJlbGV2YW50IGJlaGF2aW9ycyBpbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFjdGlvbnMgbWF5 DQo+IGFscmVhZHkgYmUgZGVmaW5lZC4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBkcmFmdC1kai1t cGxzLXRwLWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0aGUgRVhFUi9SUiBjb21tYW5kcyB0 bw0KPiB0ZXN0IGlmIHRoZSBBUFMgY29tbXVuaWNhdGlvbiBpcyBvcGVyYXRpbmcgY29ycmVjdGx5 LiBJbiBvdGhlciB3b3Jkcw0KPiBib3RoIEFQUyBwcm9jZXNzIGxvZ2ljIGluY2x1ZGluZyBzdGF0 ZSBtYWNoaW5lIGFuZCBBUFMgY2hhbm5lbCBvbg0KPiBwcm90ZWN0aW9uIHBhdGgsIHdpdGhvdXQg c2VydmljZSBkaXNydXB0aW9uIGFuZCB3aXRob3V0IGFmZmVjdGluZyBhbnkNCj4gcHJvdGVjdGlv biBvcGVyYXRpb24sIHVubGVzcyB0aGUgcHJvdGVjdGlvbiB0cmFuc3BvcnQgZW50aXR5IGlzIGlu IHVzZS4NCj4gVGhpcyBjb21tYW5kIGlzIGRvY3VtZW50ZWQgaW4gUjg0IG9mIFtSRkM1NjU0XSBh bmQgaXQgaXMgcGFydCBvZiBJVFUtVA0KPiB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzLg0KPiBBbiBh bHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIHRoZSBBcHBlbmRpeCBCIG9mIFJG QzYzNzggdGhhdA0KPiB1dGlsaXplcyB0aGUgTG9ja291dCBvZiBQcm90ZWN0aW9uIChMTykgb3Ig Rm9yY2VkIFN3aXRjaCAoRlMpIGluDQo+IGNvbWJpbmF0aW9uIG9mIE9BTSBmdW5jdGlvbmFsaXRp ZXMuIEhvd2V2ZXIsIGl0IGhhcyBzb21lIGZ1bmN0aW9uYWwNCj4gbGltaXRhdGlvbiBhbmQgaGFz IGEgcG90ZW50aWFsIHJpc2sgb2YgbG9zaW5nIHRyYWZmaWMgYXMgYSBzaWduYWwNCj4gZmFpbHVy ZSBtaWdodCBvY2N1ciBkdXJpbmcgdGhlIGV4ZXJjaXNlIG9wZXJhdGlvbi4gSW4gdGhhdCBjYXNl LCBMTyBvcg0KPiBGUyBoYXMgdG8gYmUgY2FuY2VsZWQgdG8gYWxsb3cgdGhlIFBTQyBwcm90b2Nv bCB0byBwcm92aWRlIHByb3Blcg0KPiBzd2l0Y2hpbmcuDQo+IEEgZnVydGhlciBhbHRlcm5hdGl2 ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtDQo+IGFs aXZlLTAwIHRoYXQgYW55d2F5IHNob3cgc29tZSBmdW5jdGlvbmFsIGxpbWl0YXRpb25zIGJlY2F1 c2UgY2Fubm90DQo+IHZhbGlkYXRlIHRoZSBQU0Mgc3RhdGUgbWFjaGluZSBzdGF0dXMgYW5kIHBy b2JhYmx5IHRoZSBMb2NhbCBSZXF1ZXN0DQo+IGxvZ2ljLg0KPg0KPg0KPiBUaGUgYXV0aG9ycyBl bmNvdXJhZ2UgdGhlIElFVEYgZXhwZXJ0cyB0byBjb21tZW50IG9uIHRoZXNlIGRyYWZ0cywNCj4g ZXZlbnR1YWxseSBwcm9wb3Npbmcgb3RoZXIgb3B0aW9ucy9tZWNoYW5pc21zIHRoYXQgY2FuIHNh dGlzZnkgdGhlIHNhbWUNCj4gcmVxdWlyZW1lbnRzLg0KPiBCZXN0IHJlZ2FyZHMsDQo+IEFsZXNz YW5kcm8sIEh1dWIsIEplb25nLWRvbmcsIFRhZWtzaWQNCj4gUXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUNCj4gcGVy c29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXpp b25lDQo+IGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkg c29ubyByaWdvcm9zYW1lbnRlDQo+IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBx dWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUNCj4gY29ydGVzZW1lbnRlIHByZWdhdGkg ZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaQ0KPiBwcm92 dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQo+DQo+IFRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbg0KPiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuDQo+ IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2Ug aXMgdW5hdXRob3Jpc2VkLg0KPiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQNCj4gYW55IGF0dGFjaG1lbnRzIGFuZCBh ZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQo+DQo+IHJpc3BldHRh IGwnYW1iaWVudGVSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwg c2Ugbm9uDQo+IMOoIG5lY2Vzc2FyaW8uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1w bHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2768034DSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQpIaSwgU2hhaHJhbS48L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij5UaGVyZSBhcmUgcHJvcyBhbmQgY29ucyBmb3IgZWFjaCBkZXRlY3Rp b24gbWV0aG9kLg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+VGhlcmUg aGF2ZSBiZWVuIGEgbG90IG9mIGRpc2N1c3Npb25zIGFuZCBhcmd1ZW1lbnRzIGFyb3VuZCZuYnNw O3RoZSZuYnNwO1NEIGRldGVjdGlvbi48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij5QZW9wbGUgY2FuIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9ucyBhbmQgZGVmaW5lIGFueSBh ZGRpdGlvbmFsIG1lY2hhbmlzbXMgaW4gYW55IHJlbGV2YW50IHN0YW5kYXJkcyZuYnNwO2xhdGVy IG9uLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkZyb20gdGhlIHZpZXdwb2ludCBvZiBwcm90 ZWN0aW9uIHN3aXRjaGluZywgd2hhdCBtYXR0ZXJzIGlzIGhvdyB0byBwcm92aWRlIHByb3RlY3Rp b24gc3dpdGNoaW5nIGFnYWluc3QgU0Qgd2hlbiBpdCBvY2N1cnMuPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRv bmc8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQombmJzcDs8L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZx dW90O1MuIERhdmFyaSZxdW90OyAmbHQ7ZGF2YXJpc2hAeWFob28uY29tJmd0Ozxicj4NCjxiPlNl bnQgOiA8L2I+MjAxMy0wNy0yMiAxOTowNjoxMSAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDog PC9iPlJ5b28sIEplb25nLWRvbmcgJmx0O3J5b29AZXRyaS5yZS5rciZndDs8YnI+DQo8Yj5DYyA6 IDwvYj5FcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSAmbHQ7ZW9zYm9ybmVAY2lzY28uY29tJmd0Oywg RCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyAmbHQ7YWxlc3NhbmRyby5kYWxlc3NhbmRy b0B0ZWxlY29taXRhbGlhLml0Jmd0OywgbXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZn dDssIEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pICZsdDtodXVi LnZhbi5oZWx2b29ydEBodWF3ZWkuY29tJmd0OywgaHV1YmF0d29ya0BnbWFpbC5jb20NCiAmbHQ7 aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5SZTogW21wbHNd IHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rp b24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50czxicj4NCjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkhpLCZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPkNvdXBsZSBvZiBwb2ludHMuIFRoZSBTRCB0cmlnZ2VyIGZvciBwcm90ZWN0aW9u IGFuZCByZXF1aXJlcyB5b3UgdG8gcnVuIFBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG9uIGFsbCBM U1BzIGFuZCBQV3MsIHdoaWNoIGlzIG5vdCBzY2FsYWJsZS48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij5BbHNvIHRoZXJlIGlzIG5vIHN0YW5kYXJkIG1ldGhvZCBkZWZpbmVkIHRvIGNvdW50IEND TSBvciBCRkQgcGFja2V0cy4mbmJzcDs8YnI+DQo8YnI+DQpSZWdhcmRzLA0KPGRpdj5TaGFocmFt PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+PGJyPg0KT24gSnVsIDIyLCAyMDEzLCBhdCAxMDoxNCBBTSwgJnF1b3Q7Unlvbywg SmVvbmctZG9uZyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ5b29AZXRyaS5yZS5rciIgdGFy Z2V0PSJfYmxhbmsiPnJ5b29AZXRyaS5yZS5rcjwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiB0eXBlPSJjaXRlIj4N CjxkaXY+PHN0eWxlPlAgewoJTUFSR0lOLVRPUDogMG1tOyBNQVJHSU4tQk9UVE9NOiAwbW0KfQo8 L3N0eWxlPg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQi IGlkPSJlekZvcm1Qcm9jX2RpdiI+DQo8ZGl2IHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWwiIGlk PSJtc2dib2R5Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SGksIEVy aWMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+TGV0IG1lIGFuc3dlciZuYnNwO3lvdXIgMm5k IHF1ZXN0aW9uIG9uIFNELjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZu YnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlNEIGRldGVjdGlvbiBt ZXRob2RzIGRlZmluZWQgb3IgcHJvcG9zZWQgZm9yIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3Mg Y2FuIGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij4tIEJ5IE9BTSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIHRvb2w6Jm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7IFNEIGlzJm5ic3A7cmFp c2VkIGlmIHBhY2tldCBsb3NzIHJhdGlvIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5nIGEgbWVh c3VyZW1lbnQgcGVyaW9kLg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ Jm5ic3A7IFRocmVzaG9sZCB2YWx1ZSBhbmQgbWVhc3VyZW1lbnQgcGVyaW9kIGFyZSBjb25maWd1 cmVkIGJ5IGFuIG5ldHdvcmsgb3BlcmF0b3IuPGJyPg0KJm5ic3A7IFRoaXMgZGV0ZWN0aW9uIG1l dGhvZCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gSVRVLVQgRy44MDIxIChFdGhlcm5ldCBlcXVpcG1l bnQgc3BlYy4pDQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDsg YW5kIHRoZSBlcXVpcG1lbnQgc3BlYyBmb3IgTVBMUy1UUCBjYW4gZWFzaWx5IGZvbGxvdyB0aGUg c2FtZSBkZWZpbml0aW9uLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPi0g Qnkgc2VydmVyIGxheWVyIGluZGljYXRpb246PC9kaXY+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5i c3A7U0QgaXMgcmFpc2VkIGlmIGEgc2VydmVyIGxheWVyIGJlbG93IE1QTFMtVFAgcmVwb3J0cyBT RCBjb25kaXRpb24gb24gaXRzIG93biBsYXllci48L2Rpdj4NCjxkaXY+LSBCeSBDQ00gcGFja2V0 IGNvdW50aW5nOjwvZGl2Pg0KPGRpdj4mbmJzcDsgU0QgaXMgcmFpc2VkIGlmIHRoZSBsb3NzIHJh dGlvIG9mIENDTSBwYWNrZXRzIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5nIGEgbWVhc3VyZW1l bnQgcGVyaW9kLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnYXJkbGVzcyBvZiBo b3cgdG8gZGV0ZWN0IFNELCBhbnkgcHJvdGVjdGlvbiZuYnNwO3N3aXRjaGluZyBkb2N1bWVudHMg c2hvdWxkIGRlc2NyaWJlIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBvcGVyYXRpb24gb25jZSBz dWNoIGEgU0QgaXMgZGVjbGFyZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUg cHJvcG9zZWQgZHJhZnQgY292ZXJzIFNELXRyaWdnZXJlZCBwcm90ZWN0aW9uIG5vIG1hdHRlciB3 aGF0IGtpbmRzIG9mIFNEIGRldGVjdGlvbiBtZXRob2RzIGFyZSB1c2VkLjwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+UmVnYXJkaW5nIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgU0Q6PC9k aXY+DQo8ZGl2Pkl0IGlzJm5ic3A7Y2VydGFpbmx5IHBvc3NpYmxlIHRvIGRlZmluZSBtdWx0aXBs ZSBsZXZlbHMgb2YgU0QuPC9kaXY+DQo8ZGl2PkJ1dCwgYXMgZmFyIGFzIHRoZSBwcm90ZWN0aW9u IHN3aXRjaGluZyBpcyBjb25jZXJuZWQsJm5ic3A7aXQmbmJzcDtqdXN0IG5lZWRzIHRvIGtub3cg aWYmbmJzcDtTRCBpcyZuYnNwO3NpZ25hbGVkIHRvIHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb2Nl c3Mgb3Igbm90LiZuYnNwOzwvZGl2Pg0KPGRpdj5JdCB3b3VsZCBiZSBhIG5ldHdvcmsgb3BlcmF0 b3IncyBjaG9pY2UmbmJzcDthdCB3aGF0IGxldmVsIG9mIFNEIGhlIHdhbnRzJm5ic3A7aGlzJm5i c3A7bmV0d29yayBwcm90ZWN0aW9uJm5ic3A7dG8gc3dpdGNob3Zlci48L2Rpdj4NCjxkaXY+SW4g b3RoZXIgd29yZHMsIHdoYXQgdHJpZ2dlcnMgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgU0QmbmJz cDtvciBubyBTRC4gSXQgaXMgeWVzIG9yIG5vIGRlY2lzaW9uLjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+U0YgY2FuIGFsc28gYmUgdmlld2VkIGFzIGhhdmluZyBtdWx0aXBsZSBsZXZl bHMgb2YgU0YgYXMmbmJzcDt0aGUgbmV0d29yayBvcGVyYXRvciBjYW4gYWxzbyBtYWtlIGEgY2hv aWNlJm5ic3A7b24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ00gbWVzc2FnZXMuPC9kaXY+DQo8 ZGl2PklmIENDTSBpcyBkaXNhYmxlZCwgQUlTIGZyb20gYSBzZXJ2ZXIgbGF5ZXIgY2FuIGJlIHVz ZWQgYXMgYSB0cmlnZ2VyIGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZy4gU28gYW5kIHNvIGZvcnRo LjwvZGl2Pg0KPGRpdj5Ib3dldmVyLCBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2Vz IG5vdCBkZWZpbmUgaG93IHRvIGRldGVjdCBTRiBpbiBhbnl3aGVyZS48L2Rpdj4NCjxkaXY+U2lt aWxhcnksIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cg bWFudWFsIHN3aXRjaCZuYnNwO2FuZCZuYnNwO2ZvcmNlZCBzd2l0Y2gmbmJzcDtjb21tYW5kcw0K PC9kaXY+DQo8ZGl2PmFyZSBpbml0aWF0ZWQgaW4gYSBtYW5hZ2VtZW50IHN5c3RlbSBhbmQgc2ln bmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2Vzcy48L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PkFnYWluLCBpbiBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVj dGlvbiBjYW4gYWNjb21tb2RhdGUgYW55IFNEIGRldGVjdGlvbiBtZXRob2RzLiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+SmVvbmctZG9uZzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDs8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmlu ZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9t IDogPC9iPiZxdW90O0VyaWMgT3Nib3JuZSAoZW9zYm9ybmUpJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZW9zYm9ybmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZW9zYm9ybmVAY2lzY28u Y29tPC9hPiZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMDctMjAgMDI6NDg6MjggKCAmIzQz OzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5EJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRv ICZsdDs8YSBocmVmPSJtYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlh Lml0IiB0YXJnZXQ9Il9ibGFuayI+YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlh Lml0PC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1wbHNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjIDogPC9iPkh1 dWIgaGVsdm9vcnQgKDxhIGhyZWY9Im1haWx0bzpodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29t IiB0YXJnZXQ9Il9ibGFuayI+aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTwvYT4pICZsdDs8 YSBocmVmPSJtYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb208L2E+Jmd0OywNCjxhIGhyZWY9Im1haWx0 bzpodXViYXR3b3JrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh1dWJhdHdvcmtAZ21haWwu Y29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+aHV1YmF0d29ya0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8 L2I+UmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxp bmVhciBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHM8YnI+DQo8 YnI+DQo8YnI+DQpIaSBBbGVzc2FuZHJvLTxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhpczsgdGhl IHRocmVhZHMgSSBzdGFydGVkIHNvbWUgdGltZSBiYWNrIHNlZW0gdG8gaGF2ZSBkaWVkIGRvd24s IGl0J3MgZ29vZCB0byBnZXQgdGhlbSBnb2luZyBhZ2Fpbi48YnI+DQpJIGhhdmUgdHdvIHRoaW5n cyBJIG5ldmVyIHF1aXRlIHVuZGVyc3Rvb2QsIGNhbiB5b3UgY2xhcmlmeSB0aGVtIGZvciBtZT88 YnI+DQo8YnI+DQppKSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBsZXZlbD8gSSdt IG5vdCBsb29raW5nIGZvciBhIGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGNoYW5n ZXMsIGFuZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZSBvbmUgbGluZSAmcXVvdDtJdCBhbGxvd3Mg dGhlIEZTTSB0byBiZSB0ZXN0ZWQmcXVvdDsuIFdlIGhhdmUgYWxsIG9mIHRoYXQgaW4gdGhlIGRy YWZ0IGFuZCBpbiB0aGUgZXF1aXZhbGVudCBJVFUgc3BlY3MuPGJyPg0KPGJyPg0KV2hhdCBJJ2Qg bGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9tLiBUaGUg SVRVIHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3csIHRoZXkg c2VlbSB0byBhc3N1bWUgdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBpcyBhbmQg d2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQgZmVlbHMgdmVyeSBtdWNoIGxpa2UgYSBtZWNoYW5p c20gdXNlZCB0byBjYXRjaCBhIHZlcnkNCiBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBidWcsIGJh Y2sgd2hlbiB0cmFuc3BvcnQgZ2VhciB3YXMgZmFyIGxlc3MgZGVidWdnYWJsZSB0aGFuIHdoYXQg d2UgaGF2ZSB0b2RheS4NCjxicj4NCjxicj4NCk5vIG90aGVyIHN0YXRlIG1hY2hpbmVzIHRoYXQg SSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwgQkdQLCBPU1BGLCBJU0lTKSBoYXZlIGV4cGxp Y2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvciB3aGV0aGVyIGl0 ICp3b3VsZCogYmUgYnJva2VuIGlmIGlmIHdlcmUsIGluIHRoZSBmdXR1cmUsIHRvIGJlIGdpdmVu IGEgcGFydGljdWxhciBpbnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBiZWhpbmQN CiBFWEVSIGhhcyBiZWVuIHRoYXQgSSBkb24ndCBmZWVsIGNvbWZvcnRhYmxlIHdpdGggdGhlIGlk ZWEgb2Yga2VlcGluZyBhIDMwLXllYXItb2xkIHdvcmthcm91bmQgaW4gYSBwcm90b2NvbC4gSXMg dGhlcmUgbW9yZSB0byBpdCB0aGFuIHRoYXQ/IEhhdmUgSSBtaXNyZWFkIGFuZCBtaXN1bmRlcnN0 b29kIEVYRVI/IERvZXMgbW9kZXJuIHRyYW5zcG9ydCBnZWFyIGV2ZXIgYWN0dWFsbHkgZGV0ZWN0 IGEgcHJvYmxlbSB2aWEgRVhFUi9SUiB0aGF0IHdhc24ndA0KIG9idmlvdXMgdG8gdGhlIG9wZXJh dG9yIHVzaW5nIG90aGVyIG1lYW5zPzxicj4NCjxicj4NCjxicj4NCmlpKSBXaHkgdGhlIHB1c2gg dG8gc3RhbmRhcmRpemUgdGhlIFNEIHN0YXRlIGNoYW5nZXMgYmVmb3JlIHdlJ3ZlIGRlZmluZWQg U0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxpbmcgc2lnbmFsIGRlZ3JhZGUgaXMgYSBn b29kIGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0aCBhIGRlZmluaXRpb24gZm9yIGl0IGhhcyBiZWVu IGNoYWxsZW5naW5nLiBXaGF0IGhhcHBlbnMgaWYgd2UgY2hhbmdlIHRoZSBGU00gdG8gaGFuZGxl IGl0LCB0aGVuIGNvbWUNCiB1cCB3aXRoIHNvbWV0aGluZyBtb3JlIHNvcGhpc3RpY2F0ZWQgKHNh eSwgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEKSB0aGF0IGRvZXNuJ3QgcXVpdGUgZml0IHdpdGggdGhl IEZTTSBjaGFuZ2VzPw0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KdGhhbmtzITxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCmVyaWM8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3Jn PC9hPiBbPGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8YnI+DQom Z3Q7IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG88YnI+DQomZ3Q7IFNlbnQ6IFdlZG5l c2RheSwgSnVseSAxNywgMjAxMyAzOjIzIFBNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiZn dDsgQ2M6IEh1dWIgaGVsdm9vcnQgKDxhIGhyZWY9Im1haWx0bzpodXViLnZhbi5oZWx2b29ydEBo dWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTwv YT4pOw0KPGEgaHJlZj0ibWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+aHV1YmF0d29ya0BnbWFpbC5jb208L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbbXBsc10gcHJv cG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXI8YnI+DQomZ3Q7IHBy b3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50czxicj4NCiZndDsgPGJy Pg0KJmd0OyBEZWFyIGFsbCw8YnI+DQomZ3Q7IHdlIHdvdWxkIGxpa2Ugc29jaWFsaXppbmcgdGhl IGhlcmViZWxvdyBkcmFmdHMgdGhhdCB3ZXJlIHN1Ym1pdHRlZCBzb21lPGJyPg0KJmd0OyBtb250 aHMgYWdvIHdpdGggdGhlIGFpbSB0byBhbGlnbiBQU0MgcHJvdG9jb2wgKFJGQyA2Mzc4KSB0byBJ VFUtVDxicj4NCiZndDsgdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRl IHlvdXIgY29tbWVudHMgYWJvdXQgdGhlPGJyPg0KJmd0OyBwcm9wb3NlZCBtZWNoYW5pc21zIGFu ZCBiZWhhdmlvdXJzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2Mt cHJpb3JpdHktMDA8YnI+DQomZ3Q7IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZl LTAwPGJyPg0KJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDA8YnI+DQomZ3Q7IGRyYWZ0 LWRqLW1wbHMtdHAtZXhlci1wc2MtMDEgLyBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLWFsaXZlLTAw PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBhYm92ZSBkcmFmdHMgY292ZXIgbW9zdCBvZiBpdGVt cyBoaWdobGlnaHRlZCBpbiBJVFUtVCBsaWFpc29ucyBhYm91dDxicj4NCiZndDsgUFNDIGFuZCB0 aGV5IHByb3Bvc2Ugc29sdXRpb25zIGluIGxpbmUgd2l0aCBNUExTLVRQIHRyYW5zcG9ydDxicj4N CiZndDsgcmVxdWlyZW1lbnRzLjxicj4NCiZndDsgQSBsaXN0IG9mIG1haW4gbGlhaXNvbnMgZXhj aGFuZ2VkIGJldHdlZW4gSVRVLVQgYW5kIElFVEYgd2l0aCB0aGUgYWltIHRvPGJyPg0KJmd0OyBh bGlnbiBQU0MgYmVoYXZpb3VzIHdpdGggSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBmb3Ig bGluZWFyPGJyPg0KJmd0OyBwcm90ZWN0aW9uIGFyZSBnaXZlbiBiZWxvdzo8YnI+DQomZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMTYyLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMTYyLzwvYT4g KEp1bmUgMjAxMik8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbGlhaXNvbi8xMjA1LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbGlhaXNvbi8xMjA1LzwvYT48YnI+DQomZ3Q7IDxIVFRQUzogZGF0YXRyYWNrZXIuaWV0 Zi5vcmdsaWFpc29uMTE2Mj0iIj4oT2N0b2JlciAyMDEyKTxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMjkvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMjkvPC9hPjxicj4NCiZndDsg PEhUVFBTOiBkYXRhdHJhY2tlci5pZXRmLm9yZ2xpYWlzb24xMTYyPSIiPihKYW51YXJ5IDIwMTMp PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24v MTIzNC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlz b24vMTIzNC88L2E+PGJyPg0KJmd0OyA8SFRUUFM6IGRhdGF0cmFja2VyLmlldGYub3JnbGlhaXNv bjExNjI9IiI+KEZlYnJ1YXJ5IDIwMTMpPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni88L2E+PGJyPg0KJmd0OyA8SFRUUFM6IGRh dGF0cmFja2VyLmlldGYub3JnbGlhaXNvbjExNjI9IiI+KE1heSAyMDEzKTxicj4NCiZndDsgPGJy Pg0KJmd0OyBTb21lIGRldGFpbHMgYWJvdSB0aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQ U0MgYmVoYXZpb3VyIHdpdGg8YnI+DQomZ3Q7IHRyYW5zcG9ydCByZXF1aXJlbWVudHM6PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMCBwcm9wb3Nl cyBzd2FwcGluZyB0aGUgcHJpb3JpdGllczxicj4NCiZndDsgYmV0d2VlbiBGUyBhbmQgU0YtUCAo c2VlIHNlY3Rpb24gNC4zLjIgb2YgcmZjNjM3OCkuPGJyPg0KJmd0OyBBbW9uZyB0aGUgb3RoZXJz LCBiZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkIHVwZGF0ZTxi cj4NCiZndDsgYXJlOjxicj4NCiZndDsgVXNlIGNhc2UgQSkgQXQgZmlyc3QsIHdvcmtpbmcgcGF0 aChXUCkgYW5kIHByb3RlY3Rpb24gcGF0aChQUCkgYXJlPGJyPg0KJmd0OyBub3JtYWwuIFRoZW4s IEZvcmNlZCBTd2l0Y2goRlMpIGNvbW1hbmQgaXMgaXNzdWVkIGZvciBtYWludGVuYW5jZSBvbiB0 aGU8YnI+DQomZ3Q7IFdQIGFuZCB0aGUgdHJhZmZpYyBtb3ZlcyBmcm9tIFdQIHRvIFBQLiBXaGVu IFNpZ25hbCBGYWlsIG9jY3VycyBvbiBQUCw8YnI+DQomZ3Q7IHNlcnZpY2UgY2Fubm90IHJlY292 ZXIgYW5kIGlzIGludGVycnVwdGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvciBleGFtcGxlPGJyPg0K Jmd0OyBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci48 YnI+DQomZ3Q7IFVzZSBjYXNlIEIpIElmIHRoZXJlIGlzIGFuIGV4aXN0aW5nIHNpZ25hbCBmYWls IG9uIGEgcHJvdGVjdGlvbiBwYXRoPGJyPg0KJmd0OyAoU0YtUCksYW5kIEZTIGNvbW1hbmQgaXMg aXNzdWVkIGJ5IGFjY2lkZW50IHRoZSB0cmFmZmljIG9uIFdQIHdpbGwgbW92ZTxicj4NCiZndDsg dG8gUFAuIFRoaXMgcmVzdWx0cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9tIHdo aWNoIHlvdSB3aWxsPGJyPg0KJmd0OyBub3QgYXV0b21hdGljYWxseSByZWNvdmVyLCBiZWNhdXNl IFBTQyBzaG91bGQgbm90IGhhdmUgc3dpdGNoZWQgdGhlPGJyPg0KJmd0OyB0cmFmZmljIGZyb20g V1AgdG8gUFAuPGJyPg0KJmd0OyBEaXNjdXNzaW9uIGFib3V0IHRoaXMgZHJhZnQgbGVkIHRvIHRo ZSBwcm9wb3NhbCB0byBtb2RpZnkgUkZDIDQ0MjcgdGhhdDxicj4NCiZndDsgd2FzICZxdW90O3dy aXR0ZW4gY29ycmVjdGx5IHRob3VnaCBsYWNraW5nIGluIGRldGFpbCBjYXVzaW5nIG1pcy08YnI+ DQomZ3Q7IGludGVycHJldGF0aW9uJnF1b3Q7IHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBz ZXQgb2YgcHJpb3JpdHkgdGhhdCB0aGU8YnI+DQomZ3Q7IGFib3ZlIGRyYWZ0IGlzIHByb3Bvc2lu ZyB0byBtb2RpZmllZCBhbmQgdG8gYWxpZ24gdG8gdGhlIHJlcXVpcmVkPGJyPg0KJmd0OyB0cmFu c3BvcnQgYmVoYXZpb3IuIGRyYWZ0LWhlbHZvb3J0LWNjYW1wLWZzLXByaW9yaXR5LTAwIGhhcyBi ZWVuPGJyPg0KJmd0OyBzdWJtaXR0ZWQgdG8gQ0NBTVAgZm9yIGNsYXJpZnlpbmcgdGhlIGRlZmlu aXRpb25zIHJlbGF0ZWQgdG8gTWFudWFsPGJyPg0KJmd0OyBTd2l0Y2ggYW5kIEZvcmNlZCBTd2l0 Y2ggYW5kIHRoZWlyIHVzYWdlIHJlbGF0aXZlIHRvIHByaW9yaXRpZXMuPGJyPg0KJmd0OyBUaGUg d2F5IHRoaXMgYmVoYXZpb3IgaGFzIHRvIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBQU0MgaGFz IHRvIGJlPGJyPg0KJmd0OyBkaXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRvIHJlcGxhY2Ug dGhlIGN1cnJlbnQgYmVoYXZpb3Igd2l0aCB0aGU8YnI+DQomZ3Q7IG5ldyBvbmUuIElmIHRoZXJl IGlzIGNvbnNlbnN1cyB0byBwcm9jZWRlIGluIHRoYXQgd2F5IHRoaXMgY2FuIGJyaW5nIHRvPGJy Pg0KJmd0OyBhIHNpbXBsZSBhbmQgZWZmZWN0aXZlIHdheSB0byBvcGVyYXRlIHRoZSBwcm90b2Nv bC48YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgZHJhZnQtY2Ro LW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAgY29udGFpbnMgdGhlIHVwZGF0ZXMgdG8gUkZD NjM3ODxicj4NCiZndDsgdG8gY2hhbmdlIG5vbi1yZXZlcnRpdmUgb3BlcmF0aW9ucyB0byBiZWhh dmVzIGluIHRoZSBzYW1lIHdheTxicj4NCiZndDsgaXJyZXNwZWN0aXZlbHkgb2YgdGhlIHRyaWdn ZXIgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGZhdWx0IG9yIG9wZXJhdG9yPGJyPg0KJmd0OyBj b21tYW5kIEZTLCBNUykuIENvbnNlcXVlbnRseSBhbiBvcGVyYXRvciBjb21tYW5kLCBNYW51YWwg U3dpdGNoIHRvPGJyPg0KJmd0OyBXb3JraW5nIChNUy1XKSBhLmsuYSAmcXVvdDtNYW51YWwgc3dp dGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuJnF1b3Q7IGlzIGFsc288YnI+DQomZ3Q7IGFk ZGVkIHRvIGVuYWJsZSB0aGlzIGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9m IHZpZXcsIE1TIHRvPGJyPg0KJmd0OyB3b3JraW5nIHBhdGggaGFzIGFsc28gdG8gYmUgc3VwcG9y dGVkIHRvIGJlIGFibGUgdG8gaW5pdGlhbGx5IGFsaWduIGF0PGJyPg0KJmd0OyBib3RoIHNpZGVz IGluIGNhc2Ugb2Ygbm9uLXJldmVydGl2ZSBzd2l0Y2hpbmcgbW9kZS4gTVMgdG8gd29ya2luZyBw YXRoPGJyPg0KJmd0OyBpcyBkZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My48YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhlIHByb3Bvc2VkIE1TLVcgY29tbWFuZCBpcyBvZiBlcXVhbCBw cmlvcml0eSB0byB0aGUgZXhpc3RpbmcgTVMtUDxicj4NCiZndDsgY29tbWFuZCwgYW5kIHRoZXJl IGlzIHRleHQgdG8gaGFuZGxlIHRoZSBzaW11bHRhbmVvdXMgb3Igc2VxdWVudGlhbDxicj4NCiZn dDsgb2NjdXJyZW5jZSBvZiB0d28gZXF1YWwtcHJpb3JpdHkgY29tbWFuZHMuIFRoaXMgYmVoYXZp b3IsIGFscmVhZHk8YnI+DQomZ3Q7IGFkb3B0ZWQgaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsg cHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdG9jb2wsIGNhbiBiZTxicj4NCiZndDsgdXNlZCBmb3Ig b3RoZXIgYWRkaXRpb24gdG8gdGhlIHByb3RvY29sIGluIHRoZSBmdXR1cmUuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1z ZC0wMCBwcm92aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQU0Mgc3RhdGU8YnI+DQomZ3Q7IG1hY2hp bmUgdG8gaGFuZGxlIFNpZ25hbCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmluZSBTRCBv ciBwcm92aWRlPGJyPg0KJmd0OyBzY29wZSBhcm91bmQgd2hlcmUgb3IgaG93IFNEIG1heSBiZSB1 c2VkIHNpbWlsYXJseSBhcyBpdCBhbHJlYWR5IGhhcHBlbjxicj4NCiZndDsgaW4gdGhlIGRyYWZ0 IGluIGhhbmRsaW5nIG90aGVyIGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZhaWx1cmUpLjxicj4N CiZndDsgSW4gTVBMUy1UUCBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBbUkZDNjM3Ml0sIGEgZmF1 bHQgY29uZGl0aW9uPGJyPg0KJmd0OyBpbmNsdWRlcyBib3RoIFNpZ25hbCBGYWlsIChTRikgYW5k IFNpZ25hbCBEZWdyYWRlIChTRCkgdGhhdCBjYW4gYmUgdXNlZDxicj4NCiZndDsgdG8gdHJpZ2dl ciBwcm90ZWN0aW9uIHN3aXRjaGluZy48YnI+DQomZ3Q7IFdoaWxlIHRoZSBzdGFuZGFyZGl6YXRp b24gbGFjayBvZiBhbiBTRCBkZWZpbml0aW9uIGFuZCBkZXRlY3Rpb248YnI+DQomZ3Q7IG1lY2hh bmlzbXMsIHRoZSByZWxldmFudCBiZWhhdmlvcnMgaW4gdGVybXMgb2YgcHJvdGVjdGlvbiBhY3Rp b25zIG1heTxicj4NCiZndDsgYWxyZWFkeSBiZSBkZWZpbmVkLjxicj4NCiZndDsgPGJyPg0KJmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIHBy b3Bvc2VzIGFkZGluZyB0aGUgRVhFUi9SUiBjb21tYW5kcyB0bzxicj4NCiZndDsgdGVzdCBpZiB0 aGUgQVBTIGNvbW11bmljYXRpb24gaXMgb3BlcmF0aW5nIGNvcnJlY3RseS4gSW4gb3RoZXIgd29y ZHM8YnI+DQomZ3Q7IGJvdGggQVBTIHByb2Nlc3MgbG9naWMgaW5jbHVkaW5nIHN0YXRlIG1hY2hp bmUgYW5kIEFQUyBjaGFubmVsIG9uPGJyPg0KJmd0OyBwcm90ZWN0aW9uIHBhdGgsIHdpdGhvdXQg c2VydmljZSBkaXNydXB0aW9uIGFuZCB3aXRob3V0IGFmZmVjdGluZyBhbnk8YnI+DQomZ3Q7IHBy b3RlY3Rpb24gb3BlcmF0aW9uLCB1bmxlc3MgdGhlIHByb3RlY3Rpb24gdHJhbnNwb3J0IGVudGl0 eSBpcyBpbiB1c2UuPGJyPg0KJmd0OyBUaGlzIGNvbW1hbmQgaXMgZG9jdW1lbnRlZCBpbiBSODQg b2YgW1JGQzU2NTRdIGFuZCBpdCBpcyBwYXJ0IG9mIElUVS1UPGJyPg0KJmd0OyB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzLjxicj4NCiZndDsgQW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1l bnRlZCBpbiB0aGUgQXBwZW5kaXggQiBvZiBSRkM2Mzc4IHRoYXQ8YnI+DQomZ3Q7IHV0aWxpemVz IHRoZSBMb2Nrb3V0IG9mIFByb3RlY3Rpb24gKExPKSBvciBGb3JjZWQgU3dpdGNoIChGUykgaW48 YnI+DQomZ3Q7IGNvbWJpbmF0aW9uIG9mIE9BTSBmdW5jdGlvbmFsaXRpZXMuIEhvd2V2ZXIsIGl0 IGhhcyBzb21lIGZ1bmN0aW9uYWw8YnI+DQomZ3Q7IGxpbWl0YXRpb24gYW5kIGhhcyBhIHBvdGVu dGlhbCByaXNrIG9mIGxvc2luZyB0cmFmZmljIGFzIGEgc2lnbmFsPGJyPg0KJmd0OyBmYWlsdXJl IG1pZ2h0IG9jY3VyIGR1cmluZyB0aGUgZXhlcmNpc2Ugb3BlcmF0aW9uLiBJbiB0aGF0IGNhc2Us IExPIG9yPGJyPg0KJmd0OyBGUyBoYXMgdG8gYmUgY2FuY2VsZWQgdG8gYWxsb3cgdGhlIFBTQyBw cm90b2NvbCB0byBwcm92aWRlIHByb3Blcjxicj4NCiZndDsgc3dpdGNoaW5nLjxicj4NCiZndDsg QSBmdXJ0aGVyIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gZHJhZnQtb3Ni b3JuZS1tcGxzLXBzYy08YnI+DQomZ3Q7IGFsaXZlLTAwIHRoYXQgYW55d2F5IHNob3cgc29tZSBm dW5jdGlvbmFsIGxpbWl0YXRpb25zIGJlY2F1c2UgY2Fubm90PGJyPg0KJmd0OyB2YWxpZGF0ZSB0 aGUgUFNDIHN0YXRlIG1hY2hpbmUgc3RhdHVzIGFuZCBwcm9iYWJseSB0aGUgTG9jYWwgUmVxdWVz dDxicj4NCiZndDsgbG9naWMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGF1 dGhvcnMgZW5jb3VyYWdlIHRoZSBJRVRGIGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFm dHMsPGJyPg0KJmd0OyBldmVudHVhbGx5IHByb3Bvc2luZyBvdGhlciBvcHRpb25zL21lY2hhbmlz bXMgdGhhdCBjYW4gc2F0aXNmeSB0aGUgc2FtZTxicj4NCiZndDsgcmVxdWlyZW1lbnRzLjxicj4N CiZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgQWxlc3NhbmRybywgSHV1YiwgSmVvbmctZG9u ZywgVGFla3NpZDxicj4NCiZndDsgUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBz b25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGU8YnI+DQomZ3Q7IHBlcnNvbmUgaW5k aWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZTxicj4N CiZndDsgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGU8YnI+DQomZ3Q7IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNl dnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGU8YnI+DQomZ3Q7IGNvcnRlc2Vt ZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRl IGUgZGk8YnI+DQomZ3Q7IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluPGJyPg0KJmd0OyBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuPGJyPg0KJmd0OyBEaXNzZW1p bmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0 aG9yaXNlZC48YnI+DQomZ3Q7IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZDxicj4NCiZndDsgYW55IGF0dGFjaG1lbnRz IGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IHJpc3BldHRhIGwnYW1iaWVudGVSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uPGJyPg0KJmd0OyDDqCBuZWNlc3NhcmlvLjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4NCjwvSFRUUFM6Pjwv SFRUUFM6PjwvSFRUUFM6PjwvSFRUUFM6PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5tcGxzIG1haWxpbmcgbGlzdDwv c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48L3NwYW4+PGJyPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2768034DSMTP2etriinfo_-- From huubatwork@gmail.com Mon Jul 22 04:19:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7621F89C3 for ; Mon, 22 Jul 2013 04:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbMuge8E07Ka for ; Mon, 22 Jul 2013 04:19:34 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B67DC21F8F78 for ; Mon, 22 Jul 2013 04:19:31 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id d10so3759665eaj.41 for ; Mon, 22 Jul 2013 04:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rVVQ+T1bT3YMVH/A/8L048QKF1BnXWA5XsH24BJKOZs=; b=pO5AHQ/V+9s6bDNCGwn7IBcBUue8lnOtvBZPgdQmW1SnDNYrZE9qOItewWKATIJZNa kWBXP4T69X3jbhioMZApnoe4m+SASMpK/uOx7/bpAUg7L6aisnOrEXUeRlRFYpAIjwB1 2gDfVjtTQm0Ng3HyuQqYcVe1G7D1xezBztp/V6xlcJJpgw/mzxJqfWxyQjQCVJwDslVw PUox1jwGdvt//zvIjlAOKz0ocwNuzIZ+LfbgCOom85qd9rz/nPT9PMcPEsQEIupmk2+V J0G2C39oM8mhyft/WOACf1gvoZj6hqontw5jOn3dY4kQf2nBqa2eoLhUdKSPXqyG8w7x Wz5A== X-Received: by 10.15.21.78 with SMTP id c54mr27036105eeu.14.1374491970813; Mon, 22 Jul 2013 04:19:30 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id l42sm49958268eeo.14.2013.07.22.04.19.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 04:19:30 -0700 (PDT) Message-ID: <51ED1541.70108@gmail.com> Date: Mon, 22 Jul 2013 13:19:29 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements 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: Mon, 22 Jul 2013 11:19:34 -0000 Hello Eric, You wrote: > Thanks for this; the threads I started some time back seem to have > died down, it's good to get them going again. There was atwo week ITU-T plenary meeting, and after that I took (and still have) a holiday. > I have two things I never quite understood, can you clarify them > for me? OK, I'll try. See in-line [Huub] > i) can you explain EXER at a higher level? I'm not looking for a > description of the state machine changes, and I'm not looking for the > one line "It allows the FSM to be tested". We have all of that in > the draft and in the equivalent ITU specs. > > What I'd like to understand about EXER is where it came from. The > ITU specs that define it are pretty hard to follow, they seem to > assume the reader already knows what EXER is and what problem it > solves. It feels very much like a mechanism used to catch a very > specific implementation bug, back when transport gear was far less > debuggable than what we have today. [Huub] EXER was not designed/intended to be used for bug finding although it will detect problems with implementation. [Huub] EXER was designed to verify that the state-machine at the far end is able to respond to APS/PSC messages it receives from the local end. Even though state-machines should be tested extensively, there is no 100% warranty. It can still have stopped due to external circumstances, be in a deadlock due to unforseen order of events, etc. [Huub] note that APS/PSC should continue to operate even if no control plane is available. The EXER is to enable an operator to take corrective action before a protection switch request fails and the 50ms switch time is not met. > No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, > ISIS) have explicit signaling in them just to ask the neighbor > whether it *would* be broken if if were, in the future, to be given a > particular input. [Huub] All these rely on a control plane, some of then include "keepalive" messages to see if the far end responds. > Part of my reluctance to get behind EXER has been > that I don't feel comfortable with the idea of keeping a 30-year-old > workaround in a protocol. [Huub] it is NOT a workaround, it is an essential part of the protocol. > Is there more to it than that? Have I > misread and misunderstood EXER? Does modern transport gear ever > actually detect a problem via EXER/RR that wasn't obvious to the > operator using other means? [Huub] if there is no control plane I have no other means. What means are available to verify if a state-machine that is in a stable state is still functioning? > ii) Why the push to standardize the SD state changes before we've > defined SD? I certainly agree that handling signal degrade is a good > idea, but coming up with a definition for it has been challenging. > What happens if we change the FSM to handle it, then come up with > something more sophisticated (say, multiple levels of SD) that > doesn't quite fit with the FSM changes? [Huub] the definition of the signal degrade defect that causes the SD event for the APS/PSC is still under discussion, but the APS/PSC response to an SD event should be included. If we don't do it now we have to issue another version of PSC later with all kinds of backwards compatibility issues, additional complexity, and options that operators do not like to have to manage. [Huub] APS/PSC now responds to an SF event, based on detected signal fail defects. However in the future we may extend the signal fail defect by another probable cause. This will not affect the existing APS/PCS. Regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From alessandro.dalessandro@telecomitalia.it Mon Jul 22 06:03:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83711E8114 for ; Mon, 22 Jul 2013 06:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMGy8qpDBbva for ; Mon, 22 Jul 2013 06:03:14 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F311E80F5 for ; Mon, 22 Jul 2013 06:03:10 -0700 (PDT) Content-Type: multipart/mixed; boundary="_0ffdfb99-43a0-4c6e-b2bd-4f3f642a3e81_" Received: from TELCAH001RM001.telecomitalia.local (10.19.10.102) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 22 Jul 2013 15:03:04 +0200 Received: from TELMBA002RM001.telecomitalia.local ([169.254.1.126]) by TELCAH001RM001.telecomitalia.local ([10.19.10.102]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 15:03:03 +0200 From: D'Alessandro Alessandro Gerardo To: "S. Davari" , "Ryoo, Jeong-dong" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQAAbpZAAAJuJNV Date: Mon, 22 Jul 2013 13:03:03 +0000 Message-ID: <22257C41A415324A984CD03D63344E271F1B8441@TELMBA002RM001.telecomitalia.local> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.10.76] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 13:03:19 -0000 --_0ffdfb99-43a0-4c6e-b2bd-4f3f642a3e81_ Content-Type: multipart/alternative; boundary="_000_22257C41A415324A984CD03D63344E271F1B8441TELMBA002RM001t_" --_000_22257C41A415324A984CD03D63344E271F1B8441TELMBA002RM001t_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I understand your point but I believe it is not relevant to the proposed mo= dification to PSC to manage SD. Actually if it is appropriate to carry out PM on all LSPs/PWs or on a subse= t of LSPs/PWs is a carrier decision based on costs / benefits analysis. Mor= eover the method that will be used for signal degrade detection (you mentio= nd CCM or BFD packet count) is not relevant to PSC. In fact the proposed ch= anges only describe how the linear protection mechanism behaves when SD occ= urs (and not how to detect SD). I believe there are two main points that are really important and that are = relevant to PSC when we talk about SD. Those points have been highlighted i= n previous emails about this threat from Jeong-dong and Huub: it is importa= nt to be able to provide protection switching when signal degrade occurs if= a carrier has set SD as a criteria for doing that and it is important to a= dd now the description on how PSC protection switching protocol behaves to = avoid to face with extra operational costs for carriers and with extra deve= loping costs for vendors in adding this functionality later on to the PSC. best regards, Alessandro PS sorry for being late in answering but I'm on holiday ________________________________ From: S. Davari [davarish@yahoo.com] Sent: Monday, July 22, 2013 12:05 PM To: Ryoo, Jeong-dong Cc: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo; mpls@ietf.org= ; Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protect= ion protocol to transport requirements Hi, Couple of points. The SD trigger for protection and requires you to run Per= formance measurement on all LSPs and PWs, which is not scalable. Also there is no standard method defined to count CCM or BFD packets. Regards, Shahram On Jul 22, 2013, at 10:14 AM, "Ryoo, Jeong-dong" > wrote: Hi, Eric. Let me answer your 2nd question on SD. SD detection methods defined or proposed for packet transport networks can = be summarized as follows: - By OAM performance monitoring tool: SD is raised if packet loss ratio exceeds a threshold during a measuremen= t period. Threshold value and measurement period are configured by an network opera= tor. This detection method is already defined in ITU-T G.8021 (Ethernet equipm= ent spec.) and the equipment spec for MPLS-TP can easily follow the same definition. - By server layer indication: SD is raised if a server layer below MPLS-TP reports SD condition on its = own layer. - By CCM packet counting: SD is raised if the loss ratio of CCM packets exceeds a threshold during = a measurement period. Regardless of how to detect SD, any protection switching documents should d= escribe the protection switching operation once such a SD is declared. The proposed draft covers SD-triggered protection no matter what kinds of S= D detection methods are used. Regarding the multiple levels of SD: It is certainly possible to define multiple levels of SD. But, as far as the protection switching is concerned, it just needs to know= if SD is signaled to protection switching process or not. It would be a network operator's choice at what level of SD he wants his ne= twork protection to switchover. In other words, what triggers protection switching is SD or no SD. It is ye= s or no decision. SF can also be viewed as having multiple levels of SF as the network operat= or can also make a choice on the period/interval of CCM messages. If CCM is disabled, AIS from a server layer can be used as a trigger for pr= otection switching. So and so forth. However, protection switching document does not define how to detect SF in = anywhere. Similary, protection switching document does not define how manual switch a= nd forced switch commands are initiated in a management system and signaled to protection switching p= rocess. Again, in my opinion, the draft on SD protection can accommodate any SD det= ection methods. Best regards, Jeong-dong ________________________________ >From : "Eric Osborne (eosborne)" > Sent : 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerardo >, mpls@ietf.org > Cc : Huub helvoort (huub.van.helvoort@huawei.com) >, huubatwork@gmail.com > Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protec= tion protocol to transport requirements Hi Alessandro- Thanks for this; the threads I started some time back seem to have died dow= n, it's good to get them going again. I have two things I never quite understood, can you clarify them for me? i) can you explain EXER at a higher level? I'm not looking for a descriptio= n of the state machine changes, and I'm not looking for the one line "It al= lows the FSM to be tested". We have all of that in the draft and in the equ= ivalent ITU specs. What I'd like to understand about EXER is where it came from. The ITU specs= that define it are pretty hard to follow, they seem to assume the reader a= lready knows what EXER is and what problem it solves. It feels very much li= ke a mechanism used to catch a very specific implementation bug, back when = transport gear was far less debuggable than what we have today. No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, ISIS)= have explicit signaling in them just to ask the neighbor whether it *would= * be broken if if were, in the future, to be given a particular input. Part= of my reluctance to get behind EXER has been that I don't feel comfortable= with the idea of keeping a 30-year-old workaround in a protocol. Is there = more to it than that? Have I misread and misunderstood EXER? Does modern tr= ansport gear ever actually detect a problem via EXER/RR that wasn't obvious= to the operator using other means? ii) Why the push to standardize the SD state changes before we've defined S= D? I certainly agree that handling signal degrade is a good idea, but comin= g up with a definition for it has been challenging. What happens if we chan= ge the FSM to handle it, then come up with something more sophisticated (sa= y, multiple levels of SD) that doesn't quite fit with the FSM changes? thanks! eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of > D'Alessandro Alessandro Gerardo > Sent: Wednesday, July 17, 2013 3:23 PM > To: mpls@ietf.org > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear > protection protocol to transport requirements > > Dear all, > we would like socializing the herebelow drafts that were submitted some > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T > transport requirements. I would appreciate your comments about the > proposed mechanisms and behaviours. > > draft-rhd-mpls-tp-psc-priority-00 > draft-cdh-mpls-tp-psc-non-revertive-00 > draft-rhd-mpls-tp-psc-sd-00 > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 > > The above drafts cover most of items highlighted in ITU-T liaisons about > PSC and they propose solutions in line with MPLS-TP transport > requirements. > A list of main liaisons exchanged between ITU-T and IETF with the aim to > align PSC behavious with ITU-T transport requirements for linear > protection are given below: > https://datatracker.ietf.org/liaison/1162/ (June 2012) > https://datatracker.ietf.org/liaison/1205/ > (October 2012) > https://datatracker.ietf.org/liaison/1229/ > (January 2013) > https://datatracker.ietf.org/liaison/1234/ > (February 2013) > https://datatracker.ietf.org/liaison/1256/ > (May 2013) > > Some details abou the proposed drafts for align PSC behaviour with > transport requirements: > > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities > between FS and SF-P (see section 4.3.2 of rfc6378). > Among the others, behaviors that will be fixed with the proposed update > are: > Use case A) At first, working path(WP) and protection path(PP) are > normal. Then, Forced Switch(FS) command is issued for maintenance on the > WP and the traffic moves from WP to PP. When Signal Fail occurs on PP, > service cannot recover and is interrupted. This could occur for example > as a result of accidentally un-plugging a PP fiber. > Use case B) If there is an existing signal fail on a protection path > (SF-P),and FS command is issued by accident the traffic on WP will move > to PP. This results in an interruption of service from which you will > not automatically recover, because PSC should not have switched the > traffic from WP to PP. > Discussion about this draft led to the proposal to modify RFC 4427 that > was "written correctly though lacking in detail causing mis- > interpretation" that led to the current PSC set of priority that the > above draft is proposing to modified and to align to the required > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been > submitted to CCAMP for clarifying the definitions related to Manual > Switch and Forced Switch and their usage relative to priorities. > The way this behavior has to be incorporated into the PSC has to be > discussed. The text proposes to replace the current behavior with the > new one. If there is consensus to procede in that way this can bring to > a simple and effective way to operate the protocol. > > ---------------------------------------------------------------------- > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378 > to change non-revertive operations to behaves in the same way > irrespectively of the trigger of protection switching (fault or operator > command FS, MS). Consequently an operator command, Manual Switch to > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is also > added to enable this behavior. From an operational point of view, MS to > working path has also to be supported to be able to initially align at > both sides in case of non-revertive switching mode. MS to working path > is defined in RFC 5654, requirement 83. > > The proposed MS-W command is of equal priority to the existing MS-P > command, and there is text to handle the simultaneous or sequential > occurrence of two equal-priority commands. This behavior, already > adopted in other transport network protection switching protocol, can be > used for other addition to the protocol in the future. > > ---------------------------------------------------------------------- > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state > machine to handle Signal Degrade (SD). It does not define SD or provide > scope around where or how SD may be used similarly as it already happen > in the draft in handling other defects like SF (Signal Failure). > In MPLS-TP survivability framework [RFC6372], a fault condition > includes both Signal Fail (SF) and Signal Degrade (SD) that can be used > to trigger protection switching. > While the standardization lack of an SD definition and detection > mechanisms, the relevant behaviors in terms of protection actions may > already be defined. > > ---------------------------------------------------------------------- > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to > test if the APS communication is operating correctly. In other words > both APS process logic including state machine and APS channel on > protection path, without service disruption and without affecting any > protection operation, unless the protection transport entity is in use. > This command is documented in R84 of [RFC5654] and it is part of ITU-T > transport requirements. > An alternative proposal is documented in the Appendix B of RFC6378 that > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in > combination of OAM functionalities. However, it has some functional > limitation and has a potential risk of losing traffic as a signal > failure might occur during the exercise operation. In that case, LO or > FS has to be canceled to allow the PSC protocol to provide proper > switching. > A further alternative proposal is documented in draft-osborne-mpls-psc- > alive-00 that anyway show some functional limitations because cannot > validate the PSC state machine status and probably the Local Request > logic. > > > The authors encourage the IETF experts to comment on these drafts, > eventually proposing other options/mechanisms that can satisfy the same > requirements. > Best regards, > Alessandro, Huub, Jeong-dong, Taeksid > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is unauthorised. > If you are not the intended recipient, please delete this message and > any attachments and advise the sender by return e-mail, Thanks. > > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non > =E8 necessario. _______________________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_22257C41A415324A984CD03D63344E271F1B8441TELMBA002RM001t_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I understand your point but I believe it is not relevant to the proposed mo= dification to PSC to manage SD.
Actually if it is appropriate to carry out PM on all LSPs/PWs or on a subse= t of LSPs/PWs is a carrier decision based on costs / benefits analysis. Mor= eover the method that will be used for signal degrade detection (you mentio= nd CCM or BFD packet count) is not relevant to PSC. In fact the proposed changes only describe how the linear= protection mechanism behaves when SD occurs (and not how to detect SD).
I believe there are two main points that are really important and that are = relevant to PSC when we talk about SD. Those points have been highlighted i= n previous emails about this threat from Jeong-dong and Huub: it is importa= nt to be able to provide protection switching when signal degrade occurs if a carrier has set SD as a criteria= for doing that and it is important to add now the description on how PSC p= rotection switching protocol behaves to avoid to face with extra operationa= l costs for carriers and with extra developing costs for vendors in adding this functionality later on to the = PSC.

best regards,
Alessandro
PS sorry for being late in answering but I'm on holiday
  
From: S. Davari [davarish@yahoo.com]
Sent: Monday, July 22, 2013 12:05 PM
To: Ryoo, Jeong-dong
Cc: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo; mpls@i= etf.org; Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com=
Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear = protection protocol to transport requirements

Hi, 

Couple of points. The SD trigger for protection and requires you to ru= n Performance measurement on all LSPs and PWs, which is not scalable.

Also there is no standard method defined to count CCM or BFD packets.&= nbsp;

Regards,
Shahram


On Jul 22, 2013, at 10:14 AM, "Ryoo, Jeong-dong" <ryoo@etri.re.kr> wrote:

Hi, Eric.
 
Let me answer your 2nd question on SD.=
 
SD detection methods defined or proposed fo= r packet transport networks can be summarized as follows:
- By OAM performance monitoring tool: =
  SD is raised if packet loss rat= io exceeds a threshold during a measurement period.
  Threshold value and measurement peri= od are configured by an network operator.
  This detection method is already defined in ITU-T G.8021 (Ethernet e= quipment spec.)
  and the equipment spec for MPLS-TP c= an easily follow the same definition.
- By server layer indication:
  SD is raised if a server layer below MPLS-TP reports SD co= ndition on its own layer.
- By CCM packet counting:
  SD is raised if the loss ratio of CCM packets exceeds a thresho= ld during a measurement period.
 
Regardless of how to detect SD, any protection switching document= s should describe the protection switching operation once such a SD is decl= ared.
 
The proposed draft covers SD-triggered protection no matter what kinds= of SD detection methods are used.
 
Regarding the multiple levels of SD:
It is certainly possible to define multiple levels of SD.
But, as far as the protection switching is concerned, it jus= t needs to know if SD is signaled to protection switching process= or not. 
It would be a network operator's choice at what level of SD he wa= nts his network protection to switchover.
In other words, what triggers protection switching is SD or no SD= . It is yes or no decision.
 
SF can also be viewed as having multiple levels of SF as the netw= ork operator can also make a choice on the period/interval of CCM mess= ages.
If CCM is disabled, AIS from a server layer can be used as a trigger f= or protection switching. So and so forth.
However, protection switching document does not define how to detect S= F in anywhere.
Similary, protection switching document does not define how manual swi= tch and forced switch commands
are initiated in a management system and signaled to protection switch= ing process.
 
Again, in my opinion, the draft on SD protection can accommodate any S= D detection methods. 
 
Best regards,
 
Jeong-dong
  
 
 
 
 

From : "Eric Osborne (eosborne)= " <eosborne= @cisco.com>
Sent : 2013-07-20 02:48:28 ( +09:00 )
To : D'Alessandro Alessandro Gerardo <alessandro.dalessandro@te= lecomitalia.it>, mpls@ietf.org <mpls@ietf.org>
Cc : Huub helvoort (huub.van.helvoort@huawei.com) <huub.van.helvoort@huawei.com= >, huubatwork@gmail.= com <huuba= twork@gmail.com>
Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear= protection protocol to transport requirements


Hi Alessandro-

Thanks for this; the threads I started some time back seem to have died dow= n, it's good to get them going again.
I have two things I never quite understood, can you clarify them for me?
i) can you explain EXER at a higher level? I'm not looking for a descriptio= n of the state machine changes, and I'm not looking for the one line "= It allows the FSM to be tested". We have all of that in the draft and = in the equivalent ITU specs.

What I'd like to understand about EXER is where it came from. The ITU specs= that define it are pretty hard to follow, they seem to assume the reader a= lready knows what EXER is and what problem it solves. It feels very much li= ke a mechanism used to catch a very specific implementation bug, back when transport gear was far less debugga= ble than what we have today.

No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, ISIS)= have explicit signaling in them just to ask the neighbor whether it *would= * be broken if if were, in the future, to be given a particular input. Part= of my reluctance to get behind EXER has been that I don't feel comfortable with the idea of keeping a 30-= year-old workaround in a protocol. Is there more to it than that? Have I mi= sread and misunderstood EXER? Does modern transport gear ever actually dete= ct a problem via EXER/RR that wasn't obvious to the operator using other means?


ii) Why the push to standardize the SD state changes before we've defined S= D? I certainly agree that handling signal degrade is a good idea, but comin= g up with a definition for it has been challenging. What happens if we chan= ge the FSM to handle it, then come up with something more sophisticated (say, multiple levels of SD) that doe= sn't quite fit with the FSM changes?



thanks!





eric


> -----Original Message-----
> From: mpls-= bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> D'Alessandro Alessandro Gerardo
> Sent: Wednesday, July 17, 2013 3:23 PM
> To: mpls@ietf.org
> Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.= com
> Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
>
> Dear all,
> we would like socializing the herebelow drafts that were submitted som= e
> months ago with the aim to align PSC protocol (RFC 6378) to ITU-T
> transport requirements. I would appreciate your comments about the
> proposed mechanisms and behaviours.
>
> draft-rhd-mpls-tp-psc-priority-00
> draft-cdh-mpls-tp-psc-non-revertive-00
> draft-rhd-mpls-tp-psc-sd-00
> draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00
>
> The above drafts cover most of items highlighted in ITU-T liaisons abo= ut
> PSC and they propose solutions in line with MPLS-TP transport
> requirements.
> A list of main liaisons exchanged between ITU-T and IETF with the aim = to
> align PSC behavious with ITU-T transport requirements for linear
> protection are given below:
> https://datatracker.ietf.org/liaison/1162/ (June 2012)
> https://datatracker.ietf.org/liaison/1205/
> (October 2012)
> https://datatracker.ietf.org/liaison/1229/
> (January 2013)
> https://datatracker.ietf.org/liaison/1234/
> (February 2013)
> https://datatracker.ietf.org/liaison/1256/
> (May 2013)
>
> Some details abou the proposed drafts for align PSC behaviour with
> transport requirements:
>
> draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities
> between FS and SF-P (see section 4.3.2 of rfc6378).
> Among the others, behaviors that will be fixed with the proposed updat= e
> are:
> Use case A) At first, working path(WP) and protection path(PP) are
> normal. Then, Forced Switch(FS) command is issued for maintenance on t= he
> WP and the traffic moves from WP to PP. When Signal Fail occurs on PP,=
> service cannot recover and is interrupted. This could occur for exampl= e
> as a result of accidentally un-plugging a PP fiber.
> Use case B) If there is an existing signal fail on a protection path > (SF-P),and FS command is issued by accident the traffic on WP will mov= e
> to PP. This results in an interruption of service from which you will<= br> > not automatically recover, because PSC should not have switched the > traffic from WP to PP.
> Discussion about this draft led to the proposal to modify RFC 4427 tha= t
> was "written correctly though lacking in detail causing mis-
> interpretation" that led to the current PSC set of priority that = the
> above draft is proposing to modified and to align to the required
> transport behavior. draft-helvoort-ccamp-fs-priority-00 has been
> submitted to CCAMP for clarifying the definitions related to Manual > Switch and Forced Switch and their usage relative to priorities.
> The way this behavior has to be incorporated into the PSC has to be > discussed. The text proposes to replace the current behavior with the<= br> > new one. If there is consensus to procede in that way this can bring t= o
> a simple and effective way to operate the protocol.
>
> ----------------------------------------------------------------------=
> draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378=
> to change non-revertive operations to behaves in the same way
> irrespectively of the trigger of protection switching (fault or operat= or
> command FS, MS). Consequently an operator command, Manual Switch to > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span&qu= ot; is also
> added to enable this behavior. From an operational point of view, MS t= o
> working path has also to be supported to be able to initially align at=
> both sides in case of non-revertive switching mode. MS to working path=
> is defined in RFC 5654, requirement 83.
>
> The proposed MS-W command is of equal priority to the existing MS-P > command, and there is text to handle the simultaneous or sequential > occurrence of two equal-priority commands. This behavior, already
> adopted in other transport network protection switching protocol, can = be
> used for other addition to the protocol in the future.
>
> ----------------------------------------------------------------------=
> draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state
> machine to handle Signal Degrade (SD). It does not define SD or provid= e
> scope around where or how SD may be used similarly as it already happe= n
> in the draft in handling other defects like SF (Signal Failure).
> In MPLS-TP survivability framework [RFC6372], a fault condition
> includes both Signal Fail (SF) and Signal Degrade (SD) that can be use= d
> to trigger protection switching.
> While the standardization lack of an SD definition and detection
> mechanisms, the relevant behaviors in terms of protection actions may<= br> > already be defined.
>
> ----------------------------------------------------------------------=
> draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to > test if the APS communication is operating correctly. In other words > both APS process logic including state machine and APS channel on
> protection path, without service disruption and without affecting any<= br> > protection operation, unless the protection transport entity is in use= .
> This command is documented in R84 of [RFC5654] and it is part of ITU-T=
> transport requirements.
> An alternative proposal is documented in the Appendix B of RFC6378 tha= t
> utilizes the Lockout of Protection (LO) or Forced Switch (FS) in
> combination of OAM functionalities. However, it has some functional > limitation and has a potential risk of losing traffic as a signal
> failure might occur during the exercise operation. In that case, LO or=
> FS has to be canceled to allow the PSC protocol to provide proper
> switching.
> A further alternative proposal is documented in draft-osborne-mpls-psc= -
> alive-00 that anyway show some functional limitations because cannot > validate the PSC state machine status and probably the Local Request > logic.
>
>
> The authors encourage the IETF experts to comment on these drafts,
> eventually proposing other options/mechanisms that can satisfy the sam= e
> requirements.
> Best regards,
> Alessandro, Huub, Jeong-dong, Taeksid
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e
> persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di=
> provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorise= d.
> If you are not the intended recipient, please delete this message and<= br> > any attachments and advise the sender by return e-mail, Thanks.
>
> rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se no= n
> =E8 necessario.

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/mpls
= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_22257C41A415324A984CD03D63344E271F1B8441TELMBA002RM001t_-- --_0ffdfb99-43a0-4c6e-b2bd-4f3f642a3e81_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_0ffdfb99-43a0-4c6e-b2bd-4f3f642a3e81_-- From stefano.ruffini@ericsson.com Mon Jul 22 06:06:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E11411E8118; Mon, 22 Jul 2013 06:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNWsyc88z6m7; Mon, 22 Jul 2013 06:06:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D8EC111E8111; Mon, 22 Jul 2013 06:06:25 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-b6-51ed2e50b8cd Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D6.9D.11907.05E2DE15; Mon, 22 Jul 2013 15:06:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.144]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 15:06:24 +0200 From: Stefano Ruffini To: Shahram Davari , "stbryant@cisco.com" Thread-Topic: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls Thread-Index: AQHOhFZGV50KoBkbc06ZNTDtPNmY5ZlrhPeAgAAnYYCAAC6qAIAALv2AgAASLwCABJMAwQ== Date: Mon, 22 Jul 2013 13:06:23 +0000 Message-ID: <1B5CAFEB4D81154AA0F020783784C3150F7E56@ESESSMB301.ericsson.se> References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> , <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <51E915BF.6020308@cisco.com> <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> <51E9644F.8060100@cisco.com>, <4A6CE49E6084B141B15C0713B8993F281BE8F310@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE8F310@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW6A3ttAg+0HbSzW93paHHzexGhx a+lKVotzT+cwWvxt7mF3YPWYdf8sm8eU3xtZPZYs+cnkMWvWYaYAligum5TUnMyy1CJ9uwSu jMv9V9kLGqUrDnVuYm1g/CXaxcjJISFgItH96RgThC0mceHeerYuRi4OIYGjjBL7f81jAUkI CSxhlFh3UR7EZgNqeL54NVADB4eIQKjEsnslIGFmgRyJxp+r2EBsYQFviQkTZkCV+Eo8WsIB EhYRCJM4M/MSI4jNIqAqMefPTjCbF6j8zKMmdohNc1kkWucWgticAuESx59dBTuNUUBWYsLu RYwQq8QlXkw/wQ5xsoDEkj3nmSFsUYmXj/+xQtiKEh9f7YOq15O4MXUKG4StLbFs4WtmiL2C EidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjuLU4qTcdCODTYzAiDq45bfFDsbLf20OMUpz sCiJ827ROxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFHegrH78XRG4ND1/2+35b58HP8 6473Fv63j9id/X5U0jrf5865ZI7gHbur1TawHDTRX/wi5ullbu/cE9J80/tKN0065jr/7Q/2 N64FmZtkjyzIm63CYDjLpdWmnO90pJ3hC5ZCk0DBvct3eT9ZY5Bl8vdqkWTuTJZdnAcPsZ1q un0sOE/HJFCJpTgj0VCLuag4EQDfhII2dgIAAA== Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: [mpls] R: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 13:06:33 -0000 Hi Please note that the performance is heavily dependent on the actual traffic= load as it can create asymmetries. Under certain conditions 7 hops might lead to quite bad performance Study is still ongoing to understand the partial timing support scenarios Best regards Stefano ________________________________________ Da: tictoc-bounces@ietf.org [tictoc-bounces@ietf.org] per conto di Shahram = Davari [davari@broadcom.com] Inviato: venerd=EC 19 luglio 2013 19.12 A: stbryant@cisco.com Cc: mpls@ietf.org; tictoc@ietf.org; S. Davari Oggetto: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpl= s Hi Stewart, Good question. It depends on the Servo algorithms used. The more hops the m= ore complex algorithms with longer convergence time. Any queuing point is p= otentially one hop that can introduce PDV. The 5-7 hops I mentioned is the = best proprietory servo algorithm I have seen, but the convergence time is v= ery long (many minutes). Thanks Shahram -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Friday, July 19, 2013 9:08 AM To: Shahram Davari Cc: Bhatia, Manav (Manav); mpls@ietf.org; tictoc@ietf.org; S. Davari Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpl= s Shahram That then poses two interesting question: 1) Do you ever need to go more than 7 hops? In the work we did on IPFRR the core was normally 8 hops across so most of the traffic in a single routing domain went less that 8 hops. 2) What happens when there is an underlying packet transport network which will introduce hidden hops? Stewart On 19/07/2013 14:19, Shahram Davari wrote: > Hi Stewart, > > Not necessarily. It is ok if some of the routers in the path are not timi= ng aware. That is the whole idea. We have tested cases in which 5-7 hops ar= e not 1588 aware and still we can recover the time correctly. > > Regards, > Shahram > > > On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" wrote: > >> On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote: >>> Hi Sasha, >>> >>>> 1) reserved label is not backward compatible with existing routers. On= e >>>> of the requirements is that routers that are not PTP aware can just >>>> switch the packet normally. Using a reserved label can't achieve this >>>> requirement, since routers that don't understand it will drop it or >>>> sent it to CPU. >>>> [[Sasha]] Is not this concern applicable to any new reserved label? >>>> And routers that use network processors as forwarding engines could >>>> easily overcome this issue by upgrading their microcode. >>>> But I agree that this is a valid concern. >>> This is a huge concern because not all routers use network processors t= hat can be reprogrammed. >>> >>> The current solution works with any router that can set up an MPLS path= . >> Really? >> >> Surely the LSR needs to know that on seeing a label in the FEC it needs >> to timestamp the packet. >> >> Stewart >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From stbryant@cisco.com Mon Jul 22 06:12:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14F221E8093 for ; Mon, 22 Jul 2013 06:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59f+FtZf4SGG for ; Mon, 22 Jul 2013 06:12:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D81FC21F99F7 for ; Mon, 22 Jul 2013 06:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1263; q=dns/txt; s=iport; t=1374498769; x=1375708369; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z0/JgO7Pz9S9KaguIWEC7ckGMKvivcHgewHTdlKRpYY=; b=WUCA/t5puOliQN1Bn/wDmSfppwEw6m9LqUQ/hDvbwdaFTAYY1PMZfRKW qVYkx3hc9S6I0qxyt2beXYXYYTeDDufn3XmfHiV4bmUYVklVfskKNZzi1 rTWCeGQ6vu/BbJNbxqoe6vbF8A3dWuTtC5IFjFUAODNury1ptHBE9SoH7 k=; X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208";a="84907139" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Jul 2013 13:12:44 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6MDCgVc001172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 13:12:42 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6MDCf2H025808; Mon, 22 Jul 2013 14:12:41 +0100 (BST) Message-ID: <51ED2FC9.304@cisco.com> Date: Mon, 22 Jul 2013 14:12:41 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: huubatwork@gmail.com References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <51ED1541.70108@gmail.com> In-Reply-To: <51ED1541.70108@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements 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: Mon, 22 Jul 2013 13:12:54 -0000 On 22/07/2013 12:19, Huub van Helvoort wrote: > >> >> What I'd like to understand about EXER is where it came from. The >> ITU specs that define it are pretty hard to follow, they seem to >> assume the reader already knows what EXER is and what problem it >> solves. It feels very much like a mechanism used to catch a very >> specific implementation bug, back when transport gear was far less >> debuggable than what we have today. > > [Huub] EXER was not designed/intended to be used for bug finding > although it will detect problems with implementation. > > [Huub] EXER was designed to verify that the state-machine at the > far end is able to respond to APS/PSC messages it receives from > the local end. > Even though state-machines should be tested extensively, there is > no 100% warranty. It can still have stopped due to external > circumstances, be in a deadlock due to unforseen order of events, > etc. Huub, I get a terrible Heisenberg feeling when you explain this to me. It is not clear whether or not including the EXER state and executing it from time to time poses a greater risk than assuming that : provided the daemon is running and the variables are as expected, the code will execute correctly. Stewart From eosborne@cisco.com Mon Jul 22 06:36:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BDA21E80B3 for ; Mon, 22 Jul 2013 06:36:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjxK5iMSrda3 for ; Mon, 22 Jul 2013 06:36:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1681C21E80A1 for ; Mon, 22 Jul 2013 06:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20400; q=dns/txt; s=iport; t=1374500176; x=1375709776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uzZ0lHPhtSOC7AZ1eu/t8l7JV2k1tlWeDpbBAgC+W1g=; b=AJSUQrrEuzKXiAVLDgc0skAmLEP2wU1j+iSSQ0VAY7mDtHOxltWIS20l xkVurAvFj7uRg7O5rvt1eQqbTxoyuAay4VPWf94g7eaT1iQh/LsvBWN0I XEHuMgsVjwuzUVmXFaGgZceWDmworbU7Sd55NrTO+hNIK85jwImHIolMY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAOkz7VGtJXG8/2dsb2JhbABagwY1UIMKvSYXdxZ0giQBAQEDAQEBASARNwMLBQcEAgEIEQQBAQMCBhkEAwICAh8GCxQBCAgBAQQBDQUIE4djAwkGDKYriC0NiFoEgSiMAoEfG4EBFhYFBwaCVzNuA5V0jhCFJoFZgTmBaAICBRcGHA X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208";a="234805256" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2013 13:36:15 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6MDaEPb029951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 13:36:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 08:36:14 -0500 From: "Eric Osborne (eosborne)" To: "Ryoo, Jeong-dong" , "D'Alessandro Alessandro Gerardo" , "mpls@ietf.org" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQADK5f8A== Date: Mon, 22 Jul 2013 13:36:14 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 13:36:21 -0000 SGkgSmVvbmctZG9uZywNCg0KICBUaGFua3MgZm9yIHRoZSByZXBseS4gIFBsZWFzZSBzZWUgaW5s aW5lIHdpdGggRU8jLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJ5 b28sIEplb25nLWRvbmcgW21haWx0bzpyeW9vQGV0cmkucmUua3JdDQo+IFNlbnQ6IE1vbmRheSwg SnVseSAyMiwgMjAxMyA0OjE1IEFNDQo+IFRvOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgRCdB bGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsNCj4gbXBsc0BpZXRmLm9yZw0KPiBDYzogSHV1 YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSk7IGh1dWJhdHdvcmtAZ21h aWwuY29tDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmlu ZyBNUExTLVRQIFBTQyBsaW5lYXINCj4gcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzDQo+IA0KPiBIaSwgRXJpYy4NCj4gDQo+IExldCBtZSBhbnN3ZXIgeW91ciAy bmQgcXVlc3Rpb24gb24gU0QuDQo+IA0KPiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBkZWZpbmVkIG9y IHByb3Bvc2VkIGZvciBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzDQo+IGNhbiBiZSBzdW1tYXJp emVkIGFzIGZvbGxvd3M6DQo+IC0gQnkgT0FNIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdG9vbDoN Cj4gICBTRCBpcyByYWlzZWQgaWYgcGFja2V0IGxvc3MgcmF0aW8gZXhjZWVkcyBhIHRocmVzaG9s ZCBkdXJpbmcgYQ0KPiBtZWFzdXJlbWVudCBwZXJpb2QuDQo+ICAgVGhyZXNob2xkIHZhbHVlIGFu ZCBtZWFzdXJlbWVudCBwZXJpb2QgYXJlIGNvbmZpZ3VyZWQgYnkgYW4gbmV0d29yaw0KPiBvcGVy YXRvci4NCj4gICBUaGlzIGRldGVjdGlvbiBtZXRob2QgaXMgYWxyZWFkeSBkZWZpbmVkIGluIElU VS1UIEcuODAyMSAoRXRoZXJuZXQNCj4gZXF1aXBtZW50IHNwZWMuKQ0KDQoNCkVPIyAgV2hlcmU/ ICBJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2aW5n IGEgaGFyZCB0aW1lIGZpbmRpbmcgaXQuICBBIHNlYXJjaCBmb3IgRVRIX0NJX1NTRCBkb2Vzbid0 IHlpZWxkIG11Y2guICBJZiBJIGxvb2sgZm9yICdzaWduYWwgZGVncmFkZScgSSBzZWUgcC4gMTMx IHdoaWNoIHNheXMgdGhhdCB0aGUgYWxnb3JpdGhtIGlzIGRlZmluZWQgaW4gRy44MDMxLiAgRy44 MDMxIHNheXMgJyBIb3cgdGhlc2UgZGVmZWN0cyBhcmUgZGV0ZWN0ZWQgaXMgdGhlIHN1YmplY3Qg b2YgdGhlIGVxdWlwbWVudCBSZWNvbW1lbmRhdGlvbnMnLiAgSSdtIGxvb2tpbmcgZm9yIHNvbWV0 aGluZyBsaWtlICJTaWduYWwgRGVncmFkZSBpcyBkZWZpbmVkIGFzICRmb28gcGFja2V0IGxvc3Mg b3IgQ1JDIGZhaWx1cmUgb3ZlciAkYmFyIHRpbWUiLi4uLndoYXQgaGF2ZSBJIG1pc3NlZD8NCg0K DQo+ICAgYW5kIHRoZSBlcXVpcG1lbnQgc3BlYyBmb3IgTVBMUy1UUCBjYW4gZWFzaWx5IGZvbGxv dyB0aGUgc2FtZQ0KPiBkZWZpbml0aW9uLg0KPiAtIEJ5IHNlcnZlciBsYXllciBpbmRpY2F0aW9u Og0KPiAgIFNEIGlzIHJhaXNlZCBpZiBhIHNlcnZlciBsYXllciBiZWxvdyBNUExTLVRQIHJlcG9y dHMgU0QgY29uZGl0aW9uIG9uDQo+IGl0cyBvd24gbGF5ZXIuDQo+IC0gQnkgQ0NNIHBhY2tldCBj b3VudGluZzoNCj4gICBTRCBpcyByYWlzZWQgaWYgdGhlIGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tl dHMgZXhjZWVkcyBhIHRocmVzaG9sZA0KPiBkdXJpbmcgYSBtZWFzdXJlbWVudCBwZXJpb2QuDQo+ IA0KPiBSZWdhcmRsZXNzIG9mIGhvdyB0byBkZXRlY3QgU0QsIGFueSBwcm90ZWN0aW9uIHN3aXRj aGluZyBkb2N1bWVudHMNCj4gc2hvdWxkIGRlc2NyaWJlIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGlu ZyBvcGVyYXRpb24gb25jZSBzdWNoIGEgU0QgaXMNCj4gZGVjbGFyZWQuDQo+IA0KLi4uDQo+IFJl Z2FyZGluZyB0aGUgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEOg0KPiBJdCBpcyBjZXJ0YWlubHkgcG9z c2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC4NCj4gQnV0LCBhcyBmYXIgYXMg dGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGNvbmNlcm5lZCwgaXQganVzdCBuZWVkcyB0bw0K PiBrbm93IGlmIFNEIGlzIHNpZ25hbGVkIHRvIHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb2Nlc3Mg b3Igbm90Lg0KPiBJdCB3b3VsZCBiZSBhIG5ldHdvcmsgb3BlcmF0b3IncyBjaG9pY2UgYXQgd2hh dCBsZXZlbCBvZiBTRCBoZSB3YW50cyBoaXMNCj4gbmV0d29yayBwcm90ZWN0aW9uIHRvIHN3aXRj aG92ZXIuDQo+IEluIG90aGVyIHdvcmRzLCB3aGF0IHRyaWdnZXJzIHByb3RlY3Rpb24gc3dpdGNo aW5nIGlzIFNEIG9yIG5vIFNELiBJdCBpcw0KPiB5ZXMgb3Igbm8gZGVjaXNpb24uDQoNCg0KRU8j ICBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgZG9jdW1lbnQgd2hpY2ggc3VnZ2VzdHMgdGhhdCBhIHNl cnZlciBsYXllciBTRCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhIGNsaWVudCBsYXllciBTRC4gIElu IHRoZSBJUCB3b3JsZCwgaWYgd2UgaGF2ZSBTRCBvbiBhIHRyYW5zcG9ydCBpbnRlcmZhY2UgdGhh dCBpcyBnZW5lcmFsbHkgdXNlZCB0byBicmluZyB0aGUgaW50ZXJmYWNlIGRvd24gKGkuZS4gU0Yp LiAgVGhpcyBpcyB0aGUgc29ydCBvZiB0aGluZyBJJ2QgbGlrZSB0byBzZWUgaW4gbW9yZSBkZXRh aWwsIGFzIFNEIGluIHRoZSBwYWNrZXQgd29ybGQgaXMgYSBuZXcgY29uY2VwdCBhbmQgd2UgY2Fu J3QganVzdCBhc3N1bWUgdGhhdCBpdCB3aWxsIHdvcmsgdGhlIHNhbWUgZXZlcnl3aGVyZSBiZWNh dXNlIHdlIGRlZmluZSBzdGF0ZSBtYWNoaW5lIHBvaW50cyBmb3IgaXQuDQoNClRoZSBwb2ludCBh Ym91dCBDQ00gaXMgYSBnb29kIG9uZS4gIExldCdzIHNheSB3ZSBjb21lIHVwIHdpdGggYSBjbGV2 ZXIgU0QgbWVjaGFuaXNtIHdpdGggdHdvIHRocmVzaG9sZHMsIGNhbGwgdGhlbSBtYWpvciBhbmQg bWlub3IuICBGb3IgZGlzY3Vzc2lvbiBwdXJwb3NlcyB0aGV5IGNvdWxkIGJlIHNpbXBsZSBlcnJv ciByYXRpb3MsIGUuZy4gMToxMF42IGFuZCAxOjEwXjkuICBCdXQgdGhleSBjb3VsZCBiZSBtb3Jl IHBvd2VyZnVsIHRoYW4gdGhhdCAoZmxvdyB0eXBlLCBmbG93IGxlbmd0aCwgZXJyb3IgYnVyc3Qg c2l6ZSwgZXRjKS4NCg0KSWYgd2Ugd2FudCB0byBoYXZlIFNELU1ham9yIGFuZCBTRC1NaW5vciBp bnB1dHMgYXMgc2VwYXJhdGUgdHJpZ2dlcnMgZm9yIFBTQywgd2UgbWF5IHdhbnQgdGhlbSBhdCBk aWZmZXJlbnQgcG9pbnRzLiAgUGVyaGFwcyAgKGxlYXZpbmcgb3V0IHRoZSBXb3JraW5nIHBhdGgg Zm9yIGVhc2Ugb2YgcmVhZGluZykNCg0KTE8NCkZTDQpTRi1QDQpTRC1QLU1ham9yDQpNUw0KU0Qt UC1NaW5vcg0KDQoNClRoaXMgc2VlbXMgbGlrZSBhIHBlcmZlY3RseSByZWFzb25hYmxlIHRoaW5n IHRvIHdhbnQuICANCg0KDQpFdmVuIGlmIHdlIGRvbid0IGhhdmUgbXVsdGktdGllciBTRCwgZXZl biB0aGUgc2luZ2xlLXRpZXIgU0QgbmVlZHMgdG8gYmUgZGVmaW5lZCBiZWZvcmUgd2UgY2FuIGRl Y2lkZSBob3cgdG8gcmVzcG9uZCB0byBpdC4NCg0KPiBUaGUgcHJvcG9zZWQgZHJhZnQgY292ZXJz IFNELXRyaWdnZXJlZCBwcm90ZWN0aW9uIG5vIG1hdHRlciB3aGF0IGtpbmRzDQo+IG9mIFNEIGRl dGVjdGlvbiBtZXRob2RzIGFyZSB1c2VkLg0KPiANCj4gDQo+IFNGIGNhbiBhbHNvIGJlIHZpZXdl ZCBhcyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFzIHRoZSBuZXR3b3JrDQo+IG9wZXJh dG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ00g bWVzc2FnZXMuDQoNCg0KRU8jIA0KSSdtIG5vdCBzdXJlIHdoYXQgdGhhdCB3b3VsZCBsb29rIGxp a2UuICAnRmFpbCcgaXMgYSBwcmV0dHkgYmluYXJ5IHRoaW5nLiAgJ0RlZ3JhZGUnIGlzIGEgY29u dGludW91cyB2YXJpYWJsZSwgYXMgaXQgY2FuIGJlIGFueXRoaW5nIGZyb20gJ2EgbGl0dGxlIGJh ZCcgdG8gYSAnYSB3aG9sZSBsb3Qgb2YgYmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuDQoNCj4gSWYg Q0NNIGlzIGRpc2FibGVkLCBBSVMgZnJvbSBhIHNlcnZlciBsYXllciBjYW4gYmUgdXNlZCBhcyBh IHRyaWdnZXIgZm9yDQo+IHByb3RlY3Rpb24gc3dpdGNoaW5nLiBTbyBhbmQgc28gZm9ydGguDQoN CkVPIyAgQUlTIGZyb20gdGhlIHNlcnZlciBsYXllciBvbmx5IGdldHMgeW91IFNEIGZyb20gdGhl IGZpcnN0IGhvcCBvZiB0aGUgdW5kZXJseWluZyBzZXJ2ZXIgcGF0aC4NCg0KDQoNCg0KZXJpYw0K DQo+IEhvd2V2ZXIsIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmlu ZSBob3cgdG8gZGV0ZWN0IFNGDQo+IGluIGFueXdoZXJlLg0KPiBTaW1pbGFyeSwgcHJvdGVjdGlv biBzd2l0Y2hpbmcgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGhvdyBtYW51YWwNCj4gc3dpdGNo IGFuZCBmb3JjZWQgc3dpdGNoIGNvbW1hbmRzDQo+IGFyZSBpbml0aWF0ZWQgaW4gYSBtYW5hZ2Vt ZW50IHN5c3RlbSBhbmQgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbg0KPiBzd2l0Y2hpbmcgcHJvY2Vz cy4NCj4gDQo+IEFnYWluLCBpbiBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlv biBjYW4gYWNjb21tb2RhdGUgYW55IFNEDQo+IGRldGVjdGlvbiBtZXRob2RzLg0KPiANCj4gQmVz dCByZWdhcmRzLA0KPiANCj4gSmVvbmctZG9uZw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gRnJvbSA6ICJFcmljIE9zYm9y bmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4NCj4gU2VudCA6IDIwMTMtMDctMjAg MDI6NDg6MjggKCArMDk6MDAgKQ0KPiBUbyA6IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFy ZG8NCj4gPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4sIG1wbHNAaWV0 Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+DQo+IENjIDogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVs dm9vcnRAaHVhd2VpLmNvbSkNCj4gPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+LCBodXVi YXR3b3JrQGdtYWlsLmNvbQ0KPiA8aHV1YmF0d29ya0BnbWFpbC5jb20+DQo+IFN1YmplY3QgOiBS ZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFy DQo+IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPiANCj4g DQo+IEhpIEFsZXNzYW5kcm8tDQo+IA0KPiBUaGFua3MgZm9yIHRoaXM7IHRoZSB0aHJlYWRzIEkg c3RhcnRlZCBzb21lIHRpbWUgYmFjayBzZWVtIHRvIGhhdmUgZGllZA0KPiBkb3duLCBpdCdzIGdv b2QgdG8gZ2V0IHRoZW0gZ29pbmcgYWdhaW4uDQo+IEkgaGF2ZSB0d28gdGhpbmdzIEkgbmV2ZXIg cXVpdGUgdW5kZXJzdG9vZCwgY2FuIHlvdSBjbGFyaWZ5IHRoZW0gZm9yIG1lPw0KPiANCj4gaSkg Y2FuIHlvdSBleHBsYWluIEVYRVIgYXQgYSBoaWdoZXIgbGV2ZWw/IEknbSBub3QgbG9va2luZyBm b3IgYQ0KPiBkZXNjcmlwdGlvbiBvZiB0aGUgc3RhdGUgbWFjaGluZSBjaGFuZ2VzLCBhbmQgSSdt IG5vdCBsb29raW5nIGZvciB0aGUNCj4gb25lIGxpbmUgIkl0IGFsbG93cyB0aGUgRlNNIHRvIGJl IHRlc3RlZCIuIFdlIGhhdmUgYWxsIG9mIHRoYXQgaW4gdGhlDQo+IGRyYWZ0IGFuZCBpbiB0aGUg ZXF1aXZhbGVudCBJVFUgc3BlY3MuDQo+IA0KPiBXaGF0IEknZCBsaWtlIHRvIHVuZGVyc3RhbmQg YWJvdXQgRVhFUiBpcyB3aGVyZSBpdCBjYW1lIGZyb20uIFRoZSBJVFUNCj4gc3BlY3MgdGhhdCBk ZWZpbmUgaXQgYXJlIHByZXR0eSBoYXJkIHRvIGZvbGxvdywgdGhleSBzZWVtIHRvIGFzc3VtZSB0 aGUNCj4gcmVhZGVyIGFscmVhZHkga25vd3Mgd2hhdCBFWEVSIGlzIGFuZCB3aGF0IHByb2JsZW0g aXQgc29sdmVzLiBJdCBmZWVscw0KPiB2ZXJ5IG11Y2ggbGlrZSBhIG1lY2hhbmlzbSB1c2VkIHRv IGNhdGNoIGEgdmVyeSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbg0KPiBidWcsIGJhY2sgd2hlbiB0 cmFuc3BvcnQgZ2VhciB3YXMgZmFyIGxlc3MgZGVidWdnYWJsZSB0aGFuIHdoYXQgd2UgaGF2ZQ0K PiB0b2RheS4NCj4gDQo+IE5vIG90aGVyIHN0YXRlIG1hY2hpbmVzIHRoYXQgSSdtIGZhbWlsaWFy IHdpdGggKFJTVlAsIExEUCwgQkdQLCBPU1BGLA0KPiBJU0lTKSBoYXZlIGV4cGxpY2l0IHNpZ25h bGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvciB3aGV0aGVyDQo+IGl0ICp3b3Vs ZCogYmUgYnJva2VuIGlmIGlmIHdlcmUsIGluIHRoZSBmdXR1cmUsIHRvIGJlIGdpdmVuIGEgcGFy dGljdWxhcg0KPiBpbnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBiZWhpbmQgRVhF UiBoYXMgYmVlbiB0aGF0IEkgZG9uJ3QNCj4gZmVlbCBjb21mb3J0YWJsZSB3aXRoIHRoZSBpZGVh IG9mIGtlZXBpbmcgYSAzMC15ZWFyLW9sZCB3b3JrYXJvdW5kIGluIGENCj4gcHJvdG9jb2wuIElz IHRoZXJlIG1vcmUgdG8gaXQgdGhhbiB0aGF0PyBIYXZlIEkgbWlzcmVhZCBhbmQNCj4gbWlzdW5k ZXJzdG9vZCBFWEVSPyBEb2VzIG1vZGVybiB0cmFuc3BvcnQgZ2VhciBldmVyIGFjdHVhbGx5IGRl dGVjdCBhDQo+IHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3YXNuJ3Qgb2J2aW91cyB0byB0aGUg b3BlcmF0b3IgdXNpbmcgb3RoZXINCj4gbWVhbnM/DQo+IA0KPiANCj4gaWkpIFdoeSB0aGUgcHVz aCB0byBzdGFuZGFyZGl6ZSB0aGUgU0Qgc3RhdGUgY2hhbmdlcyBiZWZvcmUgd2UndmUNCj4gZGVm aW5lZCBTRD8gSSBjZXJ0YWlubHkgYWdyZWUgdGhhdCBoYW5kbGluZyBzaWduYWwgZGVncmFkZSBp cyBhIGdvb2QNCj4gaWRlYSwgYnV0IGNvbWluZyB1cCB3aXRoIGEgZGVmaW5pdGlvbiBmb3IgaXQg aGFzIGJlZW4gY2hhbGxlbmdpbmcuIFdoYXQNCj4gaGFwcGVucyBpZiB3ZSBjaGFuZ2UgdGhlIEZT TSB0byBoYW5kbGUgaXQsIHRoZW4gY29tZSB1cCB3aXRoIHNvbWV0aGluZw0KPiBtb3JlIHNvcGhp c3RpY2F0ZWQgKHNheSwgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEKSB0aGF0IGRvZXNuJ3QgcXVpdGUg Zml0DQo+IHdpdGggdGhlIEZTTSBjaGFuZ2VzPw0KPiANCj4gDQo+IA0KPiB0aGFua3MhDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gZXJpYw0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJv IEdlcmFyZG8NCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgMzoyMyBQTQ0KPiA+ IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gQ2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZv b3J0QGh1YXdlaS5jb20pOyBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiA+IFN1YmplY3Q6IFttcGxz XSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcg0KPiA+IHBy b3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPiA+DQo+ID4gRGVh ciBhbGwsDQo+ID4gd2Ugd291bGQgbGlrZSBzb2NpYWxpemluZyB0aGUgaGVyZWJlbG93IGRyYWZ0 cyB0aGF0IHdlcmUgc3VibWl0dGVkDQo+IHNvbWUNCj4gPiBtb250aHMgYWdvIHdpdGggdGhlIGFp bSB0byBhbGlnbiBQU0MgcHJvdG9jb2wgKFJGQyA2Mzc4KSB0byBJVFUtVA0KPiA+IHRyYW5zcG9y dCByZXF1aXJlbWVudHMuIEkgd291bGQgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFib3V0IHRo ZQ0KPiA+IHByb3Bvc2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91cnMuDQo+ID4NCj4gPiBkcmFm dC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDANCj4gPiBkcmFmdC1jZGgtbXBscy10cC1wc2Mt bm9uLXJldmVydGl2ZS0wMA0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMA0KPiA+IGRy YWZ0LWRqLW1wbHMtdHAtZXhlci1wc2MtMDEgLyBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLWFsaXZl LTAwDQo+ID4NCj4gPiBUaGUgYWJvdmUgZHJhZnRzIGNvdmVyIG1vc3Qgb2YgaXRlbXMgaGlnaGxp Z2h0ZWQgaW4gSVRVLVQgbGlhaXNvbnMNCj4gYWJvdXQNCj4gPiBQU0MgYW5kIHRoZXkgcHJvcG9z ZSBzb2x1dGlvbnMgaW4gbGluZSB3aXRoIE1QTFMtVFAgdHJhbnNwb3J0DQo+ID4gcmVxdWlyZW1l bnRzLg0KPiA+IEEgbGlzdCBvZiBtYWluIGxpYWlzb25zIGV4Y2hhbmdlZCBiZXR3ZWVuIElUVS1U IGFuZCBJRVRGIHdpdGggdGhlIGFpbQ0KPiB0bw0KPiA+IGFsaWduIFBTQyBiZWhhdmlvdXMgd2l0 aCBJVFUtVCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGZvciBsaW5lYXINCj4gPiBwcm90ZWN0aW9u IGFyZSBnaXZlbiBiZWxvdzoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlz b24vMTE2Mi8gKEp1bmUgMjAxMikNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xp YWlzb24vMTIwNS8NCj4gPiAoT2N0b2JlciAyMDEyKQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbGlhaXNvbi8xMjI5Lw0KPiA+IChKYW51YXJ5IDIwMTMpDQo+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvDQo+ID4gKEZlYnJ1YXJ5IDIwMTMpDQo+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyNTYvDQo+ID4gKE1heSAy MDEzKQ0KPiA+DQo+ID4gU29tZSBkZXRhaWxzIGFib3UgdGhlIHByb3Bvc2VkIGRyYWZ0cyBmb3Ig YWxpZ24gUFNDIGJlaGF2aW91ciB3aXRoDQo+ID4gdHJhbnNwb3J0IHJlcXVpcmVtZW50czoNCj4g Pg0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMCBwcm9wb3NlcyBzd2FwcGlu ZyB0aGUgcHJpb3JpdGllcw0KPiA+IGJldHdlZW4gRlMgYW5kIFNGLVAgKHNlZSBzZWN0aW9uIDQu My4yIG9mIHJmYzYzNzgpLg0KPiA+IEFtb25nIHRoZSBvdGhlcnMsIGJlaGF2aW9ycyB0aGF0IHdp bGwgYmUgZml4ZWQgd2l0aCB0aGUgcHJvcG9zZWQNCj4gdXBkYXRlDQo+ID4gYXJlOg0KPiA+IFVz ZSBjYXNlIEEpIEF0IGZpcnN0LCB3b3JraW5nIHBhdGgoV1ApIGFuZCBwcm90ZWN0aW9uIHBhdGgo UFApIGFyZQ0KPiA+IG5vcm1hbC4gVGhlbiwgRm9yY2VkIFN3aXRjaChGUykgY29tbWFuZCBpcyBp c3N1ZWQgZm9yIG1haW50ZW5hbmNlIG9uDQo+IHRoZQ0KPiA+IFdQIGFuZCB0aGUgdHJhZmZpYyBt b3ZlcyBmcm9tIFdQIHRvIFBQLiBXaGVuIFNpZ25hbCBGYWlsIG9jY3VycyBvbiBQUCwNCj4gPiBz ZXJ2aWNlIGNhbm5vdCByZWNvdmVyIGFuZCBpcyBpbnRlcnJ1cHRlZC4gVGhpcyBjb3VsZCBvY2N1 ciBmb3INCj4gZXhhbXBsZQ0KPiA+IGFzIGEgcmVzdWx0IG9mIGFjY2lkZW50YWxseSB1bi1wbHVn Z2luZyBhIFBQIGZpYmVyLg0KPiA+IFVzZSBjYXNlIEIpIElmIHRoZXJlIGlzIGFuIGV4aXN0aW5n IHNpZ25hbCBmYWlsIG9uIGEgcHJvdGVjdGlvbiBwYXRoDQo+ID4gKFNGLVApLGFuZCBGUyBjb21t YW5kIGlzIGlzc3VlZCBieSBhY2NpZGVudCB0aGUgdHJhZmZpYyBvbiBXUCB3aWxsDQo+IG1vdmUN Cj4gPiB0byBQUC4gVGhpcyByZXN1bHRzIGluIGFuIGludGVycnVwdGlvbiBvZiBzZXJ2aWNlIGZy b20gd2hpY2ggeW91IHdpbGwNCj4gPiBub3QgYXV0b21hdGljYWxseSByZWNvdmVyLCBiZWNhdXNl IFBTQyBzaG91bGQgbm90IGhhdmUgc3dpdGNoZWQgdGhlDQo+ID4gdHJhZmZpYyBmcm9tIFdQIHRv IFBQLg0KPiA+IERpc2N1c3Npb24gYWJvdXQgdGhpcyBkcmFmdCBsZWQgdG8gdGhlIHByb3Bvc2Fs IHRvIG1vZGlmeSBSRkMgNDQyNw0KPiB0aGF0DQo+ID4gd2FzICJ3cml0dGVuIGNvcnJlY3RseSB0 aG91Z2ggbGFja2luZyBpbiBkZXRhaWwgY2F1c2luZyBtaXMtDQo+ID4gaW50ZXJwcmV0YXRpb24i IHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBzZXQgb2YgcHJpb3JpdHkgdGhhdCB0aGUNCj4g PiBhYm92ZSBkcmFmdCBpcyBwcm9wb3NpbmcgdG8gbW9kaWZpZWQgYW5kIHRvIGFsaWduIHRvIHRo ZSByZXF1aXJlZA0KPiA+IHRyYW5zcG9ydCBiZWhhdmlvci4gZHJhZnQtaGVsdm9vcnQtY2NhbXAt ZnMtcHJpb3JpdHktMDAgaGFzIGJlZW4NCj4gPiBzdWJtaXR0ZWQgdG8gQ0NBTVAgZm9yIGNsYXJp ZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0ZWQgdG8gTWFudWFsDQo+ID4gU3dpdGNoIGFuZCBG b3JjZWQgU3dpdGNoIGFuZCB0aGVpciB1c2FnZSByZWxhdGl2ZSB0byBwcmlvcml0aWVzLg0KPiA+ IFRoZSB3YXkgdGhpcyBiZWhhdmlvciBoYXMgdG8gYmUgaW5jb3Jwb3JhdGVkIGludG8gdGhlIFBT QyBoYXMgdG8gYmUNCj4gPiBkaXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRvIHJlcGxhY2Ug dGhlIGN1cnJlbnQgYmVoYXZpb3Igd2l0aCB0aGUNCj4gPiBuZXcgb25lLiBJZiB0aGVyZSBpcyBj b25zZW5zdXMgdG8gcHJvY2VkZSBpbiB0aGF0IHdheSB0aGlzIGNhbiBicmluZw0KPiB0bw0KPiA+ IGEgc2ltcGxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIG9wZXJhdGUgdGhlIHByb3RvY29sLg0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0 aXZlLTAwIGNvbnRhaW5zIHRoZSB1cGRhdGVzIHRvIFJGQzYzNzgNCj4gPiB0byBjaGFuZ2Ugbm9u LXJldmVydGl2ZSBvcGVyYXRpb25zIHRvIGJlaGF2ZXMgaW4gdGhlIHNhbWUgd2F5DQo+ID4gaXJy ZXNwZWN0aXZlbHkgb2YgdGhlIHRyaWdnZXIgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGZhdWx0 IG9yDQo+IG9wZXJhdG9yDQo+ID4gY29tbWFuZCBGUywgTVMpLiBDb25zZXF1ZW50bHkgYW4gb3Bl cmF0b3IgY29tbWFuZCwgTWFudWFsIFN3aXRjaCB0bw0KPiA+IFdvcmtpbmcgKE1TLVcpIGEuay5h ICJNYW51YWwgc3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIiBpcw0KPiBhbHNvDQo+ ID4gYWRkZWQgdG8gZW5hYmxlIHRoaXMgYmVoYXZpb3IuIEZyb20gYW4gb3BlcmF0aW9uYWwgcG9p bnQgb2YgdmlldywgTVMNCj4gdG8NCj4gPiB3b3JraW5nIHBhdGggaGFzIGFsc28gdG8gYmUgc3Vw cG9ydGVkIHRvIGJlIGFibGUgdG8gaW5pdGlhbGx5IGFsaWduIGF0DQo+ID4gYm90aCBzaWRlcyBp biBjYXNlIG9mIG5vbi1yZXZlcnRpdmUgc3dpdGNoaW5nIG1vZGUuIE1TIHRvIHdvcmtpbmcgcGF0 aA0KPiA+IGlzIGRlZmluZWQgaW4gUkZDIDU2NTQsIHJlcXVpcmVtZW50IDgzLg0KPiA+DQo+ID4g VGhlIHByb3Bvc2VkIE1TLVcgY29tbWFuZCBpcyBvZiBlcXVhbCBwcmlvcml0eSB0byB0aGUgZXhp c3RpbmcgTVMtUA0KPiA+IGNvbW1hbmQsIGFuZCB0aGVyZSBpcyB0ZXh0IHRvIGhhbmRsZSB0aGUg c2ltdWx0YW5lb3VzIG9yIHNlcXVlbnRpYWwNCj4gPiBvY2N1cnJlbmNlIG9mIHR3byBlcXVhbC1w cmlvcml0eSBjb21tYW5kcy4gVGhpcyBiZWhhdmlvciwgYWxyZWFkeQ0KPiA+IGFkb3B0ZWQgaW4g b3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdG9jb2wsIGNh bg0KPiBiZQ0KPiA+IHVzZWQgZm9yIG90aGVyIGFkZGl0aW9uIHRvIHRoZSBwcm90b2NvbCBpbiB0 aGUgZnV0dXJlLg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRw LXBzYy1zZC0wMCBwcm92aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQU0Mgc3RhdGUNCj4gPiBtYWNo aW5lIHRvIGhhbmRsZSBTaWduYWwgRGVncmFkZSAoU0QpLiBJdCBkb2VzIG5vdCBkZWZpbmUgU0Qg b3INCj4gcHJvdmlkZQ0KPiA+IHNjb3BlIGFyb3VuZCB3aGVyZSBvciBob3cgU0QgbWF5IGJlIHVz ZWQgc2ltaWxhcmx5IGFzIGl0IGFscmVhZHkNCj4gaGFwcGVuDQo+ID4gaW4gdGhlIGRyYWZ0IGlu IGhhbmRsaW5nIG90aGVyIGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZhaWx1cmUpLg0KPiA+IElu IE1QTFMtVFAgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgW1JGQzYzNzJdLCBhIGZhdWx0IGNvbmRp dGlvbg0KPiA+IGluY2x1ZGVzIGJvdGggU2lnbmFsIEZhaWwgKFNGKSBhbmQgU2lnbmFsIERlZ3Jh ZGUgKFNEKSB0aGF0IGNhbiBiZQ0KPiB1c2VkDQo+ID4gdG8gdHJpZ2dlciBwcm90ZWN0aW9uIHN3 aXRjaGluZy4NCj4gPiBXaGlsZSB0aGUgc3RhbmRhcmRpemF0aW9uIGxhY2sgb2YgYW4gU0QgZGVm aW5pdGlvbiBhbmQgZGV0ZWN0aW9uDQo+ID4gbWVjaGFuaXNtcywgdGhlIHJlbGV2YW50IGJlaGF2 aW9ycyBpbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFjdGlvbnMgbWF5DQo+ID4gYWxyZWFkeSBiZSBk ZWZpbmVkLg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IGRyYWZ0LWRqLW1wbHMtdHAtZXhl ci1wc2MtMDEgcHJvcG9zZXMgYWRkaW5nIHRoZSBFWEVSL1JSIGNvbW1hbmRzIHRvDQo+ID4gdGVz dCBpZiB0aGUgQVBTIGNvbW11bmljYXRpb24gaXMgb3BlcmF0aW5nIGNvcnJlY3RseS4gSW4gb3Ro ZXIgd29yZHMNCj4gPiBib3RoIEFQUyBwcm9jZXNzIGxvZ2ljIGluY2x1ZGluZyBzdGF0ZSBtYWNo aW5lIGFuZCBBUFMgY2hhbm5lbCBvbg0KPiA+IHByb3RlY3Rpb24gcGF0aCwgd2l0aG91dCBzZXJ2 aWNlIGRpc3J1cHRpb24gYW5kIHdpdGhvdXQgYWZmZWN0aW5nIGFueQ0KPiA+IHByb3RlY3Rpb24g b3BlcmF0aW9uLCB1bmxlc3MgdGhlIHByb3RlY3Rpb24gdHJhbnNwb3J0IGVudGl0eSBpcyBpbg0K PiB1c2UuDQo+ID4gVGhpcyBjb21tYW5kIGlzIGRvY3VtZW50ZWQgaW4gUjg0IG9mIFtSRkM1NjU0 XSBhbmQgaXQgaXMgcGFydCBvZiBJVFUtVA0KPiA+IHRyYW5zcG9ydCByZXF1aXJlbWVudHMuDQo+ ID4gQW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiB0aGUgQXBwZW5kaXgg QiBvZiBSRkM2Mzc4DQo+IHRoYXQNCj4gPiB1dGlsaXplcyB0aGUgTG9ja291dCBvZiBQcm90ZWN0 aW9uIChMTykgb3IgRm9yY2VkIFN3aXRjaCAoRlMpIGluDQo+ID4gY29tYmluYXRpb24gb2YgT0FN IGZ1bmN0aW9uYWxpdGllcy4gSG93ZXZlciwgaXQgaGFzIHNvbWUgZnVuY3Rpb25hbA0KPiA+IGxp bWl0YXRpb24gYW5kIGhhcyBhIHBvdGVudGlhbCByaXNrIG9mIGxvc2luZyB0cmFmZmljIGFzIGEg c2lnbmFsDQo+ID4gZmFpbHVyZSBtaWdodCBvY2N1ciBkdXJpbmcgdGhlIGV4ZXJjaXNlIG9wZXJh dGlvbi4gSW4gdGhhdCBjYXNlLCBMTyBvcg0KPiA+IEZTIGhhcyB0byBiZSBjYW5jZWxlZCB0byBh bGxvdyB0aGUgUFNDIHByb3RvY29sIHRvIHByb3ZpZGUgcHJvcGVyDQo+ID4gc3dpdGNoaW5nLg0K PiA+IEEgZnVydGhlciBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIGRyYWZ0 LW9zYm9ybmUtbXBscy0NCj4gcHNjLQ0KPiA+IGFsaXZlLTAwIHRoYXQgYW55d2F5IHNob3cgc29t ZSBmdW5jdGlvbmFsIGxpbWl0YXRpb25zIGJlY2F1c2UgY2Fubm90DQo+ID4gdmFsaWRhdGUgdGhl IFBTQyBzdGF0ZSBtYWNoaW5lIHN0YXR1cyBhbmQgcHJvYmFibHkgdGhlIExvY2FsIFJlcXVlc3QN Cj4gPiBsb2dpYy4NCj4gPg0KPiA+DQo+ID4gVGhlIGF1dGhvcnMgZW5jb3VyYWdlIHRoZSBJRVRG IGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFmdHMsDQo+ID4gZXZlbnR1YWxseSBwcm9w b3Npbmcgb3RoZXIgb3B0aW9ucy9tZWNoYW5pc21zIHRoYXQgY2FuIHNhdGlzZnkgdGhlDQo+IHNh bWUNCj4gPiByZXF1aXJlbWVudHMuDQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IEFsZXNzYW5kcm8s IEh1dWIsIEplb25nLWRvbmcsIFRhZWtzaWQNCj4gPiBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUNCj4gYWxsZQ0KPiA+IHBl cnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6 aW9uZQ0KPiA+IGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlv bmkgc29ubyByaWdvcm9zYW1lbnRlDQo+ID4gdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2 dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZQ0KPiA+IGNvcnRlc2VtZW50ZSBw cmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkN Cj4gPiBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQo+ID4NCj4gPiBU aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNv bnRhaW4NCj4gPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVz c2VlKHMpIG9ubHkuDQo+ID4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNl IGJ5IGFueWJvZHkgZWxzZSBpcw0KPiB1bmF1dGhvcmlzZWQuDQo+ID4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kDQo+ ID4gYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls LCBUaGFua3MuDQo+ID4NCj4gPiByaXNwZXR0YSBsJ2FtYmllbnRlUmlzcGV0dGEgbCdhbWJpZW50 ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlDQo+IG5vbg0KPiA+IMOoIG5lY2Vzc2FyaW8u DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From eosborne@cisco.com Mon Jul 22 06:42:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BE511E80AE for ; Mon, 22 Jul 2013 06:42:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFgdMKcjNYl7 for ; Mon, 22 Jul 2013 06:42:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B4EEE11E8105 for ; Mon, 22 Jul 2013 06:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8992; q=dns/txt; s=iport; t=1374500542; x=1375710142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KQ0+RPTaSJTC5jVTLfJx4rnIO+gIv6rhkPP/6KnSPuI=; b=iPiCpBdKuAxSZHxJ5J5neWQgxnNxNnADtOgSp29E5Dwa9oPSsoHbB1F4 U/Ga+ePBKEdi5nCFxNt6O4saFgL617dTPnOf59pe6uDMO37RVpvFo069m vyLEMngEWKWqs+t2H5sgUwunDNUFzKWt4BgG0Axtze3nkzrOO09uQOQWf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAHg27VGtJV2Z/2dsb2JhbABagwaBBYMKvSYXeBZ0giQBAQEDASMRMxIFCwIBBgIaAgYZBwICAjAVEAEBBA4NiAIGinybQZEZgSiOPTEHgl0zbgOUBpUkgVmBOYFoIx8 X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208";a="237823398" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jul 2013 13:42:22 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6MDgM84019685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 13:42:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 08:42:21 -0500 From: "Eric Osborne (eosborne)" To: "huubatwork@gmail.com" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAJQvYYAABxHNoA== Date: Mon, 22 Jul 2013 13:42:20 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721028A463@xmb-rcd-x09.cisco.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <51ED1541.70108@gmail.com> In-Reply-To: <51ED1541.70108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 13:42:36 -0000 SW5saW5lIHdpdGggRU8jLCB0cmltbWVkIGEgYml0Lg0KDQo+IA0KPiBUaGVyZSB3YXMgYXR3byB3 ZWVrIElUVS1UIHBsZW5hcnkgbWVldGluZywgYW5kIGFmdGVyIHRoYXQgSSB0b29rDQo+IChhbmQg c3RpbGwgaGF2ZSkgYSBob2xpZGF5Lg0KDQpJZiB5b3UncmUgb24gaG9saWRheSwgd2h5IGFyZSB5 b3Ugd29ya2luZz8gIEkgdGhvdWdodCB0aGF0IHdhcyBhIHVuaXF1ZWx5IEFtZXJpY2FuIHRyYWl0 LiAgSXMgdGhpcyBzdHVmZiB0aGF0IG11Y2ggZnVuIHRvIHlvdT8gOikNCg0KLi4uDQoNCj4gPiBp KSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBsZXZlbD8gIEknbSBub3QgbG9va2lu ZyBmb3IgYQ0KPiA+IGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGNoYW5nZXMsIGFu ZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZQ0KPiA+IG9uZSBsaW5lICJJdCBhbGxvd3MgdGhlIEZT TSB0byBiZSB0ZXN0ZWQiLiAgV2UgaGF2ZSBhbGwgb2YgdGhhdCBpbg0KPiA+IHRoZSBkcmFmdCBh bmQgaW4gdGhlIGVxdWl2YWxlbnQgSVRVIHNwZWNzLg0KPiA+DQo+ID4gV2hhdCBJJ2QgbGlrZSB0 byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9tLiAgVGhlDQo+ID4g SVRVIHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3csIHRoZXkg c2VlbSB0bw0KPiA+IGFzc3VtZSB0aGUgcmVhZGVyIGFscmVhZHkga25vd3Mgd2hhdCBFWEVSIGlz IGFuZCB3aGF0IHByb2JsZW0gaXQNCj4gPiBzb2x2ZXMuICBJdCBmZWVscyB2ZXJ5IG11Y2ggbGlr ZSBhIG1lY2hhbmlzbSB1c2VkIHRvIGNhdGNoIGEgdmVyeQ0KPiA+IHNwZWNpZmljIGltcGxlbWVu dGF0aW9uIGJ1ZywgYmFjayB3aGVuIHRyYW5zcG9ydCBnZWFyIHdhcyBmYXIgbGVzcw0KPiA+IGRl YnVnZ2FibGUgdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuDQo+IA0KPiBbSHV1Yl0gRVhFUiB3YXMg bm90IGRlc2lnbmVkL2ludGVuZGVkIHRvIGJlIHVzZWQgZm9yIGJ1ZyBmaW5kaW5nDQo+IGFsdGhv dWdoIGl0IHdpbGwgZGV0ZWN0IHByb2JsZW1zIHdpdGggaW1wbGVtZW50YXRpb24uDQo+IA0KPiBb SHV1Yl0gRVhFUiB3YXMgZGVzaWduZWQgdG8gdmVyaWZ5IHRoYXQgdGhlIHN0YXRlLW1hY2hpbmUg YXQgdGhlDQo+IGZhciBlbmQgaXMgYWJsZSB0byByZXNwb25kIHRvIEFQUy9QU0MgbWVzc2FnZXMg aXQgcmVjZWl2ZXMgZnJvbQ0KPiB0aGUgbG9jYWwgZW5kLg0KPiBFdmVuIHRob3VnaCBzdGF0ZS1t YWNoaW5lcyBzaG91bGQgYmUgdGVzdGVkIGV4dGVuc2l2ZWx5LCB0aGVyZSBpcw0KPiBubyAxMDAl IHdhcnJhbnR5LiBJdCBjYW4gc3RpbGwgaGF2ZSBzdG9wcGVkIGR1ZSB0byBleHRlcm5hbA0KPiBj aXJjdW1zdGFuY2VzLCBiZSBpbiBhIGRlYWRsb2NrIGR1ZSB0byB1bmZvcnNlZW4gb3JkZXIgb2Yg ZXZlbnRzLA0KPiBldGMuDQoNCkVPIyAgSSBhZ3JlZSB3aXRoIHlvdXIgbGFzdCB0d28gc3RhdGVt ZW50cy4gIFRvIG1lLCB0aG91Z2gsIHRoYXQgdmVyeSB0ZXh0IGlzIGEgcmVhc29uYWJsZSBhcmd1 bWVudCBhZ2FpbnN0IEVYRVIuICBUaGVyZSBpcyBubyBtZWNoYW5pc20gd2l0aGluIGEgcHJvdG9j b2wgd2hpY2ggY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSBlbnRpcmUgc3RhdGUgbWFjaGluZSBpcyAx MDAlIHBlcmZlY3QuICBBIG5vZGUgY291bGQgYmUgYWJsZSB0byByZXNwb25kIHRvIEVYRVIvUlIg YnV0IGJlIHVuYWJsZSB0byBwcm9jZXNzIGEgcmVhbCBmYWlsdXJlIHByb3Blcmx5LCBlaXRoZXIg ZHVlIHRvIGJ1ZyBvciB0byAoYXMgeW91IGluZGljYXRlKSBzb21lIHVuZm9yc2VlbiBjb21iaW5h dGlvbiBvZiBleHRlcm5hbCBldmVudHMuICBUaGUgY2xhc3Mgb2YgcHJvYmxlbXMgd2hpY2ggRVhF UiBjYW4gY2F0Y2ggYnV0IHdoaWNoIHdpbGwgbm90IGJlIGRldGVjdGFibGUgYnkgb3RoZXIgbWVh bnMgKGUuZy4gQ0MvQ1YsIHNlZSBiZWxvdykgc2VlbXMgcHJldHR5IHNtYWxsLg0KDQpJbiB0aGUg dHJhbnNwb3J0IHdvcmxkLCB3aGF0IHNvcnQgb2YgcHJvYmxlbXMgZG9lcyBFWEVSIF9hY3R1YWxs eSBmaW5kXz8gIEknbSBub3QgYXNraW5nIGFib3V0IHRoaW5ncyBpdCBfY291bGRfIGZpbmQsIGJ1 dCB0aGluZ3MgdGhhdCBpdCAqZG9lcyouDQoNCj4gDQo+IFtIdXViXSBub3RlIHRoYXQgQVBTL1BT QyBzaG91bGQgY29udGludWUgdG8gb3BlcmF0ZSBldmVuIGlmIG5vDQo+IGNvbnRyb2wgcGxhbmUg aXMgYXZhaWxhYmxlLiANCg0KRU8jICBJIGFncmVlLCBidXQgdGhpcyBpcyBub3QgcmVsZXZhbnQg dG8gdGhlIGRpc2N1c3Npb24gYXQgaGFuZC4gIExvdHMgb2Ygd29yayB3YXMgZG9uZSBpbiBUUCB0 byBlbnN1cmUgdGhhdCBpdCB3b3VsZCBmdW5jdGlvbiB3aXRob3V0IHRoZSBhYmlsaXR5IHRvIGZv cndhcmQgSVAgcGFja2V0cyAod2hpY2ggSSB0aGluayBpcyB3aGF0IHlvdSBtZWFuIGJ5ICdubyBj b250cm9sIHBsYW5lJykuICBOb25lIG9mIHRoYXQgaGFzIGFueXRoaW5nIHRvIGRvIHdpdGggdGhl IHNldCBvZiBtZXNzYWdlcyBhbmQgc3RhdGVzIGluIFBTQy4NCg0KPiBUaGUgRVhFUiBpcyB0byBl bmFibGUgYW4gb3BlcmF0b3IgdG8NCj4gdGFrZSBjb3JyZWN0aXZlIGFjdGlvbiBiZWZvcmUgYSBw cm90ZWN0aW9uIHN3aXRjaCByZXF1ZXN0IGZhaWxzDQo+IGFuZCB0aGUgNTBtcyBzd2l0Y2ggdGlt ZSBpcyBub3QgbWV0Lg0KPiANCj4gPiBObyBvdGhlciBzdGF0ZSBtYWNoaW5lcyB0aGF0IEknbSBm YW1pbGlhciB3aXRoIChSU1ZQLCBMRFAsIEJHUCwgT1NQRiwNCj4gPiBJU0lTKSBoYXZlIGV4cGxp Y2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvcg0KPiA+IHdoZXRo ZXIgaXQgKndvdWxkKiBiZSBicm9rZW4gaWYgaWYgd2VyZSwgaW4gdGhlIGZ1dHVyZSwgdG8gYmUg Z2l2ZW4gYQ0KPiA+IHBhcnRpY3VsYXIgaW5wdXQuDQo+IA0KPiBbSHV1Yl0gQWxsIHRoZXNlIHJl bHkgb24gYSBjb250cm9sIHBsYW5lLCBzb21lIG9mIHRoZW4gaW5jbHVkZQ0KPiAia2VlcGFsaXZl IiBtZXNzYWdlcyB0byBzZWUgaWYgdGhlIGZhciBlbmQgcmVzcG9uZHMuDQoNCkVPIyAgUFNDIGhh cyBrZWVwYWxpdmVzOyBzZWUgc2VjdGlvbiA0LjEgb2YgcmZjNjM3OCAtICJUaGUgcHVycG9zZSBv ZiB0aGUgY29udGludWFsIG1lc3NhZ2VzIGlzIHRvIHZlcmlmeSB0aGF0IHRoZSBQU0Mgc2Vzc2lv biBpcyBzdGlsbCBhbGl2ZS4iDQoNClRoZSBuZXh0IHNlbnRlbmNlIHNheXMgIklmIG5vIHZhbGlk IFBTQyBtZXNzYWdlIGlzIHJlY2VpdmVkLCBvdmVyIGEgcGVyaW9kIG9mIHNldmVyYWwgY29udGlu dWFsIG1lc3NhZ2VzIGludGVydmFscywgdGhlIGxhc3QgdmFsaWQgcmVjZWl2ZWQgbWVzc2FnZSBy ZW1haW5zIGFwcGxpY2FibGUuIiAgQXMgYW4gaW1wbGVtZW50b3IsIHdoYXQgdGhhdCBtZWFucyB0 byBtZSBpcyB0aGF0IEkgdGltZSBvdXQgb25seSBhZnRlciB0aGUgbG9zcyBvZiBhIGZldyByZXRy YW5zbWlzc2lvbnMuICANCg0KPiANCj4gPiBQYXJ0IG9mIG15IHJlbHVjdGFuY2UgdG8gZ2V0IGJl aGluZCBFWEVSIGhhcyBiZWVuDQo+ID4gdGhhdCBJIGRvbid0IGZlZWwgY29tZm9ydGFibGUgd2l0 aCB0aGUgaWRlYSBvZiBrZWVwaW5nIGEgMzAteWVhci1vbGQNCj4gPiB3b3JrYXJvdW5kIGluIGEg cHJvdG9jb2wuDQo+IA0KPiBbSHV1Yl0gaXQgaXMgTk9UIGEgd29ya2Fyb3VuZCwgaXQgaXMgYW4g ZXNzZW50aWFsIHBhcnQgb2YgdGhlDQo+IHByb3RvY29sLg0KDQpFTyMgIEluIGEgVERNIHdvcmxk LCBJIGNhbiBzZWUgdGhpcyBwb2ludC4gIEFQUyBpcyBjYXJyaWVkIGluIHRoZSBmcmFtZSBoZWFk ZXIsIHNvIHRoZSByZWNlaXB0IG9mIGFuIEFQUyBtZXNzYWdlIGRvZXNuJ3QgbWVhbiB0aGF0IHRo ZXJlJ3MgYW55IGludGVsbGlnZW5jZSBiZWhpbmQgaXQgYXMgaXQgY291bGQganVzdCBiZSB0aGUg aGFyZHdhcmUgcmVwZWF0aW5nIHRoZSBsYXN0IEFQUyBvdmVyaGVhZCB0aGF0IGl0IHNlbnQuICBJ ZiBhIFBTQyBtZXNzYWdlIGlzIHNlbnQgaXQgbXVzdCBoYXZlIGJlZW4gc2VudCBkZWxpYmVyYXRl bHksIGFzIGR1cmluZyBzdGVhZHkgc3RhdGUgd2UgaGF2ZSBwZXJpb2RpYyByZXRyYW5zbWlzc2lv bnMuICBEbyB5b3UgYWdyZWU/DQoNCj4gDQo+ID4gSXMgdGhlcmUgbW9yZSB0byBpdCB0aGFuIHRo YXQ/ICBIYXZlIEkNCj4gPiBtaXNyZWFkIGFuZCBtaXN1bmRlcnN0b29kIEVYRVI/ICBEb2VzIG1v ZGVybiB0cmFuc3BvcnQgZ2VhciBldmVyDQo+ID4gYWN0dWFsbHkgZGV0ZWN0IGEgcHJvYmxlbSB2 aWEgRVhFUi9SUiB0aGF0IHdhc24ndCBvYnZpb3VzIHRvIHRoZQ0KPiA+IG9wZXJhdG9yIHVzaW5n IG90aGVyIG1lYW5zPw0KPiANCj4gW0h1dWJdIGlmIHRoZXJlIGlzIG5vIGNvbnRyb2wgcGxhbmUg SSBoYXZlIG5vIG90aGVyIG1lYW5zLg0KPiBXaGF0IG1lYW5zIGFyZSBhdmFpbGFibGUgdG8gdmVy aWZ5IGlmIGEgc3RhdGUtbWFjaGluZSB0aGF0IGlzDQo+IGluIGEgc3RhYmxlIHN0YXRlIGlzIHN0 aWxsIGZ1bmN0aW9uaW5nPw0KDQpFTyMgIFBlcmlvZGljIHJldHJhbnNtaXNzaW9uIG9mIGN1cnJl bnQgc3RhdGUgYnkgdGhlIHJlbW90ZSBzaWRlLiAgVGhpcyBwZXJmb3JtcyB0aGUgZXhhY3Qgc2Ft ZSBmdW5jdGlvbiBhcyBhIGtlZXBhbGl2ZSBpbiBhbnkgb3RoZXIgcHJvdG9jb2wsIGFuZCBJIHRo aW5rIHdlIGFncmVlIHRoYXQgdGhlIGtlZXBhbGl2ZSBmdW5jdGlvbiBpbiBwcm90b2NvbHMgc3Vj aCBhcyBPU1BGIGlzIHN1ZmZpY2llbnQgdG8gZW5zdXJlIHRoZSBzYW5pdHkgb2YgdGhlIHJlbW90 ZSBlbmQuICBNYW55LCBtYW55IHByb3RvY29scyB1c2Uga2VlcGFsaXZlcyBhcyBhIHNvcnQgb2Yg YmVsdC1hbmQtc3VzcGVuZGVycyBmYWlsdXJlIGRldGVjdGlvbiBtZWNoYW5pc20uICBJbiB0aGUg SVAgd29ybGQgdGhlc2UgbWVjaGFuaXNtcyBhcmUgZmFyLCBmYXIgbGVzcyB1c2VmdWwgdGhhbiB0 aGV5IHVzZWQgdG8gYmUgYXMgd2Ugbm93IGhhdmUgQkZELiAgDQoNClRoYXQgYnJpbmdzIHVzIHRv IENDL0NWLiAgIExvdHMgb2Ygd29yayB3YXMgZG9uZSB0byBlbnN1cmUgdGhhdCBpdCBkaWQgbm90 IHJlcXVpcmUgSVAgdG8gZnVuY3Rpb24uICBJIGNhbm5ub3QgYmVsaWV2ZSB0aGF0IGFueSBUUCBp bXBsZW1lbnRhdGlvbiB3b3VsZCBzaGlwIHdpdGhvdXQgc29tZSBzb3J0IG9mIENDL0NWLCBhbmQg aXNuJ3QgdGhhdCBhIHN0cm9uZyBlbm91Z2ggbWVjaGFuaXNtIHRvIGRldGVjdCB0aGUgZmFpbHVy ZSBvZiB0aGUgcmVtb3RlIGVuZD8NCg0KDQo+IA0KPiA+IGlpKSBXaHkgdGhlIHB1c2ggdG8gc3Rh bmRhcmRpemUgdGhlIFNEIHN0YXRlIGNoYW5nZXMgYmVmb3JlIHdlJ3ZlDQo+ID4gZGVmaW5lZCBT RD8gIEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxpbmcgc2lnbmFsIGRlZ3JhZGUgaXMgYSBn b29kDQo+ID4gaWRlYSwgYnV0IGNvbWluZyB1cCB3aXRoIGEgZGVmaW5pdGlvbiBmb3IgaXQgaGFz IGJlZW4gY2hhbGxlbmdpbmcuDQo+ID4gV2hhdCBoYXBwZW5zIGlmIHdlIGNoYW5nZSB0aGUgRlNN IHRvIGhhbmRsZSBpdCwgdGhlbiBjb21lIHVwIHdpdGgNCj4gPiBzb21ldGhpbmcgbW9yZSBzb3Bo aXN0aWNhdGVkIChzYXksIG11bHRpcGxlIGxldmVscyBvZiBTRCkgdGhhdA0KPiA+IGRvZXNuJ3Qg cXVpdGUgZml0IHdpdGggdGhlIEZTTSBjaGFuZ2VzPw0KPiANCj4gW0h1dWJdIHRoZSBkZWZpbml0 aW9uIG9mIHRoZSBzaWduYWwgZGVncmFkZSBkZWZlY3QgdGhhdCBjYXVzZXMgdGhlDQo+IFNEIGV2 ZW50IGZvciB0aGUgQVBTL1BTQyBpcyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uLCBidXQgdGhlIEFQ Uy9QU0MNCj4gcmVzcG9uc2UgdG8gYW4gU0QgZXZlbnQgc2hvdWxkIGJlIGluY2x1ZGVkLiBJZiB3 ZSBkb24ndCBkbyBpdCBub3cNCj4gd2UgaGF2ZSB0byBpc3N1ZSBhbm90aGVyIHZlcnNpb24gb2Yg UFNDIGxhdGVyIHdpdGggYWxsIGtpbmRzIG9mDQo+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGlz c3VlcywgYWRkaXRpb25hbCBjb21wbGV4aXR5LCBhbmQgb3B0aW9ucw0KPiB0aGF0IG9wZXJhdG9y cyBkbyBub3QgbGlrZSB0byBoYXZlIHRvIG1hbmFnZS4NCg0KDQpFTyMNClNlZSBteSByZXBseSB0 byBKZW9uZy1kb25nIG9uIHRoaXMuICANCg0KDQoNCg0KDQplcmljDQoNCg0KDQo+IFtIdXViXSBB UFMvUFNDIG5vdyByZXNwb25kcyB0byBhbiBTRiBldmVudCwgYmFzZWQgb24gZGV0ZWN0ZWQNCj4g c2lnbmFsIGZhaWwgZGVmZWN0cy4gSG93ZXZlciBpbiB0aGUgZnV0dXJlIHdlIG1heSBleHRlbmQg dGhlDQo+IHNpZ25hbCBmYWlsIGRlZmVjdCBieSBhbm90aGVyIHByb2JhYmxlIGNhdXNlLiBUaGlz IHdpbGwgbm90DQo+IGFmZmVjdCB0aGUgZXhpc3RpbmcgQVBTL1BDUy4NCg0KDQo+IA0KPiBSZWdh cmRzLCBIdXViLg0KPiANCj4gDQo+IA0KPiAtLQ0KPiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAgICAgICAgICAgICAg ICDor7forrDkvY/vvIzkvaDmmK/ni6zkuIDml6DkuoznmoTvvIzlsLHlg4/lhbbku5bmr4/kuIDk uKrkurrkuIDmoLcNCg== From rcallon@juniper.net Mon Jul 22 07:40:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5069C11E80AE for ; Mon, 22 Jul 2013 07:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.249 X-Spam-Level: X-Spam-Status: No, score=-101.249 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO-gsqX94Grf for ; Mon, 22 Jul 2013 07:40:43 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6735021F9655 for ; Mon, 22 Jul 2013 07:40:43 -0700 (PDT) Received: from mail182-va3-R.bigfish.com (10.7.14.233) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Mon, 22 Jul 2013 14:40:42 +0000 Received: from mail182-va3 (localhost [127.0.0.1]) by mail182-va3-R.bigfish.com (Postfix) with ESMTP id 2F65B20185 for ; Mon, 22 Jul 2013 14:40:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail182-va3: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rcallon@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail182-va3 (localhost.localdomain [127.0.0.1]) by mail182-va3 (MessageSwitch) id 1374504040946710_13979; Mon, 22 Jul 2013 14:40:40 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.251]) by mail182-va3.bigfish.com (Postfix) with ESMTP id E1855A004E for ; Mon, 22 Jul 2013 14:40:40 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.54) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 22 Jul 2013 14:40:38 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 22 Jul 2013 07:40:37 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Mon, 22 Jul 2013 07:40:37 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 22 Jul 2013 07:45:04 -0700 Received: from mail57-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE013.bigfish.com (10.3.207.135) with Microsoft SMTP Server id 14.1.225.22; Mon, 22 Jul 2013 14:40:34 +0000 Received: from mail57-am1 (localhost [127.0.0.1]) by mail57-am1-R.bigfish.com (Postfix) with ESMTP id 7E072440235 for ; Mon, 22 Jul 2013 14:40:34 +0000 (UTC) Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1 (MessageSwitch) id 1374504032805817_4355; Mon, 22 Jul 2013 14:40:32 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.242]) by mail57-am1.bigfish.com (Postfix) with ESMTP id B65BB60252; Mon, 22 Jul 2013 14:40:32 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 22 Jul 2013 14:40:29 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.67]) by CH1PRD0510HT001.namprd05.prod.outlook.com ([10.255.150.36]) with mapi id 14.16.0329.000; Mon, 22 Jul 2013 14:40:27 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOhulnWy9Dbx3LCECSz5UbIX6taw== Date: Mon, 22 Jul 2013 14:40:26 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.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, 22 Jul 2013 14:40:50 -0000 Working Group and authors; The authors of draft-ietf-mpls-tp-rosetta-stone-11.txt and the=20 working group chairs are working to prepare the draft for working group last call. Before starting the working group last call we first are issuing a=20 poll to check whether there is IPR on the document that needs to be=20 disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to=20 draft-ietf-mpls-tp-rosetta-stone-11.txt? If so, has this IPR been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details.) If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The=20 documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --=20 From nurit.sprecher@nsn.com Mon Jul 22 07:54:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E52021F9D09 for ; Mon, 22 Jul 2013 07:54:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHj2lFT5f+fj for ; Mon, 22 Jul 2013 07:54:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id EAC8621F9970 for ; Mon, 22 Jul 2013 07:53:30 -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 r6MErPCp029021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Jul 2013 16:53:26 +0200 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6MErPGF027711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 16:53:25 +0200 Received: from DEMUMBX009.nsn-intra.net ([169.254.9.221]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Mon, 22 Jul 2013 16:53:25 +0200 From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: ext Ross Callon , "mpls@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOhulnWy9Dbx3LCECSz5UbIX6ta5lwyHFQ Date: Mon, 22 Jul 2013 14:53:24 +0000 Message-ID: <9B067372C2434A429FBD4CF7F0E869FD119AA6@DEMUMBX009.nsn-intra.net> References: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1740 X-purgate-ID: 151667::1374504806-00002EAE-FC297368/0-0/0-0 Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.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, 22 Jul 2013 14:54:12 -0000 I am not aware of a related IPR. Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Ross Callon Sent: Monday, July 22, 2013 5:40 PM To: mpls@ietf.org Cc: ; mpls-chairs@tools.ietf.org; draft-ietf-mpls-= tp-rosetta-stone@tools.ietf.org Subject: [mpls] IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.txt Working Group and authors; The authors of draft-ietf-mpls-tp-rosetta-stone-11.txt and the=20 working group chairs are working to prepare the draft for working group last call. Before starting the working group last call we first are issuing a=20 poll to check whether there is IPR on the document that needs to be=20 disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to=20 draft-ietf-mpls-tp-rosetta-stone-11.txt? If so, has this IPR been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details.) If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The=20 documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Mon Jul 22 08:25:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA3921E80B2 for ; Mon, 22 Jul 2013 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SekoXz5sEAGL for ; Mon, 22 Jul 2013 08:25:29 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7D44321E80AF for ; Mon, 22 Jul 2013 08:24:43 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so3878277eaj.15 for ; Mon, 22 Jul 2013 08:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Jm0lo+P7i4xu6A2eA4tCnAk+LtqSePRWwIr3/Lp+/BI=; b=qUsPbBf7bGzhx5hWVSbQXtO8jrrvefRD1/0aXKUz2fM/flja/UqSzAUoXn5FSHjU61 eFXp3P/4lixgujgYm5UHkv1d6SJo3maJscYKuyY2R3+Ua3x/eI2jtD1AsbmuIFfYVSS/ SY6V1kLJjY68x+UAuXOwM0rtTJH+CxLdGH2F3o9D9UyENX4n2uliQboMETUOHEmCZ/YR L4ppD2mZcnncXoeB1a8xQcVa2CbarooUFEZGgRQvJyhYC3ay/h4BCyJn8dwGDnRHjTk0 Uquz239Vgrc+V+Ub8esxFxBSqpbQLWyqGzJ65qYZ7qGMk8ElE2u2Atx5dwN9rj5qTcSE rM6Q== X-Received: by 10.14.104.135 with SMTP id i7mr27882295eeg.3.1374506682144; Mon, 22 Jul 2013 08:24:42 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id i2sm51576382eeu.4.2013.07.22.08.24.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 08:24:41 -0700 (PDT) Message-ID: <51ED4EB8.9080009@gmail.com> Date: Mon, 22 Jul 2013 17:24:40 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ross Callon References: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" , "" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.txt 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: Mon, 22 Jul 2013 15:25:29 -0000 I am not aware of any IPR. Regards, Huub. ============ > Working Group and authors; > > The authors of draft-ietf-mpls-tp-rosetta-stone-11.txt and the > working group chairs are working to prepare the draft for working > group last call. > > Before starting the working group last call we first are issuing a > poll to check whether there is IPR on the document that needs to be > disclosed. This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-ietf-mpls-tp-rosetta-stone-11.txt? > > If so, has this IPR been disclosed in compliance with IETF IPR rules? > (see RFCs 3979, 4879, 3669 and 5378 for more details.) > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Ross > (as MPLS WG co-chair) > -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From Tom.Huber@tellabs.com Mon Jul 22 12:03:52 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA9711E80D2 for ; Mon, 22 Jul 2013 12:03:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3FZNcVy1ONt for ; Mon, 22 Jul 2013 12:03:47 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3BECB11E80C5 for ; Mon, 22 Jul 2013 12:03:44 -0700 (PDT) Received: from mail206-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Mon, 22 Jul 2013 19:03:43 +0000 Received: from mail206-ch1 (localhost [127.0.0.1]) by mail206-ch1-R.bigfish.com (Postfix) with ESMTP id 708D81C0115; Mon, 22 Jul 2013 19:03:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:204.154.129.150; KIP:(null); UIP:(null); IPV:NLI; H:usnvwwmspedge02.tellabs-west.tellabsinc.net; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz98dI9371Ic89bh936eI103dK542Iec9I1432I1447Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h1de096h8275bh8275dhz2ei2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1155h) Received-SPF: neutral (mail206-ch1: 204.154.129.150 is neither permitted nor denied by domain of tellabs.com) client-ip=204.154.129.150; envelope-from=Tom.Huber@tellabs.com; helo=usnvwwmspedge02.tellabs-west.tellabsinc.net ; llabsinc.net ; Received: from mail206-ch1 (localhost.localdomain [127.0.0.1]) by mail206-ch1 (MessageSwitch) id 1374519820959056_2651; Mon, 22 Jul 2013 19:03:40 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail206-ch1.bigfish.com (Postfix) with ESMTP id CC34C40004E; Mon, 22 Jul 2013 19:03:40 +0000 (UTC) Received: from usnvwwmspedge02.tellabs-west.tellabsinc.net (204.154.129.150) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 22 Jul 2013 19:03:39 +0000 Received: from usnvwwmspht01.tellabs-west.tellabsinc.net (172.23.211.69) by usnvwwmspedge02.tellabs-west.tellabsinc.net (204.154.131.191) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 22 Jul 2013 14:03:22 -0500 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Mon, 22 Jul 2013 14:03:39 -0500 From: "Huber, Thomas J." To: "Eric Osborne (eosborne)" , "Ryoo, Jeong-dong" , D'Alessandro Alessandro Gerardo , "mpls@ietf.org" Date: Mon, 22 Jul 2013 14:03:36 -0500 Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQADK5f8AALo9nQ Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: tellabs.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 19:03:52 -0000 SGkgRXJpYywNCg0KWW91IHdyb3RlOg0KPkVPIw0KPkknbSBub3Qgc3VyZSB3aGF0IHRoYXQgd291 bGQgbG9vayBsaWtlLiAgJ0ZhaWwnIGlzIGEgcHJldHR5IGJpbmFyeSB0aGluZy4gICdEZWdyYWRl JyBpcyBhIGNvbnRpbnVvdXMgdmFyaWFibGUsIGFzIGl0IGNhbiBiZSBhbnl0aGluZyBmcm9tICdh IGxpdHRsZSBiYWQnIHRvIGEgJ2Egd2hvbGUgbG90IG9mIGJhZCBidXQgbm90IHF1aXRlIGZhaWwn Lg0KDQpJIHRoaW5rIHRoaXMgbWF5IGJlIGEgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBpbiBhc3N1 bXB0aW9ucy4gIFdoaWxlIGl0IGlzIGNlcnRhaW5seSB0cnVlIHRoYXQgZGVncmFkYXRpb24gb2Yg YSBzaWduYWwgaXMgYSBjb250aW51b3VzIHZhcmlhYmxlLCBpbiB0aGUgY29udGV4dCBvZiBwcm90 ZWN0aW9uIHN3aXRjaGluZyBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmssIHRoZXJlIGlzIGEgcGFy dGljdWxhciB2YWx1ZSBvZiB0aGF0IGNvbnRpbnVvdXMgdmFyaWFibGUgdGhhdCBkZWZpbmVzIHRo ZSB0aHJlc2hvbGQgYXQgd2hpY2ggdGhlIEJvb2xlYW4gdmFyaWFibGUgInNpZ25hbCBkZWdyYWRl IChTRCkiIGJlY29tZXMgdHJ1ZS4gIEl0IGlzIGZvciB0aGlzIHJlYXNvbiB0aGF0IEplb25nLWRv bmcgYW5kIG90aGVycyBhcmUgc3VnZ2VzdGluZyB0aGF0IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0 byBpbmNvcnBvcmF0ZSB0aGUgYmVoYXZpb3Igb2YgdGhlIFNEIHN0YXRlIGludG8gdGhlIFBTQyBk ZWZpbml0aW9uIHdpdGhvdXQgbmVlZGluZyB0byBoYXZlIGEgcHJlY2lzZSBkZWZpbml0aW9uIG9m IHRoZSBtZWNoYW5pc20gZm9yIG1lYXN1cmluZyB0aGUgZGVncmFkYXRpb24gb2YgYSBzaWduYWwu ICBXaGF0ZXZlciB0aGUgbWVjaGFuaXNtIGlzLCBpdCB3aWxsIGJlIGNvbnZlcnRlZCB0byB0aGUg YmluYXJ5IFNEIGluZGljYXRpb24uDQoNCkJlc3QgcmVnYXJkcywNClRvbQ0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5l KQ0KU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDg6MzYgQU0NClRvOiBSeW9vLCBKZW9uZy1k b25nOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBtcGxzQGlldGYub3JnDQpDYzog SHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSk7IGh1dWJhdHdvcmtA Z21haWwuY29tDQpTdWJqZWN0OiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p bmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJl cXVpcmVtZW50cw0KDQpIaSBKZW9uZy1kb25nLA0KDQogIFRoYW5rcyBmb3IgdGhlIHJlcGx5LiAg UGxlYXNlIHNlZSBpbmxpbmUgd2l0aCBFTyMuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOnJ5b29AZXRyaS5yZS5rcl0NCj4g U2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDQ6MTUgQU0NCj4gVG86IEVyaWMgT3Nib3JuZSAo ZW9zYm9ybmUpOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOw0KPiBtcGxzQGlldGYu b3JnDQo+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tKTsg aHV1YmF0d29ya0BnbWFpbC5jb20NCj4gU3ViamVjdDogUkU6IFttcGxzXSBwcm9wb3NlZCBkcmFm dHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcg0KPiBwcm90ZWN0aW9uIHByb3RvY29s IHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCj4NCj4gSGksIEVyaWMuDQo+DQo+IExldCBtZSBh bnN3ZXIgeW91ciAybmQgcXVlc3Rpb24gb24gU0QuDQo+DQo+IFNEIGRldGVjdGlvbiBtZXRob2Rz IGRlZmluZWQgb3IgcHJvcG9zZWQgZm9yIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MNCj4gY2Fu IGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czoNCj4gLSBCeSBPQU0gcGVyZm9ybWFuY2UgbW9uaXRv cmluZyB0b29sOg0KPiAgIFNEIGlzIHJhaXNlZCBpZiBwYWNrZXQgbG9zcyByYXRpbyBleGNlZWRz IGEgdGhyZXNob2xkIGR1cmluZyBhDQo+IG1lYXN1cmVtZW50IHBlcmlvZC4NCj4gICBUaHJlc2hv bGQgdmFsdWUgYW5kIG1lYXN1cmVtZW50IHBlcmlvZCBhcmUgY29uZmlndXJlZCBieSBhbiBuZXR3 b3JrDQo+IG9wZXJhdG9yLg0KPiAgIFRoaXMgZGV0ZWN0aW9uIG1ldGhvZCBpcyBhbHJlYWR5IGRl ZmluZWQgaW4gSVRVLVQgRy44MDIxIChFdGhlcm5ldA0KPiBlcXVpcG1lbnQgc3BlYy4pDQoNCg0K RU8jICBXaGVyZT8gIEknbSBub3QgYXJndWluZyB0aGF0IGl0J3Mgbm90IGluIHRoZXJlLCBJJ20g anVzdCBoYXZpbmcgYSBoYXJkIHRpbWUgZmluZGluZyBpdC4gIEEgc2VhcmNoIGZvciBFVEhfQ0lf U1NEIGRvZXNuJ3QgeWllbGQgbXVjaC4gIElmIEkgbG9vayBmb3IgJ3NpZ25hbCBkZWdyYWRlJyBJ IHNlZSBwLiAxMzEgd2hpY2ggc2F5cyB0aGF0IHRoZSBhbGdvcml0aG0gaXMgZGVmaW5lZCBpbiBH LjgwMzEuICBHLjgwMzEgc2F5cyAnIEhvdyB0aGVzZSBkZWZlY3RzIGFyZSBkZXRlY3RlZCBpcyB0 aGUgc3ViamVjdCBvZiB0aGUgZXF1aXBtZW50IFJlY29tbWVuZGF0aW9ucycuICBJJ20gbG9va2lu ZyBmb3Igc29tZXRoaW5nIGxpa2UgIlNpZ25hbCBEZWdyYWRlIGlzIGRlZmluZWQgYXMgJGZvbyBw YWNrZXQgbG9zcyBvciBDUkMgZmFpbHVyZSBvdmVyICRiYXIgdGltZSIuLi4ud2hhdCBoYXZlIEkg bWlzc2VkPw0KDQoNCj4gICBhbmQgdGhlIGVxdWlwbWVudCBzcGVjIGZvciBNUExTLVRQIGNhbiBl YXNpbHkgZm9sbG93IHRoZSBzYW1lDQo+IGRlZmluaXRpb24uDQo+IC0gQnkgc2VydmVyIGxheWVy IGluZGljYXRpb246DQo+ICAgU0QgaXMgcmFpc2VkIGlmIGEgc2VydmVyIGxheWVyIGJlbG93IE1Q TFMtVFAgcmVwb3J0cyBTRCBjb25kaXRpb24gb24NCj4gaXRzIG93biBsYXllci4NCj4gLSBCeSBD Q00gcGFja2V0IGNvdW50aW5nOg0KPiAgIFNEIGlzIHJhaXNlZCBpZiB0aGUgbG9zcyByYXRpbyBv ZiBDQ00gcGFja2V0cyBleGNlZWRzIGEgdGhyZXNob2xkDQo+IGR1cmluZyBhIG1lYXN1cmVtZW50 IHBlcmlvZC4NCj4NCj4gUmVnYXJkbGVzcyBvZiBob3cgdG8gZGV0ZWN0IFNELCBhbnkgcHJvdGVj dGlvbiBzd2l0Y2hpbmcgZG9jdW1lbnRzDQo+IHNob3VsZCBkZXNjcmliZSB0aGUgcHJvdGVjdGlv biBzd2l0Y2hpbmcgb3BlcmF0aW9uIG9uY2Ugc3VjaCBhIFNEIGlzDQo+IGRlY2xhcmVkLg0KPg0K Li4uDQo+IFJlZ2FyZGluZyB0aGUgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEOg0KPiBJdCBpcyBjZXJ0 YWlubHkgcG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC4NCj4gQnV0LCBh cyBmYXIgYXMgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGNvbmNlcm5lZCwgaXQganVzdCBu ZWVkcyB0bw0KPiBrbm93IGlmIFNEIGlzIHNpZ25hbGVkIHRvIHByb3RlY3Rpb24gc3dpdGNoaW5n IHByb2Nlc3Mgb3Igbm90Lg0KPiBJdCB3b3VsZCBiZSBhIG5ldHdvcmsgb3BlcmF0b3IncyBjaG9p Y2UgYXQgd2hhdCBsZXZlbCBvZiBTRCBoZSB3YW50cw0KPiBoaXMgbmV0d29yayBwcm90ZWN0aW9u IHRvIHN3aXRjaG92ZXIuDQo+IEluIG90aGVyIHdvcmRzLCB3aGF0IHRyaWdnZXJzIHByb3RlY3Rp b24gc3dpdGNoaW5nIGlzIFNEIG9yIG5vIFNELiBJdA0KPiBpcyB5ZXMgb3Igbm8gZGVjaXNpb24u DQoNCg0KRU8jICBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgZG9jdW1lbnQgd2hpY2ggc3VnZ2VzdHMg dGhhdCBhIHNlcnZlciBsYXllciBTRCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhIGNsaWVudCBsYXll ciBTRC4gIEluIHRoZSBJUCB3b3JsZCwgaWYgd2UgaGF2ZSBTRCBvbiBhIHRyYW5zcG9ydCBpbnRl cmZhY2UgdGhhdCBpcyBnZW5lcmFsbHkgdXNlZCB0byBicmluZyB0aGUgaW50ZXJmYWNlIGRvd24g KGkuZS4gU0YpLiAgVGhpcyBpcyB0aGUgc29ydCBvZiB0aGluZyBJJ2QgbGlrZSB0byBzZWUgaW4g bW9yZSBkZXRhaWwsIGFzIFNEIGluIHRoZSBwYWNrZXQgd29ybGQgaXMgYSBuZXcgY29uY2VwdCBh bmQgd2UgY2FuJ3QganVzdCBhc3N1bWUgdGhhdCBpdCB3aWxsIHdvcmsgdGhlIHNhbWUgZXZlcnl3 aGVyZSBiZWNhdXNlIHdlIGRlZmluZSBzdGF0ZSBtYWNoaW5lIHBvaW50cyBmb3IgaXQuDQoNClRo ZSBwb2ludCBhYm91dCBDQ00gaXMgYSBnb29kIG9uZS4gIExldCdzIHNheSB3ZSBjb21lIHVwIHdp dGggYSBjbGV2ZXIgU0QgbWVjaGFuaXNtIHdpdGggdHdvIHRocmVzaG9sZHMsIGNhbGwgdGhlbSBt YWpvciBhbmQgbWlub3IuICBGb3IgZGlzY3Vzc2lvbiBwdXJwb3NlcyB0aGV5IGNvdWxkIGJlIHNp bXBsZSBlcnJvciByYXRpb3MsIGUuZy4gMToxMF42IGFuZCAxOjEwXjkuICBCdXQgdGhleSBjb3Vs ZCBiZSBtb3JlIHBvd2VyZnVsIHRoYW4gdGhhdCAoZmxvdyB0eXBlLCBmbG93IGxlbmd0aCwgZXJy b3IgYnVyc3Qgc2l6ZSwgZXRjKS4NCg0KSWYgd2Ugd2FudCB0byBoYXZlIFNELU1ham9yIGFuZCBT RC1NaW5vciBpbnB1dHMgYXMgc2VwYXJhdGUgdHJpZ2dlcnMgZm9yIFBTQywgd2UgbWF5IHdhbnQg dGhlbSBhdCBkaWZmZXJlbnQgcG9pbnRzLiAgUGVyaGFwcyAgKGxlYXZpbmcgb3V0IHRoZSBXb3Jr aW5nIHBhdGggZm9yIGVhc2Ugb2YgcmVhZGluZykNCg0KTE8NCkZTDQpTRi1QDQpTRC1QLU1ham9y DQpNUw0KU0QtUC1NaW5vcg0KDQoNClRoaXMgc2VlbXMgbGlrZSBhIHBlcmZlY3RseSByZWFzb25h YmxlIHRoaW5nIHRvIHdhbnQuDQoNCg0KRXZlbiBpZiB3ZSBkb24ndCBoYXZlIG11bHRpLXRpZXIg U0QsIGV2ZW4gdGhlIHNpbmdsZS10aWVyIFNEIG5lZWRzIHRvIGJlIGRlZmluZWQgYmVmb3JlIHdl IGNhbiBkZWNpZGUgaG93IHRvIHJlc3BvbmQgdG8gaXQuDQoNCj4gVGhlIHByb3Bvc2VkIGRyYWZ0 IGNvdmVycyBTRC10cmlnZ2VyZWQgcHJvdGVjdGlvbiBubyBtYXR0ZXIgd2hhdCBraW5kcw0KPiBv ZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBhcmUgdXNlZC4NCj4NCj4NCj4gU0YgY2FuIGFsc28gYmUg dmlld2VkIGFzIGhhdmluZyBtdWx0aXBsZSBsZXZlbHMgb2YgU0YgYXMgdGhlIG5ldHdvcmsNCj4g b3BlcmF0b3IgY2FuIGFsc28gbWFrZSBhIGNob2ljZSBvbiB0aGUgcGVyaW9kL2ludGVydmFsIG9m IENDTSBtZXNzYWdlcy4NCg0KDQpFTyMNCkknbSBub3Qgc3VyZSB3aGF0IHRoYXQgd291bGQgbG9v ayBsaWtlLiAgJ0ZhaWwnIGlzIGEgcHJldHR5IGJpbmFyeSB0aGluZy4gICdEZWdyYWRlJyBpcyBh IGNvbnRpbnVvdXMgdmFyaWFibGUsIGFzIGl0IGNhbiBiZSBhbnl0aGluZyBmcm9tICdhIGxpdHRs ZSBiYWQnIHRvIGEgJ2Egd2hvbGUgbG90IG9mIGJhZCBidXQgbm90IHF1aXRlIGZhaWwnLg0KDQo+ IElmIENDTSBpcyBkaXNhYmxlZCwgQUlTIGZyb20gYSBzZXJ2ZXIgbGF5ZXIgY2FuIGJlIHVzZWQg YXMgYSB0cmlnZ2VyDQo+IGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZy4gU28gYW5kIHNvIGZvcnRo Lg0KDQpFTyMgIEFJUyBmcm9tIHRoZSBzZXJ2ZXIgbGF5ZXIgb25seSBnZXRzIHlvdSBTRCBmcm9t IHRoZSBmaXJzdCBob3Agb2YgdGhlIHVuZGVybHlpbmcgc2VydmVyIHBhdGguDQoNCg0KDQoNCmVy aWMNCg0KPiBIb3dldmVyLCBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBk ZWZpbmUgaG93IHRvIGRldGVjdA0KPiBTRiBpbiBhbnl3aGVyZS4NCj4gU2ltaWxhcnksIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgbWFudWFsDQo+IHN3 aXRjaCBhbmQgZm9yY2VkIHN3aXRjaCBjb21tYW5kcyBhcmUgaW5pdGlhdGVkIGluIGEgbWFuYWdl bWVudCBzeXN0ZW0NCj4gYW5kIHNpZ25hbGVkIHRvIHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb2Nl c3MuDQo+DQo+IEFnYWluLCBpbiBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlv biBjYW4gYWNjb21tb2RhdGUgYW55DQo+IFNEIGRldGVjdGlvbiBtZXRob2RzLg0KPg0KPiBCZXN0 IHJlZ2FyZHMsDQo+DQo+IEplb25nLWRvbmcNCj4NCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gRnJvbSA6ICJFcmljIE9zYm9ybmUgKGVvc2Jv cm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4gU2VudCA6DQo+IDIwMTMtMDctMjAgMDI6NDg6Mjgg KCArMDk6MDAgKSBUbyA6IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPGFsZXNz YW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4sIG1wbHNAaWV0Zi5vcmcNCj4gPG1w bHNAaWV0Zi5vcmc+IENjIDogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2Vp LmNvbSkNCj4gPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+LCBodXViYXR3b3JrQGdtYWls LmNvbQ0KPiA8aHV1YmF0d29ya0BnbWFpbC5jb20+IFN1YmplY3QgOiBSZTogW21wbHNdIHByb3Bv c2VkIGRyYWZ0cyBmb3INCj4gYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24g cHJvdG9jb2wgdG8gdHJhbnNwb3J0DQo+IHJlcXVpcmVtZW50cw0KPg0KPg0KPiBIaSBBbGVzc2Fu ZHJvLQ0KPg0KPiBUaGFua3MgZm9yIHRoaXM7IHRoZSB0aHJlYWRzIEkgc3RhcnRlZCBzb21lIHRp bWUgYmFjayBzZWVtIHRvIGhhdmUNCj4gZGllZCBkb3duLCBpdCdzIGdvb2QgdG8gZ2V0IHRoZW0g Z29pbmcgYWdhaW4uDQo+IEkgaGF2ZSB0d28gdGhpbmdzIEkgbmV2ZXIgcXVpdGUgdW5kZXJzdG9v ZCwgY2FuIHlvdSBjbGFyaWZ5IHRoZW0gZm9yIG1lPw0KPg0KPiBpKSBjYW4geW91IGV4cGxhaW4g RVhFUiBhdCBhIGhpZ2hlciBsZXZlbD8gSSdtIG5vdCBsb29raW5nIGZvciBhDQo+IGRlc2NyaXB0 aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGNoYW5nZXMsIGFuZCBJJ20gbm90IGxvb2tpbmcgZm9y IHRoZQ0KPiBvbmUgbGluZSAiSXQgYWxsb3dzIHRoZSBGU00gdG8gYmUgdGVzdGVkIi4gV2UgaGF2 ZSBhbGwgb2YgdGhhdCBpbiB0aGUNCj4gZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBz cGVjcy4NCj4NCj4gV2hhdCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hl cmUgaXQgY2FtZSBmcm9tLiBUaGUgSVRVDQo+IHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0 dHkgaGFyZCB0byBmb2xsb3csIHRoZXkgc2VlbSB0byBhc3N1bWUNCj4gdGhlIHJlYWRlciBhbHJl YWR5IGtub3dzIHdoYXQgRVhFUiBpcyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQNCj4g ZmVlbHMgdmVyeSBtdWNoIGxpa2UgYSBtZWNoYW5pc20gdXNlZCB0byBjYXRjaCBhIHZlcnkgc3Bl Y2lmaWMNCj4gaW1wbGVtZW50YXRpb24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2Fz IGZhciBsZXNzIGRlYnVnZ2FibGUNCj4gdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuDQo+DQo+IE5v IG90aGVyIHN0YXRlIG1hY2hpbmVzIHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwg QkdQLCBPU1BGLA0KPiBJU0lTKSBoYXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3Qg dG8gYXNrIHRoZSBuZWlnaGJvciB3aGV0aGVyDQo+IGl0ICp3b3VsZCogYmUgYnJva2VuIGlmIGlm IHdlcmUsIGluIHRoZSBmdXR1cmUsIHRvIGJlIGdpdmVuIGENCj4gcGFydGljdWxhciBpbnB1dC4g UGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBiZWhpbmQgRVhFUiBoYXMgYmVlbg0KPiB0aGF0 IEkgZG9uJ3QgZmVlbCBjb21mb3J0YWJsZSB3aXRoIHRoZSBpZGVhIG9mIGtlZXBpbmcgYSAzMC15 ZWFyLW9sZA0KPiB3b3JrYXJvdW5kIGluIGEgcHJvdG9jb2wuIElzIHRoZXJlIG1vcmUgdG8gaXQg dGhhbiB0aGF0PyBIYXZlIEkNCj4gbWlzcmVhZCBhbmQgbWlzdW5kZXJzdG9vZCBFWEVSPyBEb2Vz IG1vZGVybiB0cmFuc3BvcnQgZ2VhciBldmVyDQo+IGFjdHVhbGx5IGRldGVjdCBhIHByb2JsZW0g dmlhIEVYRVIvUlIgdGhhdCB3YXNuJ3Qgb2J2aW91cyB0byB0aGUNCj4gb3BlcmF0b3IgdXNpbmcg b3RoZXIgbWVhbnM/DQo+DQo+DQo+IGlpKSBXaHkgdGhlIHB1c2ggdG8gc3RhbmRhcmRpemUgdGhl IFNEIHN0YXRlIGNoYW5nZXMgYmVmb3JlIHdlJ3ZlDQo+IGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5 IGFncmVlIHRoYXQgaGFuZGxpbmcgc2lnbmFsIGRlZ3JhZGUgaXMgYSBnb29kDQo+IGlkZWEsIGJ1 dCBjb21pbmcgdXAgd2l0aCBhIGRlZmluaXRpb24gZm9yIGl0IGhhcyBiZWVuIGNoYWxsZW5naW5n Lg0KPiBXaGF0IGhhcHBlbnMgaWYgd2UgY2hhbmdlIHRoZSBGU00gdG8gaGFuZGxlIGl0LCB0aGVu IGNvbWUgdXAgd2l0aA0KPiBzb21ldGhpbmcgbW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRp cGxlIGxldmVscyBvZiBTRCkgdGhhdCBkb2Vzbid0DQo+IHF1aXRlIGZpdCB3aXRoIHRoZSBGU00g Y2hhbmdlcz8NCj4NCj4NCj4NCj4gdGhhbmtzIQ0KPg0KPg0KPg0KPg0KPg0KPiBlcmljDQo+DQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0K PiA+IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPiBTZW50OiBXZWRuZXNkYXks IEp1bHkgMTcsIDIwMTMgMzoyMyBQTQ0KPiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gQ2M6IEh1 dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pOw0KPiA+IGh1dWJhdHdv cmtAZ21haWwuY29tDQo+ID4gU3ViamVjdDogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxp Z25pbmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+ID4gcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFu c3BvcnQgcmVxdWlyZW1lbnRzDQo+ID4NCj4gPiBEZWFyIGFsbCwNCj4gPiB3ZSB3b3VsZCBsaWtl IHNvY2lhbGl6aW5nIHRoZSBoZXJlYmVsb3cgZHJhZnRzIHRoYXQgd2VyZSBzdWJtaXR0ZWQNCj4g c29tZQ0KPiA+IG1vbnRocyBhZ28gd2l0aCB0aGUgYWltIHRvIGFsaWduIFBTQyBwcm90b2NvbCAo UkZDIDYzNzgpIHRvIElUVS1UDQo+ID4gdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBh cHByZWNpYXRlIHlvdXIgY29tbWVudHMgYWJvdXQgdGhlDQo+ID4gcHJvcG9zZWQgbWVjaGFuaXNt cyBhbmQgYmVoYXZpb3Vycy4NCj4gPg0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0 eS0wMA0KPiA+IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwDQo+ID4gZHJh ZnQtcmhkLW1wbHMtdHAtcHNjLXNkLTAwDQo+ID4gZHJhZnQtZGotbXBscy10cC1leGVyLXBzYy0w MSAvIGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtYWxpdmUtMDANCj4gPg0KPiA+IFRoZSBhYm92ZSBk cmFmdHMgY292ZXIgbW9zdCBvZiBpdGVtcyBoaWdobGlnaHRlZCBpbiBJVFUtVCBsaWFpc29ucw0K PiBhYm91dA0KPiA+IFBTQyBhbmQgdGhleSBwcm9wb3NlIHNvbHV0aW9ucyBpbiBsaW5lIHdpdGgg TVBMUy1UUCB0cmFuc3BvcnQNCj4gPiByZXF1aXJlbWVudHMuDQo+ID4gQSBsaXN0IG9mIG1haW4g bGlhaXNvbnMgZXhjaGFuZ2VkIGJldHdlZW4gSVRVLVQgYW5kIElFVEYgd2l0aCB0aGUNCj4gPiBh aW0NCj4gdG8NCj4gPiBhbGlnbiBQU0MgYmVoYXZpb3VzIHdpdGggSVRVLVQgdHJhbnNwb3J0IHJl cXVpcmVtZW50cyBmb3IgbGluZWFyDQo+ID4gcHJvdGVjdGlvbiBhcmUgZ2l2ZW4gYmVsb3c6DQo+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzExNjIvIChKdW5lIDIwMTIp DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMDUvDQo+ID4gKE9j dG9iZXIgMjAxMikNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIy OS8NCj4gPiAoSmFudWFyeSAyMDEzKQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bGlhaXNvbi8xMjM0Lw0KPiA+IChGZWJydWFyeSAyMDEzKQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjU2Lw0KPiA+IChNYXkgMjAxMykNCj4gPg0KPiA+IFNvbWUg ZGV0YWlscyBhYm91IHRoZSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduIFBTQyBiZWhhdmlvdXIg d2l0aA0KPiA+IHRyYW5zcG9ydCByZXF1aXJlbWVudHM6DQo+ID4NCj4gPiBkcmFmdC1yaGQtbXBs cy10cC1wc2MtcHJpb3JpdHktMDAgcHJvcG9zZXMgc3dhcHBpbmcgdGhlIHByaW9yaXRpZXMNCj4g PiBiZXR3ZWVuIEZTIGFuZCBTRi1QIChzZWUgc2VjdGlvbiA0LjMuMiBvZiByZmM2Mzc4KS4NCj4g PiBBbW9uZyB0aGUgb3RoZXJzLCBiZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdpdGggdGhl IHByb3Bvc2VkDQo+IHVwZGF0ZQ0KPiA+IGFyZToNCj4gPiBVc2UgY2FzZSBBKSBBdCBmaXJzdCwg d29ya2luZyBwYXRoKFdQKSBhbmQgcHJvdGVjdGlvbiBwYXRoKFBQKSBhcmUNCj4gPiBub3JtYWwu IFRoZW4sIEZvcmNlZCBTd2l0Y2goRlMpIGNvbW1hbmQgaXMgaXNzdWVkIGZvciBtYWludGVuYW5j ZSBvbg0KPiB0aGUNCj4gPiBXUCBhbmQgdGhlIHRyYWZmaWMgbW92ZXMgZnJvbSBXUCB0byBQUC4g V2hlbiBTaWduYWwgRmFpbCBvY2N1cnMgb24NCj4gPiBQUCwgc2VydmljZSBjYW5ub3QgcmVjb3Zl ciBhbmQgaXMgaW50ZXJydXB0ZWQuIFRoaXMgY291bGQgb2NjdXIgZm9yDQo+IGV4YW1wbGUNCj4g PiBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci4NCj4g PiBVc2UgY2FzZSBCKSBJZiB0aGVyZSBpcyBhbiBleGlzdGluZyBzaWduYWwgZmFpbCBvbiBhIHBy b3RlY3Rpb24gcGF0aA0KPiA+IChTRi1QKSxhbmQgRlMgY29tbWFuZCBpcyBpc3N1ZWQgYnkgYWNj aWRlbnQgdGhlIHRyYWZmaWMgb24gV1Agd2lsbA0KPiBtb3ZlDQo+ID4gdG8gUFAuIFRoaXMgcmVz dWx0cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9tIHdoaWNoIHlvdQ0KPiA+IHdp bGwgbm90IGF1dG9tYXRpY2FsbHkgcmVjb3ZlciwgYmVjYXVzZSBQU0Mgc2hvdWxkIG5vdCBoYXZl IHN3aXRjaGVkDQo+ID4gdGhlIHRyYWZmaWMgZnJvbSBXUCB0byBQUC4NCj4gPiBEaXNjdXNzaW9u IGFib3V0IHRoaXMgZHJhZnQgbGVkIHRvIHRoZSBwcm9wb3NhbCB0byBtb2RpZnkgUkZDIDQ0MjcN Cj4gdGhhdA0KPiA+IHdhcyAid3JpdHRlbiBjb3JyZWN0bHkgdGhvdWdoIGxhY2tpbmcgaW4gZGV0 YWlsIGNhdXNpbmcgbWlzLQ0KPiA+IGludGVycHJldGF0aW9uIiB0aGF0IGxlZCB0byB0aGUgY3Vy cmVudCBQU0Mgc2V0IG9mIHByaW9yaXR5IHRoYXQgdGhlDQo+ID4gYWJvdmUgZHJhZnQgaXMgcHJv cG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBhbGlnbiB0byB0aGUgcmVxdWlyZWQNCj4gPiB0cmFu c3BvcnQgYmVoYXZpb3IuIGRyYWZ0LWhlbHZvb3J0LWNjYW1wLWZzLXByaW9yaXR5LTAwIGhhcyBi ZWVuDQo+ID4gc3VibWl0dGVkIHRvIENDQU1QIGZvciBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9u cyByZWxhdGVkIHRvIE1hbnVhbA0KPiA+IFN3aXRjaCBhbmQgRm9yY2VkIFN3aXRjaCBhbmQgdGhl aXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJpb3JpdGllcy4NCj4gPiBUaGUgd2F5IHRoaXMgYmVoYXZp b3IgaGFzIHRvIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBQU0MgaGFzIHRvIGJlDQo+ID4gZGlz Y3Vzc2VkLiBUaGUgdGV4dCBwcm9wb3NlcyB0byByZXBsYWNlIHRoZSBjdXJyZW50IGJlaGF2aW9y IHdpdGgNCj4gPiB0aGUgbmV3IG9uZS4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHByb2NlZGUg aW4gdGhhdCB3YXkgdGhpcyBjYW4NCj4gPiBicmluZw0KPiB0bw0KPiA+IGEgc2ltcGxlIGFuZCBl ZmZlY3RpdmUgd2F5IHRvIG9wZXJhdGUgdGhlIHByb3RvY29sLg0KPiA+DQo+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPiAtLQ0KPiA+IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwIGNv bnRhaW5zIHRoZSB1cGRhdGVzIHRvDQo+ID4gUkZDNjM3OCB0byBjaGFuZ2Ugbm9uLXJldmVydGl2 ZSBvcGVyYXRpb25zIHRvIGJlaGF2ZXMgaW4gdGhlIHNhbWUNCj4gPiB3YXkgaXJyZXNwZWN0aXZl bHkgb2YgdGhlIHRyaWdnZXIgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGZhdWx0IG9yDQo+IG9w ZXJhdG9yDQo+ID4gY29tbWFuZCBGUywgTVMpLiBDb25zZXF1ZW50bHkgYW4gb3BlcmF0b3IgY29t bWFuZCwgTWFudWFsIFN3aXRjaCB0bw0KPiA+IFdvcmtpbmcgKE1TLVcpIGEuay5hICJNYW51YWwg c3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIiBpcw0KPiBhbHNvDQo+ID4gYWRkZWQg dG8gZW5hYmxlIHRoaXMgYmVoYXZpb3IuIEZyb20gYW4gb3BlcmF0aW9uYWwgcG9pbnQgb2Ygdmll dywgTVMNCj4gdG8NCj4gPiB3b3JraW5nIHBhdGggaGFzIGFsc28gdG8gYmUgc3VwcG9ydGVkIHRv IGJlIGFibGUgdG8gaW5pdGlhbGx5IGFsaWduDQo+ID4gYXQgYm90aCBzaWRlcyBpbiBjYXNlIG9m IG5vbi1yZXZlcnRpdmUgc3dpdGNoaW5nIG1vZGUuIE1TIHRvIHdvcmtpbmcNCj4gPiBwYXRoIGlz IGRlZmluZWQgaW4gUkZDIDU2NTQsIHJlcXVpcmVtZW50IDgzLg0KPiA+DQo+ID4gVGhlIHByb3Bv c2VkIE1TLVcgY29tbWFuZCBpcyBvZiBlcXVhbCBwcmlvcml0eSB0byB0aGUgZXhpc3RpbmcgTVMt UA0KPiA+IGNvbW1hbmQsIGFuZCB0aGVyZSBpcyB0ZXh0IHRvIGhhbmRsZSB0aGUgc2ltdWx0YW5l b3VzIG9yIHNlcXVlbnRpYWwNCj4gPiBvY2N1cnJlbmNlIG9mIHR3byBlcXVhbC1wcmlvcml0eSBj b21tYW5kcy4gVGhpcyBiZWhhdmlvciwgYWxyZWFkeQ0KPiA+IGFkb3B0ZWQgaW4gb3RoZXIgdHJh bnNwb3J0IG5ldHdvcmsgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdG9jb2wsDQo+ID4gY2FuDQo+ IGJlDQo+ID4gdXNlZCBmb3Igb3RoZXIgYWRkaXRpb24gdG8gdGhlIHByb3RvY29sIGluIHRoZSBm dXR1cmUuDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4gZHJhZnQtcmhkLW1wbHMt dHAtcHNjLXNkLTAwIHByb3ZpZGVzIGV4dGVuc2lvbnMgdG8gdGhlIFBTQyBzdGF0ZQ0KPiA+IG1h Y2hpbmUgdG8gaGFuZGxlIFNpZ25hbCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmluZSBT RCBvcg0KPiBwcm92aWRlDQo+ID4gc2NvcGUgYXJvdW5kIHdoZXJlIG9yIGhvdyBTRCBtYXkgYmUg dXNlZCBzaW1pbGFybHkgYXMgaXQgYWxyZWFkeQ0KPiBoYXBwZW4NCj4gPiBpbiB0aGUgZHJhZnQg aW4gaGFuZGxpbmcgb3RoZXIgZGVmZWN0cyBsaWtlIFNGIChTaWduYWwgRmFpbHVyZSkuDQo+ID4g SW4gTVBMUy1UUCBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBbUkZDNjM3Ml0sIGEgZmF1bHQgY29u ZGl0aW9uDQo+ID4gaW5jbHVkZXMgYm90aCBTaWduYWwgRmFpbCAoU0YpIGFuZCBTaWduYWwgRGVn cmFkZSAoU0QpIHRoYXQgY2FuIGJlDQo+IHVzZWQNCj4gPiB0byB0cmlnZ2VyIHByb3RlY3Rpb24g c3dpdGNoaW5nLg0KPiA+IFdoaWxlIHRoZSBzdGFuZGFyZGl6YXRpb24gbGFjayBvZiBhbiBTRCBk ZWZpbml0aW9uIGFuZCBkZXRlY3Rpb24NCj4gPiBtZWNoYW5pc21zLCB0aGUgcmVsZXZhbnQgYmVo YXZpb3JzIGluIHRlcm1zIG9mIHByb3RlY3Rpb24gYWN0aW9ucw0KPiA+IG1heSBhbHJlYWR5IGJl IGRlZmluZWQuDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4gZHJhZnQtZGotbXBs cy10cC1leGVyLXBzYy0wMSBwcm9wb3NlcyBhZGRpbmcgdGhlIEVYRVIvUlIgY29tbWFuZHMgdG8N Cj4gPiB0ZXN0IGlmIHRoZSBBUFMgY29tbXVuaWNhdGlvbiBpcyBvcGVyYXRpbmcgY29ycmVjdGx5 LiBJbiBvdGhlciB3b3Jkcw0KPiA+IGJvdGggQVBTIHByb2Nlc3MgbG9naWMgaW5jbHVkaW5nIHN0 YXRlIG1hY2hpbmUgYW5kIEFQUyBjaGFubmVsIG9uDQo+ID4gcHJvdGVjdGlvbiBwYXRoLCB3aXRo b3V0IHNlcnZpY2UgZGlzcnVwdGlvbiBhbmQgd2l0aG91dCBhZmZlY3RpbmcNCj4gPiBhbnkgcHJv dGVjdGlvbiBvcGVyYXRpb24sIHVubGVzcyB0aGUgcHJvdGVjdGlvbiB0cmFuc3BvcnQgZW50aXR5 IGlzDQo+ID4gaW4NCj4gdXNlLg0KPiA+IFRoaXMgY29tbWFuZCBpcyBkb2N1bWVudGVkIGluIFI4 NCBvZiBbUkZDNTY1NF0gYW5kIGl0IGlzIHBhcnQgb2YNCj4gPiBJVFUtVCB0cmFuc3BvcnQgcmVx dWlyZW1lbnRzLg0KPiA+IEFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4g dGhlIEFwcGVuZGl4IEIgb2YgUkZDNjM3OA0KPiB0aGF0DQo+ID4gdXRpbGl6ZXMgdGhlIExvY2tv dXQgb2YgUHJvdGVjdGlvbiAoTE8pIG9yIEZvcmNlZCBTd2l0Y2ggKEZTKSBpbg0KPiA+IGNvbWJp bmF0aW9uIG9mIE9BTSBmdW5jdGlvbmFsaXRpZXMuIEhvd2V2ZXIsIGl0IGhhcyBzb21lIGZ1bmN0 aW9uYWwNCj4gPiBsaW1pdGF0aW9uIGFuZCBoYXMgYSBwb3RlbnRpYWwgcmlzayBvZiBsb3Npbmcg dHJhZmZpYyBhcyBhIHNpZ25hbA0KPiA+IGZhaWx1cmUgbWlnaHQgb2NjdXIgZHVyaW5nIHRoZSBl eGVyY2lzZSBvcGVyYXRpb24uIEluIHRoYXQgY2FzZSwgTE8NCj4gPiBvciBGUyBoYXMgdG8gYmUg Y2FuY2VsZWQgdG8gYWxsb3cgdGhlIFBTQyBwcm90b2NvbCB0byBwcm92aWRlIHByb3Blcg0KPiA+ IHN3aXRjaGluZy4NCj4gPiBBIGZ1cnRoZXIgYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1l bnRlZCBpbiBkcmFmdC1vc2Jvcm5lLW1wbHMtDQo+IHBzYy0NCj4gPiBhbGl2ZS0wMCB0aGF0IGFu eXdheSBzaG93IHNvbWUgZnVuY3Rpb25hbCBsaW1pdGF0aW9ucyBiZWNhdXNlIGNhbm5vdA0KPiA+ IHZhbGlkYXRlIHRoZSBQU0Mgc3RhdGUgbWFjaGluZSBzdGF0dXMgYW5kIHByb2JhYmx5IHRoZSBM b2NhbCBSZXF1ZXN0DQo+ID4gbG9naWMuDQo+ID4NCj4gPg0KPiA+IFRoZSBhdXRob3JzIGVuY291 cmFnZSB0aGUgSUVURiBleHBlcnRzIHRvIGNvbW1lbnQgb24gdGhlc2UgZHJhZnRzLA0KPiA+IGV2 ZW50dWFsbHkgcHJvcG9zaW5nIG90aGVyIG9wdGlvbnMvbWVjaGFuaXNtcyB0aGF0IGNhbiBzYXRp c2Z5IHRoZQ0KPiBzYW1lDQo+ID4gcmVxdWlyZW1lbnRzLg0KPiA+IEJlc3QgcmVnYXJkcywNCj4g PiBBbGVzc2FuZHJvLCBIdXViLCBKZW9uZy1kb25nLCBUYWVrc2lkIFF1ZXN0byBtZXNzYWdnaW8g ZSBpIHN1b2kNCj4gPiBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlDQo+ IGFsbGUNCj4gPiBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxz aWFzaSBhbHRyYSBhemlvbmUNCj4gPiBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVz dGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZQ0KPiA+IHZpZXRhdGUuIFF1YWxvcmEg YWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUNCj4gPiBj b3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBt aXR0ZW50ZSBlDQo+ID4gZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll Lg0KPiA+DQo+ID4gVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRp YWwgYW5kIG1heSBjb250YWluDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBm b3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5Lg0KPiA+IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHBy aW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMNCj4gdW5hdXRob3Jpc2VkLg0KPiA+IElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlDQo+ID4gYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkg cmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KPiA+DQo+ID4gcmlzcGV0dGEgbCdhbWJpZW50ZVJpc3Bl dHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZQ0KPiBub24NCj4gPiDD qCBuZWNlc3NhcmlvLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From eosborne@cisco.com Mon Jul 22 13:12:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E48111E8140 for ; Mon, 22 Jul 2013 13:12:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZh5ICef9unJ for ; Mon, 22 Jul 2013 13:12:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A6AB511E813B for ; Mon, 22 Jul 2013 13:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25130; q=dns/txt; s=iport; t=1374523950; x=1375733550; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r65cvEtK4H88duTtNnI89pM+Ak28LvJuoASZKydTchs=; b=GTqaQWEtM9s4mhV2P0hxQP/IUOBP+WIAl+Zom26Y1+Ivs/k/GHM0Mqx1 CSd17DfcPX+qnyvRzfWRjJjVxk8jyWGSgd4OMiege18apU8bDPYZB8aTJ z1iCAVyb0gjmhGgmwJqOvAdp8C/SsX5KkOH6pBDThisx3C9TC73ml9ySQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAC+R7VGtJXG9/2dsb2JhbABbgwM1UIMKvSgXfxZ0giQBAQEEAQEBIBE3AwsMBAIBCBEEAQEBAgIGGQQDAgICHwYLFAEICAEBBAENBQgTh2MDDwymW4hVDYhaBIEojAKBHxuBARYWBQcGglczbgOVdI4QhSaBWYE5gWgCAgUXBhw X-IronPort-AV: E=Sophos;i="4.89,721,1367971200"; d="scan'208";a="237792048" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 22 Jul 2013 20:12:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6MKCTsv006324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 20:12:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 15:12:29 -0500 From: "Eric Osborne (eosborne)" To: "Huber, Thomas J." , "Ryoo, Jeong-dong" , "D'Alessandro Alessandro Gerardo" , "mpls@ietf.org" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQADK5f8AALo9nQAAJm74A= Date: Mon, 22 Jul 2013 20:12:28 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721028AD97@xmb-rcd-x09.cisco.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2013 20:12:38 -0000 SGkgVG9tLQ0KDQoNCiAgVGhhdCdzIGEgZ29vZCB3YXkgdG8gcHV0IGl0LCBhbmQgSSB0aGluayBp dCBjYXB0dXJlcyB0aGUgdHdvIG9waW5pb25zLiAgTXkgY29uY2VybiB3aXRoIHRoZSBib29sZWFu IFNEIGFwcHJvYWNoIGlzIHRoYXQgaXQncyBiZWVuIGEgc3RydWdnbGUgdG8gZGVmaW5lIFNEIGF0 IGFsbCBmb3IgSVAvTVBMUyBuZXR3b3Jrcy4gIEkgY2FuIGVjaG8gSmVvbmctRG9uZydzIHBvaW50 IGhlcmUgLSBTRCBjb3VsZCBiZSBzZXJ2ZXIgU0QgW1NTRF0sIGl0IGNvdWxkIGJlIFBNLCBpdCBj b3VsZCBiZSBDQ00uICBVbmxlc3Mgd2UgYWN0dWFsbHkgZGVmaW5lIFNELCBpdCdzIG5vdCBhdCBh bGwgY2xlYXIgdG8gbWUgdGhhdCBJUCBTRCB3aWxsIGluIGZhY3QgYmUgYSBzaW1wbGUgeWVzL25v IHRoaW5nLiAgV2hhdCBpZiB3ZSBkZWNpZGUgdGhhdCBib3RoIFBNIGFuZCBTU0QgYXJlIHZhbGlk LCBidXQgdGhhdCBvbmUgb2YgdGhlbSBpcyB3b3JzZSB0aGFuIHRoZSBvdGhlcj8gIA0KDQogIEp1 c3Qgc28gd2UncmUgY2xlYXIgLSBJIGFtIG5vdCBhZ2FpbnN0IHRoZSBjb25jZXB0IG9mIFNEIGlu IFBTQy4gIEkgYW0gYWdhaW5zdCBkZWZpbmluZyBob3cgd2UgcmVhY3QgdG8gYW4gZXZlbnQgYmVm b3JlIHdlIGRlZmluZSB0aGUgZXZlbnQgaXRzZWxmLg0KDQoNCg0KDQplcmljDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIdWJlciwgVGhvbWFzIEouIFttYWlsdG86 VG9tLkh1YmVyQHRlbGxhYnMuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzow NCBQTQ0KPiBUbzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IFJ5b28sIEplb25nLWRvbmc7IEQn QWxlc3NhbmRybyBBbGVzc2FuZHJvDQo+IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IEh1 dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pOyBodXViYXR3b3JrQGdt YWlsLmNvbQ0KPiBTdWJqZWN0OiBSRTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p bmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0 IHJlcXVpcmVtZW50cw0KPiANCj4gSGkgRXJpYywNCj4gDQo+IFlvdSB3cm90ZToNCj4gPkVPIw0K PiA+SSdtIG5vdCBzdXJlIHdoYXQgdGhhdCB3b3VsZCBsb29rIGxpa2UuICAnRmFpbCcgaXMgYSBw cmV0dHkgYmluYXJ5DQo+IHRoaW5nLiAgJ0RlZ3JhZGUnIGlzIGEgY29udGludW91cyB2YXJpYWJs ZSwgYXMgaXQgY2FuIGJlIGFueXRoaW5nIGZyb20NCj4gJ2EgbGl0dGxlIGJhZCcgdG8gYSAnYSB3 aG9sZSBsb3Qgb2YgYmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuDQo+IA0KPiBJIHRoaW5rIHRoaXMg bWF5IGJlIGEgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBpbiBhc3N1bXB0aW9ucy4gIFdoaWxlIGl0 DQo+IGlzIGNlcnRhaW5seSB0cnVlIHRoYXQgZGVncmFkYXRpb24gb2YgYSBzaWduYWwgaXMgYSBj b250aW51b3VzIHZhcmlhYmxlLA0KPiBpbiB0aGUgY29udGV4dCBvZiBwcm90ZWN0aW9uIHN3aXRj aGluZyBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmssIHRoZXJlDQo+IGlzIGEgcGFydGljdWxhciB2 YWx1ZSBvZiB0aGF0IGNvbnRpbnVvdXMgdmFyaWFibGUgdGhhdCBkZWZpbmVzIHRoZQ0KPiB0aHJl c2hvbGQgYXQgd2hpY2ggdGhlIEJvb2xlYW4gdmFyaWFibGUgInNpZ25hbCBkZWdyYWRlIChTRCki IGJlY29tZXMNCj4gdHJ1ZS4gIEl0IGlzIGZvciB0aGlzIHJlYXNvbiB0aGF0IEplb25nLWRvbmcg YW5kIG90aGVycyBhcmUgc3VnZ2VzdGluZw0KPiB0aGF0IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0 byBpbmNvcnBvcmF0ZSB0aGUgYmVoYXZpb3Igb2YgdGhlIFNEIHN0YXRlDQo+IGludG8gdGhlIFBT QyBkZWZpbml0aW9uIHdpdGhvdXQgbmVlZGluZyB0byBoYXZlIGEgcHJlY2lzZSBkZWZpbml0aW9u IG9mDQo+IHRoZSBtZWNoYW5pc20gZm9yIG1lYXN1cmluZyB0aGUgZGVncmFkYXRpb24gb2YgYSBz aWduYWwuICBXaGF0ZXZlciB0aGUNCj4gbWVjaGFuaXNtIGlzLCBpdCB3aWxsIGJlIGNvbnZlcnRl ZCB0byB0aGUgYmluYXJ5IFNEIGluZGljYXRpb24uDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFRv bQ0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m DQo+IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAyMiwgMjAx MyA4OjM2IEFNDQo+IFRvOiBSeW9vLCBKZW9uZy1kb25nOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRy byBHZXJhcmRvOyBtcGxzQGlldGYub3JnDQo+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5o ZWx2b29ydEBodWF3ZWkuY29tKTsgaHV1YmF0d29ya0BnbWFpbC5jb20NCj4gU3ViamVjdDogUmU6 IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcg0K PiBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCj4gDQo+IEhp IEplb25nLWRvbmcsDQo+IA0KPiAgIFRoYW5rcyBmb3IgdGhlIHJlcGx5LiAgUGxlYXNlIHNlZSBp bmxpbmUgd2l0aCBFTyMuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogUnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOnJ5b29AZXRyaS5yZS5rcl0NCj4gPiBTZW50 OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgNDoxNSBBTQ0KPiA+IFRvOiBFcmljIE9zYm9ybmUgKGVv c2Jvcm5lKTsgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsNCj4gPiBtcGxzQGlldGYu b3JnDQo+ID4gQ2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20p OyBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiA+IFN1YmplY3Q6IFJFOiBbbXBsc10gcHJvcG9zZWQg ZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXINCj4gPiBwcm90ZWN0aW9uIHBy b3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCj4gPg0KPiA+IEhpLCBFcmljLg0KPiA+ DQo+ID4gTGV0IG1lIGFuc3dlciB5b3VyIDJuZCBxdWVzdGlvbiBvbiBTRC4NCj4gPg0KPiA+IFNE IGRldGVjdGlvbiBtZXRob2RzIGRlZmluZWQgb3IgcHJvcG9zZWQgZm9yIHBhY2tldCB0cmFuc3Bv cnQgbmV0d29ya3MNCj4gPiBjYW4gYmUgc3VtbWFyaXplZCBhcyBmb2xsb3dzOg0KPiA+IC0gQnkg T0FNIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdG9vbDoNCj4gPiAgIFNEIGlzIHJhaXNlZCBpZiBw YWNrZXQgbG9zcyByYXRpbyBleGNlZWRzIGEgdGhyZXNob2xkIGR1cmluZyBhDQo+ID4gbWVhc3Vy ZW1lbnQgcGVyaW9kLg0KPiA+ICAgVGhyZXNob2xkIHZhbHVlIGFuZCBtZWFzdXJlbWVudCBwZXJp b2QgYXJlIGNvbmZpZ3VyZWQgYnkgYW4gbmV0d29yaw0KPiA+IG9wZXJhdG9yLg0KPiA+ICAgVGhp cyBkZXRlY3Rpb24gbWV0aG9kIGlzIGFscmVhZHkgZGVmaW5lZCBpbiBJVFUtVCBHLjgwMjEgKEV0 aGVybmV0DQo+ID4gZXF1aXBtZW50IHNwZWMuKQ0KPiANCj4gDQo+IEVPIyAgV2hlcmU/ICBJJ20g bm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2aW5nIGENCj4g aGFyZCB0aW1lIGZpbmRpbmcgaXQuICBBIHNlYXJjaCBmb3IgRVRIX0NJX1NTRCBkb2Vzbid0IHlp ZWxkIG11Y2guICBJZiBJDQo+IGxvb2sgZm9yICdzaWduYWwgZGVncmFkZScgSSBzZWUgcC4gMTMx IHdoaWNoIHNheXMgdGhhdCB0aGUgYWxnb3JpdGhtIGlzDQo+IGRlZmluZWQgaW4gRy44MDMxLiAg Ry44MDMxIHNheXMgJyBIb3cgdGhlc2UgZGVmZWN0cyBhcmUgZGV0ZWN0ZWQgaXMgdGhlDQo+IHN1 YmplY3Qgb2YgdGhlIGVxdWlwbWVudCBSZWNvbW1lbmRhdGlvbnMnLiAgSSdtIGxvb2tpbmcgZm9y IHNvbWV0aGluZw0KPiBsaWtlICJTaWduYWwgRGVncmFkZSBpcyBkZWZpbmVkIGFzICRmb28gcGFj a2V0IGxvc3Mgb3IgQ1JDIGZhaWx1cmUgb3Zlcg0KPiAkYmFyIHRpbWUiLi4uLndoYXQgaGF2ZSBJ IG1pc3NlZD8NCj4gDQo+IA0KPiA+ICAgYW5kIHRoZSBlcXVpcG1lbnQgc3BlYyBmb3IgTVBMUy1U UCBjYW4gZWFzaWx5IGZvbGxvdyB0aGUgc2FtZQ0KPiA+IGRlZmluaXRpb24uDQo+ID4gLSBCeSBz ZXJ2ZXIgbGF5ZXIgaW5kaWNhdGlvbjoNCj4gPiAgIFNEIGlzIHJhaXNlZCBpZiBhIHNlcnZlciBs YXllciBiZWxvdyBNUExTLVRQIHJlcG9ydHMgU0QgY29uZGl0aW9uIG9uDQo+ID4gaXRzIG93biBs YXllci4NCj4gPiAtIEJ5IENDTSBwYWNrZXQgY291bnRpbmc6DQo+ID4gICBTRCBpcyByYWlzZWQg aWYgdGhlIGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhjZWVkcyBhIHRocmVzaG9sZA0KPiA+ IGR1cmluZyBhIG1lYXN1cmVtZW50IHBlcmlvZC4NCj4gPg0KPiA+IFJlZ2FyZGxlc3Mgb2YgaG93 IHRvIGRldGVjdCBTRCwgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50cw0KPiA+IHNo b3VsZCBkZXNjcmliZSB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb3BlcmF0aW9uIG9uY2Ugc3Vj aCBhIFNEIGlzDQo+ID4gZGVjbGFyZWQuDQo+ID4NCj4gLi4uDQo+ID4gUmVnYXJkaW5nIHRoZSBt dWx0aXBsZSBsZXZlbHMgb2YgU0Q6DQo+ID4gSXQgaXMgY2VydGFpbmx5IHBvc3NpYmxlIHRvIGRl ZmluZSBtdWx0aXBsZSBsZXZlbHMgb2YgU0QuDQo+ID4gQnV0LCBhcyBmYXIgYXMgdGhlIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIGlzIGNvbmNlcm5lZCwgaXQganVzdCBuZWVkcyB0bw0KPiA+IGtub3cg aWYgU0QgaXMgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2VzcyBvciBub3Qu DQo+ID4gSXQgd291bGQgYmUgYSBuZXR3b3JrIG9wZXJhdG9yJ3MgY2hvaWNlIGF0IHdoYXQgbGV2 ZWwgb2YgU0QgaGUgd2FudHMNCj4gPiBoaXMgbmV0d29yayBwcm90ZWN0aW9uIHRvIHN3aXRjaG92 ZXIuDQo+ID4gSW4gb3RoZXIgd29yZHMsIHdoYXQgdHJpZ2dlcnMgcHJvdGVjdGlvbiBzd2l0Y2hp bmcgaXMgU0Qgb3Igbm8gU0QuIEl0DQo+ID4gaXMgeWVzIG9yIG5vIGRlY2lzaW9uLg0KPiANCj4g DQo+IEVPIyAgSSBhbSBub3QgYXdhcmUgb2YgYW55IGRvY3VtZW50IHdoaWNoIHN1Z2dlc3RzIHRo YXQgYSBzZXJ2ZXIgbGF5ZXINCj4gU0Qgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYSBjbGllbnQgbGF5 ZXIgU0QuICBJbiB0aGUgSVAgd29ybGQsIGlmIHdlIGhhdmUNCj4gU0Qgb24gYSB0cmFuc3BvcnQg aW50ZXJmYWNlIHRoYXQgaXMgZ2VuZXJhbGx5IHVzZWQgdG8gYnJpbmcgdGhlDQo+IGludGVyZmFj ZSBkb3duIChpLmUuIFNGKS4gIFRoaXMgaXMgdGhlIHNvcnQgb2YgdGhpbmcgSSdkIGxpa2UgdG8g c2VlIGluDQo+IG1vcmUgZGV0YWlsLCBhcyBTRCBpbiB0aGUgcGFja2V0IHdvcmxkIGlzIGEgbmV3 IGNvbmNlcHQgYW5kIHdlIGNhbid0DQo+IGp1c3QgYXNzdW1lIHRoYXQgaXQgd2lsbCB3b3JrIHRo ZSBzYW1lIGV2ZXJ5d2hlcmUgYmVjYXVzZSB3ZSBkZWZpbmUNCj4gc3RhdGUgbWFjaGluZSBwb2lu dHMgZm9yIGl0Lg0KPiANCj4gVGhlIHBvaW50IGFib3V0IENDTSBpcyBhIGdvb2Qgb25lLiAgTGV0 J3Mgc2F5IHdlIGNvbWUgdXAgd2l0aCBhIGNsZXZlcg0KPiBTRCBtZWNoYW5pc20gd2l0aCB0d28g dGhyZXNob2xkcywgY2FsbCB0aGVtIG1ham9yIGFuZCBtaW5vci4gIEZvcg0KPiBkaXNjdXNzaW9u IHB1cnBvc2VzIHRoZXkgY291bGQgYmUgc2ltcGxlIGVycm9yIHJhdGlvcywgZS5nLiAxOjEwXjYg YW5kDQo+IDE6MTBeOS4gIEJ1dCB0aGV5IGNvdWxkIGJlIG1vcmUgcG93ZXJmdWwgdGhhbiB0aGF0 IChmbG93IHR5cGUsIGZsb3cNCj4gbGVuZ3RoLCBlcnJvciBidXJzdCBzaXplLCBldGMpLg0KPiAN Cj4gSWYgd2Ugd2FudCB0byBoYXZlIFNELU1ham9yIGFuZCBTRC1NaW5vciBpbnB1dHMgYXMgc2Vw YXJhdGUgdHJpZ2dlcnMgZm9yDQo+IFBTQywgd2UgbWF5IHdhbnQgdGhlbSBhdCBkaWZmZXJlbnQg cG9pbnRzLiAgUGVyaGFwcyAgKGxlYXZpbmcgb3V0IHRoZQ0KPiBXb3JraW5nIHBhdGggZm9yIGVh c2Ugb2YgcmVhZGluZykNCj4gDQo+IExPDQo+IEZTDQo+IFNGLVANCj4gU0QtUC1NYWpvcg0KPiBN Uw0KPiBTRC1QLU1pbm9yDQo+IA0KPiANCj4gVGhpcyBzZWVtcyBsaWtlIGEgcGVyZmVjdGx5IHJl YXNvbmFibGUgdGhpbmcgdG8gd2FudC4NCj4gDQo+IA0KPiBFdmVuIGlmIHdlIGRvbid0IGhhdmUg bXVsdGktdGllciBTRCwgZXZlbiB0aGUgc2luZ2xlLXRpZXIgU0QgbmVlZHMgdG8gYmUNCj4gZGVm aW5lZCBiZWZvcmUgd2UgY2FuIGRlY2lkZSBob3cgdG8gcmVzcG9uZCB0byBpdC4NCj4gDQo+ID4g VGhlIHByb3Bvc2VkIGRyYWZ0IGNvdmVycyBTRC10cmlnZ2VyZWQgcHJvdGVjdGlvbiBubyBtYXR0 ZXIgd2hhdCBraW5kcw0KPiA+IG9mIFNEIGRldGVjdGlvbiBtZXRob2RzIGFyZSB1c2VkLg0KPiA+ DQo+ID4NCj4gPiBTRiBjYW4gYWxzbyBiZSB2aWV3ZWQgYXMgaGF2aW5nIG11bHRpcGxlIGxldmVs cyBvZiBTRiBhcyB0aGUgbmV0d29yaw0KPiA+IG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9p Y2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ00NCj4gbWVzc2FnZXMuDQo+IA0KPiANCj4g RU8jDQo+IEknbSBub3Qgc3VyZSB3aGF0IHRoYXQgd291bGQgbG9vayBsaWtlLiAgJ0ZhaWwnIGlz IGEgcHJldHR5IGJpbmFyeQ0KPiB0aGluZy4gICdEZWdyYWRlJyBpcyBhIGNvbnRpbnVvdXMgdmFy aWFibGUsIGFzIGl0IGNhbiBiZSBhbnl0aGluZyBmcm9tDQo+ICdhIGxpdHRsZSBiYWQnIHRvIGEg J2Egd2hvbGUgbG90IG9mIGJhZCBidXQgbm90IHF1aXRlIGZhaWwnLg0KPiANCj4gPiBJZiBDQ00g aXMgZGlzYWJsZWQsIEFJUyBmcm9tIGEgc2VydmVyIGxheWVyIGNhbiBiZSB1c2VkIGFzIGEgdHJp Z2dlcg0KPiA+IGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZy4gU28gYW5kIHNvIGZvcnRoLg0KPiAN Cj4gRU8jICBBSVMgZnJvbSB0aGUgc2VydmVyIGxheWVyIG9ubHkgZ2V0cyB5b3UgU0QgZnJvbSB0 aGUgZmlyc3QgaG9wIG9mDQo+IHRoZSB1bmRlcmx5aW5nIHNlcnZlciBwYXRoLg0KPiANCj4gDQo+ IA0KPiANCj4gZXJpYw0KPiANCj4gPiBIb3dldmVyLCBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1 bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGRldGVjdA0KPiA+IFNGIGluIGFueXdoZXJlLg0K PiA+IFNpbWlsYXJ5LCBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZp bmUgaG93IG1hbnVhbA0KPiA+IHN3aXRjaCBhbmQgZm9yY2VkIHN3aXRjaCBjb21tYW5kcyBhcmUg aW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW0NCj4gPiBhbmQgc2lnbmFsZWQgdG8gcHJv dGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2Vzcy4NCj4gPg0KPiA+IEFnYWluLCBpbiBteSBvcGluaW9u LCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlvbiBjYW4gYWNjb21tb2RhdGUgYW55DQo+ID4gU0Qg ZGV0ZWN0aW9uIG1ldGhvZHMuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBKZW9u Zy1kb25nDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IEZyb20gOiAiRXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSkiIDxlb3Nib3JuZUBjaXNjby5jb20+IFNlbnQgOg0KPiA+IDIwMTMtMDctMjAgMDI6NDg6Mjgg KCArMDk6MDAgKSBUbyA6IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPiA8YWxl c3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0PiwgbXBsc0BpZXRmLm9yZw0KPiA+ IDxtcGxzQGlldGYub3JnPiBDYyA6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1 YXdlaS5jb20pDQo+ID4gPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+LCBodXViYXR3b3Jr QGdtYWlsLmNvbQ0KPiA+IDxodXViYXR3b3JrQGdtYWlsLmNvbT4gU3ViamVjdCA6IFJlOiBbbXBs c10gcHJvcG9zZWQgZHJhZnRzIGZvcg0KPiA+IGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhciBw cm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydA0KPiA+IHJlcXVpcmVtZW50cw0KPiA+DQo+ ID4NCj4gPiBIaSBBbGVzc2FuZHJvLQ0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGlzOyB0aGUgdGhy ZWFkcyBJIHN0YXJ0ZWQgc29tZSB0aW1lIGJhY2sgc2VlbSB0byBoYXZlDQo+ID4gZGllZCBkb3du LCBpdCdzIGdvb2QgdG8gZ2V0IHRoZW0gZ29pbmcgYWdhaW4uDQo+ID4gSSBoYXZlIHR3byB0aGlu Z3MgSSBuZXZlciBxdWl0ZSB1bmRlcnN0b29kLCBjYW4geW91IGNsYXJpZnkgdGhlbSBmb3INCj4g bWU/DQo+ID4NCj4gPiBpKSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBsZXZlbD8g SSdtIG5vdCBsb29raW5nIGZvciBhDQo+ID4gZGVzY3JpcHRpb24gb2YgdGhlIHN0YXRlIG1hY2hp bmUgY2hhbmdlcywgYW5kIEknbSBub3QgbG9va2luZyBmb3IgdGhlDQo+ID4gb25lIGxpbmUgIkl0 IGFsbG93cyB0aGUgRlNNIHRvIGJlIHRlc3RlZCIuIFdlIGhhdmUgYWxsIG9mIHRoYXQgaW4gdGhl DQo+ID4gZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBzcGVjcy4NCj4gPg0KPiA+IFdo YXQgSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCBhYm91dCBFWEVSIGlzIHdoZXJlIGl0IGNhbWUgZnJv bS4gVGhlIElUVQ0KPiA+IHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0dHkgaGFyZCB0byBm b2xsb3csIHRoZXkgc2VlbSB0byBhc3N1bWUNCj4gPiB0aGUgcmVhZGVyIGFscmVhZHkga25vd3Mg d2hhdCBFWEVSIGlzIGFuZCB3aGF0IHByb2JsZW0gaXQgc29sdmVzLiBJdA0KPiA+IGZlZWxzIHZl cnkgbXVjaCBsaWtlIGEgbWVjaGFuaXNtIHVzZWQgdG8gY2F0Y2ggYSB2ZXJ5IHNwZWNpZmljDQo+ ID4gaW1wbGVtZW50YXRpb24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2FzIGZhciBs ZXNzIGRlYnVnZ2FibGUNCj4gPiB0aGFuIHdoYXQgd2UgaGF2ZSB0b2RheS4NCj4gPg0KPiA+IE5v IG90aGVyIHN0YXRlIG1hY2hpbmVzIHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwg QkdQLCBPU1BGLA0KPiA+IElTSVMpIGhhdmUgZXhwbGljaXQgc2lnbmFsaW5nIGluIHRoZW0ganVz dCB0byBhc2sgdGhlIG5laWdoYm9yIHdoZXRoZXINCj4gPiBpdCAqd291bGQqIGJlIGJyb2tlbiBp ZiBpZiB3ZXJlLCBpbiB0aGUgZnV0dXJlLCB0byBiZSBnaXZlbiBhDQo+ID4gcGFydGljdWxhciBp bnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBiZWhpbmQgRVhFUiBoYXMgYmVlbg0K PiA+IHRoYXQgSSBkb24ndCBmZWVsIGNvbWZvcnRhYmxlIHdpdGggdGhlIGlkZWEgb2Yga2VlcGlu ZyBhIDMwLXllYXItb2xkDQo+ID4gd29ya2Fyb3VuZCBpbiBhIHByb3RvY29sLiBJcyB0aGVyZSBt b3JlIHRvIGl0IHRoYW4gdGhhdD8gSGF2ZSBJDQo+ID4gbWlzcmVhZCBhbmQgbWlzdW5kZXJzdG9v ZCBFWEVSPyBEb2VzIG1vZGVybiB0cmFuc3BvcnQgZ2VhciBldmVyDQo+ID4gYWN0dWFsbHkgZGV0 ZWN0IGEgcHJvYmxlbSB2aWEgRVhFUi9SUiB0aGF0IHdhc24ndCBvYnZpb3VzIHRvIHRoZQ0KPiA+ IG9wZXJhdG9yIHVzaW5nIG90aGVyIG1lYW5zPw0KPiA+DQo+ID4NCj4gPiBpaSkgV2h5IHRoZSBw dXNoIHRvIHN0YW5kYXJkaXplIHRoZSBTRCBzdGF0ZSBjaGFuZ2VzIGJlZm9yZSB3ZSd2ZQ0KPiA+ IGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxpbmcgc2lnbmFsIGRlZ3Jh ZGUgaXMgYSBnb29kDQo+ID4gaWRlYSwgYnV0IGNvbWluZyB1cCB3aXRoIGEgZGVmaW5pdGlvbiBm b3IgaXQgaGFzIGJlZW4gY2hhbGxlbmdpbmcuDQo+ID4gV2hhdCBoYXBwZW5zIGlmIHdlIGNoYW5n ZSB0aGUgRlNNIHRvIGhhbmRsZSBpdCwgdGhlbiBjb21lIHVwIHdpdGgNCj4gPiBzb21ldGhpbmcg bW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRpcGxlIGxldmVscyBvZiBTRCkgdGhhdCBkb2Vz bid0DQo+ID4gcXVpdGUgZml0IHdpdGggdGhlIEZTTSBjaGFuZ2VzPw0KPiA+DQo+ID4NCj4gPg0K PiA+IHRoYW5rcyENCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gZXJpYw0KPiA+DQo+ID4N Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+ IE9mDQo+ID4gPiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvDQo+ID4gPiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgMzoyMyBQTQ0KPiA+ID4gVG86IG1wbHNAaWV0Zi5vcmcN Cj4gPiA+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tKTsN Cj4gPiA+IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+ID4gPiBTdWJqZWN0OiBbbXBsc10gcHJvcG9z ZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXINCj4gPiA+IHByb3RlY3Rp b24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPiA+ID4NCj4gPiA+IERlYXIg YWxsLA0KPiA+ID4gd2Ugd291bGQgbGlrZSBzb2NpYWxpemluZyB0aGUgaGVyZWJlbG93IGRyYWZ0 cyB0aGF0IHdlcmUgc3VibWl0dGVkDQo+ID4gc29tZQ0KPiA+ID4gbW9udGhzIGFnbyB3aXRoIHRo ZSBhaW0gdG8gYWxpZ24gUFNDIHByb3RvY29sIChSRkMgNjM3OCkgdG8gSVRVLVQNCj4gPiA+IHRy YW5zcG9ydCByZXF1aXJlbWVudHMuIEkgd291bGQgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFi b3V0IHRoZQ0KPiA+ID4gcHJvcG9zZWQgbWVjaGFuaXNtcyBhbmQgYmVoYXZpb3Vycy4NCj4gPiA+ DQo+ID4gPiBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDANCj4gPiA+IGRyYWZ0LWNk aC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwDQo+ID4gPiBkcmFmdC1yaGQtbXBscy10cC1w c2Mtc2QtMDANCj4gPiA+IGRyYWZ0LWRqLW1wbHMtdHAtZXhlci1wc2MtMDEgLyBkcmFmdC1vc2Jv cm5lLW1wbHMtcHNjLWFsaXZlLTAwDQo+ID4gPg0KPiA+ID4gVGhlIGFib3ZlIGRyYWZ0cyBjb3Zl ciBtb3N0IG9mIGl0ZW1zIGhpZ2hsaWdodGVkIGluIElUVS1UIGxpYWlzb25zDQo+ID4gYWJvdXQN Cj4gPiA+IFBTQyBhbmQgdGhleSBwcm9wb3NlIHNvbHV0aW9ucyBpbiBsaW5lIHdpdGggTVBMUy1U UCB0cmFuc3BvcnQNCj4gPiA+IHJlcXVpcmVtZW50cy4NCj4gPiA+IEEgbGlzdCBvZiBtYWluIGxp YWlzb25zIGV4Y2hhbmdlZCBiZXR3ZWVuIElUVS1UIGFuZCBJRVRGIHdpdGggdGhlDQo+ID4gPiBh aW0NCj4gPiB0bw0KPiA+ID4gYWxpZ24gUFNDIGJlaGF2aW91cyB3aXRoIElUVS1UIHRyYW5zcG9y dCByZXF1aXJlbWVudHMgZm9yIGxpbmVhcg0KPiA+ID4gcHJvdGVjdGlvbiBhcmUgZ2l2ZW4gYmVs b3c6DQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTE2Mi8gKEp1 bmUgMjAxMikNCj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjA1 Lw0KPiA+ID4gKE9jdG9iZXIgMjAxMikNCj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbGlhaXNvbi8xMjI5Lw0KPiA+ID4gKEphbnVhcnkgMjAxMykNCj4gPiA+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjM0Lw0KPiA+ID4gKEZlYnJ1YXJ5IDIwMTMpDQo+ ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni8NCj4gPiA+IChN YXkgMjAxMykNCj4gPiA+DQo+ID4gPiBTb21lIGRldGFpbHMgYWJvdSB0aGUgcHJvcG9zZWQgZHJh ZnRzIGZvciBhbGlnbiBQU0MgYmVoYXZpb3VyIHdpdGgNCj4gPiA+IHRyYW5zcG9ydCByZXF1aXJl bWVudHM6DQo+ID4gPg0KPiA+ID4gZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwIHBy b3Bvc2VzIHN3YXBwaW5nIHRoZSBwcmlvcml0aWVzDQo+ID4gPiBiZXR3ZWVuIEZTIGFuZCBTRi1Q IChzZWUgc2VjdGlvbiA0LjMuMiBvZiByZmM2Mzc4KS4NCj4gPiA+IEFtb25nIHRoZSBvdGhlcnMs IGJlaGF2aW9ycyB0aGF0IHdpbGwgYmUgZml4ZWQgd2l0aCB0aGUgcHJvcG9zZWQNCj4gPiB1cGRh dGUNCj4gPiA+IGFyZToNCj4gPiA+IFVzZSBjYXNlIEEpIEF0IGZpcnN0LCB3b3JraW5nIHBhdGgo V1ApIGFuZCBwcm90ZWN0aW9uIHBhdGgoUFApIGFyZQ0KPiA+ID4gbm9ybWFsLiBUaGVuLCBGb3Jj ZWQgU3dpdGNoKEZTKSBjb21tYW5kIGlzIGlzc3VlZCBmb3IgbWFpbnRlbmFuY2Ugb24NCj4gPiB0 aGUNCj4gPiA+IFdQIGFuZCB0aGUgdHJhZmZpYyBtb3ZlcyBmcm9tIFdQIHRvIFBQLiBXaGVuIFNp Z25hbCBGYWlsIG9jY3VycyBvbg0KPiA+ID4gUFAsIHNlcnZpY2UgY2Fubm90IHJlY292ZXIgYW5k IGlzIGludGVycnVwdGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvcg0KPiA+IGV4YW1wbGUNCj4gPiA+ IGFzIGEgcmVzdWx0IG9mIGFjY2lkZW50YWxseSB1bi1wbHVnZ2luZyBhIFBQIGZpYmVyLg0KPiA+ ID4gVXNlIGNhc2UgQikgSWYgdGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFsIGZhaWwgb24gYSBw cm90ZWN0aW9uIHBhdGgNCj4gPiA+IChTRi1QKSxhbmQgRlMgY29tbWFuZCBpcyBpc3N1ZWQgYnkg YWNjaWRlbnQgdGhlIHRyYWZmaWMgb24gV1Agd2lsbA0KPiA+IG1vdmUNCj4gPiA+IHRvIFBQLiBU aGlzIHJlc3VsdHMgaW4gYW4gaW50ZXJydXB0aW9uIG9mIHNlcnZpY2UgZnJvbSB3aGljaCB5b3UN Cj4gPiA+IHdpbGwgbm90IGF1dG9tYXRpY2FsbHkgcmVjb3ZlciwgYmVjYXVzZSBQU0Mgc2hvdWxk IG5vdCBoYXZlIHN3aXRjaGVkDQo+ID4gPiB0aGUgdHJhZmZpYyBmcm9tIFdQIHRvIFBQLg0KPiA+ ID4gRGlzY3Vzc2lvbiBhYm91dCB0aGlzIGRyYWZ0IGxlZCB0byB0aGUgcHJvcG9zYWwgdG8gbW9k aWZ5IFJGQyA0NDI3DQo+ID4gdGhhdA0KPiA+ID4gd2FzICJ3cml0dGVuIGNvcnJlY3RseSB0aG91 Z2ggbGFja2luZyBpbiBkZXRhaWwgY2F1c2luZyBtaXMtDQo+ID4gPiBpbnRlcnByZXRhdGlvbiIg dGhhdCBsZWQgdG8gdGhlIGN1cnJlbnQgUFNDIHNldCBvZiBwcmlvcml0eSB0aGF0IHRoZQ0KPiA+ ID4gYWJvdmUgZHJhZnQgaXMgcHJvcG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBhbGlnbiB0byB0 aGUgcmVxdWlyZWQNCj4gPiA+IHRyYW5zcG9ydCBiZWhhdmlvci4gZHJhZnQtaGVsdm9vcnQtY2Nh bXAtZnMtcHJpb3JpdHktMDAgaGFzIGJlZW4NCj4gPiA+IHN1Ym1pdHRlZCB0byBDQ0FNUCBmb3Ig Y2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byBNYW51YWwNCj4gPiA+IFN3aXRj aCBhbmQgRm9yY2VkIFN3aXRjaCBhbmQgdGhlaXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJpb3JpdGll cy4NCj4gPiA+IFRoZSB3YXkgdGhpcyBiZWhhdmlvciBoYXMgdG8gYmUgaW5jb3Jwb3JhdGVkIGlu dG8gdGhlIFBTQyBoYXMgdG8gYmUNCj4gPiA+IGRpc2N1c3NlZC4gVGhlIHRleHQgcHJvcG9zZXMg dG8gcmVwbGFjZSB0aGUgY3VycmVudCBiZWhhdmlvciB3aXRoDQo+ID4gPiB0aGUgbmV3IG9uZS4g SWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHByb2NlZGUgaW4gdGhhdCB3YXkgdGhpcyBjYW4NCj4g PiA+IGJyaW5nDQo+ID4gdG8NCj4gPiA+IGEgc2ltcGxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIG9w ZXJhdGUgdGhlIHByb3RvY29sLg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtLQ0K PiA+ID4gZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAgY29udGFpbnMgdGhl IHVwZGF0ZXMgdG8NCj4gPiA+IFJGQzYzNzggdG8gY2hhbmdlIG5vbi1yZXZlcnRpdmUgb3BlcmF0 aW9ucyB0byBiZWhhdmVzIGluIHRoZSBzYW1lDQo+ID4gPiB3YXkgaXJyZXNwZWN0aXZlbHkgb2Yg dGhlIHRyaWdnZXIgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGZhdWx0IG9yDQo+ID4gb3BlcmF0 b3INCj4gPiA+IGNvbW1hbmQgRlMsIE1TKS4gQ29uc2VxdWVudGx5IGFuIG9wZXJhdG9yIGNvbW1h bmQsIE1hbnVhbCBTd2l0Y2ggdG8NCj4gPiA+IFdvcmtpbmcgKE1TLVcpIGEuay5hICJNYW51YWwg c3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIiBpcw0KPiA+IGFsc28NCj4gPiA+IGFk ZGVkIHRvIGVuYWJsZSB0aGlzIGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9m IHZpZXcsIE1TDQo+ID4gdG8NCj4gPiA+IHdvcmtpbmcgcGF0aCBoYXMgYWxzbyB0byBiZSBzdXBw b3J0ZWQgdG8gYmUgYWJsZSB0byBpbml0aWFsbHkgYWxpZ24NCj4gPiA+IGF0IGJvdGggc2lkZXMg aW4gY2FzZSBvZiBub24tcmV2ZXJ0aXZlIHN3aXRjaGluZyBtb2RlLiBNUyB0byB3b3JraW5nDQo+ ID4gPiBwYXRoIGlzIGRlZmluZWQgaW4gUkZDIDU2NTQsIHJlcXVpcmVtZW50IDgzLg0KPiA+ID4N Cj4gPiA+IFRoZSBwcm9wb3NlZCBNUy1XIGNvbW1hbmQgaXMgb2YgZXF1YWwgcHJpb3JpdHkgdG8g dGhlIGV4aXN0aW5nIE1TLVANCj4gPiA+IGNvbW1hbmQsIGFuZCB0aGVyZSBpcyB0ZXh0IHRvIGhh bmRsZSB0aGUgc2ltdWx0YW5lb3VzIG9yIHNlcXVlbnRpYWwNCj4gPiA+IG9jY3VycmVuY2Ugb2Yg dHdvIGVxdWFsLXByaW9yaXR5IGNvbW1hbmRzLiBUaGlzIGJlaGF2aW9yLCBhbHJlYWR5DQo+ID4g PiBhZG9wdGVkIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3JrIHByb3RlY3Rpb24gc3dpdGNoaW5n IHByb3RvY29sLA0KPiA+ID4gY2FuDQo+ID4gYmUNCj4gPiA+IHVzZWQgZm9yIG90aGVyIGFkZGl0 aW9uIHRvIHRoZSBwcm90b2NvbCBpbiB0aGUgZnV0dXJlLg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gPiAtLQ0KPiA+ID4gZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXNkLTAwIHByb3ZpZGVz IGV4dGVuc2lvbnMgdG8gdGhlIFBTQyBzdGF0ZQ0KPiA+ID4gbWFjaGluZSB0byBoYW5kbGUgU2ln bmFsIERlZ3JhZGUgKFNEKS4gSXQgZG9lcyBub3QgZGVmaW5lIFNEIG9yDQo+ID4gcHJvdmlkZQ0K PiA+ID4gc2NvcGUgYXJvdW5kIHdoZXJlIG9yIGhvdyBTRCBtYXkgYmUgdXNlZCBzaW1pbGFybHkg YXMgaXQgYWxyZWFkeQ0KPiA+IGhhcHBlbg0KPiA+ID4gaW4gdGhlIGRyYWZ0IGluIGhhbmRsaW5n IG90aGVyIGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZhaWx1cmUpLg0KPiA+ID4gSW4gTVBMUy1U UCBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBbUkZDNjM3Ml0sIGEgZmF1bHQgY29uZGl0aW9uDQo+ ID4gPiBpbmNsdWRlcyBib3RoIFNpZ25hbCBGYWlsIChTRikgYW5kIFNpZ25hbCBEZWdyYWRlIChT RCkgdGhhdCBjYW4gYmUNCj4gPiB1c2VkDQo+ID4gPiB0byB0cmlnZ2VyIHByb3RlY3Rpb24gc3dp dGNoaW5nLg0KPiA+ID4gV2hpbGUgdGhlIHN0YW5kYXJkaXphdGlvbiBsYWNrIG9mIGFuIFNEIGRl ZmluaXRpb24gYW5kIGRldGVjdGlvbg0KPiA+ID4gbWVjaGFuaXNtcywgdGhlIHJlbGV2YW50IGJl aGF2aW9ycyBpbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFjdGlvbnMNCj4gPiA+IG1heSBhbHJlYWR5 IGJlIGRlZmluZWQuDQo+ID4gPg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0tDQo+ID4gPiBk cmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0aGUgRVhFUi9SUiBj b21tYW5kcyB0bw0KPiA+ID4gdGVzdCBpZiB0aGUgQVBTIGNvbW11bmljYXRpb24gaXMgb3BlcmF0 aW5nIGNvcnJlY3RseS4gSW4gb3RoZXIgd29yZHMNCj4gPiA+IGJvdGggQVBTIHByb2Nlc3MgbG9n aWMgaW5jbHVkaW5nIHN0YXRlIG1hY2hpbmUgYW5kIEFQUyBjaGFubmVsIG9uDQo+ID4gPiBwcm90 ZWN0aW9uIHBhdGgsIHdpdGhvdXQgc2VydmljZSBkaXNydXB0aW9uIGFuZCB3aXRob3V0IGFmZmVj dGluZw0KPiA+ID4gYW55IHByb3RlY3Rpb24gb3BlcmF0aW9uLCB1bmxlc3MgdGhlIHByb3RlY3Rp b24gdHJhbnNwb3J0IGVudGl0eSBpcw0KPiA+ID4gaW4NCj4gPiB1c2UuDQo+ID4gPiBUaGlzIGNv bW1hbmQgaXMgZG9jdW1lbnRlZCBpbiBSODQgb2YgW1JGQzU2NTRdIGFuZCBpdCBpcyBwYXJ0IG9m DQo+ID4gPiBJVFUtVCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzLg0KPiA+ID4gQW4gYWx0ZXJuYXRp dmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiB0aGUgQXBwZW5kaXggQiBvZiBSRkM2Mzc4DQo+ ID4gdGhhdA0KPiA+ID4gdXRpbGl6ZXMgdGhlIExvY2tvdXQgb2YgUHJvdGVjdGlvbiAoTE8pIG9y IEZvcmNlZCBTd2l0Y2ggKEZTKSBpbg0KPiA+ID4gY29tYmluYXRpb24gb2YgT0FNIGZ1bmN0aW9u YWxpdGllcy4gSG93ZXZlciwgaXQgaGFzIHNvbWUgZnVuY3Rpb25hbA0KPiA+ID4gbGltaXRhdGlv biBhbmQgaGFzIGEgcG90ZW50aWFsIHJpc2sgb2YgbG9zaW5nIHRyYWZmaWMgYXMgYSBzaWduYWwN Cj4gPiA+IGZhaWx1cmUgbWlnaHQgb2NjdXIgZHVyaW5nIHRoZSBleGVyY2lzZSBvcGVyYXRpb24u IEluIHRoYXQgY2FzZSwgTE8NCj4gPiA+IG9yIEZTIGhhcyB0byBiZSBjYW5jZWxlZCB0byBhbGxv dyB0aGUgUFNDIHByb3RvY29sIHRvIHByb3ZpZGUgcHJvcGVyDQo+ID4gPiBzd2l0Y2hpbmcuDQo+ ID4gPiBBIGZ1cnRoZXIgYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiBkcmFm dC1vc2Jvcm5lLW1wbHMtDQo+ID4gcHNjLQ0KPiA+ID4gYWxpdmUtMDAgdGhhdCBhbnl3YXkgc2hv dyBzb21lIGZ1bmN0aW9uYWwgbGltaXRhdGlvbnMgYmVjYXVzZSBjYW5ub3QNCj4gPiA+IHZhbGlk YXRlIHRoZSBQU0Mgc3RhdGUgbWFjaGluZSBzdGF0dXMgYW5kIHByb2JhYmx5IHRoZSBMb2NhbCBS ZXF1ZXN0DQo+ID4gPiBsb2dpYy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGF1dGhvcnMgZW5j b3VyYWdlIHRoZSBJRVRGIGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFmdHMsDQo+ID4g PiBldmVudHVhbGx5IHByb3Bvc2luZyBvdGhlciBvcHRpb25zL21lY2hhbmlzbXMgdGhhdCBjYW4g c2F0aXNmeSB0aGUNCj4gPiBzYW1lDQo+ID4gPiByZXF1aXJlbWVudHMuDQo+ID4gPiBCZXN0IHJl Z2FyZHMsDQo+ID4gPiBBbGVzc2FuZHJvLCBIdXViLCBKZW9uZy1kb25nLCBUYWVrc2lkIFF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kNCj4gPiA+IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNj bHVzaXZhbWVudGUNCj4gPiBhbGxlDQo+ID4gPiBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNp b25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUNCj4gPiA+IGRlcml2YW50ZSBkYWxs YSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlDQo+ ID4gPiB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBw ZXIgZXJyb3JlIHNpZXRlDQo+ID4gPiBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1l ZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlDQo+ID4gPiBkaSBwcm92dmVkZXJlIGFs bGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQo+ID4gPg0KPiA+ID4gVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluDQo+ID4gPiBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHku DQo+ID4gPiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9k eSBlbHNlIGlzDQo+ID4gdW5hdXRob3Jpc2VkLg0KPiA+ID4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UNCj4gPiA+IGFuZCBh bnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRo YW5rcy4NCj4gPiA+DQo+ID4gPiByaXNwZXR0YSBsJ2FtYmllbnRlUmlzcGV0dGEgbCdhbWJpZW50 ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlDQo+ID4gbm9uDQo+ID4gPiDDqCBuZWNlc3Nh cmlvLg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0 DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo= From huubatwork@gmail.com Mon Jul 22 16:11:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4876E11E818C for ; Mon, 22 Jul 2013 16:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkpkMmZy5Fdd for ; Mon, 22 Jul 2013 16:11:23 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0203411E8185 for ; Mon, 22 Jul 2013 16:11:22 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so6577392wgg.20 for ; Mon, 22 Jul 2013 16:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=sWDyxJ7TfzdJSgYYhqPU9qEc5HLH2cMwVbFxRYiMQZ0=; b=HUrykOqamYOpWlZ1ia9aJOnechoN868b8m68yxeLpj4h0uOPzy39wrFzg6MV5ZAca/ 5SJwftA6nsI50iMJ2xONX0Fl1speu3T0fCZa9Il3Tdkkep+fme6ZTqoJHrvkegtF+pzX iMKVU9Pom7xztgsMYRvuNbdZlZTAuRILgOq2vE2N6AdVeYL4lTHMdcmqXZ14U3bl6lt7 qZICDCBulMzEVN8PpluxrO0kLqYEpCQh/NC0cm1hMTgBFlLHtyJEVfieXZ75NyhfQYgj NOFgL+aFq0hpgDJTNWk7X4HWfZIinhwr/UHq4Ysxi5YmhhlFAqlJk8/pz+0NAFnNgjER 7pmw== X-Received: by 10.180.108.129 with SMTP id hk1mr31029215wib.56.1374534681922; Mon, 22 Jul 2013 16:11:21 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id w4sm1989832wia.9.2013.07.22.16.11.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 16:11:21 -0700 (PDT) Message-ID: <51EDBC18.4060104@gmail.com> Date: Tue, 23 Jul 2013 01:11:20 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <51ED1541.70108@gmail.com> <20ECF67871905846A80F77F8F4A275721028A463@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721028A463@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements 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: Mon, 22 Jul 2013 23:11:24 -0000 Hello Eric, You replied: > Inline with EO#, trimmed a bit. My response inline [Huub2] >> >> There was atwo week ITU-T plenary meeting, and after that I took >> (and still have) a holiday. > > If you're on holiday, why are you working? [Huub2] It is too hot outside, and I had dug out my logbooks from before 1984, I want to to return to storage as soon as possible ^_^ > I thought that was a uniquely American trait. [Huub2] maybe it is infectious... > Is this stuff that much fun to you? :) [Huub2] my wife does not like the piles of logbooks and I like to share my knowledge > ... > >>> i) can you explain EXER at a higher level? I'm not looking for a >>> description of the state machine changes, and I'm not looking for the >>> one line "It allows the FSM to be tested". We have all of that in >>> the draft and in the equivalent ITU specs. >>> >>> What I'd like to understand about EXER is where it came from. The >>> ITU specs that define it are pretty hard to follow, they seem to >>> assume the reader already knows what EXER is and what problem it >>> solves. It feels very much like a mechanism used to catch a very >>> specific implementation bug, back when transport gear was far less >>> debuggable than what we have today. >> >> [Huub] EXER was not designed/intended to be used for bug finding >> although it will detect problems with implementation. >> >> [Huub] EXER was designed to verify that the state-machine at the >> far end is able to respond to APS/PSC messages it receives from >> the local end. >> Even though state-machines should be tested extensively, there is >> no 100% warranty. It can still have stopped due to external >> circumstances, be in a deadlock due to unforseen order of events, >> etc. > > EO# I agree with your last two statements. To me, though, that > very text is a reasonable argument against EXER. > There is no mechanism within a protocol which can guarantee that > the entire state machine is 100% perfect. [Huub2] indeed > A node could be able to respond to EXER/RR but be unable to process > a real failure properly, either due to bug or to (as you indicate) > some unforseen combination of external events. [Huub2] in the case you describe the node has to send periodical NR _AND_ respond to the EXER while not responding to a real SF/SD, this would be a very complex state-machine fault. > The class of problems which EXER can catch but which will not be > detectable by other means (e.g. CC/CV, see below) seems pretty small. [Huub2] the EXER will detect the most common "stuck-at" problems. > In the transport world, what sort of problems does EXER _actually find_? > I'm not asking about things it _could_ find, but things that it *does*. [Huub2] stuck-at, deadlock >> [Huub] note that APS/PSC should continue to operate even if no >> control plane is available. > > EO# I agree, but this is not relevant to the discussion at hand. > Lots of work was done in TP to ensure that it would function without > the ability to forward IP packets (which I think is what you mean by > 'no control plane'). None of that has anything to do with the set > of messages and states in PSC. [Huub2] I did mean to say that the exercise request caanot be sent via the control plane, so it should be in the dataplane. Since the APS/PSC state-machine is exercised the EXER command should be part of the APS/PSC protocol. >> The EXER is to enable an operator to >> take corrective action before a protection switch request fails >> and the 50ms switch time is not met. >> >>> No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, >>> ISIS) have explicit signaling in them just to ask the neighbor >>> whether it *would* be broken if if were, in the future, to be given a >>> particular input. >> >> [Huub] All these rely on a control plane, some of then include >> "keepalive" messages to see if the far end responds. > > EO# PSC has keepalives; see section 4.1 of rfc6378 - "The purpose of > the continual messages is to verify that the PSC session is still alive." [Huub2] it only proves that the state-machine can send NR priodically, it does not prove that it wil respond to any external/remote events. The EXER will give much more confidence of being alive. > The next sentence says "If no valid PSC message is received, over a > period of several continual messages intervals, the last valid > received message remains applicable." As an implementor, what that > means to me is that I time out only after the loss of a few > retransmissions. [Huub2] yes, this is part if the PDU validation process >>> Part of my reluctance to get behind EXER has been >>> that I don't feel comfortable with the idea of keeping a 30-year-old >>> workaround in a protocol. >> >> [Huub] it is NOT a workaround, it is an essential part of the >> protocol. > > EO# In a TDM world, I can see this point. APS is carried in the > frame header, so the receipt of an APS message doesn't mean that > there's any intelligence behind it as it could just be the hardware > repeating the last APS overhead that it sent. If a PSC message is > sent it must have been sent deliberately, as during steady state > we have periodic retransmissions. Do you agree? [Huub2] similarly hardware (or software) can contiouously send NR messages. So I agree that there is no difference between TDM and packet APS/PSC. >>> Is there more to it than that? Have I >>> misread and misunderstood EXER? Does modern transport gear ever >>> actually detect a problem via EXER/RR that wasn't obvious to the >>> operator using other means? >> >> [Huub] if there is no control plane I have no other means. >> What means are available to verify if a state-machine that is >> in a stable state is still functioning? > > EO# Periodic retransmission of current state by the remote side. > This performs the exact same function as a keepalive in any other > protocol, and I think we agree that the keepalive function in > protocols such as OSPF is sufficient to ensure the sanity of the > remote end. [Huub2] see above for the possibilty of stuck-at repeating only the NR message. > Many, many protocols use keepalives as a sort of belt-and-suspenders > failure detection mechanism. In the IP world these mechanisms are > far, far less useful than they used to be as we now have BFD. [Huub2] I would consider the "hello" message to have the same purpose as the EXER message: check if the remote BFD session is still up. > That brings us to CC/CV. Lots of work was done to ensure that it > did not require IP to function. I cannnot believe that any TP > implementation would ship without some sort of CC/CV, and isn't > that a strong enough mechanism to detect the failure of the remote > end? [Huub2] CC/CV only checks the conductivity and connectivity of a path It has no relation at all with the APS/PSC state-machine other than in case CC/CV causes a signal fail defect the resulting SF event triggers the APS/PSC state-machine. Regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From quintin.zhao@huawei.com Mon Jul 22 17:10:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99F921F8FF3 for ; Mon, 22 Jul 2013 17:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.015 X-Spam-Level: X-Spam-Status: No, score=-5.015 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NQUPWAkhk2q for ; Mon, 22 Jul 2013 17:10:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F00421F91B7 for ; Mon, 22 Jul 2013 17:10:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR55686; Tue, 23 Jul 2013 00:10:16 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 01:10:07 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 01:10:15 +0100 Received: from QZHAO (10.212.246.172) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.7; Mon, 22 Jul 2013 17:10:09 -0700 From: Quintin Zhao To: References: In-Reply-To: Date: Mon, 22 Jul 2013 20:10:29 -0400 Message-ID: <00c801ce8739$0b32d750$219885f0$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6Fe4igqBSdFuNNTQKOR1fI/CdOEwBuSQkA Content-Language: zh-cn X-Originating-IP: [10.212.246.172] X-CFilter-Loop: Reflected Cc: mpls@ietf.org Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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: Tue, 23 Jul 2013 00:10:21 -0000 Hi Eric, This is the requirement draft that documents the requirements and user cases for receiver driven multicast RSVP-TE: http://datatracker.ietf.org/doc/draft-jacquenet-mpls-rd-p2mp-te-requirements / Here let me elaborate a little more on the purpose of the receiver driven multicase rsvp te. mLDP has the advantage of a receiver-driven tree setup protocol, where it scales independently of the number of receivers joining the tree, but it doesn't provide both the traffic engineering and bandwidth guarantees. RSVP-TE P2MP has the advantage of both traffic engineering and bandwidth guarantees, but it is not flexible when the number of receivers joining the tree increases. Instead of deploying both the mLDP and RSVP-TE P2MP in the network to have the scalability for some applications, the traffic engineering and the bandwidth guarantees for some applications, it would be good for users to have one protocol deployed, with said protocol having both the advantages of mLDP and RSVP-TE P2MP. This is what receiver driven multicast rsvp is trying to solve. Regards, Quintin ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Jul 2013 15:02:12 -0400 From: Eric Rosen To: Richard Li Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt Message-ID: <16359.1374260532@erosen-linux> > But in MPLS, the multicast distribution tree (LSP) are built in a > totally different ordering. I am always struggling with why MPLS > should be doing it in a different way from PIM. If would be nice if > MPLS could unify with PIM with respect to MDT build-ups. Please see RFC 6388 (mLDP), which explains how to do receiver-driven tree setup for MPLS. The advantage of receiver-driven tree setup protocols is that they scale independently of the number of receivers that join the tree. That's because each node on the tree knows only about the nodes that are one hop away. This is the design center of PIM-SM -- the number of receivers joining the tree can increase without bound. The advantage of a head-end-driven tree setup protocol (like RSVP-TE P2MP) is that the head-end knows all the nodes on the tree, and thus can set up a more optimal tree. You probably wouldn't do this in an environment where the number of receivers can increase without bound. In that light, a receiver-driven version of RSVP-TE just doesn't seem to make much sense. What problem does it actually solve? From ryoo@etri.re.kr Mon Jul 22 20:04:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6259A11E81D5 for ; Mon, 22 Jul 2013 20:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yidxDmBapQUs for ; Mon, 22 Jul 2013 20:04:04 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 517AA11E81D4 for ; Mon, 22 Jul 2013 20:04:03 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Jul 2013 12:04:00 +0900 Received: from SMTP2.etri.info ([169.254.2.217]) by SMTP4.etri.info ([169.254.3.10]) with mapi id 14.01.0355.002; Tue, 23 Jul 2013 12:03:58 +0900 From: "Ryoo, Jeong-dong" To: "Eric Osborne (eosborne)" , D'Alessandro Alessandro Gerardo , "mpls@ietf.org" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQADK5f8AAaQNKX Date: Tue, 23 Jul 2013 03:03:57 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A27680488@SMTP2.etri.info> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info>, <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A27680488SMTP2etriinfo_" MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 23 Jul 2013 03:04:09 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A27680488SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEksIEVyaWMuDQoNClRoYW5rcyBmb3IgdGhlIGVtYWlsLg0KUGxlYXNlIHNlZSBpbmxpbmUgd2l0 aCBbSlJdDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIkVyaWMg T3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPg0KU2VudCA6IDIwMTMtMDct MjIgMjI6MzY6MjEgKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0cmku cmUua3I+LCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIDxhbGVzc2FuZHJvLmRhbGVz c2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ+LCBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0K Q2MgOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tKSA8aHV1Yi52 YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT4sIGh1dWJhdHdvcmtAZ21haWwuY29tIDxodXViYXR3b3Jr QGdtYWlsLmNvbT4NClN1YmplY3QgOiBSRTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxp Z25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0 IHJlcXVpcmVtZW50cw0KDQpIaSBKZW9uZy1kb25nLA0KDQpUaGFua3MgZm9yIHRoZSByZXBseS4g UGxlYXNlIHNlZSBpbmxpbmUgd2l0aCBFTyMuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOnJ5b29AZXRyaS5yZS5rcl0NCj4g U2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDQ6MTUgQU0NCj4gVG86IEVyaWMgT3Nib3JuZSAo ZW9zYm9ybmUpOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOw0KPiBtcGxzQGlldGYu b3JnDQo+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tKTsg aHV1YmF0d29ya0BnbWFpbC5jb20NCj4gU3ViamVjdDogUkU6IFttcGxzXSBwcm9wb3NlZCBkcmFm dHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcg0KPiBwcm90ZWN0aW9uIHByb3RvY29s IHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCj4NCj4gSGksIEVyaWMuDQo+DQo+IExldCBtZSBh bnN3ZXIgeW91ciAybmQgcXVlc3Rpb24gb24gU0QuDQo+DQo+IFNEIGRldGVjdGlvbiBtZXRob2Rz IGRlZmluZWQgb3IgcHJvcG9zZWQgZm9yIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MNCj4gY2Fu IGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czoNCj4gLSBCeSBPQU0gcGVyZm9ybWFuY2UgbW9uaXRv cmluZyB0b29sOg0KPiBTRCBpcyByYWlzZWQgaWYgcGFja2V0IGxvc3MgcmF0aW8gZXhjZWVkcyBh IHRocmVzaG9sZCBkdXJpbmcgYQ0KPiBtZWFzdXJlbWVudCBwZXJpb2QuDQo+IFRocmVzaG9sZCB2 YWx1ZSBhbmQgbWVhc3VyZW1lbnQgcGVyaW9kIGFyZSBjb25maWd1cmVkIGJ5IGFuIG5ldHdvcmsN Cj4gb3BlcmF0b3IuDQo+IFRoaXMgZGV0ZWN0aW9uIG1ldGhvZCBpcyBhbHJlYWR5IGRlZmluZWQg aW4gSVRVLVQgRy44MDIxIChFdGhlcm5ldA0KPiBlcXVpcG1lbnQgc3BlYy4pDQoNCg0KRU8jIFdo ZXJlPyBJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2 aW5nIGEgaGFyZCB0aW1lIGZpbmRpbmcgaXQuIEEgc2VhcmNoIGZvciBFVEhfQ0lfU1NEIGRvZXNu J3QgeWllbGQgbXVjaC4gSWYgSSBsb29rIGZvciAnc2lnbmFsIGRlZ3JhZGUnIEkgc2VlIHAuIDEz MSB3aGljaCBzYXlzIHRoYXQgdGhlIGFsZ29yaXRobSBpcyBkZWZpbmVkIGluIEcuODAzMS4gRy44 MDMxIHNheXMgJyBIb3cgdGhlc2UgZGVmZWN0cyBhcmUgZGV0ZWN0ZWQgaXMgdGhlIHN1YmplY3Qg b2YgdGhlIGVxdWlwbWVudCBSZWNvbW1lbmRhdGlvbnMnLiBJJ20gbG9va2luZyBmb3Igc29tZXRo aW5nIGxpa2UgIlNpZ25hbCBEZWdyYWRlIGlzIGRlZmluZWQgYXMgJGZvbyBwYWNrZXQgbG9zcyBv ciBDUkMgZmFpbHVyZSBvdmVyICRiYXIgdGltZSIuLi4ud2hhdCBoYXZlIEkgbWlzc2VkPw0KW0pS XSBZZXMsIEkga25vdyB0aGF0IGl0IGlzIHJhdGhlciBkaWZmaWN1bHQgdG8gZmluZCB3aGF0IHdl IG5lZWQgZnJvbSB0aGF0IGRvY3VtZW50LiBJbiBUYWJsZSA2LTIsIGRlZmVjdCBkZXRlY3Rpb24g YW5kIGNsZWFyYW5jZSBmb3IgZERFRyAoZGVncmFkZWQgc2lnbmFsIGRlZmVjdCkgYXJlIHNob3du LCBhbmQgQ2xhdXNlIDYuMS4zLjQgaGFzIGRldGFpbGVkIHRleHQgZGVzY3JpcHRpb24gYW5kIGZs b3cgY2hhcnQgKEZpZ3VyZSA2LTMpIGZvciBkZXRlY3Rpb24gYW5kIGNsZWFyYW5jZSBmb3IgREVH LiBJIGd1ZXNzIHRoaXMgd291bGQgYmUgdGhlIG9uZSB0aGF0IHlvdSB3ZXJlIGxvb2tpbmcgZm9y Lg0KSWYgeW91IHdhbnQgdG8gc2VhcmNoIGZ1cnRoZXIsIHRoZW4gaXQgd2lsbCBnbyBsaWtlOiBk REVHIC0tPiBFVEhfQUlfVFNEIC0tPiBFVEhfQ0lfU1NELg0KDQoNCj4gYW5kIHRoZSBlcXVpcG1l bnQgc3BlYyBmb3IgTVBMUy1UUCBjYW4gZWFzaWx5IGZvbGxvdyB0aGUgc2FtZQ0KPiBkZWZpbml0 aW9uLg0KPiAtIEJ5IHNlcnZlciBsYXllciBpbmRpY2F0aW9uOg0KPiBTRCBpcyByYWlzZWQgaWYg YSBzZXJ2ZXIgbGF5ZXIgYmVsb3cgTVBMUy1UUCByZXBvcnRzIFNEIGNvbmRpdGlvbiBvbg0KPiBp dHMgb3duIGxheWVyLg0KPiAtIEJ5IENDTSBwYWNrZXQgY291bnRpbmc6DQo+IFNEIGlzIHJhaXNl ZCBpZiB0aGUgbG9zcyByYXRpbyBvZiBDQ00gcGFja2V0cyBleGNlZWRzIGEgdGhyZXNob2xkDQo+ IGR1cmluZyBhIG1lYXN1cmVtZW50IHBlcmlvZC4NCj4NCj4gUmVnYXJkbGVzcyBvZiBob3cgdG8g ZGV0ZWN0IFNELCBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZG9jdW1lbnRzDQo+IHNob3VsZCBk ZXNjcmliZSB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb3BlcmF0aW9uIG9uY2Ugc3VjaCBhIFNE IGlzDQo+IGRlY2xhcmVkLg0KPg0KLi4uDQo+IFJlZ2FyZGluZyB0aGUgbXVsdGlwbGUgbGV2ZWxz IG9mIFNEOg0KPiBJdCBpcyBjZXJ0YWlubHkgcG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxl dmVscyBvZiBTRC4NCj4gQnV0LCBhcyBmYXIgYXMgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlz IGNvbmNlcm5lZCwgaXQganVzdCBuZWVkcyB0bw0KPiBrbm93IGlmIFNEIGlzIHNpZ25hbGVkIHRv IHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb2Nlc3Mgb3Igbm90Lg0KPiBJdCB3b3VsZCBiZSBhIG5l dHdvcmsgb3BlcmF0b3IncyBjaG9pY2UgYXQgd2hhdCBsZXZlbCBvZiBTRCBoZSB3YW50cyBoaXMN Cj4gbmV0d29yayBwcm90ZWN0aW9uIHRvIHN3aXRjaG92ZXIuDQo+IEluIG90aGVyIHdvcmRzLCB3 aGF0IHRyaWdnZXJzIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIFNEIG9yIG5vIFNELiBJdCBpcw0K PiB5ZXMgb3Igbm8gZGVjaXNpb24uDQoNCg0KRU8jIEkgYW0gbm90IGF3YXJlIG9mIGFueSBkb2N1 bWVudCB3aGljaCBzdWdnZXN0cyB0aGF0IGEgc2VydmVyIGxheWVyIFNEIHNob3VsZCBiZSB0cmVh dGVkIGFzIGEgY2xpZW50IGxheWVyIFNELiBJbiB0aGUgSVAgd29ybGQsIGlmIHdlIGhhdmUgU0Qg b24gYSB0cmFuc3BvcnQgaW50ZXJmYWNlIHRoYXQgaXMgZ2VuZXJhbGx5IHVzZWQgdG8gYnJpbmcg dGhlIGludGVyZmFjZSBkb3duIChpLmUuIFNGKS4gVGhpcyBpcyB0aGUgc29ydCBvZiB0aGluZyBJ J2QgbGlrZSB0byBzZWUgaW4gbW9yZSBkZXRhaWwsIGFzIFNEIGluIHRoZSBwYWNrZXQgd29ybGQg aXMgYSBuZXcgY29uY2VwdCBhbmQgd2UgY2FuJ3QganVzdCBhc3N1bWUgdGhhdCBpdCB3aWxsIHdv cmsgdGhlIHNhbWUgZXZlcnl3aGVyZSBiZWNhdXNlIHdlIGRlZmluZSBzdGF0ZSBtYWNoaW5lIHBv aW50cyBmb3IgaXQuDQpUaGUgcG9pbnQgYWJvdXQgQ0NNIGlzIGEgZ29vZCBvbmUuIExldCdzIHNh eSB3ZSBjb21lIHVwIHdpdGggYSBjbGV2ZXIgU0QgbWVjaGFuaXNtIHdpdGggdHdvIHRocmVzaG9s ZHMsIGNhbGwgdGhlbSBtYWpvciBhbmQgbWlub3IuIEZvciBkaXNjdXNzaW9uIHB1cnBvc2VzIHRo ZXkgY291bGQgYmUgc2ltcGxlIGVycm9yIHJhdGlvcywgZS5nLiAxOjEwXjYgYW5kIDE6MTBeOS4g QnV0IHRoZXkgY291bGQgYmUgbW9yZSBwb3dlcmZ1bCB0aGFuIHRoYXQgKGZsb3cgdHlwZSwgZmxv dyBsZW5ndGgsIGVycm9yIGJ1cnN0IHNpemUsIGV0YykuDQoNCklmIHdlIHdhbnQgdG8gaGF2ZSBT RC1NYWpvciBhbmQgU0QtTWlub3IgaW5wdXRzIGFzIHNlcGFyYXRlIHRyaWdnZXJzIGZvciBQU0Ms IHdlIG1heSB3YW50IHRoZW0gYXQgZGlmZmVyZW50IHBvaW50cy4gUGVyaGFwcyAobGVhdmluZyBv dXQgdGhlIFdvcmtpbmcgcGF0aCBmb3IgZWFzZSBvZiByZWFkaW5nKQ0KDQpMTw0KRlMNClNGLVAN ClNELVAtTWFqb3INCk1TDQpTRC1QLU1pbm9yDQoNCg0KVGhpcyBzZWVtcyBsaWtlIGEgcGVyZmVj dGx5IHJlYXNvbmFibGUgdGhpbmcgdG8gd2FudC4NCg0KRXZlbiBpZiB3ZSBkb24ndCBoYXZlIG11 bHRpLXRpZXIgU0QsIGV2ZW4gdGhlIHNpbmdsZS10aWVyIFNEIG5lZWRzIHRvIGJlIGRlZmluZWQg YmVmb3JlIHdlIGNhbiBkZWNpZGUgaG93IHRvIHJlc3BvbmQgdG8gaXQuDQpbSlJdIFRoZSBzZXJ2 ZXIgbGF5ZXIgU0QgaGFzIGJlZW4gYSBwcm9wb3NhbCwgYW5kIEkgaGF2ZSBiZWVuIHRvbGQgdGhh dCB0aGVyZSBpcyBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbi4gQnV0LCB0aGlzIGlzIG91dHNp ZGUgdGhlIHNjb3BlIG9mIFBTQy4gV2hhdCB3ZSBuZWVkIHRvIGNhcmUgaXMgd2hldGhlciBTRCBp cyBkZWNsYXJlZC9jbGVhcmVkIG9uIHdvcmtpbmcgcGF0aCBhbmQgd2hldGhlciBTRCBpcyBkZWNs ZWFyZWQvY2xlYXJlZCBvbiBwcm90ZWN0aW9uIHBhdGguDQpJZiBhbnkgU0QgZGV0ZWN0aW9uIG1l Y2hhbmlzbSBjYW4gc2lnbmFsIHRoaXMgaW5mb3JtYXRpb24gdG8gUFNDLCBQU0MgaXMgcmVhZHkg dG8gcHJvdmlkZSB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQoNCltKUl0gUmVnYXJkaW5nIG11 bHRpLXRpZXIgU0QsIHllcywgSSBhZ3JlZSB3aXRoIHlvdSBpbiBwcmluY2lwbGUuDQpDZXJ0YWlu bHksIGlmIHByb3RlY3Rpb24gYWdhaW50IFNELXNlY29uZCBpcyByZXF1aXJlZCwgd2UgY2FuIGFk ZCBhbnRoZXIgcmVxdWVzdCBjb2RlcG9pbnQgYW5kIHByaW9yaXR5IGxldmVsIGZvciBpdC4NCkJ1 dCwgdGhhdCBkb2Vzbid0IG1lYW4gd2UgY2Fubm90IGRlZmluZSBwcm90ZWN0aW9uIGZvciB0aGUg Zmlyc3QgU0QuDQpUaGVyZSBoYXMgYmVlbiBhIHN0cm9uZyBkZW1hbmQgZm9yIHByb3RlY3Rpb24g YWdhaW5zdCBTRC4NClNvIGZhciwgSSBoYXZlbid0IHNlZW4gYW55IGRlbWFuZCBmb3IgcHJvdGVj dGlvbiBhZ2FpbnN0IHRoZSAybmQgU0QNCmFuZCBJIGNhbm5vdCBpbWFnaW5lIGhvdyB0aGUgcHJv dGVjdGlvbiBhZ2FpbnN0IDJuZCBTRCB3aWxsIGJlIGFjY2VwdGVkLCBjb25zaWRlcmluZyB0aGUg cHJvdGVjdGlvbiBhZ2FpbnN0IHRoZSBmaXJzdCBhbmQgb25seSBvbmUgU0QgaXMgaGF2aW5nIHRo aXMgbXVjaCBkaWZmaWN1bHQgdGltZS4NCg0KDQo+IFRoZSBwcm9wb3NlZCBkcmFmdCBjb3ZlcnMg U0QtdHJpZ2dlcmVkIHByb3RlY3Rpb24gbm8gbWF0dGVyIHdoYXQga2luZHMNCj4gb2YgU0QgZGV0 ZWN0aW9uIG1ldGhvZHMgYXJlIHVzZWQuDQo+DQo+DQo+IFNGIGNhbiBhbHNvIGJlIHZpZXdlZCBh cyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFzIHRoZSBuZXR3b3JrDQo+IG9wZXJhdG9y IGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ00gbWVz c2FnZXMuDQoNCg0KRU8jDQpJJ20gbm90IHN1cmUgd2hhdCB0aGF0IHdvdWxkIGxvb2sgbGlrZS4g J0ZhaWwnIGlzIGEgcHJldHR5IGJpbmFyeSB0aGluZy4gJ0RlZ3JhZGUnIGlzIGEgY29udGludW91 cyB2YXJpYWJsZSwgYXMgaXQgY2FuIGJlIGFueXRoaW5nIGZyb20gJ2EgbGl0dGxlIGJhZCcgdG8g YSAnYSB3aG9sZSBsb3Qgb2YgYmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuDQpbSlJdIEFnYWluLCBF cmljLiBXaGF0IHdlIG5lZWQgaXMgd2hldGhlciBTRCBpcyBkZWNsYXJlZC9jbGVhcmVkIG9uIHdv cmtpbmcgcGF0aCBhbmQgd2hldGhlciBTRCBpcyBkZWNsZWFyZWQvY2xlYXJlZCBvbiBwcm90ZWN0 aW9uIHBhdGguDQpJdCB3b3VsZCBiZSBvcGVyYXRvcidzIGNob2ljZSBhdCB3aGF0IGxldmVsIG9m IGRlZ3JhZGUgaGUgd2FudHMgaGlzIHRyYWZmaWMgdG8gYmUgc3dpdGNoZWQgb3Zlci4NCg0KDQo+ IElmIENDTSBpcyBkaXNhYmxlZCwgQUlTIGZyb20gYSBzZXJ2ZXIgbGF5ZXIgY2FuIGJlIHVzZWQg YXMgYSB0cmlnZ2VyIGZvcg0KPiBwcm90ZWN0aW9uIHN3aXRjaGluZy4gU28gYW5kIHNvIGZvcnRo Lg0KDQpFTyMgQUlTIGZyb20gdGhlIHNlcnZlciBsYXllciBvbmx5IGdldHMgeW91IFNEIGZyb20g dGhlIGZpcnN0IGhvcCBvZiB0aGUgdW5kZXJseWluZyBzZXJ2ZXIgcGF0aC4NCltKUl0gSXQgZGVw ZW5kcyBvbiB3aGVyZSB5b3Ugd2FudCB0byBwdXQgTUVQIGZvciBtb25pdG9yaW5nIFNEIGluIHRo ZSBzZXJ2ZXIgbGF5ZXIuDQpBSVMgZnJvbSB0aGUgc2VydmVyIGxheWVyIGNhbiBiZSBwcm9wYWdh dGVkIHRvIGNsaWVudCBsYXllciBNRVAgbm9kZSwgd2hpY2ggcnVucyBwcm90ZWN0aW9uIHN3aXRj aGluZyBwcm9jZXNzLCBpbiBtdWx0aXBsZSBob3BzLg0KDQoNCmVyaWMNCg0KPiBIb3dldmVyLCBw cm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGRldGVj dCBTRg0KPiBpbiBhbnl3aGVyZS4NCj4gU2ltaWxhcnksIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRv Y3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgbWFudWFsDQo+IHN3aXRjaCBhbmQgZm9yY2VkIHN3 aXRjaCBjb21tYW5kcw0KPiBhcmUgaW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW0gYW5k IHNpZ25hbGVkIHRvIHByb3RlY3Rpb24NCj4gc3dpdGNoaW5nIHByb2Nlc3MuDQo+DQo+IEFnYWlu LCBpbiBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlvbiBjYW4gYWNjb21tb2Rh dGUgYW55IFNEDQo+IGRldGVjdGlvbiBtZXRob2RzLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+ IEplb25nLWRvbmcNCj4NCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4NCj4gRnJvbSA6ICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSINCj4gU2VudCA6 IDIwMTMtMDctMjAgMDI6NDg6MjggKCArMDk6MDAgKQ0KPiBUbyA6IEQnQWxlc3NhbmRybyBBbGVz c2FuZHJvIEdlcmFyZG8NCj4gLCBtcGxzQGlldGYub3JnDQo+IENjIDogSHV1YiBoZWx2b29ydCAo aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSkNCj4gLCBodXViYXR3b3JrQGdtYWlsLmNvbQ0K Pg0KPiBTdWJqZWN0IDogUmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1Q TFMtVFAgUFNDIGxpbmVhcg0KPiBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1 aXJlbWVudHMNCj4NCj4NCj4gSGkgQWxlc3NhbmRyby0NCj4NCj4gVGhhbmtzIGZvciB0aGlzOyB0 aGUgdGhyZWFkcyBJIHN0YXJ0ZWQgc29tZSB0aW1lIGJhY2sgc2VlbSB0byBoYXZlIGRpZWQNCj4g ZG93biwgaXQncyBnb29kIHRvIGdldCB0aGVtIGdvaW5nIGFnYWluLg0KPiBJIGhhdmUgdHdvIHRo aW5ncyBJIG5ldmVyIHF1aXRlIHVuZGVyc3Rvb2QsIGNhbiB5b3UgY2xhcmlmeSB0aGVtIGZvciBt ZT8NCj4NCj4gaSkgY2FuIHlvdSBleHBsYWluIEVYRVIgYXQgYSBoaWdoZXIgbGV2ZWw/IEknbSBu b3QgbG9va2luZyBmb3IgYQ0KPiBkZXNjcmlwdGlvbiBvZiB0aGUgc3RhdGUgbWFjaGluZSBjaGFu Z2VzLCBhbmQgSSdtIG5vdCBsb29raW5nIGZvciB0aGUNCj4gb25lIGxpbmUgIkl0IGFsbG93cyB0 aGUgRlNNIHRvIGJlIHRlc3RlZCIuIFdlIGhhdmUgYWxsIG9mIHRoYXQgaW4gdGhlDQo+IGRyYWZ0 IGFuZCBpbiB0aGUgZXF1aXZhbGVudCBJVFUgc3BlY3MuDQo+DQo+IFdoYXQgSSdkIGxpa2UgdG8g dW5kZXJzdGFuZCBhYm91dCBFWEVSIGlzIHdoZXJlIGl0IGNhbWUgZnJvbS4gVGhlIElUVQ0KPiBz cGVjcyB0aGF0IGRlZmluZSBpdCBhcmUgcHJldHR5IGhhcmQgdG8gZm9sbG93LCB0aGV5IHNlZW0g dG8gYXNzdW1lIHRoZQ0KPiByZWFkZXIgYWxyZWFkeSBrbm93cyB3aGF0IEVYRVIgaXMgYW5kIHdo YXQgcHJvYmxlbSBpdCBzb2x2ZXMuIEl0IGZlZWxzDQo+IHZlcnkgbXVjaCBsaWtlIGEgbWVjaGFu aXNtIHVzZWQgdG8gY2F0Y2ggYSB2ZXJ5IHNwZWNpZmljIGltcGxlbWVudGF0aW9uDQo+IGJ1Zywg YmFjayB3aGVuIHRyYW5zcG9ydCBnZWFyIHdhcyBmYXIgbGVzcyBkZWJ1Z2dhYmxlIHRoYW4gd2hh dCB3ZSBoYXZlDQo+IHRvZGF5Lg0KPg0KPiBObyBvdGhlciBzdGF0ZSBtYWNoaW5lcyB0aGF0IEkn bSBmYW1pbGlhciB3aXRoIChSU1ZQLCBMRFAsIEJHUCwgT1NQRiwNCj4gSVNJUykgaGF2ZSBleHBs aWNpdCBzaWduYWxpbmcgaW4gdGhlbSBqdXN0IHRvIGFzayB0aGUgbmVpZ2hib3Igd2hldGhlcg0K PiBpdCAqd291bGQqIGJlIGJyb2tlbiBpZiBpZiB3ZXJlLCBpbiB0aGUgZnV0dXJlLCB0byBiZSBn aXZlbiBhIHBhcnRpY3VsYXINCj4gaW5wdXQuIFBhcnQgb2YgbXkgcmVsdWN0YW5jZSB0byBnZXQg YmVoaW5kIEVYRVIgaGFzIGJlZW4gdGhhdCBJIGRvbid0DQo+IGZlZWwgY29tZm9ydGFibGUgd2l0 aCB0aGUgaWRlYSBvZiBrZWVwaW5nIGEgMzAteWVhci1vbGQgd29ya2Fyb3VuZCBpbiBhDQo+IHBy b3RvY29sLiBJcyB0aGVyZSBtb3JlIHRvIGl0IHRoYW4gdGhhdD8gSGF2ZSBJIG1pc3JlYWQgYW5k DQo+IG1pc3VuZGVyc3Rvb2QgRVhFUj8gRG9lcyBtb2Rlcm4gdHJhbnNwb3J0IGdlYXIgZXZlciBh Y3R1YWxseSBkZXRlY3QgYQ0KPiBwcm9ibGVtIHZpYSBFWEVSL1JSIHRoYXQgd2Fzbid0IG9idmlv dXMgdG8gdGhlIG9wZXJhdG9yIHVzaW5nIG90aGVyDQo+IG1lYW5zPw0KPg0KPg0KPiBpaSkgV2h5 IHRoZSBwdXNoIHRvIHN0YW5kYXJkaXplIHRoZSBTRCBzdGF0ZSBjaGFuZ2VzIGJlZm9yZSB3ZSd2 ZQ0KPiBkZWZpbmVkIFNEPyBJIGNlcnRhaW5seSBhZ3JlZSB0aGF0IGhhbmRsaW5nIHNpZ25hbCBk ZWdyYWRlIGlzIGEgZ29vZA0KPiBpZGVhLCBidXQgY29taW5nIHVwIHdpdGggYSBkZWZpbml0aW9u IGZvciBpdCBoYXMgYmVlbiBjaGFsbGVuZ2luZy4gV2hhdA0KPiBoYXBwZW5zIGlmIHdlIGNoYW5n ZSB0aGUgRlNNIHRvIGhhbmRsZSBpdCwgdGhlbiBjb21lIHVwIHdpdGggc29tZXRoaW5nDQo+IG1v cmUgc29waGlzdGljYXRlZCAoc2F5LCBtdWx0aXBsZSBsZXZlbHMgb2YgU0QpIHRoYXQgZG9lc24n dCBxdWl0ZSBmaXQNCj4gd2l0aCB0aGUgRlNNIGNoYW5nZXM/DQo+DQo+DQo+DQo+IHRoYW5rcyEN Cj4NCj4NCj4NCj4NCj4NCj4gZXJpYw0KPg0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YNCj4gPiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBH ZXJhcmRvDQo+ID4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDM6MjMgUE0NCj4gPiBU bzogbXBsc0BpZXRmLm9yZw0KPiA+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29y dEBodWF3ZWkuY29tKTsgaHV1YmF0d29ya0BnbWFpbC5jb20NCj4gPiBTdWJqZWN0OiBbbXBsc10g cHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXINCj4gPiBwcm90 ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCj4gPg0KPiA+IERlYXIg YWxsLA0KPiA+IHdlIHdvdWxkIGxpa2Ugc29jaWFsaXppbmcgdGhlIGhlcmViZWxvdyBkcmFmdHMg dGhhdCB3ZXJlIHN1Ym1pdHRlZA0KPiBzb21lDQo+ID4gbW9udGhzIGFnbyB3aXRoIHRoZSBhaW0g dG8gYWxpZ24gUFNDIHByb3RvY29sIChSRkMgNjM3OCkgdG8gSVRVLVQNCj4gPiB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzLiBJIHdvdWxkIGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBhYm91dCB0aGUN Cj4gPiBwcm9wb3NlZCBtZWNoYW5pc21zIGFuZCBiZWhhdmlvdXJzLg0KPiA+DQo+ID4gZHJhZnQt cmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwDQo+ID4gZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5v bi1yZXZlcnRpdmUtMDANCj4gPiBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDANCj4gPiBkcmFm dC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIC8gZHJhZnQtb3Nib3JuZS1tcGxzLXBzYy1hbGl2ZS0w MA0KPiA+DQo+ID4gVGhlIGFib3ZlIGRyYWZ0cyBjb3ZlciBtb3N0IG9mIGl0ZW1zIGhpZ2hsaWdo dGVkIGluIElUVS1UIGxpYWlzb25zDQo+IGFib3V0DQo+ID4gUFNDIGFuZCB0aGV5IHByb3Bvc2Ug c29sdXRpb25zIGluIGxpbmUgd2l0aCBNUExTLVRQIHRyYW5zcG9ydA0KPiA+IHJlcXVpcmVtZW50 cy4NCj4gPiBBIGxpc3Qgb2YgbWFpbiBsaWFpc29ucyBleGNoYW5nZWQgYmV0d2VlbiBJVFUtVCBh bmQgSUVURiB3aXRoIHRoZSBhaW0NCj4gdG8NCj4gPiBhbGlnbiBQU0MgYmVoYXZpb3VzIHdpdGgg SVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBmb3IgbGluZWFyDQo+ID4gcHJvdGVjdGlvbiBh cmUgZ2l2ZW4gYmVsb3c6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u LzExNjIvIChKdW5lIDIwMTIpDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFp c29uLzEyMDUvDQo+ID4gKE9jdG9iZXIgMjAxMikNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTIyOS8NCj4gPiAoSmFudWFyeSAyMDEzKQ0KPiA+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjM0Lw0KPiA+IChGZWJydWFyeSAyMDEzKQ0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjU2Lw0KPiA+IChNYXkgMjAx MykNCj4gPg0KPiA+IFNvbWUgZGV0YWlscyBhYm91IHRoZSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFs aWduIFBTQyBiZWhhdmlvdXIgd2l0aA0KPiA+IHRyYW5zcG9ydCByZXF1aXJlbWVudHM6DQo+ID4N Cj4gPiBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDAgcHJvcG9zZXMgc3dhcHBpbmcg dGhlIHByaW9yaXRpZXMNCj4gPiBiZXR3ZWVuIEZTIGFuZCBTRi1QIChzZWUgc2VjdGlvbiA0LjMu MiBvZiByZmM2Mzc4KS4NCj4gPiBBbW9uZyB0aGUgb3RoZXJzLCBiZWhhdmlvcnMgdGhhdCB3aWxs IGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkDQo+IHVwZGF0ZQ0KPiA+IGFyZToNCj4gPiBVc2Ug Y2FzZSBBKSBBdCBmaXJzdCwgd29ya2luZyBwYXRoKFdQKSBhbmQgcHJvdGVjdGlvbiBwYXRoKFBQ KSBhcmUNCj4gPiBub3JtYWwuIFRoZW4sIEZvcmNlZCBTd2l0Y2goRlMpIGNvbW1hbmQgaXMgaXNz dWVkIGZvciBtYWludGVuYW5jZSBvbg0KPiB0aGUNCj4gPiBXUCBhbmQgdGhlIHRyYWZmaWMgbW92 ZXMgZnJvbSBXUCB0byBQUC4gV2hlbiBTaWduYWwgRmFpbCBvY2N1cnMgb24gUFAsDQo+ID4gc2Vy dmljZSBjYW5ub3QgcmVjb3ZlciBhbmQgaXMgaW50ZXJydXB0ZWQuIFRoaXMgY291bGQgb2NjdXIg Zm9yDQo+IGV4YW1wbGUNCj4gPiBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dp bmcgYSBQUCBmaWJlci4NCj4gPiBVc2UgY2FzZSBCKSBJZiB0aGVyZSBpcyBhbiBleGlzdGluZyBz aWduYWwgZmFpbCBvbiBhIHByb3RlY3Rpb24gcGF0aA0KPiA+IChTRi1QKSxhbmQgRlMgY29tbWFu ZCBpcyBpc3N1ZWQgYnkgYWNjaWRlbnQgdGhlIHRyYWZmaWMgb24gV1Agd2lsbA0KPiBtb3ZlDQo+ ID4gdG8gUFAuIFRoaXMgcmVzdWx0cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9t IHdoaWNoIHlvdSB3aWxsDQo+ID4gbm90IGF1dG9tYXRpY2FsbHkgcmVjb3ZlciwgYmVjYXVzZSBQ U0Mgc2hvdWxkIG5vdCBoYXZlIHN3aXRjaGVkIHRoZQ0KPiA+IHRyYWZmaWMgZnJvbSBXUCB0byBQ UC4NCj4gPiBEaXNjdXNzaW9uIGFib3V0IHRoaXMgZHJhZnQgbGVkIHRvIHRoZSBwcm9wb3NhbCB0 byBtb2RpZnkgUkZDIDQ0MjcNCj4gdGhhdA0KPiA+IHdhcyAid3JpdHRlbiBjb3JyZWN0bHkgdGhv dWdoIGxhY2tpbmcgaW4gZGV0YWlsIGNhdXNpbmcgbWlzLQ0KPiA+IGludGVycHJldGF0aW9uIiB0 aGF0IGxlZCB0byB0aGUgY3VycmVudCBQU0Mgc2V0IG9mIHByaW9yaXR5IHRoYXQgdGhlDQo+ID4g YWJvdmUgZHJhZnQgaXMgcHJvcG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBhbGlnbiB0byB0aGUg cmVxdWlyZWQNCj4gPiB0cmFuc3BvcnQgYmVoYXZpb3IuIGRyYWZ0LWhlbHZvb3J0LWNjYW1wLWZz LXByaW9yaXR5LTAwIGhhcyBiZWVuDQo+ID4gc3VibWl0dGVkIHRvIENDQU1QIGZvciBjbGFyaWZ5 aW5nIHRoZSBkZWZpbml0aW9ucyByZWxhdGVkIHRvIE1hbnVhbA0KPiA+IFN3aXRjaCBhbmQgRm9y Y2VkIFN3aXRjaCBhbmQgdGhlaXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJpb3JpdGllcy4NCj4gPiBU aGUgd2F5IHRoaXMgYmVoYXZpb3IgaGFzIHRvIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBQU0Mg aGFzIHRvIGJlDQo+ID4gZGlzY3Vzc2VkLiBUaGUgdGV4dCBwcm9wb3NlcyB0byByZXBsYWNlIHRo ZSBjdXJyZW50IGJlaGF2aW9yIHdpdGggdGhlDQo+ID4gbmV3IG9uZS4gSWYgdGhlcmUgaXMgY29u c2Vuc3VzIHRvIHByb2NlZGUgaW4gdGhhdCB3YXkgdGhpcyBjYW4gYnJpbmcNCj4gdG8NCj4gPiBh IHNpbXBsZSBhbmQgZWZmZWN0aXZlIHdheSB0byBvcGVyYXRlIHRoZSBwcm90b2NvbC4NCj4gPg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2 ZS0wMCBjb250YWlucyB0aGUgdXBkYXRlcyB0byBSRkM2Mzc4DQo+ID4gdG8gY2hhbmdlIG5vbi1y ZXZlcnRpdmUgb3BlcmF0aW9ucyB0byBiZWhhdmVzIGluIHRoZSBzYW1lIHdheQ0KPiA+IGlycmVz cGVjdGl2ZWx5IG9mIHRoZSB0cmlnZ2VyIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIChmYXVsdCBv cg0KPiBvcGVyYXRvcg0KPiA+IGNvbW1hbmQgRlMsIE1TKS4gQ29uc2VxdWVudGx5IGFuIG9wZXJh dG9yIGNvbW1hbmQsIE1hbnVhbCBTd2l0Y2ggdG8NCj4gPiBXb3JraW5nIChNUy1XKSBhLmsuYSAi TWFudWFsIHN3aXRjaC1vdmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiIgaXMNCj4gYWxzbw0KPiA+ IGFkZGVkIHRvIGVuYWJsZSB0aGlzIGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50 IG9mIHZpZXcsIE1TDQo+IHRvDQo+ID4gd29ya2luZyBwYXRoIGhhcyBhbHNvIHRvIGJlIHN1cHBv cnRlZCB0byBiZSBhYmxlIHRvIGluaXRpYWxseSBhbGlnbiBhdA0KPiA+IGJvdGggc2lkZXMgaW4g Y2FzZSBvZiBub24tcmV2ZXJ0aXZlIHN3aXRjaGluZyBtb2RlLiBNUyB0byB3b3JraW5nIHBhdGgN Cj4gPiBpcyBkZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My4NCj4gPg0KPiA+IFRo ZSBwcm9wb3NlZCBNUy1XIGNvbW1hbmQgaXMgb2YgZXF1YWwgcHJpb3JpdHkgdG8gdGhlIGV4aXN0 aW5nIE1TLVANCj4gPiBjb21tYW5kLCBhbmQgdGhlcmUgaXMgdGV4dCB0byBoYW5kbGUgdGhlIHNp bXVsdGFuZW91cyBvciBzZXF1ZW50aWFsDQo+ID4gb2NjdXJyZW5jZSBvZiB0d28gZXF1YWwtcHJp b3JpdHkgY29tbWFuZHMuIFRoaXMgYmVoYXZpb3IsIGFscmVhZHkNCj4gPiBhZG9wdGVkIGluIG90 aGVyIHRyYW5zcG9ydCBuZXR3b3JrIHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb3RvY29sLCBjYW4N Cj4gYmUNCj4gPiB1c2VkIGZvciBvdGhlciBhZGRpdGlvbiB0byB0aGUgcHJvdG9jb2wgaW4gdGhl IGZ1dHVyZS4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBkcmFmdC1yaGQtbXBscy10cC1w c2Mtc2QtMDAgcHJvdmlkZXMgZXh0ZW5zaW9ucyB0byB0aGUgUFNDIHN0YXRlDQo+ID4gbWFjaGlu ZSB0byBoYW5kbGUgU2lnbmFsIERlZ3JhZGUgKFNEKS4gSXQgZG9lcyBub3QgZGVmaW5lIFNEIG9y DQo+IHByb3ZpZGUNCj4gPiBzY29wZSBhcm91bmQgd2hlcmUgb3IgaG93IFNEIG1heSBiZSB1c2Vk IHNpbWlsYXJseSBhcyBpdCBhbHJlYWR5DQo+IGhhcHBlbg0KPiA+IGluIHRoZSBkcmFmdCBpbiBo YW5kbGluZyBvdGhlciBkZWZlY3RzIGxpa2UgU0YgKFNpZ25hbCBGYWlsdXJlKS4NCj4gPiBJbiBN UExTLVRQIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIFtSRkM2MzcyXSwgYSBmYXVsdCBjb25kaXRp b24NCj4gPiBpbmNsdWRlcyBib3RoIFNpZ25hbCBGYWlsIChTRikgYW5kIFNpZ25hbCBEZWdyYWRl IChTRCkgdGhhdCBjYW4gYmUNCj4gdXNlZA0KPiA+IHRvIHRyaWdnZXIgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcuDQo+ID4gV2hpbGUgdGhlIHN0YW5kYXJkaXphdGlvbiBsYWNrIG9mIGFuIFNEIGRlZmlu aXRpb24gYW5kIGRldGVjdGlvbg0KPiA+IG1lY2hhbmlzbXMsIHRoZSByZWxldmFudCBiZWhhdmlv cnMgaW4gdGVybXMgb2YgcHJvdGVjdGlvbiBhY3Rpb25zIG1heQ0KPiA+IGFscmVhZHkgYmUgZGVm aW5lZC4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBkcmFmdC1kai1tcGxzLXRwLWV4ZXIt cHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0aGUgRVhFUi9SUiBjb21tYW5kcyB0bw0KPiA+IHRlc3Qg aWYgdGhlIEFQUyBjb21tdW5pY2F0aW9uIGlzIG9wZXJhdGluZyBjb3JyZWN0bHkuIEluIG90aGVy IHdvcmRzDQo+ID4gYm90aCBBUFMgcHJvY2VzcyBsb2dpYyBpbmNsdWRpbmcgc3RhdGUgbWFjaGlu ZSBhbmQgQVBTIGNoYW5uZWwgb24NCj4gPiBwcm90ZWN0aW9uIHBhdGgsIHdpdGhvdXQgc2Vydmlj ZSBkaXNydXB0aW9uIGFuZCB3aXRob3V0IGFmZmVjdGluZyBhbnkNCj4gPiBwcm90ZWN0aW9uIG9w ZXJhdGlvbiwgdW5sZXNzIHRoZSBwcm90ZWN0aW9uIHRyYW5zcG9ydCBlbnRpdHkgaXMgaW4NCj4g dXNlLg0KPiA+IFRoaXMgY29tbWFuZCBpcyBkb2N1bWVudGVkIGluIFI4NCBvZiBbUkZDNTY1NF0g YW5kIGl0IGlzIHBhcnQgb2YgSVRVLVQNCj4gPiB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzLg0KPiA+ IEFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gdGhlIEFwcGVuZGl4IEIg b2YgUkZDNjM3OA0KPiB0aGF0DQo+ID4gdXRpbGl6ZXMgdGhlIExvY2tvdXQgb2YgUHJvdGVjdGlv biAoTE8pIG9yIEZvcmNlZCBTd2l0Y2ggKEZTKSBpbg0KPiA+IGNvbWJpbmF0aW9uIG9mIE9BTSBm dW5jdGlvbmFsaXRpZXMuIEhvd2V2ZXIsIGl0IGhhcyBzb21lIGZ1bmN0aW9uYWwNCj4gPiBsaW1p dGF0aW9uIGFuZCBoYXMgYSBwb3RlbnRpYWwgcmlzayBvZiBsb3NpbmcgdHJhZmZpYyBhcyBhIHNp Z25hbA0KPiA+IGZhaWx1cmUgbWlnaHQgb2NjdXIgZHVyaW5nIHRoZSBleGVyY2lzZSBvcGVyYXRp b24uIEluIHRoYXQgY2FzZSwgTE8gb3INCj4gPiBGUyBoYXMgdG8gYmUgY2FuY2VsZWQgdG8gYWxs b3cgdGhlIFBTQyBwcm90b2NvbCB0byBwcm92aWRlIHByb3Blcg0KPiA+IHN3aXRjaGluZy4NCj4g PiBBIGZ1cnRoZXIgYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiBkcmFmdC1v c2Jvcm5lLW1wbHMtDQo+IHBzYy0NCj4gPiBhbGl2ZS0wMCB0aGF0IGFueXdheSBzaG93IHNvbWUg ZnVuY3Rpb25hbCBsaW1pdGF0aW9ucyBiZWNhdXNlIGNhbm5vdA0KPiA+IHZhbGlkYXRlIHRoZSBQ U0Mgc3RhdGUgbWFjaGluZSBzdGF0dXMgYW5kIHByb2JhYmx5IHRoZSBMb2NhbCBSZXF1ZXN0DQo+ ID4gbG9naWMuDQo+ID4NCj4gPg0KPiA+IFRoZSBhdXRob3JzIGVuY291cmFnZSB0aGUgSUVURiBl eHBlcnRzIHRvIGNvbW1lbnQgb24gdGhlc2UgZHJhZnRzLA0KPiA+IGV2ZW50dWFsbHkgcHJvcG9z aW5nIG90aGVyIG9wdGlvbnMvbWVjaGFuaXNtcyB0aGF0IGNhbiBzYXRpc2Z5IHRoZQ0KPiBzYW1l DQo+ID4gcmVxdWlyZW1lbnRzLg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBBbGVzc2FuZHJvLCBI dXViLCBKZW9uZy1kb25nLCBUYWVrc2lkDQo+ID4gUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBh bGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlDQo+IGFsbGUNCj4gPiBwZXJz b25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlv bmUNCj4gPiBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25p IHNvbm8gcmlnb3Jvc2FtZW50ZQ0KPiA+IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0 byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUNCj4gPiBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpDQo+ ID4gcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPiA+DQo+ID4gVGhp cyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250 YWluDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3Nl ZShzKSBvbmx5Lg0KPiA+IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBi eSBhbnlib2R5IGVsc2UgaXMNCj4gdW5hdXRob3Jpc2VkLg0KPiA+IElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZA0KPiA+ IGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwg VGhhbmtzLg0KPiA+DQo+ID4gcmlzcGV0dGEgbCdhbWJpZW50ZVJpc3BldHRhIGwnYW1iaWVudGUu IE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZQ0KPiBub24NCj4gPiDDqCBuZWNlc3NhcmlvLg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBt cGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A27680488SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5ISSwgRXJpYy48L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij5UaGFua3MgZm9yIHRoZSBlbWFpbC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5QbGVhc2Ugc2VlIGlubGluZSB3aXRoIFtKUl08YnI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtF cmljIE9zYm9ybmUgKGVvc2Jvcm5lKSZxdW90OyAmbHQ7ZW9zYm9ybmVAY2lzY28uY29tJmd0Ozxi cj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0wNy0yMiAyMjozNjoyMSAoICYjNDM7MDk6MDAgKTxicj4N CjxiPlRvIDogPC9iPlJ5b28sIEplb25nLWRvbmcgJmx0O3J5b29AZXRyaS5yZS5rciZndDssIEQn QWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8gJmx0O2FsZXNzYW5kcm8uZGFsZXNzYW5kcm9A dGVsZWNvbWl0YWxpYS5pdCZndDssIG1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+Q2MgOiA8L2I+SHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2Vp LmNvbSkgJmx0O2h1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20mZ3Q7LCBodXViYXR3b3JrQGdt YWlsLmNvbSAmbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwv Yj5SRTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGlu ZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50czxicj4NCjxi cj4NCkhpIEplb25nLWRvbmcsPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgcmVwbHkuIFBsZWFz ZSBzZWUgaW5saW5lIHdpdGggRU8jLjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFJ5b28sIEplb25nLWRvbmcgW21haWx0bzpyeW9vQGV0 cmkucmUua3JdPGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgNDoxNSBBTTxi cj4NCiZndDsgVG86IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBEJ0FsZXNzYW5kcm8gQWxlc3Nh bmRybyBHZXJhcmRvOzxicj4NCiZndDsgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgQ2M6IEh1dWIg aGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pOyBodXViYXR3b3JrQGdtYWls LmNvbTxicj4NCiZndDsgU3ViamVjdDogUkU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFs aWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcjxicj4NCiZndDsgcHJvdGVjdGlvbiBwcm90b2NvbCB0 byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpLCBFcmljLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBMZXQgbWUgYW5zd2VyIHlvdXIgMm5kIHF1ZXN0aW9uIG9uIFNE Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBTRCBkZXRlY3Rpb24gbWV0aG9kcyBkZWZpbmVkIG9yIHBy b3Bvc2VkIGZvciBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzPGJyPg0KJmd0OyBjYW4gYmUgc3Vt bWFyaXplZCBhcyBmb2xsb3dzOjxicj4NCiZndDsgLSBCeSBPQU0gcGVyZm9ybWFuY2UgbW9uaXRv cmluZyB0b29sOjxicj4NCiZndDsgU0QgaXMgcmFpc2VkIGlmIHBhY2tldCBsb3NzIHJhdGlvIGV4 Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5nIGE8YnI+DQomZ3Q7IG1lYXN1cmVtZW50IHBlcmlvZC48 YnI+DQomZ3Q7IFRocmVzaG9sZCB2YWx1ZSBhbmQgbWVhc3VyZW1lbnQgcGVyaW9kIGFyZSBjb25m aWd1cmVkIGJ5IGFuIG5ldHdvcms8YnI+DQomZ3Q7IG9wZXJhdG9yLjxicj4NCiZndDsgVGhpcyBk ZXRlY3Rpb24gbWV0aG9kIGlzIGFscmVhZHkgZGVmaW5lZCBpbiBJVFUtVCBHLjgwMjEgKEV0aGVy bmV0PGJyPg0KJmd0OyBlcXVpcG1lbnQgc3BlYy4pPGJyPg0KPGJyPg0KPGJyPg0KRU8jIFdoZXJl PyBJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2aW5n IGEgaGFyZCB0aW1lIGZpbmRpbmcgaXQuIEEgc2VhcmNoIGZvciBFVEhfQ0lfU1NEIGRvZXNuJ3Qg eWllbGQgbXVjaC4gSWYgSSBsb29rIGZvciAnc2lnbmFsIGRlZ3JhZGUnIEkgc2VlIHAuIDEzMSB3 aGljaCBzYXlzIHRoYXQgdGhlIGFsZ29yaXRobSBpcyBkZWZpbmVkIGluIEcuODAzMS4gRy44MDMx IHNheXMgJyBIb3cgdGhlc2UgZGVmZWN0cw0KIGFyZSBkZXRlY3RlZCBpcyB0aGUgc3ViamVjdCBv ZiB0aGUgZXF1aXBtZW50IFJlY29tbWVuZGF0aW9ucycuIEknbSBsb29raW5nIGZvciBzb21ldGhp bmcgbGlrZSAmcXVvdDtTaWduYWwgRGVncmFkZSBpcyBkZWZpbmVkIGFzICRmb28gcGFja2V0IGxv c3Mgb3IgQ1JDIGZhaWx1cmUgb3ZlciAkYmFyIHRpbWUmcXVvdDsuLi4ud2hhdCBoYXZlIEkgbWlz c2VkPzxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPltKUl0gWWVz LCBJIGtub3cgdGhhdCBpdCBpcyByYXRoZXIgZGlmZmljdWx0IHRvIGZpbmQgd2hhdCZuYnNwO3dl IG5lZWQmbmJzcDtmcm9tIHRoYXQgZG9jdW1lbnQuIEluJm5ic3A7VGFibGUgNi0yLCZuYnNwO2Rl ZmVjdCBkZXRlY3Rpb24gYW5kIGNsZWFyYW5jZSZuYnNwO2ZvciBkREVHIChkZWdyYWRlZCBzaWdu YWwmbmJzcDtkZWZlY3QpIGFyZSBzaG93biwgYW5kJm5ic3A7Q2xhdXNlIDYuMS4zLjQgaGFzJm5i c3A7ZGV0YWlsZWQgdGV4dCBkZXNjcmlwdGlvbiBhbmQNCiBmbG93IGNoYXJ0IChGaWd1cmUgNi0z KSBmb3IgZGV0ZWN0aW9uIGFuZCBjbGVhcmFuY2UgZm9yIERFRy4gSSBndWVzcyB0aGlzIHdvdWxk IGJlIHRoZSBvbmUgdGhhdCB5b3Ugd2VyZSBsb29raW5nIGZvci4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPklmIHlvdSZuYnNwO3dhbnQgdG8gc2VhcmNoJm5ic3A7ZnVy dGhlciwmbmJzcDt0aGVuIGl0IHdpbGwgZ28gbGlrZTogZERFRyAtLSZndDsgRVRIX0FJX1RTRCAt LSZndDsgRVRIX0NJX1NTRC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48 YnI+DQo8YnI+DQomZ3Q7IGFuZCB0aGUgZXF1aXBtZW50IHNwZWMgZm9yIE1QTFMtVFAgY2FuIGVh c2lseSBmb2xsb3cgdGhlIHNhbWU8YnI+DQomZ3Q7IGRlZmluaXRpb24uPGJyPg0KJmd0OyAtIEJ5 IHNlcnZlciBsYXllciBpbmRpY2F0aW9uOjxicj4NCiZndDsgU0QgaXMgcmFpc2VkIGlmIGEgc2Vy dmVyIGxheWVyIGJlbG93IE1QTFMtVFAgcmVwb3J0cyBTRCBjb25kaXRpb24gb248YnI+DQomZ3Q7 IGl0cyBvd24gbGF5ZXIuPGJyPg0KJmd0OyAtIEJ5IENDTSBwYWNrZXQgY291bnRpbmc6PGJyPg0K Jmd0OyBTRCBpcyByYWlzZWQgaWYgdGhlIGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhjZWVk cyBhIHRocmVzaG9sZDxicj4NCiZndDsgZHVyaW5nIGEgbWVhc3VyZW1lbnQgcGVyaW9kLjxicj4N CiZndDsgPGJyPg0KJmd0OyBSZWdhcmRsZXNzIG9mIGhvdyB0byBkZXRlY3QgU0QsIGFueSBwcm90 ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudHM8YnI+DQomZ3Q7IHNob3VsZCBkZXNjcmliZSB0aGUg cHJvdGVjdGlvbiBzd2l0Y2hpbmcgb3BlcmF0aW9uIG9uY2Ugc3VjaCBhIFNEIGlzPGJyPg0KJmd0 OyBkZWNsYXJlZC48YnI+DQomZ3Q7IDxicj4NCi4uLjxicj4NCiZndDsgUmVnYXJkaW5nIHRoZSBt dWx0aXBsZSBsZXZlbHMgb2YgU0Q6PGJyPg0KJmd0OyBJdCBpcyBjZXJ0YWlubHkgcG9zc2libGUg dG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC48YnI+DQomZ3Q7IEJ1dCwgYXMgZmFyIGFz IHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjb25jZXJuZWQsIGl0IGp1c3QgbmVlZHMgdG88 YnI+DQomZ3Q7IGtub3cgaWYgU0QgaXMgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcg cHJvY2VzcyBvciBub3QuPGJyPg0KJmd0OyBJdCB3b3VsZCBiZSBhIG5ldHdvcmsgb3BlcmF0b3In cyBjaG9pY2UgYXQgd2hhdCBsZXZlbCBvZiBTRCBoZSB3YW50cyBoaXM8YnI+DQomZ3Q7IG5ldHdv cmsgcHJvdGVjdGlvbiB0byBzd2l0Y2hvdmVyLjxicj4NCiZndDsgSW4gb3RoZXIgd29yZHMsIHdo YXQgdHJpZ2dlcnMgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgU0Qgb3Igbm8gU0QuIEl0IGlzPGJy Pg0KJmd0OyB5ZXMgb3Igbm8gZGVjaXNpb24uPGJyPg0KPGJyPg0KPGJyPg0KRU8jIEkgYW0gbm90 IGF3YXJlIG9mIGFueSBkb2N1bWVudCB3aGljaCBzdWdnZXN0cyB0aGF0IGEgc2VydmVyIGxheWVy IFNEIHNob3VsZCBiZSB0cmVhdGVkIGFzIGEgY2xpZW50IGxheWVyIFNELiBJbiB0aGUgSVAgd29y bGQsIGlmIHdlIGhhdmUgU0Qgb24gYSB0cmFuc3BvcnQgaW50ZXJmYWNlIHRoYXQgaXMgZ2VuZXJh bGx5IHVzZWQgdG8gYnJpbmcgdGhlIGludGVyZmFjZSBkb3duIChpLmUuIFNGKS4gVGhpcyBpcyB0 aGUgc29ydCBvZiB0aGluZw0KIEknZCBsaWtlIHRvIHNlZSBpbiBtb3JlIGRldGFpbCwgYXMgU0Qg aW4gdGhlIHBhY2tldCB3b3JsZCBpcyBhIG5ldyBjb25jZXB0IGFuZCB3ZSBjYW4ndCBqdXN0IGFz c3VtZSB0aGF0IGl0IHdpbGwgd29yayB0aGUgc2FtZSBldmVyeXdoZXJlIGJlY2F1c2Ugd2UgZGVm aW5lIHN0YXRlIG1hY2hpbmUgcG9pbnRzIGZvciBpdC48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij5UaGUgcG9pbnQgYWJvdXQgQ0NNIGlzIGEgZ29vZCBvbmUuIExl dCdzIHNheSB3ZSBjb21lIHVwIHdpdGggYSBjbGV2ZXIgU0QgbWVjaGFuaXNtIHdpdGggdHdvIHRo cmVzaG9sZHMsIGNhbGwgdGhlbSBtYWpvciBhbmQgbWlub3IuIEZvciBkaXNjdXNzaW9uIHB1cnBv c2VzIHRoZXkgY291bGQgYmUgc2ltcGxlIGVycm9yIHJhdGlvcywgZS5nLiAxOjEwXjYgYW5kIDE6 MTBeOS4gQnV0IHRoZXkgY291bGQNCiBiZSBtb3JlIHBvd2VyZnVsIHRoYW4gdGhhdCAoZmxvdyB0 eXBlLCBmbG93IGxlbmd0aCwgZXJyb3IgYnVyc3Qgc2l6ZSwgZXRjKS48YnI+DQo8YnI+DQpJZiB3 ZSB3YW50IHRvIGhhdmUgU0QtTWFqb3IgYW5kIFNELU1pbm9yIGlucHV0cyBhcyBzZXBhcmF0ZSB0 cmlnZ2VycyBmb3IgUFNDLCB3ZSBtYXkgd2FudCB0aGVtIGF0IGRpZmZlcmVudCBwb2ludHMuIFBl cmhhcHMgKGxlYXZpbmcgb3V0IHRoZSBXb3JraW5nIHBhdGggZm9yIGVhc2Ugb2YgcmVhZGluZyk8 YnI+DQo8YnI+DQpMTzxicj4NCkZTPGJyPg0KU0YtUDxicj4NClNELVAtTWFqb3I8YnI+DQpNUzxi cj4NClNELVAtTWlub3I8YnI+DQo8YnI+DQo8YnI+DQpUaGlzIHNlZW1zIGxpa2UgYSBwZXJmZWN0 bHkgcmVhc29uYWJsZSB0aGluZyB0byB3YW50LiA8YnI+DQo8YnI+DQpFdmVuIGlmIHdlIGRvbid0 IGhhdmUgbXVsdGktdGllciBTRCwgZXZlbiB0aGUgc2luZ2xlLXRpZXIgU0QgbmVlZHMgdG8gYmUg ZGVmaW5lZCBiZWZvcmUgd2UgY2FuIGRlY2lkZSBob3cgdG8gcmVzcG9uZCB0byBpdC48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij5bSlJdIFRoZSBzZXJ2ZXIgbGF5ZXIgU0QgaGFzIGJlZW4gYSBwcm9wb3Nh bCwgYW5kIEkgaGF2ZSBiZWVuIHRvbGQgdGhhdCB0aGVyZSBpcyBwcm9wcmlldGFyeSBpbXBsZW1l bnRhdGlvbi4gQnV0LCB0aGlzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFBTQy4gV2hhdCB3ZSBu ZWVkIHRvIGNhcmUgaXMgd2hldGhlciBTRCBpcyBkZWNsYXJlZC9jbGVhcmVkIG9uIHdvcmtpbmcg cGF0aCBhbmQgd2hldGhlcg0KIFNEIGlzIGRlY2xlYXJlZC9jbGVhcmVkIG9uIHByb3RlY3Rpb24g cGF0aC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5JZiBhbnkgU0QgZGV0 ZWN0aW9uIG1lY2hhbmlzbSBjYW4gc2lnbmFsIHRoaXMgaW5mb3JtYXRpb24gdG8gUFNDLCBQU0Mg aXMgcmVhZHkgdG8gcHJvdmlkZSB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQo8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPltKUl0gUmVnYXJkaW5nIG11bHRpLXRpZXIgU0QsIHll cywgSSBhZ3JlZSB3aXRoIHlvdSBpbiBwcmluY2lwbGUuDQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij5DZXJ0YWlubHksIGlmIHByb3RlY3Rpb24gYWdhaW50IFNELXNlY29u ZCBpcyByZXF1aXJlZCwgd2UgY2FuIGFkZCBhbnRoZXImbmJzcDtyZXF1ZXN0IGNvZGVwb2ludCBh bmQgcHJpb3JpdHkgbGV2ZWwgZm9yIGl0LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPkJ1dCwgdGhhdCBkb2Vzbid0IG1lYW4gd2UgY2Fubm90IGRlZmluZSZuYnNwO3Byb3Rl Y3Rpb24gZm9yIHRoZSBmaXJzdCBTRC4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5UaGVyZSBoYXMgYmVlbiBhIHN0cm9uZyBkZW1hbmQgZm9yJm5ic3A7cHJvdGVj dGlvbiBhZ2FpbnN0IFNELjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlNv IGZhciwmbmJzcDtJJm5ic3A7aGF2ZW4ndCBzZWVuIGFueSZuYnNwO2RlbWFuZCBmb3IgcHJvdGVj dGlvbiBhZ2FpbnN0IHRoZSAybmQgU0QNCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPmFuZCBJIGNhbm5vdCBpbWFnaW5lIGhvdyZuYnNwO3RoZSBwcm90ZWN0aW9uIGFnYWlu c3QgMm5kIFNEJm5ic3A7d2lsbCBiZSBhY2NlcHRlZCwgY29uc2lkZXJpbmcmbmJzcDt0aGUgcHJv dGVjdGlvbiBhZ2FpbnN0IHRoZSBmaXJzdCZuYnNwO2FuZCBvbmx5IG9uZSBTRCBpcyBoYXZpbmcg dGhpcyBtdWNoIGRpZmZpY3VsdCB0aW1lLiZuYnNwOw0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+PGJyPg0KJmd0OyBUaGUgcHJvcG9zZWQgZHJhZnQgY292ZXJzIFNELXRyaWdnZXJlZCBwcm90 ZWN0aW9uIG5vIG1hdHRlciB3aGF0IGtpbmRzPGJyPg0KJmd0OyBvZiBTRCBkZXRlY3Rpb24gbWV0 aG9kcyBhcmUgdXNlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBTRiBjYW4gYWxz byBiZSB2aWV3ZWQgYXMgaGF2aW5nIG11bHRpcGxlIGxldmVscyBvZiBTRiBhcyB0aGUgbmV0d29y azxicj4NCiZndDsgb3BlcmF0b3IgY2FuIGFsc28gbWFrZSBhIGNob2ljZSBvbiB0aGUgcGVyaW9k L2ludGVydmFsIG9mIENDTSBtZXNzYWdlcy48YnI+DQo8YnI+DQo8YnI+DQpFTyMgPGJyPg0KSSdt IG5vdCBzdXJlIHdoYXQgdGhhdCB3b3VsZCBsb29rIGxpa2UuICdGYWlsJyBpcyBhIHByZXR0eSBi aW5hcnkgdGhpbmcuICdEZWdyYWRlJyBpcyBhIGNvbnRpbnVvdXMgdmFyaWFibGUsIGFzIGl0IGNh biBiZSBhbnl0aGluZyBmcm9tICdhIGxpdHRsZSBiYWQnIHRvIGEgJ2Egd2hvbGUgbG90IG9mIGJh ZCBidXQgbm90IHF1aXRlIGZhaWwnLjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPltKUl0gQWdhaW4sIEVyaWMuIFdoYXQgd2UgbmVlZCBpcyB3aGV0aGVyIFNEIGlz IGRlY2xhcmVkL2NsZWFyZWQgb24gd29ya2luZyBwYXRoJm5ic3A7YW5kIHdoZXRoZXIgU0QgaXMg ZGVjbGVhcmVkL2NsZWFyZWQgb24gcHJvdGVjdGlvbiBwYXRoLjwvZGl2Pg0KPGRpdiBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQiPkl0IHdvdWxkIGJlIG9wZXJhdG9yJ3MgY2hvaWNlIGF0IHdoYXQg bGV2ZWwgb2YgZGVncmFkZSBoZSB3YW50cyZuYnNwO2hpcyB0cmFmZmljIHRvIGJlIHN3aXRjaGVk IG92ZXIuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KJmd0OyBJZiBDQ00gaXMgZGlz YWJsZWQsIEFJUyBmcm9tIGEgc2VydmVyIGxheWVyIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlciBm b3I8YnI+DQomZ3Q7IHByb3RlY3Rpb24gc3dpdGNoaW5nLiBTbyBhbmQgc28gZm9ydGguPGJyPg0K PGJyPg0KRU8jIEFJUyBmcm9tIHRoZSBzZXJ2ZXIgbGF5ZXIgb25seSBnZXRzIHlvdSBTRCBmcm9t IHRoZSBmaXJzdCBob3Agb2YgdGhlIHVuZGVybHlpbmcgc2VydmVyIHBhdGguPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+W0pSXSBJdCBkZXBlbmRzIG9uIHdoZXJl IHlvdSB3YW50IHRvIHB1dCBNRVAgZm9yIG1vbml0b3JpbmcgU0QgaW4gdGhlIHNlcnZlciBsYXll ci4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkFJUyBmcm9tJm5ic3A7 dGhlIHNlcnZlciBsYXllciBjYW4gYmUgcHJvcGFnYXRlZCB0byBjbGllbnQgbGF5ZXIgTUVQIG5v ZGUsIHdoaWNoIHJ1bnMgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2VzcywmbmJzcDtpbiBtdWx0 aXBsZSBob3BzLiZuYnNwOzxicj4NCjxicj4NCjxicj4NCmVyaWM8YnI+DQo8YnI+DQomZ3Q7IEhv d2V2ZXIsIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cg dG8gZGV0ZWN0IFNGPGJyPg0KJmd0OyBpbiBhbnl3aGVyZS48YnI+DQomZ3Q7IFNpbWlsYXJ5LCBw cm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IG1hbnVhbDxi cj4NCiZndDsgc3dpdGNoIGFuZCBmb3JjZWQgc3dpdGNoIGNvbW1hbmRzPGJyPg0KJmd0OyBhcmUg aW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIHNpZ25hbGVkIHRvIHByb3RlY3Rp b248YnI+DQomZ3Q7IHN3aXRjaGluZyBwcm9jZXNzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBZ2Fp biwgaW4gbXkgb3BpbmlvbiwgdGhlIGRyYWZ0IG9uIFNEIHByb3RlY3Rpb24gY2FuIGFjY29tbW9k YXRlIGFueSBTRDxicj4NCiZndDsgZGV0ZWN0aW9uIG1ldGhvZHMuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSmVvbmctZG9uZzxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IDxi cj4NCiZndDsgRnJvbSA6ICZxdW90O0VyaWMgT3Nib3JuZSAoZW9zYm9ybmUpJnF1b3Q7IDxFT1NC T1JORUBDSVNDTy5DT00+PGJyPg0KJmd0OyBTZW50IDogMjAxMy0wNy0yMCAwMjo0ODoyOCAoICYj NDM7MDk6MDAgKTxicj4NCiZndDsgVG8gOiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRv PGJyPg0KJmd0OyA8QUxFU1NBTkRSTy5EQUxFU1NBTkRST0BURUxFQ09NSVRBTElBLklUPiwgbXBs c0BpZXRmLm9yZyA8TVBMU0BJRVRGLk9SRz48YnI+DQomZ3Q7IENjIDogSHV1YiBoZWx2b29ydCAo aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSk8YnI+DQomZ3Q7IDxIVVVCLlZBTi5IRUxWT09S VEBIVUFXRUkuQ09NPiwgaHV1YmF0d29ya0BnbWFpbC5jb208YnI+DQomZ3Q7IDxIVVVCQVRXT1JL QEdNQUlMLkNPTT48YnI+DQomZ3Q7IFN1YmplY3QgOiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0 cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyPGJyPg0KJmd0OyBwcm90ZWN0aW9uIHBy b3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBIaSBBbGVzc2FuZHJvLTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MgZm9yIHRo aXM7IHRoZSB0aHJlYWRzIEkgc3RhcnRlZCBzb21lIHRpbWUgYmFjayBzZWVtIHRvIGhhdmUgZGll ZDxicj4NCiZndDsgZG93biwgaXQncyBnb29kIHRvIGdldCB0aGVtIGdvaW5nIGFnYWluLjxicj4N CiZndDsgSSBoYXZlIHR3byB0aGluZ3MgSSBuZXZlciBxdWl0ZSB1bmRlcnN0b29kLCBjYW4geW91 IGNsYXJpZnkgdGhlbSBmb3IgbWU/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGkpIGNhbiB5b3UgZXhw bGFpbiBFWEVSIGF0IGEgaGlnaGVyIGxldmVsPyBJJ20gbm90IGxvb2tpbmcgZm9yIGE8YnI+DQom Z3Q7IGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGNoYW5nZXMsIGFuZCBJJ20gbm90 IGxvb2tpbmcgZm9yIHRoZTxicj4NCiZndDsgb25lIGxpbmUgJnF1b3Q7SXQgYWxsb3dzIHRoZSBG U00gdG8gYmUgdGVzdGVkJnF1b3Q7LiBXZSBoYXZlIGFsbCBvZiB0aGF0IGluIHRoZTxicj4NCiZn dDsgZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBzcGVjcy48YnI+DQomZ3Q7IDxicj4N CiZndDsgV2hhdCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQg Y2FtZSBmcm9tLiBUaGUgSVRVPGJyPg0KJmd0OyBzcGVjcyB0aGF0IGRlZmluZSBpdCBhcmUgcHJl dHR5IGhhcmQgdG8gZm9sbG93LCB0aGV5IHNlZW0gdG8gYXNzdW1lIHRoZTxicj4NCiZndDsgcmVh ZGVyIGFscmVhZHkga25vd3Mgd2hhdCBFWEVSIGlzIGFuZCB3aGF0IHByb2JsZW0gaXQgc29sdmVz LiBJdCBmZWVsczxicj4NCiZndDsgdmVyeSBtdWNoIGxpa2UgYSBtZWNoYW5pc20gdXNlZCB0byBj YXRjaCBhIHZlcnkgc3BlY2lmaWMgaW1wbGVtZW50YXRpb248YnI+DQomZ3Q7IGJ1ZywgYmFjayB3 aGVuIHRyYW5zcG9ydCBnZWFyIHdhcyBmYXIgbGVzcyBkZWJ1Z2dhYmxlIHRoYW4gd2hhdCB3ZSBo YXZlPGJyPg0KJmd0OyB0b2RheS48YnI+DQomZ3Q7IDxicj4NCiZndDsgTm8gb3RoZXIgc3RhdGUg bWFjaGluZXMgdGhhdCBJJ20gZmFtaWxpYXIgd2l0aCAoUlNWUCwgTERQLCBCR1AsIE9TUEYsPGJy Pg0KJmd0OyBJU0lTKSBoYXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNr IHRoZSBuZWlnaGJvciB3aGV0aGVyPGJyPg0KJmd0OyBpdCAqd291bGQqIGJlIGJyb2tlbiBpZiBp ZiB3ZXJlLCBpbiB0aGUgZnV0dXJlLCB0byBiZSBnaXZlbiBhIHBhcnRpY3VsYXI8YnI+DQomZ3Q7 IGlucHV0LiBQYXJ0IG9mIG15IHJlbHVjdGFuY2UgdG8gZ2V0IGJlaGluZCBFWEVSIGhhcyBiZWVu IHRoYXQgSSBkb24ndDxicj4NCiZndDsgZmVlbCBjb21mb3J0YWJsZSB3aXRoIHRoZSBpZGVhIG9m IGtlZXBpbmcgYSAzMC15ZWFyLW9sZCB3b3JrYXJvdW5kIGluIGE8YnI+DQomZ3Q7IHByb3RvY29s LiBJcyB0aGVyZSBtb3JlIHRvIGl0IHRoYW4gdGhhdD8gSGF2ZSBJIG1pc3JlYWQgYW5kPGJyPg0K Jmd0OyBtaXN1bmRlcnN0b29kIEVYRVI/IERvZXMgbW9kZXJuIHRyYW5zcG9ydCBnZWFyIGV2ZXIg YWN0dWFsbHkgZGV0ZWN0IGE8YnI+DQomZ3Q7IHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3YXNu J3Qgb2J2aW91cyB0byB0aGUgb3BlcmF0b3IgdXNpbmcgb3RoZXI8YnI+DQomZ3Q7IG1lYW5zPzxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGlpKSBXaHkgdGhlIHB1c2ggdG8gc3RhbmRh cmRpemUgdGhlIFNEIHN0YXRlIGNoYW5nZXMgYmVmb3JlIHdlJ3ZlPGJyPg0KJmd0OyBkZWZpbmVk IFNEPyBJIGNlcnRhaW5seSBhZ3JlZSB0aGF0IGhhbmRsaW5nIHNpZ25hbCBkZWdyYWRlIGlzIGEg Z29vZDxicj4NCiZndDsgaWRlYSwgYnV0IGNvbWluZyB1cCB3aXRoIGEgZGVmaW5pdGlvbiBmb3Ig aXQgaGFzIGJlZW4gY2hhbGxlbmdpbmcuIFdoYXQ8YnI+DQomZ3Q7IGhhcHBlbnMgaWYgd2UgY2hh bmdlIHRoZSBGU00gdG8gaGFuZGxlIGl0LCB0aGVuIGNvbWUgdXAgd2l0aCBzb21ldGhpbmc8YnI+ DQomZ3Q7IG1vcmUgc29waGlzdGljYXRlZCAoc2F5LCBtdWx0aXBsZSBsZXZlbHMgb2YgU0QpIHRo YXQgZG9lc24ndCBxdWl0ZSBmaXQ8YnI+DQomZ3Q7IHdpdGggdGhlIEZTTSBjaGFuZ2VzPzxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgdGhhbmtzITxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGVy aWM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmPGJyPg0KJmd0OyBPZjxicj4NCiZn dDsgJmd0OyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvPGJyPg0KJmd0OyAmZ3Q7IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyAzOjIzIFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBt cGxzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5o ZWx2b29ydEBodWF3ZWkuY29tKTsgaHV1YmF0d29ya0BnbWFpbC5jb208YnI+DQomZ3Q7ICZndDsg U3ViamVjdDogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0Mg bGluZWFyPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJl cXVpcmVtZW50czxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBEZWFyIGFsbCw8YnI+DQom Z3Q7ICZndDsgd2Ugd291bGQgbGlrZSBzb2NpYWxpemluZyB0aGUgaGVyZWJlbG93IGRyYWZ0cyB0 aGF0IHdlcmUgc3VibWl0dGVkPGJyPg0KJmd0OyBzb21lPGJyPg0KJmd0OyAmZ3Q7IG1vbnRocyBh Z28gd2l0aCB0aGUgYWltIHRvIGFsaWduIFBTQyBwcm90b2NvbCAoUkZDIDYzNzgpIHRvIElUVS1U PGJyPg0KJmd0OyAmZ3Q7IHRyYW5zcG9ydCByZXF1aXJlbWVudHMuIEkgd291bGQgYXBwcmVjaWF0 ZSB5b3VyIGNvbW1lbnRzIGFib3V0IHRoZTxicj4NCiZndDsgJmd0OyBwcm9wb3NlZCBtZWNoYW5p c21zIGFuZCBiZWhhdmlvdXJzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBkcmFmdC1y aGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDA8YnI+DQomZ3Q7ICZndDsgZHJhZnQtY2RoLW1wbHMt dHAtcHNjLW5vbi1yZXZlcnRpdmUtMDA8YnI+DQomZ3Q7ICZndDsgZHJhZnQtcmhkLW1wbHMtdHAt cHNjLXNkLTAwPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LWRqLW1wbHMtdHAtZXhlci1wc2MtMDEgLyBk cmFmdC1vc2Jvcm5lLW1wbHMtcHNjLWFsaXZlLTAwPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFRoZSBhYm92ZSBkcmFmdHMgY292ZXIgbW9zdCBvZiBpdGVtcyBoaWdobGlnaHRlZCBpbiBJ VFUtVCBsaWFpc29uczxicj4NCiZndDsgYWJvdXQ8YnI+DQomZ3Q7ICZndDsgUFNDIGFuZCB0aGV5 IHByb3Bvc2Ugc29sdXRpb25zIGluIGxpbmUgd2l0aCBNUExTLVRQIHRyYW5zcG9ydDxicj4NCiZn dDsgJmd0OyByZXF1aXJlbWVudHMuPGJyPg0KJmd0OyAmZ3Q7IEEgbGlzdCBvZiBtYWluIGxpYWlz b25zIGV4Y2hhbmdlZCBiZXR3ZWVuIElUVS1UIGFuZCBJRVRGIHdpdGggdGhlIGFpbTxicj4NCiZn dDsgdG88YnI+DQomZ3Q7ICZndDsgYWxpZ24gUFNDIGJlaGF2aW91cyB3aXRoIElUVS1UIHRyYW5z cG9ydCByZXF1aXJlbWVudHMgZm9yIGxpbmVhcjxicj4NCiZndDsgJmd0OyBwcm90ZWN0aW9uIGFy ZSBnaXZlbiBiZWxvdzo8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9saWFpc29uLzExNjIvIChKdW5lIDIwMTIpPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjA1Lzxicj4NCiZndDsgJmd0OyAoT2N0b2JlciAyMDEy KTxicj4NCiZndDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIy OS88YnI+DQomZ3Q7ICZndDsgKEphbnVhcnkgMjAxMyk8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvPGJyPg0KJmd0OyAmZ3Q7IChGZWJydWFy eSAyMDEzKTxicj4NCiZndDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlz b24vMTI1Ni88YnI+DQomZ3Q7ICZndDsgKE1heSAyMDEzKTxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBTb21lIGRldGFpbHMgYWJvdSB0aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQ U0MgYmVoYXZpb3VyIHdpdGg8YnI+DQomZ3Q7ICZndDsgdHJhbnNwb3J0IHJlcXVpcmVtZW50czo8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9y aXR5LTAwIHByb3Bvc2VzIHN3YXBwaW5nIHRoZSBwcmlvcml0aWVzPGJyPg0KJmd0OyAmZ3Q7IGJl dHdlZW4gRlMgYW5kIFNGLVAgKHNlZSBzZWN0aW9uIDQuMy4yIG9mIHJmYzYzNzgpLjxicj4NCiZn dDsgJmd0OyBBbW9uZyB0aGUgb3RoZXJzLCBiZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdp dGggdGhlIHByb3Bvc2VkPGJyPg0KJmd0OyB1cGRhdGU8YnI+DQomZ3Q7ICZndDsgYXJlOjxicj4N CiZndDsgJmd0OyBVc2UgY2FzZSBBKSBBdCBmaXJzdCwgd29ya2luZyBwYXRoKFdQKSBhbmQgcHJv dGVjdGlvbiBwYXRoKFBQKSBhcmU8YnI+DQomZ3Q7ICZndDsgbm9ybWFsLiBUaGVuLCBGb3JjZWQg U3dpdGNoKEZTKSBjb21tYW5kIGlzIGlzc3VlZCBmb3IgbWFpbnRlbmFuY2Ugb248YnI+DQomZ3Q7 IHRoZTxicj4NCiZndDsgJmd0OyBXUCBhbmQgdGhlIHRyYWZmaWMgbW92ZXMgZnJvbSBXUCB0byBQ UC4gV2hlbiBTaWduYWwgRmFpbCBvY2N1cnMgb24gUFAsPGJyPg0KJmd0OyAmZ3Q7IHNlcnZpY2Ug Y2Fubm90IHJlY292ZXIgYW5kIGlzIGludGVycnVwdGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvcjxi cj4NCiZndDsgZXhhbXBsZTxicj4NCiZndDsgJmd0OyBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFs bHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci48YnI+DQomZ3Q7ICZndDsgVXNlIGNhc2UgQikgSWYg dGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFsIGZhaWwgb24gYSBwcm90ZWN0aW9uIHBhdGg8YnI+ DQomZ3Q7ICZndDsgKFNGLVApLGFuZCBGUyBjb21tYW5kIGlzIGlzc3VlZCBieSBhY2NpZGVudCB0 aGUgdHJhZmZpYyBvbiBXUCB3aWxsPGJyPg0KJmd0OyBtb3ZlPGJyPg0KJmd0OyAmZ3Q7IHRvIFBQ LiBUaGlzIHJlc3VsdHMgaW4gYW4gaW50ZXJydXB0aW9uIG9mIHNlcnZpY2UgZnJvbSB3aGljaCB5 b3Ugd2lsbDxicj4NCiZndDsgJmd0OyBub3QgYXV0b21hdGljYWxseSByZWNvdmVyLCBiZWNhdXNl IFBTQyBzaG91bGQgbm90IGhhdmUgc3dpdGNoZWQgdGhlPGJyPg0KJmd0OyAmZ3Q7IHRyYWZmaWMg ZnJvbSBXUCB0byBQUC48YnI+DQomZ3Q7ICZndDsgRGlzY3Vzc2lvbiBhYm91dCB0aGlzIGRyYWZ0 IGxlZCB0byB0aGUgcHJvcG9zYWwgdG8gbW9kaWZ5IFJGQyA0NDI3PGJyPg0KJmd0OyB0aGF0PGJy Pg0KJmd0OyAmZ3Q7IHdhcyAmcXVvdDt3cml0dGVuIGNvcnJlY3RseSB0aG91Z2ggbGFja2luZyBp biBkZXRhaWwgY2F1c2luZyBtaXMtPGJyPg0KJmd0OyAmZ3Q7IGludGVycHJldGF0aW9uJnF1b3Q7 IHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBzZXQgb2YgcHJpb3JpdHkgdGhhdCB0aGU8YnI+ DQomZ3Q7ICZndDsgYWJvdmUgZHJhZnQgaXMgcHJvcG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBh bGlnbiB0byB0aGUgcmVxdWlyZWQ8YnI+DQomZ3Q7ICZndDsgdHJhbnNwb3J0IGJlaGF2aW9yLiBk cmFmdC1oZWx2b29ydC1jY2FtcC1mcy1wcmlvcml0eS0wMCBoYXMgYmVlbjxicj4NCiZndDsgJmd0 OyBzdWJtaXR0ZWQgdG8gQ0NBTVAgZm9yIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0 ZWQgdG8gTWFudWFsPGJyPg0KJmd0OyAmZ3Q7IFN3aXRjaCBhbmQgRm9yY2VkIFN3aXRjaCBhbmQg dGhlaXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJpb3JpdGllcy48YnI+DQomZ3Q7ICZndDsgVGhlIHdh eSB0aGlzIGJlaGF2aW9yIGhhcyB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDIGhhcyB0 byBiZTxicj4NCiZndDsgJmd0OyBkaXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRvIHJlcGxh Y2UgdGhlIGN1cnJlbnQgYmVoYXZpb3Igd2l0aCB0aGU8YnI+DQomZ3Q7ICZndDsgbmV3IG9uZS4g SWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHByb2NlZGUgaW4gdGhhdCB3YXkgdGhpcyBjYW4gYnJp bmc8YnI+DQomZ3Q7IHRvPGJyPg0KJmd0OyAmZ3Q7IGEgc2ltcGxlIGFuZCBlZmZlY3RpdmUgd2F5 IHRvIG9wZXJhdGUgdGhlIHByb3RvY29sLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2 ZXJ0aXZlLTAwIGNvbnRhaW5zIHRoZSB1cGRhdGVzIHRvIFJGQzYzNzg8YnI+DQomZ3Q7ICZndDsg dG8gY2hhbmdlIG5vbi1yZXZlcnRpdmUgb3BlcmF0aW9ucyB0byBiZWhhdmVzIGluIHRoZSBzYW1l IHdheTxicj4NCiZndDsgJmd0OyBpcnJlc3BlY3RpdmVseSBvZiB0aGUgdHJpZ2dlciBvZiBwcm90 ZWN0aW9uIHN3aXRjaGluZyAoZmF1bHQgb3I8YnI+DQomZ3Q7IG9wZXJhdG9yPGJyPg0KJmd0OyAm Z3Q7IGNvbW1hbmQgRlMsIE1TKS4gQ29uc2VxdWVudGx5IGFuIG9wZXJhdG9yIGNvbW1hbmQsIE1h bnVhbCBTd2l0Y2ggdG88YnI+DQomZ3Q7ICZndDsgV29ya2luZyAoTVMtVykgYS5rLmEgJnF1b3Q7 TWFudWFsIHN3aXRjaC1vdmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiZxdW90OyBpczxicj4NCiZn dDsgYWxzbzxicj4NCiZndDsgJmd0OyBhZGRlZCB0byBlbmFibGUgdGhpcyBiZWhhdmlvci4gRnJv bSBhbiBvcGVyYXRpb25hbCBwb2ludCBvZiB2aWV3LCBNUzxicj4NCiZndDsgdG88YnI+DQomZ3Q7 ICZndDsgd29ya2luZyBwYXRoIGhhcyBhbHNvIHRvIGJlIHN1cHBvcnRlZCB0byBiZSBhYmxlIHRv IGluaXRpYWxseSBhbGlnbiBhdDxicj4NCiZndDsgJmd0OyBib3RoIHNpZGVzIGluIGNhc2Ugb2Yg bm9uLXJldmVydGl2ZSBzd2l0Y2hpbmcgbW9kZS4gTVMgdG8gd29ya2luZyBwYXRoPGJyPg0KJmd0 OyAmZ3Q7IGlzIGRlZmluZWQgaW4gUkZDIDU2NTQsIHJlcXVpcmVtZW50IDgzLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgcHJvcG9zZWQgTVMtVyBjb21tYW5kIGlzIG9mIGVxdWFs IHByaW9yaXR5IHRvIHRoZSBleGlzdGluZyBNUy1QPGJyPg0KJmd0OyAmZ3Q7IGNvbW1hbmQsIGFu ZCB0aGVyZSBpcyB0ZXh0IHRvIGhhbmRsZSB0aGUgc2ltdWx0YW5lb3VzIG9yIHNlcXVlbnRpYWw8 YnI+DQomZ3Q7ICZndDsgb2NjdXJyZW5jZSBvZiB0d28gZXF1YWwtcHJpb3JpdHkgY29tbWFuZHMu IFRoaXMgYmVoYXZpb3IsIGFscmVhZHk8YnI+DQomZ3Q7ICZndDsgYWRvcHRlZCBpbiBvdGhlciB0 cmFuc3BvcnQgbmV0d29yayBwcm90ZWN0aW9uIHN3aXRjaGluZyBwcm90b2NvbCwgY2FuPGJyPg0K Jmd0OyBiZTxicj4NCiZndDsgJmd0OyB1c2VkIGZvciBvdGhlciBhZGRpdGlvbiB0byB0aGUgcHJv dG9jb2wgaW4gdGhlIGZ1dHVyZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsgJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDAgcHJvdmlk ZXMgZXh0ZW5zaW9ucyB0byB0aGUgUFNDIHN0YXRlPGJyPg0KJmd0OyAmZ3Q7IG1hY2hpbmUgdG8g aGFuZGxlIFNpZ25hbCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmluZSBTRCBvcjxicj4N CiZndDsgcHJvdmlkZTxicj4NCiZndDsgJmd0OyBzY29wZSBhcm91bmQgd2hlcmUgb3IgaG93IFNE IG1heSBiZSB1c2VkIHNpbWlsYXJseSBhcyBpdCBhbHJlYWR5PGJyPg0KJmd0OyBoYXBwZW48YnI+ DQomZ3Q7ICZndDsgaW4gdGhlIGRyYWZ0IGluIGhhbmRsaW5nIG90aGVyIGRlZmVjdHMgbGlrZSBT RiAoU2lnbmFsIEZhaWx1cmUpLjxicj4NCiZndDsgJmd0OyBJbiBNUExTLVRQIHN1cnZpdmFiaWxp dHkgZnJhbWV3b3JrIFtSRkM2MzcyXSwgYSBmYXVsdCBjb25kaXRpb248YnI+DQomZ3Q7ICZndDsg aW5jbHVkZXMgYm90aCBTaWduYWwgRmFpbCAoU0YpIGFuZCBTaWduYWwgRGVncmFkZSAoU0QpIHRo YXQgY2FuIGJlPGJyPg0KJmd0OyB1c2VkPGJyPg0KJmd0OyAmZ3Q7IHRvIHRyaWdnZXIgcHJvdGVj dGlvbiBzd2l0Y2hpbmcuPGJyPg0KJmd0OyAmZ3Q7IFdoaWxlIHRoZSBzdGFuZGFyZGl6YXRpb24g bGFjayBvZiBhbiBTRCBkZWZpbml0aW9uIGFuZCBkZXRlY3Rpb248YnI+DQomZ3Q7ICZndDsgbWVj aGFuaXNtcywgdGhlIHJlbGV2YW50IGJlaGF2aW9ycyBpbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFj dGlvbnMgbWF5PGJyPg0KJmd0OyAmZ3Q7IGFscmVhZHkgYmUgZGVmaW5lZC48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyBkcmFmdC1kai1t cGxzLXRwLWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0aGUgRVhFUi9SUiBjb21tYW5kcyB0 bzxicj4NCiZndDsgJmd0OyB0ZXN0IGlmIHRoZSBBUFMgY29tbXVuaWNhdGlvbiBpcyBvcGVyYXRp bmcgY29ycmVjdGx5LiBJbiBvdGhlciB3b3Jkczxicj4NCiZndDsgJmd0OyBib3RoIEFQUyBwcm9j ZXNzIGxvZ2ljIGluY2x1ZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBUFMgY2hhbm5lbCBvbjxicj4N CiZndDsgJmd0OyBwcm90ZWN0aW9uIHBhdGgsIHdpdGhvdXQgc2VydmljZSBkaXNydXB0aW9uIGFu ZCB3aXRob3V0IGFmZmVjdGluZyBhbnk8YnI+DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBvcGVyYXRp b24sIHVubGVzcyB0aGUgcHJvdGVjdGlvbiB0cmFuc3BvcnQgZW50aXR5IGlzIGluPGJyPg0KJmd0 OyB1c2UuPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgY29tbWFuZCBpcyBkb2N1bWVudGVkIGluIFI4NCBv ZiBbUkZDNTY1NF0gYW5kIGl0IGlzIHBhcnQgb2YgSVRVLVQ8YnI+DQomZ3Q7ICZndDsgdHJhbnNw b3J0IHJlcXVpcmVtZW50cy48YnI+DQomZ3Q7ICZndDsgQW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwg aXMgZG9jdW1lbnRlZCBpbiB0aGUgQXBwZW5kaXggQiBvZiBSRkM2Mzc4PGJyPg0KJmd0OyB0aGF0 PGJyPg0KJmd0OyAmZ3Q7IHV0aWxpemVzIHRoZSBMb2Nrb3V0IG9mIFByb3RlY3Rpb24gKExPKSBv ciBGb3JjZWQgU3dpdGNoIChGUykgaW48YnI+DQomZ3Q7ICZndDsgY29tYmluYXRpb24gb2YgT0FN IGZ1bmN0aW9uYWxpdGllcy4gSG93ZXZlciwgaXQgaGFzIHNvbWUgZnVuY3Rpb25hbDxicj4NCiZn dDsgJmd0OyBsaW1pdGF0aW9uIGFuZCBoYXMgYSBwb3RlbnRpYWwgcmlzayBvZiBsb3NpbmcgdHJh ZmZpYyBhcyBhIHNpZ25hbDxicj4NCiZndDsgJmd0OyBmYWlsdXJlIG1pZ2h0IG9jY3VyIGR1cmlu ZyB0aGUgZXhlcmNpc2Ugb3BlcmF0aW9uLiBJbiB0aGF0IGNhc2UsIExPIG9yPGJyPg0KJmd0OyAm Z3Q7IEZTIGhhcyB0byBiZSBjYW5jZWxlZCB0byBhbGxvdyB0aGUgUFNDIHByb3RvY29sIHRvIHBy b3ZpZGUgcHJvcGVyPGJyPg0KJmd0OyAmZ3Q7IHN3aXRjaGluZy48YnI+DQomZ3Q7ICZndDsgQSBm dXJ0aGVyIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gZHJhZnQtb3Nib3Ju ZS1tcGxzLTxicj4NCiZndDsgcHNjLTxicj4NCiZndDsgJmd0OyBhbGl2ZS0wMCB0aGF0IGFueXdh eSBzaG93IHNvbWUgZnVuY3Rpb25hbCBsaW1pdGF0aW9ucyBiZWNhdXNlIGNhbm5vdDxicj4NCiZn dDsgJmd0OyB2YWxpZGF0ZSB0aGUgUFNDIHN0YXRlIG1hY2hpbmUgc3RhdHVzIGFuZCBwcm9iYWJs eSB0aGUgTG9jYWwgUmVxdWVzdDxicj4NCiZndDsgJmd0OyBsb2dpYy48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGF1dGhvcnMgZW5jb3VyYWdlIHRoZSBJ RVRGIGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFmdHMsPGJyPg0KJmd0OyAmZ3Q7IGV2 ZW50dWFsbHkgcHJvcG9zaW5nIG90aGVyIG9wdGlvbnMvbWVjaGFuaXNtcyB0aGF0IGNhbiBzYXRp c2Z5IHRoZTxicj4NCiZndDsgc2FtZTxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVudHMuPGJyPg0K Jmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgQWxlc3NhbmRybywgSHV1Yiwg SmVvbmctZG9uZywgVGFla3NpZDxicj4NCiZndDsgJmd0OyBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGU8YnI+DQomZ3Q7IGFs bGU8YnI+DQomZ3Q7ICZndDsgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEg byBxdWFsc2lhc2kgYWx0cmEgYXppb25lPGJyPg0KJmd0OyAmZ3Q7IGRlcml2YW50ZSBkYWxsYSBj b25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlPGJyPg0K Jmd0OyAmZ3Q7IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l bnRvIHBlciBlcnJvcmUgc2lldGU8YnI+DQomZ3Q7ICZndDsgY29ydGVzZW1lbnRlIHByZWdhdGkg ZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaTxicj4NCiZn dDsgJmd0OyBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbjxicj4NCiZndDsgJmd0OyBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuPGJyPg0KJmd0OyAm Z3Q7IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVs c2UgaXM8YnI+DQomZ3Q7IHVuYXV0aG9yaXNlZC48YnI+DQomZ3Q7ICZndDsgSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k PGJyPg0KJmd0OyAmZ3Q7IGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkg cmV0dXJuIGUtbWFpbCwgVGhhbmtzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyByaXNw ZXR0YSBsJ2FtYmllbnRlUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBt YWlsIHNlPGJyPg0KJmd0OyBub248YnI+DQomZ3Q7ICZndDsgw6ggbmVjZXNzYXJpby48YnI+DQom Z3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBtcGxzQGlldGYub3Jn PGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A27680488SMTP2etriinfo_-- From ryoo@etri.re.kr Mon Jul 22 23:51:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAE611E80D1 for ; Mon, 22 Jul 2013 23:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p51cLxq24NPo for ; Mon, 22 Jul 2013 23:51:27 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id A65DD11E80F0 for ; Mon, 22 Jul 2013 23:51:26 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Jul 2013 15:51:16 +0900 Received: from SMTP2.etri.info ([169.254.2.217]) by SMTP1.etri.info ([169.254.1.31]) with mapi id 14.01.0355.002; Tue, 23 Jul 2013 15:51:15 +0900 From: "Ryoo, Jeong-dong" To: "Eric Osborne (eosborne)" , "Huber, Thomas J." , D'Alessandro Alessandro Gerardo , "mpls@ietf.org" Thread-Topic: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements Thread-Index: Ac6DHuTBnBsFst6dRBacz35cfwebQgBh5tkQAIEysAQADK5f8AALo9nQAAJm74AAFWIQRw== Date: Tue, 23 Jul 2013 06:51:15 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A276804F3@SMTP2.etri.info> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net>, <20ECF67871905846A80F77F8F4A275721028AD97@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721028AD97@xmb-rcd-x09.cisco.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276804F3SMTP2etriinfo_" MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 23 Jul 2013 06:51:32 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276804F3SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywNCg0KSSBjYW4gdW5kZXJzdGFuZCB5b3VyIHBvaW50LCBleHBlY2lhbGx5IHRoZSBjb21s aWNhdGlvbiBhcm91bmQgbXVsdGlwbGUgY2hvaWNlcyBvZiBTRCBkZXRlY3Rpb24uDQoNCkluIGxp bmVhciBwcm90ZWN0aW9uIHN3aXRjaGluZywgYWxsIHdlIGNhbiBkbyBpcyB0byBzZWxlY3Qgb25l IG9mIHR3byBwYXRocyBubyBtYXR0ZXIgaG93IG1hbnkgZGlmZmVyZW50IFNEIGRldGVjdGlvbiBt ZXRob2RzIGFuZCBTRCBsZXZlbHMuDQpUaGVyZSBhcmUgbXVsdGlwbGUgaW5wdXRzL3JlcXVlc3Rz IGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZywgc3VjaCBhcyBTRiwgTVMsIEZTLCBldGMuDQpXaGF0 IHdlIGhhdmUgZG9uZSBzbyBmYXIgaXMgcHJpb3JpdGl6YXRpb24gb2YgdGhvc2UgcmVxdWVzdHMs IGFuZCB0aGUgbW9zdCBzZXZlcmUgb25lIHRha2VzIG9uZSBvZiB0d28gcGF0aHMgYXMgaXQgd2Fu dHMuDQpJZiB0aGVyZSBpcyBhIG5lZWQgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCBtdWx0aXBsZSwg bW9yZSBzb3BoaXN0aWNhdGVkIFNEcywNCndlIGNhbiBkZWZpbmUgYSBuZXcgcmVxdWVzdCB0eXBl IGFuZCBwcmlvcml0eSBmb3IgdGhlIGFkZGl0aW9uYWwgbGV2ZWwgb2YgU0QuDQoNCkN1cnJlbnRs eSwgd2UgYXJlIGZhY2luZyBhIGRlbWFuZCBmb3IgcHJvdGVjdGlvbiBtZWNoYW5pc20gYWdhaW5z dCBvbmUgU0QgbGV2ZWwsIHdoaWNoIGhhcyBiZWVuIHRoZSBjYXNlIGZvciBzbyBsb25nIHRpbWUg c2luY2UgU0RILg0KRm9yIGFsbCB0aGUgZXhpc3RpbmcgcHJvdGVjdGlvbiB0ZWNobm9sb2dpZXMg aW5jbHVkaW5nIEV0aGVybmV0LCBTRCBmcm9tIHByb3RlY3Rpb24gcG9pbnQgb2YgdmlldyBoYXMg YWx3YXlzIGJlZW4gYSBiaW5hcnkgZGVjaXNpb24uDQpMZXQncyB3b3JrIG9uIHN1cHBvcnRpbmcg b25lIFNEIGxldmVsLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIkVyaWMgT3Nib3JuZSAoZW9zYm9y bmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPg0KU2VudCA6IDIwMTMtMDctMjMgMDU6MTI6MzUgKCAr MDk6MDAgKQ0KVG8gOiBIdWJlciwgVGhvbWFzIEouIDxUb20uSHViZXJAdGVsbGFicy5jb20+LCBS eW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0cmkucmUua3I+LCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRy byBHZXJhcmRvIDxhbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ+LCBtcGxz QGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KQ2MgOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5o ZWx2b29ydEBodWF3ZWkuY29tKSA8aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT4sIGh1dWJh dHdvcmtAZ21haWwuY29tIDxodXViYXR3b3JrQGdtYWlsLmNvbT4NClN1YmplY3QgOiBSRTogW21w bHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3Rl Y3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KDQpIaSBUb20tDQoNCg0K VGhhdCdzIGEgZ29vZCB3YXkgdG8gcHV0IGl0LCBhbmQgSSB0aGluayBpdCBjYXB0dXJlcyB0aGUg dHdvIG9waW5pb25zLiBNeSBjb25jZXJuIHdpdGggdGhlIGJvb2xlYW4gU0QgYXBwcm9hY2ggaXMg dGhhdCBpdCdzIGJlZW4gYSBzdHJ1Z2dsZSB0byBkZWZpbmUgU0QgYXQgYWxsIGZvciBJUC9NUExT IG5ldHdvcmtzLiBJIGNhbiBlY2hvIEplb25nLURvbmcncyBwb2ludCBoZXJlIC0gU0QgY291bGQg YmUgc2VydmVyIFNEIFtTU0RdLCBpdCBjb3VsZCBiZSBQTSwgaXQgY291bGQgYmUgQ0NNLiBVbmxl c3Mgd2UgYWN0dWFsbHkgZGVmaW5lIFNELCBpdCdzIG5vdCBhdCBhbGwgY2xlYXIgdG8gbWUgdGhh dCBJUCBTRCB3aWxsIGluIGZhY3QgYmUgYSBzaW1wbGUgeWVzL25vIHRoaW5nLiBXaGF0IGlmIHdl IGRlY2lkZSB0aGF0IGJvdGggUE0gYW5kIFNTRCBhcmUgdmFsaWQsIGJ1dCB0aGF0IG9uZSBvZiB0 aGVtIGlzIHdvcnNlIHRoYW4gdGhlIG90aGVyPw0KDQpKdXN0IHNvIHdlJ3JlIGNsZWFyIC0gSSBh bSBub3QgYWdhaW5zdCB0aGUgY29uY2VwdCBvZiBTRCBpbiBQU0MuIEkgYW0gYWdhaW5zdCBkZWZp bmluZyBob3cgd2UgcmVhY3QgdG8gYW4gZXZlbnQgYmVmb3JlIHdlIGRlZmluZSB0aGUgZXZlbnQg aXRzZWxmLg0KDQoNCg0KDQplcmljDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBIdWJlciwgVGhvbWFzIEouIFttYWlsdG86VG9tLkh1YmVyQHRlbGxhYnMuY29tXQ0K PiBTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzowNCBQTQ0KPiBUbzogRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSk7IFJ5b28sIEplb25nLWRvbmc7IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvDQo+ IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhl bHZvb3J0QGh1YXdlaS5jb20pOyBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiBTdWJqZWN0OiBSRTog W21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+ IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPg0KPiBIaSBF cmljLA0KPg0KPiBZb3Ugd3JvdGU6DQo+ID5FTyMNCj4gPkknbSBub3Qgc3VyZSB3aGF0IHRoYXQg d291bGQgbG9vayBsaWtlLiAnRmFpbCcgaXMgYSBwcmV0dHkgYmluYXJ5DQo+IHRoaW5nLiAnRGVn cmFkZScgaXMgYSBjb250aW51b3VzIHZhcmlhYmxlLCBhcyBpdCBjYW4gYmUgYW55dGhpbmcgZnJv bQ0KPiAnYSBsaXR0bGUgYmFkJyB0byBhICdhIHdob2xlIGxvdCBvZiBiYWQgYnV0IG5vdCBxdWl0 ZSBmYWlsJy4NCj4NCj4gSSB0aGluayB0aGlzIG1heSBiZSBhIGZ1bmRhbWVudGFsIGRpZmZlcmVu Y2UgaW4gYXNzdW1wdGlvbnMuIFdoaWxlIGl0DQo+IGlzIGNlcnRhaW5seSB0cnVlIHRoYXQgZGVn cmFkYXRpb24gb2YgYSBzaWduYWwgaXMgYSBjb250aW51b3VzIHZhcmlhYmxlLA0KPiBpbiB0aGUg Y29udGV4dCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZyBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmss IHRoZXJlDQo+IGlzIGEgcGFydGljdWxhciB2YWx1ZSBvZiB0aGF0IGNvbnRpbnVvdXMgdmFyaWFi bGUgdGhhdCBkZWZpbmVzIHRoZQ0KPiB0aHJlc2hvbGQgYXQgd2hpY2ggdGhlIEJvb2xlYW4gdmFy aWFibGUgInNpZ25hbCBkZWdyYWRlIChTRCkiIGJlY29tZXMNCj4gdHJ1ZS4gSXQgaXMgZm9yIHRo aXMgcmVhc29uIHRoYXQgSmVvbmctZG9uZyBhbmQgb3RoZXJzIGFyZSBzdWdnZXN0aW5nDQo+IHRo YXQgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGluY29ycG9yYXRlIHRoZSBiZWhhdmlvciBvZiB0 aGUgU0Qgc3RhdGUNCj4gaW50byB0aGUgUFNDIGRlZmluaXRpb24gd2l0aG91dCBuZWVkaW5nIHRv IGhhdmUgYSBwcmVjaXNlIGRlZmluaXRpb24gb2YNCj4gdGhlIG1lY2hhbmlzbSBmb3IgbWVhc3Vy aW5nIHRoZSBkZWdyYWRhdGlvbiBvZiBhIHNpZ25hbC4gV2hhdGV2ZXIgdGhlDQo+IG1lY2hhbmlz bSBpcywgaXQgd2lsbCBiZSBjb252ZXJ0ZWQgdG8gdGhlIGJpbmFyeSBTRCBpbmRpY2F0aW9uLg0K Pg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFRvbQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKQ0KPiBTZW50 OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgODozNiBBTQ0KPiBUbzogUnlvbywgSmVvbmctZG9uZzsg RCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsgbXBsc0BpZXRmLm9yZw0KPiBDYzogSHV1 YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSk7IGh1dWJhdHdvcmtAZ21h aWwuY29tDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmlu ZyBNUExTLVRQIFBTQyBsaW5lYXINCj4gcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzDQo+DQo+IEhpIEplb25nLWRvbmcsDQo+DQo+IFRoYW5rcyBmb3IgdGhlIHJl cGx5LiBQbGVhc2Ugc2VlIGlubGluZSB3aXRoIEVPIy4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJ5b28sIEplb25nLWRvbmcgW21haWx0bzpyeW9vQGV0cmku cmUua3JdDQo+ID4gU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDQ6MTUgQU0NCj4gPiBUbzog RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87 DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IENjOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2 b29ydEBodWF3ZWkuY29tKTsgaHV1YmF0d29ya0BnbWFpbC5jb20NCj4gPiBTdWJqZWN0OiBSRTog W21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+ ID4gcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzDQo+ID4NCj4g PiBIaSwgRXJpYy4NCj4gPg0KPiA+IExldCBtZSBhbnN3ZXIgeW91ciAybmQgcXVlc3Rpb24gb24g U0QuDQo+ID4NCj4gPiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBkZWZpbmVkIG9yIHByb3Bvc2VkIGZv ciBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzDQo+ID4gY2FuIGJlIHN1bW1hcml6ZWQgYXMgZm9s bG93czoNCj4gPiAtIEJ5IE9BTSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIHRvb2w6DQo+ID4gU0Qg aXMgcmFpc2VkIGlmIHBhY2tldCBsb3NzIHJhdGlvIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5n IGENCj4gPiBtZWFzdXJlbWVudCBwZXJpb2QuDQo+ID4gVGhyZXNob2xkIHZhbHVlIGFuZCBtZWFz dXJlbWVudCBwZXJpb2QgYXJlIGNvbmZpZ3VyZWQgYnkgYW4gbmV0d29yaw0KPiA+IG9wZXJhdG9y Lg0KPiA+IFRoaXMgZGV0ZWN0aW9uIG1ldGhvZCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gSVRVLVQg Ry44MDIxIChFdGhlcm5ldA0KPiA+IGVxdWlwbWVudCBzcGVjLikNCj4NCj4NCj4gRU8jIFdoZXJl PyBJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2aW5n IGENCj4gaGFyZCB0aW1lIGZpbmRpbmcgaXQuIEEgc2VhcmNoIGZvciBFVEhfQ0lfU1NEIGRvZXNu J3QgeWllbGQgbXVjaC4gSWYgSQ0KPiBsb29rIGZvciAnc2lnbmFsIGRlZ3JhZGUnIEkgc2VlIHAu IDEzMSB3aGljaCBzYXlzIHRoYXQgdGhlIGFsZ29yaXRobSBpcw0KPiBkZWZpbmVkIGluIEcuODAz MS4gRy44MDMxIHNheXMgJyBIb3cgdGhlc2UgZGVmZWN0cyBhcmUgZGV0ZWN0ZWQgaXMgdGhlDQo+ IHN1YmplY3Qgb2YgdGhlIGVxdWlwbWVudCBSZWNvbW1lbmRhdGlvbnMnLiBJJ20gbG9va2luZyBm b3Igc29tZXRoaW5nDQo+IGxpa2UgIlNpZ25hbCBEZWdyYWRlIGlzIGRlZmluZWQgYXMgJGZvbyBw YWNrZXQgbG9zcyBvciBDUkMgZmFpbHVyZSBvdmVyDQo+ICRiYXIgdGltZSIuLi4ud2hhdCBoYXZl IEkgbWlzc2VkPw0KPg0KPg0KPiA+IGFuZCB0aGUgZXF1aXBtZW50IHNwZWMgZm9yIE1QTFMtVFAg Y2FuIGVhc2lseSBmb2xsb3cgdGhlIHNhbWUNCj4gPiBkZWZpbml0aW9uLg0KPiA+IC0gQnkgc2Vy dmVyIGxheWVyIGluZGljYXRpb246DQo+ID4gU0QgaXMgcmFpc2VkIGlmIGEgc2VydmVyIGxheWVy IGJlbG93IE1QTFMtVFAgcmVwb3J0cyBTRCBjb25kaXRpb24gb24NCj4gPiBpdHMgb3duIGxheWVy Lg0KPiA+IC0gQnkgQ0NNIHBhY2tldCBjb3VudGluZzoNCj4gPiBTRCBpcyByYWlzZWQgaWYgdGhl IGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhjZWVkcyBhIHRocmVzaG9sZA0KPiA+IGR1cmlu ZyBhIG1lYXN1cmVtZW50IHBlcmlvZC4NCj4gPg0KPiA+IFJlZ2FyZGxlc3Mgb2YgaG93IHRvIGRl dGVjdCBTRCwgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50cw0KPiA+IHNob3VsZCBk ZXNjcmliZSB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb3BlcmF0aW9uIG9uY2Ugc3VjaCBhIFNE IGlzDQo+ID4gZGVjbGFyZWQuDQo+ID4NCj4gLi4uDQo+ID4gUmVnYXJkaW5nIHRoZSBtdWx0aXBs ZSBsZXZlbHMgb2YgU0Q6DQo+ID4gSXQgaXMgY2VydGFpbmx5IHBvc3NpYmxlIHRvIGRlZmluZSBt dWx0aXBsZSBsZXZlbHMgb2YgU0QuDQo+ID4gQnV0LCBhcyBmYXIgYXMgdGhlIHByb3RlY3Rpb24g c3dpdGNoaW5nIGlzIGNvbmNlcm5lZCwgaXQganVzdCBuZWVkcyB0bw0KPiA+IGtub3cgaWYgU0Qg aXMgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2VzcyBvciBub3QuDQo+ID4g SXQgd291bGQgYmUgYSBuZXR3b3JrIG9wZXJhdG9yJ3MgY2hvaWNlIGF0IHdoYXQgbGV2ZWwgb2Yg U0QgaGUgd2FudHMNCj4gPiBoaXMgbmV0d29yayBwcm90ZWN0aW9uIHRvIHN3aXRjaG92ZXIuDQo+ ID4gSW4gb3RoZXIgd29yZHMsIHdoYXQgdHJpZ2dlcnMgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMg U0Qgb3Igbm8gU0QuIEl0DQo+ID4gaXMgeWVzIG9yIG5vIGRlY2lzaW9uLg0KPg0KPg0KPiBFTyMg SSBhbSBub3QgYXdhcmUgb2YgYW55IGRvY3VtZW50IHdoaWNoIHN1Z2dlc3RzIHRoYXQgYSBzZXJ2 ZXIgbGF5ZXINCj4gU0Qgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYSBjbGllbnQgbGF5ZXIgU0QuIElu IHRoZSBJUCB3b3JsZCwgaWYgd2UgaGF2ZQ0KPiBTRCBvbiBhIHRyYW5zcG9ydCBpbnRlcmZhY2Ug dGhhdCBpcyBnZW5lcmFsbHkgdXNlZCB0byBicmluZyB0aGUNCj4gaW50ZXJmYWNlIGRvd24gKGku ZS4gU0YpLiBUaGlzIGlzIHRoZSBzb3J0IG9mIHRoaW5nIEknZCBsaWtlIHRvIHNlZSBpbg0KPiBt b3JlIGRldGFpbCwgYXMgU0QgaW4gdGhlIHBhY2tldCB3b3JsZCBpcyBhIG5ldyBjb25jZXB0IGFu ZCB3ZSBjYW4ndA0KPiBqdXN0IGFzc3VtZSB0aGF0IGl0IHdpbGwgd29yayB0aGUgc2FtZSBldmVy eXdoZXJlIGJlY2F1c2Ugd2UgZGVmaW5lDQo+IHN0YXRlIG1hY2hpbmUgcG9pbnRzIGZvciBpdC4N Cj4NCj4gVGhlIHBvaW50IGFib3V0IENDTSBpcyBhIGdvb2Qgb25lLiBMZXQncyBzYXkgd2UgY29t ZSB1cCB3aXRoIGEgY2xldmVyDQo+IFNEIG1lY2hhbmlzbSB3aXRoIHR3byB0aHJlc2hvbGRzLCBj YWxsIHRoZW0gbWFqb3IgYW5kIG1pbm9yLiBGb3INCj4gZGlzY3Vzc2lvbiBwdXJwb3NlcyB0aGV5 IGNvdWxkIGJlIHNpbXBsZSBlcnJvciByYXRpb3MsIGUuZy4gMToxMF42IGFuZA0KPiAxOjEwXjku IEJ1dCB0aGV5IGNvdWxkIGJlIG1vcmUgcG93ZXJmdWwgdGhhbiB0aGF0IChmbG93IHR5cGUsIGZs b3cNCj4gbGVuZ3RoLCBlcnJvciBidXJzdCBzaXplLCBldGMpLg0KPg0KPiBJZiB3ZSB3YW50IHRv IGhhdmUgU0QtTWFqb3IgYW5kIFNELU1pbm9yIGlucHV0cyBhcyBzZXBhcmF0ZSB0cmlnZ2VycyBm b3INCj4gUFNDLCB3ZSBtYXkgd2FudCB0aGVtIGF0IGRpZmZlcmVudCBwb2ludHMuIFBlcmhhcHMg KGxlYXZpbmcgb3V0IHRoZQ0KPiBXb3JraW5nIHBhdGggZm9yIGVhc2Ugb2YgcmVhZGluZykNCj4N Cj4gTE8NCj4gRlMNCj4gU0YtUA0KPiBTRC1QLU1ham9yDQo+IE1TDQo+IFNELVAtTWlub3INCj4N Cj4NCj4gVGhpcyBzZWVtcyBsaWtlIGEgcGVyZmVjdGx5IHJlYXNvbmFibGUgdGhpbmcgdG8gd2Fu dC4NCj4NCj4NCj4gRXZlbiBpZiB3ZSBkb24ndCBoYXZlIG11bHRpLXRpZXIgU0QsIGV2ZW4gdGhl IHNpbmdsZS10aWVyIFNEIG5lZWRzIHRvIGJlDQo+IGRlZmluZWQgYmVmb3JlIHdlIGNhbiBkZWNp ZGUgaG93IHRvIHJlc3BvbmQgdG8gaXQuDQo+DQo+ID4gVGhlIHByb3Bvc2VkIGRyYWZ0IGNvdmVy cyBTRC10cmlnZ2VyZWQgcHJvdGVjdGlvbiBubyBtYXR0ZXIgd2hhdCBraW5kcw0KPiA+IG9mIFNE IGRldGVjdGlvbiBtZXRob2RzIGFyZSB1c2VkLg0KPiA+DQo+ID4NCj4gPiBTRiBjYW4gYWxzbyBi ZSB2aWV3ZWQgYXMgaGF2aW5nIG11bHRpcGxlIGxldmVscyBvZiBTRiBhcyB0aGUgbmV0d29yaw0K PiA+IG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZh bCBvZiBDQ00NCj4gbWVzc2FnZXMuDQo+DQo+DQo+IEVPIw0KPiBJJ20gbm90IHN1cmUgd2hhdCB0 aGF0IHdvdWxkIGxvb2sgbGlrZS4gJ0ZhaWwnIGlzIGEgcHJldHR5IGJpbmFyeQ0KPiB0aGluZy4g J0RlZ3JhZGUnIGlzIGEgY29udGludW91cyB2YXJpYWJsZSwgYXMgaXQgY2FuIGJlIGFueXRoaW5n IGZyb20NCj4gJ2EgbGl0dGxlIGJhZCcgdG8gYSAnYSB3aG9sZSBsb3Qgb2YgYmFkIGJ1dCBub3Qg cXVpdGUgZmFpbCcuDQo+DQo+ID4gSWYgQ0NNIGlzIGRpc2FibGVkLCBBSVMgZnJvbSBhIHNlcnZl ciBsYXllciBjYW4gYmUgdXNlZCBhcyBhIHRyaWdnZXINCj4gPiBmb3IgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcuIFNvIGFuZCBzbyBmb3J0aC4NCj4NCj4gRU8jIEFJUyBmcm9tIHRoZSBzZXJ2ZXIgbGF5 ZXIgb25seSBnZXRzIHlvdSBTRCBmcm9tIHRoZSBmaXJzdCBob3Agb2YNCj4gdGhlIHVuZGVybHlp bmcgc2VydmVyIHBhdGguDQo+DQo+DQo+DQo+DQo+IGVyaWMNCj4NCj4gPiBIb3dldmVyLCBwcm90 ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGRldGVjdA0K PiA+IFNGIGluIGFueXdoZXJlLg0KPiA+IFNpbWlsYXJ5LCBwcm90ZWN0aW9uIHN3aXRjaGluZyBk b2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IG1hbnVhbA0KPiA+IHN3aXRjaCBhbmQgZm9yY2Vk IHN3aXRjaCBjb21tYW5kcyBhcmUgaW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW0NCj4g PiBhbmQgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2Vzcy4NCj4gPg0KPiA+ IEFnYWluLCBpbiBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlvbiBjYW4gYWNj b21tb2RhdGUgYW55DQo+ID4gU0QgZGV0ZWN0aW9uIG1ldGhvZHMuDQo+ID4NCj4gPiBCZXN0IHJl Z2FyZHMsDQo+ID4NCj4gPiBKZW9uZy1kb25nDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IEZyb20gOiAi RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkiIFNlbnQgOg0KPiA+IDIwMTMtMDctMjAgMDI6NDg6Mjgg KCArMDk6MDAgKSBUbyA6IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPiAsIG1w bHNAaWV0Zi5vcmcNCj4gPiBDYyA6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1 YXdlaS5jb20pDQo+ID4gLCBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiA+IFN1YmplY3QgOiBSZTog W21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3INCj4gPiBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5l YXIgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQNCj4gPiByZXF1aXJlbWVudHMNCj4g Pg0KPiA+DQo+ID4gSGkgQWxlc3NhbmRyby0NCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhpczsgdGhl IHRocmVhZHMgSSBzdGFydGVkIHNvbWUgdGltZSBiYWNrIHNlZW0gdG8gaGF2ZQ0KPiA+IGRpZWQg ZG93biwgaXQncyBnb29kIHRvIGdldCB0aGVtIGdvaW5nIGFnYWluLg0KPiA+IEkgaGF2ZSB0d28g dGhpbmdzIEkgbmV2ZXIgcXVpdGUgdW5kZXJzdG9vZCwgY2FuIHlvdSBjbGFyaWZ5IHRoZW0gZm9y DQo+IG1lPw0KPiA+DQo+ID4gaSkgY2FuIHlvdSBleHBsYWluIEVYRVIgYXQgYSBoaWdoZXIgbGV2 ZWw/IEknbSBub3QgbG9va2luZyBmb3IgYQ0KPiA+IGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBt YWNoaW5lIGNoYW5nZXMsIGFuZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZQ0KPiA+IG9uZSBsaW5l ICJJdCBhbGxvd3MgdGhlIEZTTSB0byBiZSB0ZXN0ZWQiLiBXZSBoYXZlIGFsbCBvZiB0aGF0IGlu IHRoZQ0KPiA+IGRyYWZ0IGFuZCBpbiB0aGUgZXF1aXZhbGVudCBJVFUgc3BlY3MuDQo+ID4NCj4g PiBXaGF0IEknZCBsaWtlIHRvIHVuZGVyc3RhbmQgYWJvdXQgRVhFUiBpcyB3aGVyZSBpdCBjYW1l IGZyb20uIFRoZSBJVFUNCj4gPiBzcGVjcyB0aGF0IGRlZmluZSBpdCBhcmUgcHJldHR5IGhhcmQg dG8gZm9sbG93LCB0aGV5IHNlZW0gdG8gYXNzdW1lDQo+ID4gdGhlIHJlYWRlciBhbHJlYWR5IGtu b3dzIHdoYXQgRVhFUiBpcyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQNCj4gPiBmZWVs cyB2ZXJ5IG11Y2ggbGlrZSBhIG1lY2hhbmlzbSB1c2VkIHRvIGNhdGNoIGEgdmVyeSBzcGVjaWZp Yw0KPiA+IGltcGxlbWVudGF0aW9uIGJ1ZywgYmFjayB3aGVuIHRyYW5zcG9ydCBnZWFyIHdhcyBm YXIgbGVzcyBkZWJ1Z2dhYmxlDQo+ID4gdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuDQo+ID4NCj4g PiBObyBvdGhlciBzdGF0ZSBtYWNoaW5lcyB0aGF0IEknbSBmYW1pbGlhciB3aXRoIChSU1ZQLCBM RFAsIEJHUCwgT1NQRiwNCj4gPiBJU0lTKSBoYXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVt IGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvciB3aGV0aGVyDQo+ID4gaXQgKndvdWxkKiBiZSBicm9r ZW4gaWYgaWYgd2VyZSwgaW4gdGhlIGZ1dHVyZSwgdG8gYmUgZ2l2ZW4gYQ0KPiA+IHBhcnRpY3Vs YXIgaW5wdXQuIFBhcnQgb2YgbXkgcmVsdWN0YW5jZSB0byBnZXQgYmVoaW5kIEVYRVIgaGFzIGJl ZW4NCj4gPiB0aGF0IEkgZG9uJ3QgZmVlbCBjb21mb3J0YWJsZSB3aXRoIHRoZSBpZGVhIG9mIGtl ZXBpbmcgYSAzMC15ZWFyLW9sZA0KPiA+IHdvcmthcm91bmQgaW4gYSBwcm90b2NvbC4gSXMgdGhl cmUgbW9yZSB0byBpdCB0aGFuIHRoYXQ/IEhhdmUgSQ0KPiA+IG1pc3JlYWQgYW5kIG1pc3VuZGVy c3Rvb2QgRVhFUj8gRG9lcyBtb2Rlcm4gdHJhbnNwb3J0IGdlYXIgZXZlcg0KPiA+IGFjdHVhbGx5 IGRldGVjdCBhIHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3YXNuJ3Qgb2J2aW91cyB0byB0aGUN Cj4gPiBvcGVyYXRvciB1c2luZyBvdGhlciBtZWFucz8NCj4gPg0KPiA+DQo+ID4gaWkpIFdoeSB0 aGUgcHVzaCB0byBzdGFuZGFyZGl6ZSB0aGUgU0Qgc3RhdGUgY2hhbmdlcyBiZWZvcmUgd2UndmUN Cj4gPiBkZWZpbmVkIFNEPyBJIGNlcnRhaW5seSBhZ3JlZSB0aGF0IGhhbmRsaW5nIHNpZ25hbCBk ZWdyYWRlIGlzIGEgZ29vZA0KPiA+IGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0aCBhIGRlZmluaXRp b24gZm9yIGl0IGhhcyBiZWVuIGNoYWxsZW5naW5nLg0KPiA+IFdoYXQgaGFwcGVucyBpZiB3ZSBj aGFuZ2UgdGhlIEZTTSB0byBoYW5kbGUgaXQsIHRoZW4gY29tZSB1cCB3aXRoDQo+ID4gc29tZXRo aW5nIG1vcmUgc29waGlzdGljYXRlZCAoc2F5LCBtdWx0aXBsZSBsZXZlbHMgb2YgU0QpIHRoYXQg ZG9lc24ndA0KPiA+IHF1aXRlIGZpdCB3aXRoIHRoZSBGU00gY2hhbmdlcz8NCj4gPg0KPiA+DQo+ ID4NCj4gPiB0aGFua3MhDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IGVyaWMNCj4gPg0K PiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbXBscy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj4gPiBPZg0KPiA+ID4gRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbw0KPiA+ID4gU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDM6MjMgUE0NCj4gPiA+IFRvOiBtcGxzQGlldGYu b3JnDQo+ID4gPiBDYzogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNv bSk7DQo+ID4gPiBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiA+ID4gU3ViamVjdDogW21wbHNdIHBy b3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+ID4gPiBwcm90 ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCj4gPiA+DQo+ID4gPiBE ZWFyIGFsbCwNCj4gPiA+IHdlIHdvdWxkIGxpa2Ugc29jaWFsaXppbmcgdGhlIGhlcmViZWxvdyBk cmFmdHMgdGhhdCB3ZXJlIHN1Ym1pdHRlZA0KPiA+IHNvbWUNCj4gPiA+IG1vbnRocyBhZ28gd2l0 aCB0aGUgYWltIHRvIGFsaWduIFBTQyBwcm90b2NvbCAoUkZDIDYzNzgpIHRvIElUVS1UDQo+ID4g PiB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzLiBJIHdvdWxkIGFwcHJlY2lhdGUgeW91ciBjb21tZW50 cyBhYm91dCB0aGUNCj4gPiA+IHByb3Bvc2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91cnMuDQo+ ID4gPg0KPiA+ID4gZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwDQo+ID4gPiBkcmFm dC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMA0KPiA+ID4gZHJhZnQtcmhkLW1wbHMt dHAtcHNjLXNkLTAwDQo+ID4gPiBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIC8gZHJhZnQt b3Nib3JuZS1tcGxzLXBzYy1hbGl2ZS0wMA0KPiA+ID4NCj4gPiA+IFRoZSBhYm92ZSBkcmFmdHMg Y292ZXIgbW9zdCBvZiBpdGVtcyBoaWdobGlnaHRlZCBpbiBJVFUtVCBsaWFpc29ucw0KPiA+IGFi b3V0DQo+ID4gPiBQU0MgYW5kIHRoZXkgcHJvcG9zZSBzb2x1dGlvbnMgaW4gbGluZSB3aXRoIE1Q TFMtVFAgdHJhbnNwb3J0DQo+ID4gPiByZXF1aXJlbWVudHMuDQo+ID4gPiBBIGxpc3Qgb2YgbWFp biBsaWFpc29ucyBleGNoYW5nZWQgYmV0d2VlbiBJVFUtVCBhbmQgSUVURiB3aXRoIHRoZQ0KPiA+ ID4gYWltDQo+ID4gdG8NCj4gPiA+IGFsaWduIFBTQyBiZWhhdmlvdXMgd2l0aCBJVFUtVCB0cmFu c3BvcnQgcmVxdWlyZW1lbnRzIGZvciBsaW5lYXINCj4gPiA+IHByb3RlY3Rpb24gYXJlIGdpdmVu IGJlbG93Og0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzExNjIv IChKdW5lIDIwMTIpDQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24v MTIwNS8NCj4gPiA+IChPY3RvYmVyIDIwMTIpDQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTIyOS8NCj4gPiA+IChKYW51YXJ5IDIwMTMpDQo+ID4gPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIzNC8NCj4gPiA+IChGZWJydWFyeSAyMDEz KQ0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyNTYvDQo+ID4g PiAoTWF5IDIwMTMpDQo+ID4gPg0KPiA+ID4gU29tZSBkZXRhaWxzIGFib3UgdGhlIHByb3Bvc2Vk IGRyYWZ0cyBmb3IgYWxpZ24gUFNDIGJlaGF2aW91ciB3aXRoDQo+ID4gPiB0cmFuc3BvcnQgcmVx dWlyZW1lbnRzOg0KPiA+ID4NCj4gPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0w MCBwcm9wb3NlcyBzd2FwcGluZyB0aGUgcHJpb3JpdGllcw0KPiA+ID4gYmV0d2VlbiBGUyBhbmQg U0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIgb2YgcmZjNjM3OCkuDQo+ID4gPiBBbW9uZyB0aGUgb3Ro ZXJzLCBiZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkDQo+ID4g dXBkYXRlDQo+ID4gPiBhcmU6DQo+ID4gPiBVc2UgY2FzZSBBKSBBdCBmaXJzdCwgd29ya2luZyBw YXRoKFdQKSBhbmQgcHJvdGVjdGlvbiBwYXRoKFBQKSBhcmUNCj4gPiA+IG5vcm1hbC4gVGhlbiwg Rm9yY2VkIFN3aXRjaChGUykgY29tbWFuZCBpcyBpc3N1ZWQgZm9yIG1haW50ZW5hbmNlIG9uDQo+ ID4gdGhlDQo+ID4gPiBXUCBhbmQgdGhlIHRyYWZmaWMgbW92ZXMgZnJvbSBXUCB0byBQUC4gV2hl biBTaWduYWwgRmFpbCBvY2N1cnMgb24NCj4gPiA+IFBQLCBzZXJ2aWNlIGNhbm5vdCByZWNvdmVy IGFuZCBpcyBpbnRlcnJ1cHRlZC4gVGhpcyBjb3VsZCBvY2N1ciBmb3INCj4gPiBleGFtcGxlDQo+ ID4gPiBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci4N Cj4gPiA+IFVzZSBjYXNlIEIpIElmIHRoZXJlIGlzIGFuIGV4aXN0aW5nIHNpZ25hbCBmYWlsIG9u IGEgcHJvdGVjdGlvbiBwYXRoDQo+ID4gPiAoU0YtUCksYW5kIEZTIGNvbW1hbmQgaXMgaXNzdWVk IGJ5IGFjY2lkZW50IHRoZSB0cmFmZmljIG9uIFdQIHdpbGwNCj4gPiBtb3ZlDQo+ID4gPiB0byBQ UC4gVGhpcyByZXN1bHRzIGluIGFuIGludGVycnVwdGlvbiBvZiBzZXJ2aWNlIGZyb20gd2hpY2gg eW91DQo+ID4gPiB3aWxsIG5vdCBhdXRvbWF0aWNhbGx5IHJlY292ZXIsIGJlY2F1c2UgUFNDIHNo b3VsZCBub3QgaGF2ZSBzd2l0Y2hlZA0KPiA+ID4gdGhlIHRyYWZmaWMgZnJvbSBXUCB0byBQUC4N Cj4gPiA+IERpc2N1c3Npb24gYWJvdXQgdGhpcyBkcmFmdCBsZWQgdG8gdGhlIHByb3Bvc2FsIHRv IG1vZGlmeSBSRkMgNDQyNw0KPiA+IHRoYXQNCj4gPiA+IHdhcyAid3JpdHRlbiBjb3JyZWN0bHkg dGhvdWdoIGxhY2tpbmcgaW4gZGV0YWlsIGNhdXNpbmcgbWlzLQ0KPiA+ID4gaW50ZXJwcmV0YXRp b24iIHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBTQyBzZXQgb2YgcHJpb3JpdHkgdGhhdCB0aGUN Cj4gPiA+IGFib3ZlIGRyYWZ0IGlzIHByb3Bvc2luZyB0byBtb2RpZmllZCBhbmQgdG8gYWxpZ24g dG8gdGhlIHJlcXVpcmVkDQo+ID4gPiB0cmFuc3BvcnQgYmVoYXZpb3IuIGRyYWZ0LWhlbHZvb3J0 LWNjYW1wLWZzLXByaW9yaXR5LTAwIGhhcyBiZWVuDQo+ID4gPiBzdWJtaXR0ZWQgdG8gQ0NBTVAg Zm9yIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0ZWQgdG8gTWFudWFsDQo+ID4gPiBT d2l0Y2ggYW5kIEZvcmNlZCBTd2l0Y2ggYW5kIHRoZWlyIHVzYWdlIHJlbGF0aXZlIHRvIHByaW9y aXRpZXMuDQo+ID4gPiBUaGUgd2F5IHRoaXMgYmVoYXZpb3IgaGFzIHRvIGJlIGluY29ycG9yYXRl ZCBpbnRvIHRoZSBQU0MgaGFzIHRvIGJlDQo+ID4gPiBkaXNjdXNzZWQuIFRoZSB0ZXh0IHByb3Bv c2VzIHRvIHJlcGxhY2UgdGhlIGN1cnJlbnQgYmVoYXZpb3Igd2l0aA0KPiA+ID4gdGhlIG5ldyBv bmUuIElmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBwcm9jZWRlIGluIHRoYXQgd2F5IHRoaXMgY2Fu DQo+ID4gPiBicmluZw0KPiA+IHRvDQo+ID4gPiBhIHNpbXBsZSBhbmQgZWZmZWN0aXZlIHdheSB0 byBvcGVyYXRlIHRoZSBwcm90b2NvbC4NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4g LS0NCj4gPiA+IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwIGNvbnRhaW5z IHRoZSB1cGRhdGVzIHRvDQo+ID4gPiBSRkM2Mzc4IHRvIGNoYW5nZSBub24tcmV2ZXJ0aXZlIG9w ZXJhdGlvbnMgdG8gYmVoYXZlcyBpbiB0aGUgc2FtZQ0KPiA+ID4gd2F5IGlycmVzcGVjdGl2ZWx5 IG9mIHRoZSB0cmlnZ2VyIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIChmYXVsdCBvcg0KPiA+IG9w ZXJhdG9yDQo+ID4gPiBjb21tYW5kIEZTLCBNUykuIENvbnNlcXVlbnRseSBhbiBvcGVyYXRvciBj b21tYW5kLCBNYW51YWwgU3dpdGNoIHRvDQo+ID4gPiBXb3JraW5nIChNUy1XKSBhLmsuYSAiTWFu dWFsIHN3aXRjaC1vdmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiIgaXMNCj4gPiBhbHNvDQo+ID4g PiBhZGRlZCB0byBlbmFibGUgdGhpcyBiZWhhdmlvci4gRnJvbSBhbiBvcGVyYXRpb25hbCBwb2lu dCBvZiB2aWV3LCBNUw0KPiA+IHRvDQo+ID4gPiB3b3JraW5nIHBhdGggaGFzIGFsc28gdG8gYmUg c3VwcG9ydGVkIHRvIGJlIGFibGUgdG8gaW5pdGlhbGx5IGFsaWduDQo+ID4gPiBhdCBib3RoIHNp ZGVzIGluIGNhc2Ugb2Ygbm9uLXJldmVydGl2ZSBzd2l0Y2hpbmcgbW9kZS4gTVMgdG8gd29ya2lu Zw0KPiA+ID4gcGF0aCBpcyBkZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My4NCj4g PiA+DQo+ID4gPiBUaGUgcHJvcG9zZWQgTVMtVyBjb21tYW5kIGlzIG9mIGVxdWFsIHByaW9yaXR5 IHRvIHRoZSBleGlzdGluZyBNUy1QDQo+ID4gPiBjb21tYW5kLCBhbmQgdGhlcmUgaXMgdGV4dCB0 byBoYW5kbGUgdGhlIHNpbXVsdGFuZW91cyBvciBzZXF1ZW50aWFsDQo+ID4gPiBvY2N1cnJlbmNl IG9mIHR3byBlcXVhbC1wcmlvcml0eSBjb21tYW5kcy4gVGhpcyBiZWhhdmlvciwgYWxyZWFkeQ0K PiA+ID4gYWRvcHRlZCBpbiBvdGhlciB0cmFuc3BvcnQgbmV0d29yayBwcm90ZWN0aW9uIHN3aXRj aGluZyBwcm90b2NvbCwNCj4gPiA+IGNhbg0KPiA+IGJlDQo+ID4gPiB1c2VkIGZvciBvdGhlciBh ZGRpdGlvbiB0byB0aGUgcHJvdG9jb2wgaW4gdGhlIGZ1dHVyZS4NCj4gPiA+DQo+ID4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+ID4gLS0NCj4gPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMCBwcm92 aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQU0Mgc3RhdGUNCj4gPiA+IG1hY2hpbmUgdG8gaGFuZGxl IFNpZ25hbCBEZWdyYWRlIChTRCkuIEl0IGRvZXMgbm90IGRlZmluZSBTRCBvcg0KPiA+IHByb3Zp ZGUNCj4gPiA+IHNjb3BlIGFyb3VuZCB3aGVyZSBvciBob3cgU0QgbWF5IGJlIHVzZWQgc2ltaWxh cmx5IGFzIGl0IGFscmVhZHkNCj4gPiBoYXBwZW4NCj4gPiA+IGluIHRoZSBkcmFmdCBpbiBoYW5k bGluZyBvdGhlciBkZWZlY3RzIGxpa2UgU0YgKFNpZ25hbCBGYWlsdXJlKS4NCj4gPiA+IEluIE1Q TFMtVFAgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgW1JGQzYzNzJdLCBhIGZhdWx0IGNvbmRpdGlv bg0KPiA+ID4gaW5jbHVkZXMgYm90aCBTaWduYWwgRmFpbCAoU0YpIGFuZCBTaWduYWwgRGVncmFk ZSAoU0QpIHRoYXQgY2FuIGJlDQo+ID4gdXNlZA0KPiA+ID4gdG8gdHJpZ2dlciBwcm90ZWN0aW9u IHN3aXRjaGluZy4NCj4gPiA+IFdoaWxlIHRoZSBzdGFuZGFyZGl6YXRpb24gbGFjayBvZiBhbiBT RCBkZWZpbml0aW9uIGFuZCBkZXRlY3Rpb24NCj4gPiA+IG1lY2hhbmlzbXMsIHRoZSByZWxldmFu dCBiZWhhdmlvcnMgaW4gdGVybXMgb2YgcHJvdGVjdGlvbiBhY3Rpb25zDQo+ID4gPiBtYXkgYWxy ZWFkeSBiZSBkZWZpbmVkLg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtLQ0KPiA+ ID4gZHJhZnQtZGotbXBscy10cC1leGVyLXBzYy0wMSBwcm9wb3NlcyBhZGRpbmcgdGhlIEVYRVIv UlIgY29tbWFuZHMgdG8NCj4gPiA+IHRlc3QgaWYgdGhlIEFQUyBjb21tdW5pY2F0aW9uIGlzIG9w ZXJhdGluZyBjb3JyZWN0bHkuIEluIG90aGVyIHdvcmRzDQo+ID4gPiBib3RoIEFQUyBwcm9jZXNz IGxvZ2ljIGluY2x1ZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBUFMgY2hhbm5lbCBvbg0KPiA+ID4g cHJvdGVjdGlvbiBwYXRoLCB3aXRob3V0IHNlcnZpY2UgZGlzcnVwdGlvbiBhbmQgd2l0aG91dCBh ZmZlY3RpbmcNCj4gPiA+IGFueSBwcm90ZWN0aW9uIG9wZXJhdGlvbiwgdW5sZXNzIHRoZSBwcm90 ZWN0aW9uIHRyYW5zcG9ydCBlbnRpdHkgaXMNCj4gPiA+IGluDQo+ID4gdXNlLg0KPiA+ID4gVGhp cyBjb21tYW5kIGlzIGRvY3VtZW50ZWQgaW4gUjg0IG9mIFtSRkM1NjU0XSBhbmQgaXQgaXMgcGFy dCBvZg0KPiA+ID4gSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4NCj4gPiA+IEFuIGFsdGVy bmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gdGhlIEFwcGVuZGl4IEIgb2YgUkZDNjM3 OA0KPiA+IHRoYXQNCj4gPiA+IHV0aWxpemVzIHRoZSBMb2Nrb3V0IG9mIFByb3RlY3Rpb24gKExP KSBvciBGb3JjZWQgU3dpdGNoIChGUykgaW4NCj4gPiA+IGNvbWJpbmF0aW9uIG9mIE9BTSBmdW5j dGlvbmFsaXRpZXMuIEhvd2V2ZXIsIGl0IGhhcyBzb21lIGZ1bmN0aW9uYWwNCj4gPiA+IGxpbWl0 YXRpb24gYW5kIGhhcyBhIHBvdGVudGlhbCByaXNrIG9mIGxvc2luZyB0cmFmZmljIGFzIGEgc2ln bmFsDQo+ID4gPiBmYWlsdXJlIG1pZ2h0IG9jY3VyIGR1cmluZyB0aGUgZXhlcmNpc2Ugb3BlcmF0 aW9uLiBJbiB0aGF0IGNhc2UsIExPDQo+ID4gPiBvciBGUyBoYXMgdG8gYmUgY2FuY2VsZWQgdG8g YWxsb3cgdGhlIFBTQyBwcm90b2NvbCB0byBwcm92aWRlIHByb3Blcg0KPiA+ID4gc3dpdGNoaW5n Lg0KPiA+ID4gQSBmdXJ0aGVyIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4g ZHJhZnQtb3Nib3JuZS1tcGxzLQ0KPiA+IHBzYy0NCj4gPiA+IGFsaXZlLTAwIHRoYXQgYW55d2F5 IHNob3cgc29tZSBmdW5jdGlvbmFsIGxpbWl0YXRpb25zIGJlY2F1c2UgY2Fubm90DQo+ID4gPiB2 YWxpZGF0ZSB0aGUgUFNDIHN0YXRlIG1hY2hpbmUgc3RhdHVzIGFuZCBwcm9iYWJseSB0aGUgTG9j YWwgUmVxdWVzdA0KPiA+ID4gbG9naWMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBhdXRob3Jz IGVuY291cmFnZSB0aGUgSUVURiBleHBlcnRzIHRvIGNvbW1lbnQgb24gdGhlc2UgZHJhZnRzLA0K PiA+ID4gZXZlbnR1YWxseSBwcm9wb3Npbmcgb3RoZXIgb3B0aW9ucy9tZWNoYW5pc21zIHRoYXQg Y2FuIHNhdGlzZnkgdGhlDQo+ID4gc2FtZQ0KPiA+ID4gcmVxdWlyZW1lbnRzLg0KPiA+ID4gQmVz dCByZWdhcmRzLA0KPiA+ID4gQWxlc3NhbmRybywgSHV1YiwgSmVvbmctZG9uZywgVGFla3NpZCBR dWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pDQo+ID4gPiBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRp IGVzY2x1c2l2YW1lbnRlDQo+ID4gYWxsZQ0KPiA+ID4gcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlm ZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lDQo+ID4gPiBkZXJpdmFudGUg ZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50 ZQ0KPiA+ID4gdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVu dG8gcGVyIGVycm9yZSBzaWV0ZQ0KPiA+ID4gY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUg aW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZQ0KPiA+ID4gZGkgcHJvdnZlZGVy ZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPiA+ID4NCj4gPiA+IFRoaXMgZS1tYWls IGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbg0KPiA+ ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBv bmx5Lg0KPiA+ID4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcw0KPiA+IHVuYXV0aG9yaXNlZC4NCj4gPiA+IElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlDQo+ID4gPiBh bmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls LCBUaGFua3MuDQo+ID4gPg0KPiA+ID4gcmlzcGV0dGEgbCdhbWJpZW50ZVJpc3BldHRhIGwnYW1i aWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZQ0KPiA+IG5vbg0KPiA+ID4gw6ggbmVj ZXNzYXJpby4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBs aXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276804F3SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5FcmljLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPkkgY2FuIHVuZGVyc3RhbmQgeW91ciBwb2ludCwgZXhwZWNpYWxseSZuYnNwO3RoZSBjb21s aWNhdGlvbiBhcm91bmQgbXVsdGlwbGUgY2hvaWNlcyBvZiBTRCBkZXRlY3Rpb24uPC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+SW4gbGluZWFyIHByb3RlY3Rpb24gc3dpdGNoaW5nLCBhbGwgd2Um bmJzcDtjYW4mbmJzcDtkbyBpcyB0byBzZWxlY3Qgb25lIG9mIHR3byBwYXRocyBubyBtYXR0ZXIg aG93IG1hbnkgZGlmZmVyZW50IFNEIGRldGVjdGlvbiBtZXRob2RzIGFuZCBTRCBsZXZlbHMuPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+VGhlcmUmbmJzcDthcmUgbXVsdGlw bGUgaW5wdXRzL3JlcXVlc3RzIGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZywgc3VjaCBhcyBTRiwg TVMsIEZTLCBldGMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+V2hhdCB3 ZSBoYXZlIGRvbmUgc28gZmFyIGlzIHByaW9yaXRpemF0aW9uIG9mJm5ic3A7dGhvc2UgcmVxdWVz dHMsIGFuZCB0aGUgbW9zdCBzZXZlcmUgb25lJm5ic3A7dGFrZXMgb25lIG9mIHR3byBwYXRocyBh cyBpdCB3YW50cy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5JZiB0aGVy ZSBpcyBhIG5lZWQgZm9yJm5ic3A7cHJvdGVjdGlvbiBhZ2FpbnN0Jm5ic3A7bXVsdGlwbGUsIG1v cmUmbmJzcDtzb3BoaXN0aWNhdGVkIFNEcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij53ZSZuYnNwO2NhbiBkZWZpbmUgYSBuZXcgcmVxdWVzdCZuYnNwO3R5cGUgYW5kIHBy aW9yaXR5IGZvciZuYnNwO3RoZSBhZGRpdGlvbmFsIGxldmVsIG9mIFNELjwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiPkN1cnJlbnRseSwmbmJzcDt3ZSBhcmUgZmFjaW5nIGEgZGVtYW5kJm5ic3A7 Zm9yJm5ic3A7cHJvdGVjdGlvbiBtZWNoYW5pc20mbmJzcDthZ2FpbnN0IG9uZSBTRCBsZXZlbCwg d2hpY2ggaGFzIGJlZW4gdGhlIGNhc2UgZm9yIHNvIGxvbmcgdGltZSBzaW5jZSBTREguPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Rm9yJm5ic3A7YWxsIHRoZSBleGlzdGlu ZyBwcm90ZWN0aW9uIHRlY2hub2xvZ2llcyBpbmNsdWRpbmcgRXRoZXJuZXQsIFNEIGZyb20gcHJv dGVjdGlvbiBwb2ludCBvZiB2aWV3IGhhcyBhbHdheXMgYmVlbiBhIGJpbmFyeSBkZWNpc2lvbi48 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5MZXQncyB3b3JrIG9uIHN1cHBv cnRpbmcgb25lIFNEIGxldmVsLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJlc3QgcmVnYXJk cyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtFcmljIE9zYm9ybmUgKGVv c2Jvcm5lKSZxdW90OyAmbHQ7ZW9zYm9ybmVAY2lzY28uY29tJmd0Ozxicj4NCjxiPlNlbnQgOiA8 L2I+MjAxMy0wNy0yMyAwNToxMjozNSAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPkh1 YmVyLCBUaG9tYXMgSi4gJmx0O1RvbS5IdWJlckB0ZWxsYWJzLmNvbSZndDssIFJ5b28sIEplb25n LWRvbmcgJmx0O3J5b29AZXRyaS5yZS5rciZndDssIEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdl cmFyZG8gJmx0O2FsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdCZndDssIG1w bHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+SHV1YiBo ZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSkgJmx0O2h1dWIudmFuLmhlbHZv b3J0QGh1YXdlaS5jb20mZ3Q7LCBodXViYXR3b3JrQGdtYWlsLmNvbSAmbHQ7aHV1YmF0d29ya0Bn bWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5SRTogW21wbHNdIHByb3Bvc2VkIGRy YWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wg dG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50czxicj4NCjxicj4NCkhpIFRvbS08YnI+DQo8YnI+DQo8 YnI+DQpUaGF0J3MgYSBnb29kIHdheSB0byBwdXQgaXQsIGFuZCBJIHRoaW5rIGl0IGNhcHR1cmVz IHRoZSB0d28gb3BpbmlvbnMuIE15IGNvbmNlcm4gd2l0aCB0aGUgYm9vbGVhbiBTRCBhcHByb2Fj aCBpcyB0aGF0IGl0J3MgYmVlbiBhIHN0cnVnZ2xlIHRvIGRlZmluZSBTRCBhdCBhbGwgZm9yIElQ L01QTFMgbmV0d29ya3MuIEkgY2FuIGVjaG8gSmVvbmctRG9uZydzIHBvaW50IGhlcmUgLSBTRCBj b3VsZCBiZSBzZXJ2ZXIgU0QgW1NTRF0sIGl0IGNvdWxkDQogYmUgUE0sIGl0IGNvdWxkIGJlIEND TS4gVW5sZXNzIHdlIGFjdHVhbGx5IGRlZmluZSBTRCwgaXQncyBub3QgYXQgYWxsIGNsZWFyIHRv IG1lIHRoYXQgSVAgU0Qgd2lsbCBpbiBmYWN0IGJlIGEgc2ltcGxlIHllcy9ubyB0aGluZy4gV2hh dCBpZiB3ZSBkZWNpZGUgdGhhdCBib3RoIFBNIGFuZCBTU0QgYXJlIHZhbGlkLCBidXQgdGhhdCBv bmUgb2YgdGhlbSBpcyB3b3JzZSB0aGFuIHRoZSBvdGhlcj8NCjxicj4NCjxicj4NCkp1c3Qgc28g d2UncmUgY2xlYXIgLSBJIGFtIG5vdCBhZ2FpbnN0IHRoZSBjb25jZXB0IG9mIFNEIGluIFBTQy4g SSBhbSBhZ2FpbnN0IGRlZmluaW5nIGhvdyB3ZSByZWFjdCB0byBhbiBldmVudCBiZWZvcmUgd2Ug ZGVmaW5lIHRoZSBldmVudCBpdHNlbGYuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KZXJp Yzxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7IEZyb206IEh1YmVyLCBUaG9tYXMgSi4gW21haWx0bzpUb20uSHViZXJAdGVsbGFicy5jb21d PGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzowNCBQTTxicj4NCiZndDsg VG86IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBSeW9vLCBKZW9uZy1kb25nOyBEJ0FsZXNzYW5k cm8gQWxlc3NhbmRybzxicj4NCiZndDsgR2VyYXJkbzsgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsg Q2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pOyBodXViYXR3 b3JrQGdtYWlsLmNvbTxicj4NCiZndDsgU3ViamVjdDogUkU6IFttcGxzXSBwcm9wb3NlZCBkcmFm dHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcjxicj4NCiZndDsgcHJvdGVjdGlvbiBw cm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhp IEVyaWMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlvdSB3cm90ZTo8YnI+DQomZ3Q7ICZndDtFTyM8 YnI+DQomZ3Q7ICZndDtJJ20gbm90IHN1cmUgd2hhdCB0aGF0IHdvdWxkIGxvb2sgbGlrZS4gJ0Zh aWwnIGlzIGEgcHJldHR5IGJpbmFyeTxicj4NCiZndDsgdGhpbmcuICdEZWdyYWRlJyBpcyBhIGNv bnRpbnVvdXMgdmFyaWFibGUsIGFzIGl0IGNhbiBiZSBhbnl0aGluZyBmcm9tPGJyPg0KJmd0OyAn YSBsaXR0bGUgYmFkJyB0byBhICdhIHdob2xlIGxvdCBvZiBiYWQgYnV0IG5vdCBxdWl0ZSBmYWls Jy48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGlzIG1heSBiZSBhIGZ1bmRhbWVudGFs IGRpZmZlcmVuY2UgaW4gYXNzdW1wdGlvbnMuIFdoaWxlIGl0PGJyPg0KJmd0OyBpcyBjZXJ0YWlu bHkgdHJ1ZSB0aGF0IGRlZ3JhZGF0aW9uIG9mIGEgc2lnbmFsIGlzIGEgY29udGludW91cyB2YXJp YWJsZSw8YnI+DQomZ3Q7IGluIHRoZSBjb250ZXh0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlu IHRoZSB0cmFuc3BvcnQgbmV0d29yaywgdGhlcmU8YnI+DQomZ3Q7IGlzIGEgcGFydGljdWxhciB2 YWx1ZSBvZiB0aGF0IGNvbnRpbnVvdXMgdmFyaWFibGUgdGhhdCBkZWZpbmVzIHRoZTxicj4NCiZn dDsgdGhyZXNob2xkIGF0IHdoaWNoIHRoZSBCb29sZWFuIHZhcmlhYmxlICZxdW90O3NpZ25hbCBk ZWdyYWRlIChTRCkmcXVvdDsgYmVjb21lczxicj4NCiZndDsgdHJ1ZS4gSXQgaXMgZm9yIHRoaXMg cmVhc29uIHRoYXQgSmVvbmctZG9uZyBhbmQgb3RoZXJzIGFyZSBzdWdnZXN0aW5nPGJyPg0KJmd0 OyB0aGF0IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBpbmNvcnBvcmF0ZSB0aGUgYmVoYXZpb3Ig b2YgdGhlIFNEIHN0YXRlPGJyPg0KJmd0OyBpbnRvIHRoZSBQU0MgZGVmaW5pdGlvbiB3aXRob3V0 IG5lZWRpbmcgdG8gaGF2ZSBhIHByZWNpc2UgZGVmaW5pdGlvbiBvZjxicj4NCiZndDsgdGhlIG1l Y2hhbmlzbSBmb3IgbWVhc3VyaW5nIHRoZSBkZWdyYWRhdGlvbiBvZiBhIHNpZ25hbC4gV2hhdGV2 ZXIgdGhlPGJyPg0KJmd0OyBtZWNoYW5pc20gaXMsIGl0IHdpbGwgYmUgY29udmVydGVkIHRvIHRo ZSBiaW5hcnkgU0QgaW5kaWNhdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCByZWdhcmRz LDxicj4NCiZndDsgVG9tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mPGJyPg0KJmd0OyBFcmlj IE9zYm9ybmUgKGVvc2Jvcm5lKTxicj4NCiZndDsgU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEz IDg6MzYgQU08YnI+DQomZ3Q7IFRvOiBSeW9vLCBKZW9uZy1kb25nOyBEJ0FsZXNzYW5kcm8gQWxl c3NhbmRybyBHZXJhcmRvOyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyBDYzogSHV1YiBoZWx2b29y dCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSk7IGh1dWJhdHdvcmtAZ21haWwuY29tPGJy Pg0KJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcg TVBMUy1UUCBQU0MgbGluZWFyPGJyPg0KJmd0OyBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5z cG9ydCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgSmVvbmctZG9uZyw8YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGZvciB0aGUgcmVwbHkuIFBsZWFzZSBzZWUgaW5saW5l IHdpdGggRU8jLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IFJ5b28sIEplb25nLWRvbmcgW21haWx0bzpyeW9v QGV0cmkucmUua3JdPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgSnVseSAyMiwgMjAxMyA0 OjE1IEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgRCdBbGVz c2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzs8YnI+DQomZ3Q7ICZndDsgbXBsc0BpZXRmLm9yZzxi cj4NCiZndDsgJmd0OyBDYzogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2Vp LmNvbSk7IGh1dWJhdHdvcmtAZ21haWwuY29tPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBb bXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXI8YnI+ DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRz PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpLCBFcmljLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBMZXQgbWUgYW5zd2VyIHlvdXIgMm5kIHF1ZXN0aW9uIG9uIFNELjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTRCBkZXRlY3Rpb24gbWV0aG9kcyBkZWZpbmVkIG9y IHByb3Bvc2VkIGZvciBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzPGJyPg0KJmd0OyAmZ3Q7IGNh biBiZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6PGJyPg0KJmd0OyAmZ3Q7IC0gQnkgT0FNIHBlcmZv cm1hbmNlIG1vbml0b3JpbmcgdG9vbDo8YnI+DQomZ3Q7ICZndDsgU0QgaXMgcmFpc2VkIGlmIHBh Y2tldCBsb3NzIHJhdGlvIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVyaW5nIGE8YnI+DQomZ3Q7ICZn dDsgbWVhc3VyZW1lbnQgcGVyaW9kLjxicj4NCiZndDsgJmd0OyBUaHJlc2hvbGQgdmFsdWUgYW5k IG1lYXN1cmVtZW50IHBlcmlvZCBhcmUgY29uZmlndXJlZCBieSBhbiBuZXR3b3JrPGJyPg0KJmd0 OyAmZ3Q7IG9wZXJhdG9yLjxicj4NCiZndDsgJmd0OyBUaGlzIGRldGVjdGlvbiBtZXRob2QgaXMg YWxyZWFkeSBkZWZpbmVkIGluIElUVS1UIEcuODAyMSAoRXRoZXJuZXQ8YnI+DQomZ3Q7ICZndDsg ZXF1aXBtZW50IHNwZWMuKTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEVPIyBXaGVy ZT8gSSdtIG5vdCBhcmd1aW5nIHRoYXQgaXQncyBub3QgaW4gdGhlcmUsIEknbSBqdXN0IGhhdmlu ZyBhPGJyPg0KJmd0OyBoYXJkIHRpbWUgZmluZGluZyBpdC4gQSBzZWFyY2ggZm9yIEVUSF9DSV9T U0QgZG9lc24ndCB5aWVsZCBtdWNoLiBJZiBJPGJyPg0KJmd0OyBsb29rIGZvciAnc2lnbmFsIGRl Z3JhZGUnIEkgc2VlIHAuIDEzMSB3aGljaCBzYXlzIHRoYXQgdGhlIGFsZ29yaXRobSBpczxicj4N CiZndDsgZGVmaW5lZCBpbiBHLjgwMzEuIEcuODAzMSBzYXlzICcgSG93IHRoZXNlIGRlZmVjdHMg YXJlIGRldGVjdGVkIGlzIHRoZTxicj4NCiZndDsgc3ViamVjdCBvZiB0aGUgZXF1aXBtZW50IFJl Y29tbWVuZGF0aW9ucycuIEknbSBsb29raW5nIGZvciBzb21ldGhpbmc8YnI+DQomZ3Q7IGxpa2Ug JnF1b3Q7U2lnbmFsIERlZ3JhZGUgaXMgZGVmaW5lZCBhcyAkZm9vIHBhY2tldCBsb3NzIG9yIENS QyBmYWlsdXJlIG92ZXI8YnI+DQomZ3Q7ICRiYXIgdGltZSZxdW90Oy4uLi53aGF0IGhhdmUgSSBt aXNzZWQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBhbmQgdGhlIGVxdWlw bWVudCBzcGVjIGZvciBNUExTLVRQIGNhbiBlYXNpbHkgZm9sbG93IHRoZSBzYW1lPGJyPg0KJmd0 OyAmZ3Q7IGRlZmluaXRpb24uPGJyPg0KJmd0OyAmZ3Q7IC0gQnkgc2VydmVyIGxheWVyIGluZGlj YXRpb246PGJyPg0KJmd0OyAmZ3Q7IFNEIGlzIHJhaXNlZCBpZiBhIHNlcnZlciBsYXllciBiZWxv dyBNUExTLVRQIHJlcG9ydHMgU0QgY29uZGl0aW9uIG9uPGJyPg0KJmd0OyAmZ3Q7IGl0cyBvd24g bGF5ZXIuPGJyPg0KJmd0OyAmZ3Q7IC0gQnkgQ0NNIHBhY2tldCBjb3VudGluZzo8YnI+DQomZ3Q7 ICZndDsgU0QgaXMgcmFpc2VkIGlmIHRoZSBsb3NzIHJhdGlvIG9mIENDTSBwYWNrZXRzIGV4Y2Vl ZHMgYSB0aHJlc2hvbGQ8YnI+DQomZ3Q7ICZndDsgZHVyaW5nIGEgbWVhc3VyZW1lbnQgcGVyaW9k Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRsZXNzIG9mIGhvdyB0byBkZXRl Y3QgU0QsIGFueSBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudHM8YnI+DQomZ3Q7ICZndDsg c2hvdWxkIGRlc2NyaWJlIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBvcGVyYXRpb24gb25jZSBz dWNoIGEgU0QgaXM8YnI+DQomZ3Q7ICZndDsgZGVjbGFyZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAuLi48YnI+DQomZ3Q7ICZndDsgUmVnYXJkaW5nIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2Yg U0Q6PGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIGNlcnRhaW5seSBwb3NzaWJsZSB0byBkZWZpbmUgbXVs dGlwbGUgbGV2ZWxzIG9mIFNELjxicj4NCiZndDsgJmd0OyBCdXQsIGFzIGZhciBhcyB0aGUgcHJv dGVjdGlvbiBzd2l0Y2hpbmcgaXMgY29uY2VybmVkLCBpdCBqdXN0IG5lZWRzIHRvPGJyPg0KJmd0 OyAmZ3Q7IGtub3cgaWYgU0QgaXMgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJv Y2VzcyBvciBub3QuPGJyPg0KJmd0OyAmZ3Q7IEl0IHdvdWxkIGJlIGEgbmV0d29yayBvcGVyYXRv cidzIGNob2ljZSBhdCB3aGF0IGxldmVsIG9mIFNEIGhlIHdhbnRzPGJyPg0KJmd0OyAmZ3Q7IGhp cyBuZXR3b3JrIHByb3RlY3Rpb24gdG8gc3dpdGNob3Zlci48YnI+DQomZ3Q7ICZndDsgSW4gb3Ro ZXIgd29yZHMsIHdoYXQgdHJpZ2dlcnMgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgU0Qgb3Igbm8g U0QuIEl0PGJyPg0KJmd0OyAmZ3Q7IGlzIHllcyBvciBubyBkZWNpc2lvbi48YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBFTyMgSSBhbSBub3QgYXdhcmUgb2YgYW55IGRvY3VtZW50IHdo aWNoIHN1Z2dlc3RzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXI8YnI+DQomZ3Q7IFNEIHNob3VsZCBiZSB0 cmVhdGVkIGFzIGEgY2xpZW50IGxheWVyIFNELiBJbiB0aGUgSVAgd29ybGQsIGlmIHdlIGhhdmU8 YnI+DQomZ3Q7IFNEIG9uIGEgdHJhbnNwb3J0IGludGVyZmFjZSB0aGF0IGlzIGdlbmVyYWxseSB1 c2VkIHRvIGJyaW5nIHRoZTxicj4NCiZndDsgaW50ZXJmYWNlIGRvd24gKGkuZS4gU0YpLiBUaGlz IGlzIHRoZSBzb3J0IG9mIHRoaW5nIEknZCBsaWtlIHRvIHNlZSBpbjxicj4NCiZndDsgbW9yZSBk ZXRhaWwsIGFzIFNEIGluIHRoZSBwYWNrZXQgd29ybGQgaXMgYSBuZXcgY29uY2VwdCBhbmQgd2Ug Y2FuJ3Q8YnI+DQomZ3Q7IGp1c3QgYXNzdW1lIHRoYXQgaXQgd2lsbCB3b3JrIHRoZSBzYW1lIGV2 ZXJ5d2hlcmUgYmVjYXVzZSB3ZSBkZWZpbmU8YnI+DQomZ3Q7IHN0YXRlIG1hY2hpbmUgcG9pbnRz IGZvciBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHBvaW50IGFib3V0IENDTSBpcyBhIGdv b2Qgb25lLiBMZXQncyBzYXkgd2UgY29tZSB1cCB3aXRoIGEgY2xldmVyPGJyPg0KJmd0OyBTRCBt ZWNoYW5pc20gd2l0aCB0d28gdGhyZXNob2xkcywgY2FsbCB0aGVtIG1ham9yIGFuZCBtaW5vci4g Rm9yPGJyPg0KJmd0OyBkaXNjdXNzaW9uIHB1cnBvc2VzIHRoZXkgY291bGQgYmUgc2ltcGxlIGVy cm9yIHJhdGlvcywgZS5nLiAxOjEwXjYgYW5kPGJyPg0KJmd0OyAxOjEwXjkuIEJ1dCB0aGV5IGNv dWxkIGJlIG1vcmUgcG93ZXJmdWwgdGhhbiB0aGF0IChmbG93IHR5cGUsIGZsb3c8YnI+DQomZ3Q7 IGxlbmd0aCwgZXJyb3IgYnVyc3Qgc2l6ZSwgZXRjKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYg d2Ugd2FudCB0byBoYXZlIFNELU1ham9yIGFuZCBTRC1NaW5vciBpbnB1dHMgYXMgc2VwYXJhdGUg dHJpZ2dlcnMgZm9yPGJyPg0KJmd0OyBQU0MsIHdlIG1heSB3YW50IHRoZW0gYXQgZGlmZmVyZW50 IHBvaW50cy4gUGVyaGFwcyAobGVhdmluZyBvdXQgdGhlPGJyPg0KJmd0OyBXb3JraW5nIHBhdGgg Zm9yIGVhc2Ugb2YgcmVhZGluZyk8YnI+DQomZ3Q7IDxicj4NCiZndDsgTE88YnI+DQomZ3Q7IEZT PGJyPg0KJmd0OyBTRi1QPGJyPg0KJmd0OyBTRC1QLU1ham9yPGJyPg0KJmd0OyBNUzxicj4NCiZn dDsgU0QtUC1NaW5vcjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgc2VlbXMg bGlrZSBhIHBlcmZlY3RseSByZWFzb25hYmxlIHRoaW5nIHRvIHdhbnQuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgRXZlbiBpZiB3ZSBkb24ndCBoYXZlIG11bHRpLXRpZXIgU0QsIGV2 ZW4gdGhlIHNpbmdsZS10aWVyIFNEIG5lZWRzIHRvIGJlPGJyPg0KJmd0OyBkZWZpbmVkIGJlZm9y ZSB3ZSBjYW4gZGVjaWRlIGhvdyB0byByZXNwb25kIHRvIGl0Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyAmZ3Q7IFRoZSBwcm9wb3NlZCBkcmFmdCBjb3ZlcnMgU0QtdHJpZ2dlcmVkIHByb3RlY3Rpb24g bm8gbWF0dGVyIHdoYXQga2luZHM8YnI+DQomZ3Q7ICZndDsgb2YgU0QgZGV0ZWN0aW9uIG1ldGhv ZHMgYXJlIHVzZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IFNGIGNhbiBhbHNvIGJlIHZpZXdlZCBhcyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFz IHRoZSBuZXR3b3JrPGJyPg0KJmd0OyAmZ3Q7IG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9p Y2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ008YnI+DQomZ3Q7IG1lc3NhZ2VzLjxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEVPIzxicj4NCiZndDsgSSdtIG5vdCBzdXJlIHdo YXQgdGhhdCB3b3VsZCBsb29rIGxpa2UuICdGYWlsJyBpcyBhIHByZXR0eSBiaW5hcnk8YnI+DQom Z3Q7IHRoaW5nLiAnRGVncmFkZScgaXMgYSBjb250aW51b3VzIHZhcmlhYmxlLCBhcyBpdCBjYW4g YmUgYW55dGhpbmcgZnJvbTxicj4NCiZndDsgJ2EgbGl0dGxlIGJhZCcgdG8gYSAnYSB3aG9sZSBs b3Qgb2YgYmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg SWYgQ0NNIGlzIGRpc2FibGVkLCBBSVMgZnJvbSBhIHNlcnZlciBsYXllciBjYW4gYmUgdXNlZCBh cyBhIHRyaWdnZXI8YnI+DQomZ3Q7ICZndDsgZm9yIHByb3RlY3Rpb24gc3dpdGNoaW5nLiBTbyBh bmQgc28gZm9ydGguPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEVPIyBBSVMgZnJvbSB0aGUgc2VydmVy IGxheWVyIG9ubHkgZ2V0cyB5b3UgU0QgZnJvbSB0aGUgZmlyc3QgaG9wIG9mPGJyPg0KJmd0OyB0 aGUgdW5kZXJseWluZyBzZXJ2ZXIgcGF0aC48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgZXJpYzxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhv d2V2ZXIsIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cg dG8gZGV0ZWN0PGJyPg0KJmd0OyAmZ3Q7IFNGIGluIGFueXdoZXJlLjxicj4NCiZndDsgJmd0OyBT aW1pbGFyeSwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGhv dyBtYW51YWw8YnI+DQomZ3Q7ICZndDsgc3dpdGNoIGFuZCBmb3JjZWQgc3dpdGNoIGNvbW1hbmRz IGFyZSBpbml0aWF0ZWQgaW4gYSBtYW5hZ2VtZW50IHN5c3RlbTxicj4NCiZndDsgJmd0OyBhbmQg c2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvY2Vzcy48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgQWdhaW4sIGluIG15IG9waW5pb24sIHRoZSBkcmFmdCBvbiBTRCBwcm90 ZWN0aW9uIGNhbiBhY2NvbW1vZGF0ZSBhbnk8YnI+DQomZ3Q7ICZndDsgU0QgZGV0ZWN0aW9uIG1l dGhvZHMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSmVvbmctZG9uZzxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBGcm9tIDogJnF1b3Q7RXJpYyBPc2Jvcm5l IChlb3Nib3JuZSkmcXVvdDsgPEVPU0JPUk5FQENJU0NPLkNPTT5TZW50IDo8YnI+DQomZ3Q7ICZn dDsgMjAxMy0wNy0yMCAwMjo0ODoyOCAoICYjNDM7MDk6MDAgKSBUbyA6IEQnQWxlc3NhbmRybyBB bGVzc2FuZHJvIEdlcmFyZG88YnI+DQomZ3Q7ICZndDsgPEFMRVNTQU5EUk8uREFMRVNTQU5EUk9A VEVMRUNPTUlUQUxJQS5JVD4sIG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgPE1QTFNASUVU Ri5PUkc+Q2MgOiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tKTxi cj4NCiZndDsgJmd0OyA8SFVVQi5WQU4uSEVMVk9PUlRASFVBV0VJLkNPTT4sIGh1dWJhdHdvcmtA Z21haWwuY29tPGJyPg0KJmd0OyAmZ3Q7IDxIVVVCQVRXT1JLQEdNQUlMLkNPTT5TdWJqZWN0IDog UmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yPGJyPg0KJmd0OyAmZ3Q7IGFsaWduaW5nIE1Q TFMtVFAgUFNDIGxpbmVhciBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydDxicj4NCiZn dDsgJmd0OyByZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgSGkgQWxlc3NhbmRyby08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhh bmtzIGZvciB0aGlzOyB0aGUgdGhyZWFkcyBJIHN0YXJ0ZWQgc29tZSB0aW1lIGJhY2sgc2VlbSB0 byBoYXZlPGJyPg0KJmd0OyAmZ3Q7IGRpZWQgZG93biwgaXQncyBnb29kIHRvIGdldCB0aGVtIGdv aW5nIGFnYWluLjxicj4NCiZndDsgJmd0OyBJIGhhdmUgdHdvIHRoaW5ncyBJIG5ldmVyIHF1aXRl IHVuZGVyc3Rvb2QsIGNhbiB5b3UgY2xhcmlmeSB0aGVtIGZvcjxicj4NCiZndDsgbWU/PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGkpIGNhbiB5b3UgZXhwbGFpbiBFWEVSIGF0IGEgaGln aGVyIGxldmVsPyBJJ20gbm90IGxvb2tpbmcgZm9yIGE8YnI+DQomZ3Q7ICZndDsgZGVzY3JpcHRp b24gb2YgdGhlIHN0YXRlIG1hY2hpbmUgY2hhbmdlcywgYW5kIEknbSBub3QgbG9va2luZyBmb3Ig dGhlPGJyPg0KJmd0OyAmZ3Q7IG9uZSBsaW5lICZxdW90O0l0IGFsbG93cyB0aGUgRlNNIHRvIGJl IHRlc3RlZCZxdW90Oy4gV2UgaGF2ZSBhbGwgb2YgdGhhdCBpbiB0aGU8YnI+DQomZ3Q7ICZndDsg ZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBzcGVjcy48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgV2hhdCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hl cmUgaXQgY2FtZSBmcm9tLiBUaGUgSVRVPGJyPg0KJmd0OyAmZ3Q7IHNwZWNzIHRoYXQgZGVmaW5l IGl0IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3csIHRoZXkgc2VlbSB0byBhc3N1bWU8YnI+DQom Z3Q7ICZndDsgdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBpcyBhbmQgd2hhdCBw cm9ibGVtIGl0IHNvbHZlcy4gSXQ8YnI+DQomZ3Q7ICZndDsgZmVlbHMgdmVyeSBtdWNoIGxpa2Ug YSBtZWNoYW5pc20gdXNlZCB0byBjYXRjaCBhIHZlcnkgc3BlY2lmaWM8YnI+DQomZ3Q7ICZndDsg aW1wbGVtZW50YXRpb24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2FzIGZhciBsZXNz IGRlYnVnZ2FibGU8YnI+DQomZ3Q7ICZndDsgdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE5vIG90aGVyIHN0YXRlIG1hY2hpbmVzIHRoYXQgSSdt IGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwgQkdQLCBPU1BGLDxicj4NCiZndDsgJmd0OyBJU0lT KSBoYXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJv ciB3aGV0aGVyPGJyPg0KJmd0OyAmZ3Q7IGl0ICp3b3VsZCogYmUgYnJva2VuIGlmIGlmIHdlcmUs IGluIHRoZSBmdXR1cmUsIHRvIGJlIGdpdmVuIGE8YnI+DQomZ3Q7ICZndDsgcGFydGljdWxhciBp bnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBiZWhpbmQgRVhFUiBoYXMgYmVlbjxi cj4NCiZndDsgJmd0OyB0aGF0IEkgZG9uJ3QgZmVlbCBjb21mb3J0YWJsZSB3aXRoIHRoZSBpZGVh IG9mIGtlZXBpbmcgYSAzMC15ZWFyLW9sZDxicj4NCiZndDsgJmd0OyB3b3JrYXJvdW5kIGluIGEg cHJvdG9jb2wuIElzIHRoZXJlIG1vcmUgdG8gaXQgdGhhbiB0aGF0PyBIYXZlIEk8YnI+DQomZ3Q7 ICZndDsgbWlzcmVhZCBhbmQgbWlzdW5kZXJzdG9vZCBFWEVSPyBEb2VzIG1vZGVybiB0cmFuc3Bv cnQgZ2VhciBldmVyPGJyPg0KJmd0OyAmZ3Q7IGFjdHVhbGx5IGRldGVjdCBhIHByb2JsZW0gdmlh IEVYRVIvUlIgdGhhdCB3YXNuJ3Qgb2J2aW91cyB0byB0aGU8YnI+DQomZ3Q7ICZndDsgb3BlcmF0 b3IgdXNpbmcgb3RoZXIgbWVhbnM/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IGlpKSBXaHkgdGhlIHB1c2ggdG8gc3RhbmRhcmRpemUgdGhlIFNEIHN0YXRlIGNo YW5nZXMgYmVmb3JlIHdlJ3ZlPGJyPg0KJmd0OyAmZ3Q7IGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5 IGFncmVlIHRoYXQgaGFuZGxpbmcgc2lnbmFsIGRlZ3JhZGUgaXMgYSBnb29kPGJyPg0KJmd0OyAm Z3Q7IGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0aCBhIGRlZmluaXRpb24gZm9yIGl0IGhhcyBiZWVu IGNoYWxsZW5naW5nLjxicj4NCiZndDsgJmd0OyBXaGF0IGhhcHBlbnMgaWYgd2UgY2hhbmdlIHRo ZSBGU00gdG8gaGFuZGxlIGl0LCB0aGVuIGNvbWUgdXAgd2l0aDxicj4NCiZndDsgJmd0OyBzb21l dGhpbmcgbW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRpcGxlIGxldmVscyBvZiBTRCkgdGhh dCBkb2Vzbid0PGJyPg0KJmd0OyAmZ3Q7IHF1aXRlIGZpdCB3aXRoIHRoZSBGU00gY2hhbmdlcz88 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgdGhhbmtzITxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBlcmljPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZjxicj4NCiZndDsgJmd0 OyBPZjxicj4NCiZndDsgJmd0OyAmZ3Q7IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG88 YnI+DQomZ3Q7ICZndDsgJmd0OyBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgMzoyMyBQ TTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgQ2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pOzxicj4N CiZndDsgJmd0OyAmZ3Q7IGh1dWJhdHdvcmtAZ21haWwuY29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsg U3ViamVjdDogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0Mg bGluZWFyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3Bv cnQgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBE ZWFyIGFsbCw8YnI+DQomZ3Q7ICZndDsgJmd0OyB3ZSB3b3VsZCBsaWtlIHNvY2lhbGl6aW5nIHRo ZSBoZXJlYmVsb3cgZHJhZnRzIHRoYXQgd2VyZSBzdWJtaXR0ZWQ8YnI+DQomZ3Q7ICZndDsgc29t ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG1vbnRocyBhZ28gd2l0aCB0aGUgYWltIHRvIGFsaWduIFBT QyBwcm90b2NvbCAoUkZDIDYzNzgpIHRvIElUVS1UPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdHJhbnNw b3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYWJvdXQg dGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcHJvcG9zZWQgbWVjaGFuaXNtcyBhbmQgYmVoYXZpb3Vy cy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IGRyYWZ0LXJoZC1tcGxz LXRwLXBzYy1wcmlvcml0eS0wMDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRyYWZ0LWNkaC1tcGxzLXRw LXBzYy1ub24tcmV2ZXJ0aXZlLTAwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZHJhZnQtcmhkLW1wbHMt dHAtcHNjLXNkLTAwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZHJhZnQtZGotbXBscy10cC1leGVyLXBz Yy0wMSAvIGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtYWxpdmUtMDA8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSBhYm92ZSBkcmFmdHMgY292ZXIgbW9zdCBvZiBpdGVt cyBoaWdobGlnaHRlZCBpbiBJVFUtVCBsaWFpc29uczxicj4NCiZndDsgJmd0OyBhYm91dDxicj4N CiZndDsgJmd0OyAmZ3Q7IFBTQyBhbmQgdGhleSBwcm9wb3NlIHNvbHV0aW9ucyBpbiBsaW5lIHdp dGggTVBMUy1UUCB0cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHMuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgQSBsaXN0IG9mIG1haW4gbGlhaXNvbnMgZXhjaGFuZ2VkIGJldHdl ZW4gSVRVLVQgYW5kIElFVEYgd2l0aCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBhaW08YnI+DQom Z3Q7ICZndDsgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyBhbGlnbiBQU0MgYmVoYXZpb3VzIHdpdGgg SVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBmb3IgbGluZWFyPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgcHJvdGVjdGlvbiBhcmUgZ2l2ZW4gYmVsb3c6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzExNjIvIChKdW5lIDIwMTIpPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMDUvPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgKE9jdG9iZXIgMjAxMik8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIyOS88YnI+DQomZ3Q7ICZndDsgJmd0 OyAoSmFudWFyeSAyMDEzKTxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbGlhaXNvbi8xMjM0Lzxicj4NCiZndDsgJmd0OyAmZ3Q7IChGZWJydWFyeSAyMDEz KTxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNv bi8xMjU2Lzxicj4NCiZndDsgJmd0OyAmZ3Q7IChNYXkgMjAxMyk8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFNvbWUgZGV0YWlscyBhYm91IHRoZSBwcm9wb3NlZCBkcmFm dHMgZm9yIGFsaWduIFBTQyBiZWhhdmlvdXIgd2l0aDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRyYW5z cG9ydCByZXF1aXJlbWVudHM6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDAgcHJvcG9zZXMgc3dhcHBpbmcgdGhl IHByaW9yaXRpZXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBiZXR3ZWVuIEZTIGFuZCBTRi1QIChzZWUg c2VjdGlvbiA0LjMuMiBvZiByZmM2Mzc4KS48YnI+DQomZ3Q7ICZndDsgJmd0OyBBbW9uZyB0aGUg b3RoZXJzLCBiZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkPGJy Pg0KJmd0OyAmZ3Q7IHVwZGF0ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGFyZTo8YnI+DQomZ3Q7ICZn dDsgJmd0OyBVc2UgY2FzZSBBKSBBdCBmaXJzdCwgd29ya2luZyBwYXRoKFdQKSBhbmQgcHJvdGVj dGlvbiBwYXRoKFBQKSBhcmU8YnI+DQomZ3Q7ICZndDsgJmd0OyBub3JtYWwuIFRoZW4sIEZvcmNl ZCBTd2l0Y2goRlMpIGNvbW1hbmQgaXMgaXNzdWVkIGZvciBtYWludGVuYW5jZSBvbjxicj4NCiZn dDsgJmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBXUCBhbmQgdGhlIHRyYWZmaWMgbW92ZXMg ZnJvbSBXUCB0byBQUC4gV2hlbiBTaWduYWwgRmFpbCBvY2N1cnMgb248YnI+DQomZ3Q7ICZndDsg Jmd0OyBQUCwgc2VydmljZSBjYW5ub3QgcmVjb3ZlciBhbmQgaXMgaW50ZXJydXB0ZWQuIFRoaXMg Y291bGQgb2NjdXIgZm9yPGJyPg0KJmd0OyAmZ3Q7IGV4YW1wbGU8YnI+DQomZ3Q7ICZndDsgJmd0 OyBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci48YnI+ DQomZ3Q7ICZndDsgJmd0OyBVc2UgY2FzZSBCKSBJZiB0aGVyZSBpcyBhbiBleGlzdGluZyBzaWdu YWwgZmFpbCBvbiBhIHByb3RlY3Rpb24gcGF0aDxicj4NCiZndDsgJmd0OyAmZ3Q7IChTRi1QKSxh bmQgRlMgY29tbWFuZCBpcyBpc3N1ZWQgYnkgYWNjaWRlbnQgdGhlIHRyYWZmaWMgb24gV1Agd2ls bDxicj4NCiZndDsgJmd0OyBtb3ZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG8gUFAuIFRoaXMgcmVz dWx0cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9tIHdoaWNoIHlvdTxicj4NCiZn dDsgJmd0OyAmZ3Q7IHdpbGwgbm90IGF1dG9tYXRpY2FsbHkgcmVjb3ZlciwgYmVjYXVzZSBQU0Mg c2hvdWxkIG5vdCBoYXZlIHN3aXRjaGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIHRyYWZmaWMg ZnJvbSBXUCB0byBQUC48YnI+DQomZ3Q7ICZndDsgJmd0OyBEaXNjdXNzaW9uIGFib3V0IHRoaXMg ZHJhZnQgbGVkIHRvIHRoZSBwcm9wb3NhbCB0byBtb2RpZnkgUkZDIDQ0Mjc8YnI+DQomZ3Q7ICZn dDsgdGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7IHdhcyAmcXVvdDt3cml0dGVuIGNvcnJlY3RseSB0 aG91Z2ggbGFja2luZyBpbiBkZXRhaWwgY2F1c2luZyBtaXMtPGJyPg0KJmd0OyAmZ3Q7ICZndDsg aW50ZXJwcmV0YXRpb24mcXVvdDsgdGhhdCBsZWQgdG8gdGhlIGN1cnJlbnQgUFNDIHNldCBvZiBw cmlvcml0eSB0aGF0IHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGFib3ZlIGRyYWZ0IGlzIHByb3Bv c2luZyB0byBtb2RpZmllZCBhbmQgdG8gYWxpZ24gdG8gdGhlIHJlcXVpcmVkPGJyPg0KJmd0OyAm Z3Q7ICZndDsgdHJhbnNwb3J0IGJlaGF2aW9yLiBkcmFmdC1oZWx2b29ydC1jY2FtcC1mcy1wcmlv cml0eS0wMCBoYXMgYmVlbjxicj4NCiZndDsgJmd0OyAmZ3Q7IHN1Ym1pdHRlZCB0byBDQ0FNUCBm b3IgY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byBNYW51YWw8YnI+DQomZ3Q7 ICZndDsgJmd0OyBTd2l0Y2ggYW5kIEZvcmNlZCBTd2l0Y2ggYW5kIHRoZWlyIHVzYWdlIHJlbGF0 aXZlIHRvIHByaW9yaXRpZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIHdheSB0aGlzIGJlaGF2 aW9yIGhhcyB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDIGhhcyB0byBiZTxicj4NCiZn dDsgJmd0OyAmZ3Q7IGRpc2N1c3NlZC4gVGhlIHRleHQgcHJvcG9zZXMgdG8gcmVwbGFjZSB0aGUg Y3VycmVudCBiZWhhdmlvciB3aXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIG5ldyBvbmUuIElm IHRoZXJlIGlzIGNvbnNlbnN1cyB0byBwcm9jZWRlIGluIHRoYXQgd2F5IHRoaXMgY2FuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgYnJpbmc8YnI+DQomZ3Q7ICZndDsgdG88YnI+DQomZ3Q7ICZndDsgJmd0 OyBhIHNpbXBsZSBhbmQgZWZmZWN0aXZlIHdheSB0byBvcGVyYXRlIHRoZSBwcm90b2NvbC48YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgLS08YnI+DQomZ3Q7ICZndDsgJmd0OyBkcmFmdC1jZGgtbXBscy10cC1wc2Mt bm9uLXJldmVydGl2ZS0wMCBjb250YWlucyB0aGUgdXBkYXRlcyB0bzxicj4NCiZndDsgJmd0OyAm Z3Q7IFJGQzYzNzggdG8gY2hhbmdlIG5vbi1yZXZlcnRpdmUgb3BlcmF0aW9ucyB0byBiZWhhdmVz IGluIHRoZSBzYW1lPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd2F5IGlycmVzcGVjdGl2ZWx5IG9mIHRo ZSB0cmlnZ2VyIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIChmYXVsdCBvcjxicj4NCiZndDsgJmd0 OyBvcGVyYXRvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbW1hbmQgRlMsIE1TKS4gQ29uc2VxdWVu dGx5IGFuIG9wZXJhdG9yIGNvbW1hbmQsIE1hbnVhbCBTd2l0Y2ggdG88YnI+DQomZ3Q7ICZndDsg Jmd0OyBXb3JraW5nIChNUy1XKSBhLmsuYSAmcXVvdDtNYW51YWwgc3dpdGNoLW92ZXIgZm9yIHJl Y292ZXJ5IExTUC9zcGFuJnF1b3Q7IGlzPGJyPg0KJmd0OyAmZ3Q7IGFsc288YnI+DQomZ3Q7ICZn dDsgJmd0OyBhZGRlZCB0byBlbmFibGUgdGhpcyBiZWhhdmlvci4gRnJvbSBhbiBvcGVyYXRpb25h bCBwb2ludCBvZiB2aWV3LCBNUzxicj4NCiZndDsgJmd0OyB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7 IHdvcmtpbmcgcGF0aCBoYXMgYWxzbyB0byBiZSBzdXBwb3J0ZWQgdG8gYmUgYWJsZSB0byBpbml0 aWFsbHkgYWxpZ248YnI+DQomZ3Q7ICZndDsgJmd0OyBhdCBib3RoIHNpZGVzIGluIGNhc2Ugb2Yg bm9uLXJldmVydGl2ZSBzd2l0Y2hpbmcgbW9kZS4gTVMgdG8gd29ya2luZzxicj4NCiZndDsgJmd0 OyAmZ3Q7IHBhdGggaXMgZGVmaW5lZCBpbiBSRkMgNTY1NCwgcmVxdWlyZW1lbnQgODMuPGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgcHJvcG9zZWQgTVMtVyBjb21t YW5kIGlzIG9mIGVxdWFsIHByaW9yaXR5IHRvIHRoZSBleGlzdGluZyBNUy1QPGJyPg0KJmd0OyAm Z3Q7ICZndDsgY29tbWFuZCwgYW5kIHRoZXJlIGlzIHRleHQgdG8gaGFuZGxlIHRoZSBzaW11bHRh bmVvdXMgb3Igc2VxdWVudGlhbDxicj4NCiZndDsgJmd0OyAmZ3Q7IG9jY3VycmVuY2Ugb2YgdHdv IGVxdWFsLXByaW9yaXR5IGNvbW1hbmRzLiBUaGlzIGJlaGF2aW9yLCBhbHJlYWR5PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgYWRvcHRlZCBpbiBvdGhlciB0cmFuc3BvcnQgbmV0d29yayBwcm90ZWN0aW9u IHN3aXRjaGluZyBwcm90b2NvbCw8YnI+DQomZ3Q7ICZndDsgJmd0OyBjYW48YnI+DQomZ3Q7ICZn dDsgYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyB1c2VkIGZvciBvdGhlciBhZGRpdGlvbiB0byB0aGUg cHJvdG9jb2wgaW4gdGhlIGZ1dHVyZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS08YnI+DQomZ3Q7ICZndDsg Jmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDAgcHJvdmlkZXMgZXh0ZW5zaW9ucyB0byB0 aGUgUFNDIHN0YXRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbWFjaGluZSB0byBoYW5kbGUgU2lnbmFs IERlZ3JhZGUgKFNEKS4gSXQgZG9lcyBub3QgZGVmaW5lIFNEIG9yPGJyPg0KJmd0OyAmZ3Q7IHBy b3ZpZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBzY29wZSBhcm91bmQgd2hlcmUgb3IgaG93IFNEIG1h eSBiZSB1c2VkIHNpbWlsYXJseSBhcyBpdCBhbHJlYWR5PGJyPg0KJmd0OyAmZ3Q7IGhhcHBlbjxi cj4NCiZndDsgJmd0OyAmZ3Q7IGluIHRoZSBkcmFmdCBpbiBoYW5kbGluZyBvdGhlciBkZWZlY3Rz IGxpa2UgU0YgKFNpZ25hbCBGYWlsdXJlKS48YnI+DQomZ3Q7ICZndDsgJmd0OyBJbiBNUExTLVRQ IHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIFtSRkM2MzcyXSwgYSBmYXVsdCBjb25kaXRpb248YnI+ DQomZ3Q7ICZndDsgJmd0OyBpbmNsdWRlcyBib3RoIFNpZ25hbCBGYWlsIChTRikgYW5kIFNpZ25h bCBEZWdyYWRlIChTRCkgdGhhdCBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgdXNlZDxicj4NCiZndDsg Jmd0OyAmZ3Q7IHRvIHRyaWdnZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgV2hpbGUgdGhlIHN0YW5kYXJkaXphdGlvbiBsYWNrIG9mIGFuIFNEIGRlZmluaXRpb24g YW5kIGRldGVjdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7IG1lY2hhbmlzbXMsIHRoZSByZWxldmFu dCBiZWhhdmlvcnMgaW4gdGVybXMgb2YgcHJvdGVjdGlvbiBhY3Rpb25zPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgbWF5IGFscmVhZHkgYmUgZGVmaW5lZC48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS08YnI+DQomZ3Q7 ICZndDsgJmd0OyBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0 aGUgRVhFUi9SUiBjb21tYW5kcyB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7IHRlc3QgaWYgdGhlIEFQ UyBjb21tdW5pY2F0aW9uIGlzIG9wZXJhdGluZyBjb3JyZWN0bHkuIEluIG90aGVyIHdvcmRzPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgYm90aCBBUFMgcHJvY2VzcyBsb2dpYyBpbmNsdWRpbmcgc3RhdGUg bWFjaGluZSBhbmQgQVBTIGNoYW5uZWwgb248YnI+DQomZ3Q7ICZndDsgJmd0OyBwcm90ZWN0aW9u IHBhdGgsIHdpdGhvdXQgc2VydmljZSBkaXNydXB0aW9uIGFuZCB3aXRob3V0IGFmZmVjdGluZzxi cj4NCiZndDsgJmd0OyAmZ3Q7IGFueSBwcm90ZWN0aW9uIG9wZXJhdGlvbiwgdW5sZXNzIHRoZSBw cm90ZWN0aW9uIHRyYW5zcG9ydCBlbnRpdHkgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbjxicj4N CiZndDsgJmd0OyB1c2UuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhpcyBjb21tYW5kIGlzIGRvY3Vt ZW50ZWQgaW4gUjg0IG9mIFtSRkM1NjU0XSBhbmQgaXQgaXMgcGFydCBvZjxicj4NCiZndDsgJmd0 OyAmZ3Q7IElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg QW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiB0aGUgQXBwZW5kaXggQiBv ZiBSRkM2Mzc4PGJyPg0KJmd0OyAmZ3Q7IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB1dGlsaXpl cyB0aGUgTG9ja291dCBvZiBQcm90ZWN0aW9uIChMTykgb3IgRm9yY2VkIFN3aXRjaCAoRlMpIGlu PGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29tYmluYXRpb24gb2YgT0FNIGZ1bmN0aW9uYWxpdGllcy4g SG93ZXZlciwgaXQgaGFzIHNvbWUgZnVuY3Rpb25hbDxicj4NCiZndDsgJmd0OyAmZ3Q7IGxpbWl0 YXRpb24gYW5kIGhhcyBhIHBvdGVudGlhbCByaXNrIG9mIGxvc2luZyB0cmFmZmljIGFzIGEgc2ln bmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZmFpbHVyZSBtaWdodCBvY2N1ciBkdXJpbmcgdGhlIGV4 ZXJjaXNlIG9wZXJhdGlvbi4gSW4gdGhhdCBjYXNlLCBMTzxicj4NCiZndDsgJmd0OyAmZ3Q7IG9y IEZTIGhhcyB0byBiZSBjYW5jZWxlZCB0byBhbGxvdyB0aGUgUFNDIHByb3RvY29sIHRvIHByb3Zp ZGUgcHJvcGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3dpdGNoaW5nLjxicj4NCiZndDsgJmd0OyAm Z3Q7IEEgZnVydGhlciBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIGRyYWZ0 LW9zYm9ybmUtbXBscy08YnI+DQomZ3Q7ICZndDsgcHNjLTxicj4NCiZndDsgJmd0OyAmZ3Q7IGFs aXZlLTAwIHRoYXQgYW55d2F5IHNob3cgc29tZSBmdW5jdGlvbmFsIGxpbWl0YXRpb25zIGJlY2F1 c2UgY2Fubm90PGJyPg0KJmd0OyAmZ3Q7ICZndDsgdmFsaWRhdGUgdGhlIFBTQyBzdGF0ZSBtYWNo aW5lIHN0YXR1cyBhbmQgcHJvYmFibHkgdGhlIExvY2FsIFJlcXVlc3Q8YnI+DQomZ3Q7ICZndDsg Jmd0OyBsb2dpYy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgVGhlIGF1dGhvcnMgZW5jb3VyYWdlIHRoZSBJRVRGIGV4cGVydHMgdG8g Y29tbWVudCBvbiB0aGVzZSBkcmFmdHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZXZlbnR1YWxseSBw cm9wb3Npbmcgb3RoZXIgb3B0aW9ucy9tZWNoYW5pc21zIHRoYXQgY2FuIHNhdGlzZnkgdGhlPGJy Pg0KJmd0OyAmZ3Q7IHNhbWU8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudHMuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFsZXNzYW5k cm8sIEh1dWIsIEplb25nLWRvbmcsIFRhZWtzaWQgUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaTxi cj4NCiZndDsgJmd0OyAmZ3Q7IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVu dGU8YnI+DQomZ3Q7ICZndDsgYWxsZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHBlcnNvbmUgaW5kaWNh dGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZTxicj4NCiZn dDsgJmd0OyAmZ3Q7IGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1h emlvbmkgc29ubyByaWdvcm9zYW1lbnRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdmlldGF0ZS4gUXVh bG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZTxi cj4NCiZndDsgJmd0OyAmZ3Q7IGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0 YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBkaSBwcm92 dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNv bmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW48YnI+DQomZ3Q7ICZndDsgJmd0OyBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpczxicj4NCiZndDsgJmd0OyB1bmF1dGhvcmlzZWQuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0 ZSB0aGlzIG1lc3NhZ2U8YnI+DQomZ3Q7ICZndDsgJmd0OyBhbmQgYW55IGF0dGFjaG1lbnRzIGFu ZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyByaXNwZXR0YSBsJ2FtYmllbnRlUmlzcGV0dGEg bCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlPGJyPg0KJmd0OyAmZ3Q7IG5v bjxicj4NCiZndDsgJmd0OyAmZ3Q7IMOoIG5lY2Vzc2FyaW8uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyAmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IG1wbHNAaWV0 Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBtcGxzIG1haWxpbmcgbGlzdDxicj4NCiZndDsg bXBsc0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276804F3SMTP2etriinfo_-- From loa@pi.nu Tue Jul 23 01:20:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48021F9E88 for ; Tue, 23 Jul 2013 01:19:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4--djoHepQg for ; Tue, 23 Jul 2013 01:19:43 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4362A21E804D for ; Tue, 23 Jul 2013 01:19:37 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BA0BE1800272; Tue, 23 Jul 2013 10:19:34 +0200 (CEST) Message-ID: <51EE3C97.2040909@pi.nu> Date: Tue, 23 Jul 2013 10:19:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ross Callon References: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D77C95@CH1PRD0510MB355.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" , "" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-rosetta-stone-11.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, 23 Jul 2013 08:20:01 -0000 Ross, I'm not aware of any IPRs for this documents. /Loa On 2013-07-22 16:40, Ross Callon wrote: > Working Group and authors; > > The authors of draft-ietf-mpls-tp-rosetta-stone-11.txt and the > working group chairs are working to prepare the draft for working > group last call. > > Before starting the working group last call we first are issuing a > poll to check whether there is IPR on the document that needs to be > disclosed. This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-ietf-mpls-tp-rosetta-stone-11.txt? > > If so, has this IPR been disclosed in compliance with IETF IPR rules? > (see RFCs 3979, 4879, 3669 and 5378 for more details.) > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Ross > (as MPLS WG co-chair) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From martin.vigoureux@alcatel-lucent.com Tue Jul 23 03:25:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383CB21E8084 for ; Tue, 23 Jul 2013 03:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LylQmwIm15x for ; Tue, 23 Jul 2013 03:25:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 270A721F9E6E for ; Tue, 23 Jul 2013 03:25:48 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6NAPj7t010119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jul 2013 05:25:47 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6NAPj2I010585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Jul 2013 12:25:45 +0200 Received: from [172.27.205.220] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Jul 2013 12:25:45 +0200 Message-ID: <51EE5A28.20308@alcatel-lucent.com> Date: Tue, 23 Jul 2013 12:25:44 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [mpls] IETF87 - MPLS Sessions - Agenda available / Time to send slides X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 23 Jul 2013 10:25:55 -0000 Working Group, the agenda is available here: http://www.ietf.org/proceedings/87/agenda/agenda-87-mpls Please have a look at it. Speakers you can start sending your slides. Please send them to me and the co-chairs no later than Sunday 28th, 10pm, Berlin time. Thanks Martin From huubatwork@gmail.com Tue Jul 23 03:57:52 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A0C11E820B for ; Tue, 23 Jul 2013 03:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xCj-QLO4rRW for ; Tue, 23 Jul 2013 03:57:52 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 241AF11E81A5 for ; Tue, 23 Jul 2013 03:57:50 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id o10so4348235eaj.19 for ; Tue, 23 Jul 2013 03:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9ddEPfjRS1ODZfOdSnk2PI5urj/Z2yAA+7DcwWWiTRQ=; b=ey/0ErHjcqY6IXNKcE3zuBt4P/mjpK/ner0YEqBLClN3YGMPe4qpROg5JZNiK/NcMl c564zYW2d05ji2SVQZz8F64iYtdAAXW1JTBFQBcjj7wwOC2swLAvfi4cUHYQlBHfuzk8 m4BAFhWIxBNGT/Na8CevtjogNOizvjHqIkCNOJ9gPSL9r1cmrpJ6FkUQ9jnI6/u2gOnd YxnOEbjGN3uBSBll53EOxeR1L7SxSyo4Pg5b1dsxfsY6Vzjzgd/sz+nCBwaQfvkgUhUw AQAK6KefPLispbstCgNm9PjQBpRH+Wv8egZlz1AfjZDoy2icxwRA2HNl2eGCcKclfmvL yz4A== X-Received: by 10.15.42.129 with SMTP id u1mr32110515eev.116.1374577070228; Tue, 23 Jul 2013 03:57:50 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id c3sm57817398eev.3.2013.07.23.03.57.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 03:57:49 -0700 (PDT) Message-ID: <51EE61AE.7050109@gmail.com> Date: Tue, 23 Jul 2013 12:57:50 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stbryant@cisco.com References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <51ED1541.70108@gmail.com> <51ED2FC9.304@cisco.com> In-Reply-To: <51ED2FC9.304@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements 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: Tue, 23 Jul 2013 10:57:53 -0000 Hello Steward, You replied: >>> What I'd like to understand about EXER is where it came from. The >>> ITU specs that define it are pretty hard to follow, they seem to >>> assume the reader already knows what EXER is and what problem it >>> solves. It feels very much like a mechanism used to catch a very >>> specific implementation bug, back when transport gear was far less >>> debuggable than what we have today. >> >> [Huub] EXER was not designed/intended to be used for bug finding >> although it will detect problems with implementation. >> >> [Huub] EXER was designed to verify that the state-machine at the >> far end is able to respond to APS/PSC messages it receives from >> the local end. >> Even though state-machines should be tested extensively, there is >> no 100% warranty. It can still have stopped due to external >> circumstances, be in a deadlock due to unforseen order of events, >> etc. > > Huub, > > I get a terrible Heisenberg feeling when you explain this to me. [Huub] I think Werner was referring to quantum mechanics... > It is not clear whether or not including the EXER state and executing > it from time to time poses a greater risk than assuming that : > provided the daemon is running and the variables are as expected, > the code will execute correctly. [Huub] if there is a simple way to verify that the NR messages received periodically are not caused by a malfunctioning state-machine, the risk of of detecting a malfunctioning state-machine at the moment an SF/SD event occurs is reduced considerably. Regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From larryli888@yahoo.com.cn Tue Jul 23 18:46:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E650C11E81B9 for ; Tue, 23 Jul 2013 18:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCUKkciaZhP0 for ; Tue, 23 Jul 2013 18:46:23 -0700 (PDT) Received: from nm4-vm9.bullet.mail.sg3.yahoo.com (nm4-vm9.bullet.mail.sg3.yahoo.com [106.10.148.136]) by ietfa.amsl.com (Postfix) with ESMTP id 6F13211E81AC for ; Tue, 23 Jul 2013 18:46:21 -0700 (PDT) Received: from [106.10.166.119] by nm4.bullet.mail.sg3.yahoo.com with NNFMP; 24 Jul 2013 01:46:19 -0000 Received: from [106.10.151.171] by tm8.bullet.mail.sg3.yahoo.com with NNFMP; 24 Jul 2013 01:46:19 -0000 Received: from [127.0.0.1] by omp1011.mail.sg3.yahoo.com with NNFMP; 24 Jul 2013 01:46:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 845598.2589.bm@omp1011.mail.sg3.yahoo.com Received: (qmail 4248 invoked by uid 60001); 24 Jul 2013 01:46:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1374630376; bh=HIR8rQzmtBrpdBXgQtUJzBT2iFmTPuGnAcPRix2Irlw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lyhbeISgxXIxrDgYmNKVDF8cFskjnZKe6d16c7ucZnyCkvzwuzMbtw0n0nGS1lNG1vH1CWo1PoLQQVT3wuLs6Gk3eemv6ISeRtghQROXuaeTKPLaQg4Cf+iBeb8fVKqAXbt+WI9S6kv1JcnKDIfr8sApxq9G/NT44LqkDZU/0Yk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bc3g7jfFI7MhZlN7p5VienUfwrzawRYAdonaYKhLvXuDo8VsT/smHYKwF7HVZp26Wt6Sxe2vGod7Ae0CErhTeIukx1lAYoBOQZRdBIZkmtcK1/5wm9tw8iXJXqTUHYsmNrw+w78g7VHpgbEMDbRBUTIQJFaDcoCdJJhVAfgOpJM= ; X-YMail-OSG: LkwpR3YVM1nByS85_6iE59ANU8sRZDXhnxanIGSsecqQzpU sCXio4czRea_HFNApFMQo Received: from [118.213.242.86] by web15606.mail.cnb.yahoo.com via HTTP; Wed, 24 Jul 2013 09:46:16 CST X-Rocket-MIMEInfo: 002.001, SGkgYWxsLAoKSSBhZ3JlZSB3aXRoIFRvbSBhbmTCoEplb25nLWRvbmcuIFRoZXJlIGFyZSBkaWZmZXJlbnQgcmVhc29ucyB0byBjYXVzZSBTRCwgYnV0IHRoZSByZXN1bHQgaXMgdGhlIHRyYW5zcG9ydCBwZXJmb3JtYW5jZSBkZWdyYWRlIGFuZCBpdCBpcyBpbXBvcnRhbnQgdG8gbGV0IG9wZXJhdG9ycyBzZXQgYSB0aHJlc2hvbGQgdG8gdHJpZ2dlciBwcm90ZWN0aW9uIHN3aXRjaC4gRHVyaW5nIHRoZSB0cm91YmxlIHNob290aW5nLCBvcGVyYXRvcnMgbmVlZCB0b29scyB0byBkbyBmYXVsdCBsb2NhbGl6YXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> Message-ID: <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com> Date: Wed, 24 Jul 2013 09:46:16 +0800 (CST) From: Larry To: "Huber, Thomas J." , "Eric Osborne \(eosborne\)" , "Ryoo, Jeong-dong" , D'Alessandro Alessandro Gerardo , "mpls@ietf.org" In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1433708960-1708452960-1374630376=:6934" Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "huubatwork@gmail.com" Subject: [mpls] =?utf-8?b?5Zue5aSN77yaICBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWdu?= =?utf-8?q?ing_MPLS-TP_PSC_linear_protection_protocol_to_transport_require?= =?utf-8?q?ments?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Larry List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 01:46:29 -0000 --1433708960-1708452960-1374630376=:6934 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,=0A=0AI agree with Tom and=C2=A0Jeong-dong. There are different reas= ons to cause SD, but the result is the transport performance degrade and it= is important to let operators set a threshold to trigger protection switch= . During the trouble shooting, operators need tools to do fault localizatio= n. Althought "degrade" is a continous variable behaviour, it is a "0/1" pro= blem after defining the threshold.=0AThank you!=0A=C2=A0=0A****************= *********************************************************=0AHan Li, Ph.D = =0AChina Mobile Research Institute=0A32 Xuanwumen West Street, Xicheng Dist= rict, Beijing 100053, China =0AFax: +86 10 63135159 =0AMOBILE: 13501093385 = =0A************************************************************************= *=0A=0A=0A________________________________=0A =E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A "Huber, Thomas J." =0A=E6=94=B6=E4=BB=B6= =E4=BA=BA=EF=BC=9A Eric Osborne (eosborne) ; "Ryoo, Jeo= ng-dong" ; D'Alessandro Alessandro Gerardo ; "mpls@ietf.org" =0A=E6=8A=84=E9= =80=81=EF=BC=9A "Huub helvoort (huub.van.helvoort@huawei.com)" ; "huubatwork@gmail.com" =0A=E5=8F= =91=E9=80=81=E6=97=A5=E6=9C=9F=EF=BC=9A 2013=E5=B9=B47=E6=9C=8823=E6=97=A5,= =E6=98=9F=E6=9C=9F=E4=BA=8C, 3:03 =E4=B8=8A=E5=8D=88=0A=E4=B8=BB=E9=A2=98:= Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection prot= ocol to transport requirements=0A =0A=0AHi Eric,=0A=0AYou wrote:=0A>EO#=0A>= I'm not sure what that would look like.=C2=A0 'Fail' is a pretty binary thi= ng.=C2=A0 'Degrade' is a continuous variable, as it can be anything from 'a= little bad' to a 'a whole lot of bad but not quite fail'.=0A=0AI think thi= s may be a fundamental difference in assumptions.=C2=A0 While it is certain= ly true that degradation of a signal is a continuous variable, in the conte= xt of protection switching in the transport network, there is a particular = value of that continuous variable that defines the threshold at which the B= oolean variable "signal degrade (SD)" becomes true.=C2=A0 It is for this re= ason that Jeong-dong and others are suggesting that it should be possible t= o incorporate the behavior of the SD state into the PSC definition without = needing to have a precise definition of the mechanism for measuring the deg= radation of a signal.=C2=A0 Whatever the mechanism is, it will be converted= to the binary SD indication.=0A=0ABest regards,=0ATom=0A=0A=0A-----Origina= l Message-----=0AFrom: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]= On Behalf Of Eric Osborne (eosborne)=0ASent: Monday, July 22, 2013 8:36 AM= =0ATo: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; mpls@ietf.org=0AC= c: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com=0ASub= ject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection= protocol to transport requirements=0A=0AHi Jeong-dong,=0A=0A=C2=A0 Thanks = for the reply.=C2=A0 Please see inline with EO#.=0A=0A> -----Original Messa= ge-----=0A> From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr]=0A> Sent: Monda= y, July 22, 2013 4:15 AM=0A> To: Eric Osborne (eosborne); D'Alessandro Ales= sandro Gerardo;=0A> mpls@ietf.org=0A> Cc: Huub helvoort (huub.van.helvoort@= huawei.com); huubatwork@gmail.com=0A> Subject: RE: [mpls] proposed drafts f= or aligning MPLS-TP PSC linear=0A> protection protocol to transport require= ments=0A>=0A> Hi, Eric.=0A>=0A> Let me answer your 2nd question on SD.=0A>= =0A> SD detection methods defined or proposed for packet transport networks= =0A> can be summarized as follows:=0A> - By OAM performance monitoring tool= :=0A>=C2=A0 SD is raised if packet loss ratio exceeds a threshold during a= =0A> measurement period.=0A>=C2=A0 Threshold value and measurement period = are configured by an network=0A> operator.=0A>=C2=A0 This detection method= is already defined in ITU-T G.8021 (Ethernet=0A> equipment spec.)=0A=0A=0A= EO#=C2=A0 Where?=C2=A0 I'm not arguing that it's not in there, I'm just hav= ing a hard time finding it.=C2=A0 A search for ETH_CI_SSD doesn't yield muc= h.=C2=A0 If I look for 'signal degrade' I see p. 131 which says that the al= gorithm is defined in G.8031.=C2=A0 G.8031 says ' How these defects are det= ected is the subject of the equipment Recommendations'.=C2=A0 I'm looking f= or something like "Signal Degrade is defined as $foo packet loss or CRC fai= lure over $bar time"....what have I missed?=0A=0A=0A>=C2=A0 and the equipm= ent spec for MPLS-TP can easily follow the same=0A> definition.=0A> - By se= rver layer indication:=0A>=C2=A0 SD is raised if a server layer below MPLS= -TP reports SD condition on=0A> its own layer.=0A> - By CCM packet counting= :=0A>=C2=A0 SD is raised if the loss ratio of CCM packets exceeds a thresh= old=0A> during a measurement period.=0A>=0A> Regardless of how to detect SD= , any protection switching documents=0A> should describe the protection swi= tching operation once such a SD is=0A> declared.=0A>=0A...=0A> Regarding th= e multiple levels of SD:=0A> It is certainly possible to define multiple le= vels of SD.=0A> But, as far as the protection switching is concerned, it ju= st needs to=0A> know if SD is signaled to protection switching process or n= ot.=0A> It would be a network operator's choice at what level of SD he want= s=0A> his network protection to switchover.=0A> In other words, what trigge= rs protection switching is SD or no SD. It=0A> is yes or no decision.=0A=0A= =0AEO#=C2=A0 I am not aware of any document which suggests that a server la= yer SD should be treated as a client layer SD.=C2=A0 In the IP world, if we= have SD on a transport interface that is generally used to bring the inter= face down (i.e. SF).=C2=A0 This is the sort of thing I'd like to see in mor= e detail, as SD in the packet world is a new concept and we can't just assu= me that it will work the same everywhere because we define state machine po= ints for it.=0A=0AThe point about CCM is a good one.=C2=A0 Let's say we com= e up with a clever SD mechanism with two thresholds, call them major and mi= nor.=C2=A0 For discussion purposes they could be simple error ratios, e.g. = 1:10^6 and 1:10^9.=C2=A0 But they could be more powerful than that (flow ty= pe, flow length, error burst size, etc).=0A=0AIf we want to have SD-Major a= nd SD-Minor inputs as separate triggers for PSC, we may want them at differ= ent points.=C2=A0 Perhaps=C2=A0 (leaving out the Working path for ease of r= eading)=0A=0ALO=0AFS=0ASF-P=0ASD-P-Major=0AMS=0ASD-P-Minor=0A=0A=0AThis see= ms like a perfectly reasonable thing to want.=0A=0A=0AEven if we don't have= multi-tier SD, even the single-tier SD needs to be defined before we can d= ecide how to respond to it.=0A=0A> The proposed draft covers SD-triggered p= rotection no matter what kinds=0A> of SD detection methods are used.=0A>=0A= >=0A> SF can also be viewed as having multiple levels of SF as the network= =0A> operator can also make a choice on the period/interval of CCM messages= .=0A=0A=0AEO#=0AI'm not sure what that would look like.=C2=A0 'Fail' is a p= retty binary thing.=C2=A0 'Degrade' is a continuous variable, as it can be = anything from 'a little bad' to a 'a whole lot of bad but not quite fail'.= =0A=0A> If CCM is disabled, AIS from a server layer can be used as a trigge= r=0A> for protection switching. So and so forth.=0A=0AEO#=C2=A0 AIS from th= e server layer only gets you SD from the first hop of the underlying server= path.=0A=0A=0A=0A=0Aeric=0A=0A> However, protection switching document doe= s not define how to detect=0A> SF in anywhere.=0A> Similary, protection swi= tching document does not define how manual=0A> switch and forced switch com= mands are initiated in a management system=0A> and signaled to protection s= witching process.=0A>=0A> Again, in my opinion, the draft on SD protection = can accommodate any=0A> SD detection methods.=0A>=0A> Best regards,=0A>=0A>= Jeong-dong=0A>=0A>=0A>=0A>=0A>=0A>=0A> ________________________________=0A= >=0A> From : "Eric Osborne (eosborne)" Sent :=0A> 2013= -07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerardo=0A> , mpls@ietf.org=0A> Cc : = Huub helvoort (huub.van.helvoort@huawei.com)=0A> , huubatwork@gmail.com=0A> Subject : Re: [mpls] = proposed drafts for=0A> aligning MPLS-TP PSC linear protection protocol to = transport=0A> requirements=0A>=0A>=0A> Hi Alessandro-=0A>=0A> Thanks for th= is; the threads I started some time back seem to have=0A> died down, it's g= ood to get them going again.=0A> I have two things I never quite understood= , can you clarify them for me?=0A>=0A> i) can you explain EXER at a higher = level? I'm not looking for a=0A> description of the state machine changes, = and I'm not looking for the=0A> one line "It allows the FSM to be tested". = We have all of that in the=0A> draft and in the equivalent ITU specs.=0A>= =0A> What I'd like to understand about EXER is where it came from. The ITU= =0A> specs that define it are pretty hard to follow, they seem to assume=0A= > the reader already knows what EXER is and what problem it solves. It=0A> = feels very much like a mechanism used to catch a very specific=0A> implemen= tation bug, back when transport gear was far less debuggable=0A> than what = we have today.=0A>=0A> No other state machines that I'm familiar with (RSVP= , LDP, BGP, OSPF,=0A> ISIS) have explicit signaling in them just to ask the= neighbor whether=0A> it *would* be broken if if were, in the future, to be= given a=0A> particular input. Part of my reluctance to get behind EXER has= been=0A> that I don't feel comfortable with the idea of keeping a 30-year-= old=0A> workaround in a protocol. Is there more to it than that? Have I=0A>= misread and misunderstood EXER? Does modern transport gear ever=0A> actual= ly detect a problem via EXER/RR that wasn't obvious to the=0A> operator usi= ng other means?=0A>=0A>=0A> ii) Why the push to standardize the SD state ch= anges before we've=0A> defined SD? I certainly agree that handling signal d= egrade is a good=0A> idea, but coming up with a definition for it has been = challenging.=0A> What happens if we change the FSM to handle it, then come = up with=0A> something more sophisticated (say, multiple levels of SD) that = doesn't=0A> quite fit with the FSM changes?=0A>=0A>=0A>=0A> thanks!=0A>=0A>= =0A>=0A>=0A>=0A> eric=0A>=0A>=0A> > -----Original Message-----=0A> > From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=0A> Of=0A> >= D'Alessandro Alessandro Gerardo=0A> > Sent: Wednesday, July 17, 2013 3:23 = PM=0A> > To: mpls@ietf.org=0A> > Cc: Huub helvoort (huub.van.helvoort@huawe= i.com);=0A> > huubatwork@gmail.com=0A> > Subject: [mpls] proposed drafts fo= r aligning MPLS-TP PSC linear=0A> > protection protocol to transport requir= ements=0A> >=0A> > Dear all,=0A> > we would like socializing the herebelow = drafts that were submitted=0A> some=0A> > months ago with the aim to align = PSC protocol (RFC 6378) to ITU-T=0A> > transport requirements. I would appr= eciate your comments about the=0A> > proposed mechanisms and behaviours.=0A= > >=0A> > draft-rhd-mpls-tp-psc-priority-00=0A> > draft-cdh-mpls-tp-psc-non= -revertive-00=0A> > draft-rhd-mpls-tp-psc-sd-00=0A> > draft-dj-mpls-tp-exer= -psc-01 / draft-osborne-mpls-psc-alive-00=0A> >=0A> > The above drafts cove= r most of items highlighted in ITU-T liaisons=0A> about=0A> > PSC and they = propose solutions in line with MPLS-TP transport=0A> > requirements.=0A> > = A list of main liaisons exchanged between ITU-T and IETF with the=0A> > aim= =0A> to=0A> > align PSC behavious with ITU-T transport requirements for lin= ear=0A> > protection are given below:=0A> > https://datatracker.ietf.org/li= aison/1162/ (June 2012)=0A> > https://datatracker.ietf.org/liaison/1205/ = =0A> > (October 2012)=0A> > https://datatracker.ietf.org/liaison/1229/ =0A>= > (January 2013)=0A> > https://datatracker.ietf.org/liaison/1234/ =0A> > (= February 2013)=0A> > https://datatracker.ietf.org/liaison/1256/ =0A> > (May= 2013)=0A> >=0A> > Some details abou the proposed drafts for align PSC beha= viour with=0A> > transport requirements:=0A> >=0A> > draft-rhd-mpls-tp-psc-= priority-00 proposes swapping the priorities=0A> > between FS and SF-P (see= section 4.3.2 of rfc6378).=0A> > Among the others, behaviors that will be = fixed with the proposed=0A> update=0A> > are:=0A> > Use case A) At first, w= orking path(WP) and protection path(PP) are=0A> > normal. Then, Forced Swit= ch(FS) command is issued for maintenance on=0A> the=0A> > WP and the traffi= c moves from WP to PP. When Signal Fail occurs on=0A> > PP, service cannot = recover and is interrupted. This could occur for=0A> example=0A> > as a res= ult of accidentally un-plugging a PP fiber.=0A> > Use case B) If there is a= n existing signal fail on a protection path=0A> > (SF-P),and FS command is = issued by accident the traffic on WP will=0A> move=0A> > to PP. This result= s in an interruption of service from which you=0A> > will not automatically= recover, because PSC should not have switched=0A> > the traffic from WP to= PP.=0A> > Discussion about this draft led to the proposal to modify RFC 44= 27=0A> that=0A> > was "written correctly though lacking in detail causing m= is-=0A> > interpretation" that led to the current PSC set of priority that = the=0A> > above draft is proposing to modified and to align to the required= =0A> > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been=0A>= > submitted to CCAMP for clarifying the definitions related to Manual=0A> = > Switch and Forced Switch and their usage relative to priorities.=0A> > Th= e way this behavior has to be incorporated into the PSC has to be=0A> > dis= cussed. The text proposes to replace the current behavior with=0A> > the ne= w one. If there is consensus to procede in that way this can=0A> > bring=0A= > to=0A> > a simple and effective way to operate the protocol.=0A> >=0A> > = --------------------------------------------------------------------=0A> > = --=0A> > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to=0A>= > RFC6378 to change non-revertive operations to behaves in the same=0A> > = way irrespectively of the trigger of protection switching (fault or=0A> ope= rator=0A> > command FS, MS). Consequently an operator command, Manual Switc= h to=0A> > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" = is=0A> also=0A> > added to enable this behavior. From an operational point = of view, MS=0A> to=0A> > working path has also to be supported to be able t= o initially align=0A> > at both sides in case of non-revertive switching mo= de. MS to working=0A> > path is defined in RFC 5654, requirement 83.=0A> >= =0A> > The proposed MS-W command is of equal priority to the existing MS-P= =0A> > command, and there is text to handle the simultaneous or sequential= =0A> > occurrence of two equal-priority commands. This behavior, already=0A= > > adopted in other transport network protection switching protocol,=0A> >= can=0A> be=0A> > used for other addition to the protocol in the future.=0A= > >=0A> > -----------------------------------------------------------------= ---=0A> > --=0A> > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the P= SC state=0A> > machine to handle Signal Degrade (SD). It does not define SD= or=0A> provide=0A> > scope around where or how SD may be used similarly as= it already=0A> happen=0A> > in the draft in handling other defects like SF= (Signal Failure).=0A> > In MPLS-TP survivability framework [RFC6372], a fa= ult condition=0A> > includes both Signal Fail (SF) and Signal Degrade (SD) = that can be=0A> used=0A> > to trigger protection switching.=0A> > While the= standardization lack of an SD definition and detection=0A> > mechanisms, t= he relevant behaviors in terms of protection actions=0A> > may already be d= efined.=0A> >=0A> > -------------------------------------------------------= -------------=0A> > --=0A> > draft-dj-mpls-tp-exer-psc-01 proposes adding t= he EXER/RR commands to=0A> > test if the APS communication is operating cor= rectly. In other words=0A> > both APS process logic including state machine= and APS channel on=0A> > protection path, without service disruption and w= ithout affecting=0A> > any protection operation, unless the protection tran= sport entity is=0A> > in=0A> use.=0A> > This command is documented in R84 o= f [RFC5654] and it is part of=0A> > ITU-T transport requirements.=0A> > An = alternative proposal is documented in the Appendix B of RFC6378=0A> that=0A= > > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in=0A> > = combination of OAM functionalities. However, it has some functional=0A> > l= imitation and has a potential risk of losing traffic as a signal=0A> > fail= ure might occur during the exercise operation. In that case, LO=0A> > or FS= has to be canceled to allow the PSC protocol to provide proper=0A> > switc= hing.=0A> > A further alternative proposal is documented in draft-osborne-m= pls-=0A> psc-=0A> > alive-00 that anyway show some functional limitations b= ecause cannot=0A> > validate the PSC state machine status and probably the = Local Request=0A> > logic.=0A> >=0A> >=0A> > The authors encourage the IETF= experts to comment on these drafts,=0A> > eventually proposing other optio= ns/mechanisms that can satisfy the=0A> same=0A> > requirements.=0A> > Best = regards,=0A> > Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i s= uoi=0A> > allegati sono indirizzati esclusivamente=0A> alle=0A> > persone i= ndicate. La diffusione, copia o qualsiasi altra azione=0A> > derivante dall= a conoscenza di queste informazioni sono rigorosamente=0A> > vietate. Qualo= ra abbiate ricevuto questo documento per errore siete=0A> > cortesemente pr= egati di darne immediata comunicazione al mittente e=0A> > di provvedere al= la sua distruzione, Grazie.=0A> >=0A> > This e-mail and any attachments is = confidential and may contain=0A> > privileged information intended for the = addressee(s) only.=0A> > Dissemination, copying, printing or use by anybody= else is=0A> unauthorised.=0A> > If you are not the intended recipient, ple= ase delete this message=0A> > and any attachments and advise the sender by = return e-mail, Thanks.=0A> >=0A> > rispetta l'ambienteRispetta l'ambiente. = Non stampare questa mail se=0A> non=0A> > =C3=A8 necessario.=0A>=0A> ______= _________________________________________=0A> mpls mailing list=0A> mpls@ie= tf.org=0A> https://www.ietf.org/mailman/listinfo/mpls =0A=0A_______________= ________________________________=0Ampls mailing list=0Ampls@ietf.org=0Ahttp= s://www.ietf.org/mailman/listinfo/mpls =0A_________________________________= ______________=0Ampls mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/mpls --1433708960-1708452960-1374630376=:6934 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

=09I agree with Tom a= nd Jeong-dong. There are diff= erent reasons to cause SD, but the result is the transport performance degr= ade and it is important to let operators set a threshold to trigger protect= ion switch. During the trouble shooting, operators need tools to do fault l= ocalization. Althought "degrade" is a continous variable behaviour, it is a= "0/1" problem after defining the threshold.
=09Thank you!
 
****= *********************************************************************
Ha= n Li, Ph.D
China Mobile Research Institute
32 Xuanwumen West Street,= Xicheng District, Beijing 100053, China
Fax: +86 10 63135159
MOBIL= E: 13501093385
********************************************************= *****************
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A "Huber, Thomas J." <Tom.Huber@tellabs.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Eric Osbo= rne (eosborne) <eosborne@cisco.com>; "Ryoo, Jeong-dong" <ryoo@etri= .re.kr>; D'Alessandro Alessandro Gerardo <alessandro.dalessandro@tele= comitalia.it>; "mpls@ietf.org" <mpls@ietf.org>
=E6=8A=84=E9=80=81=EF=BC=9A "Huub helvoo= rt (huub.van.helvoort@huawei.com)" <huub.van.helvoort@huawei.com>; "h= uubatwork@gmail.com" <huubatwork@gmail.com>
=E5=8F=91=E9=80=81=E6=97=A5=E6=9C=9F=EF=BC=9A = 2013=E5=B9=B47=E6=9C=8823=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C, 3:03 =E4= =B8=8A=E5=8D=88
=E4=B8=BB=E9=A2= =98: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear = protection protocol to transport requirements

Hi Eric,

You wrote:
>EO#
>I'm n= ot sure what that would look like.  'Fail' is a pretty binary thing.  'Degrad= e' is a continuous variable, as it can be anything from 'a little bad' to a= 'a whole lot of bad but not quite fail'.

I think this may be a fund= amental difference in assumptions.  While it is certainly true that de= gradation of a signal is a continuous variable, in the context of protectio= n switching in the transport network, there is a particular value of that c= ontinuous variable that defines the threshold at which the Boolean variable= "signal degrade (SD)" becomes true.  It is for this reason that Jeong= -dong and others are suggesting that it should be possible to incorporate t= he behavior of the SD state into the PSC definition without needing to have= a precise definition of the mechanism for measuring the degradation of a s= ignal.  Whatever the mechanism is, it will be converted to the binary = SD indication.

Best regards,
Tom


-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpl= s-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne)
Sent: Monda= y, July 22, 2013 8:36 AM
To: Ryoo, Jeong-dong; D'Alessandro Alessandro G= erardo; m= pls@ietf.org
Cc: Huub helvoort (huub.van.helvoo= rt@huawei.com); huubatwork@gmail.com
Subject: Re: [mpls] pr= oposed drafts for aligning MPLS-TP PSC linear protection protocol to transp= ort requirements

Hi Jeong-dong,

  Thanks for the reply.&= nbsp; Please see inline with EO#.

> -----Original Message-----> From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr]
> Sent: Monday, July 22, 20= 13 4:15 AM
> To: Eric Osborne (eosborne); D'Alessandro Alessandro Ger= ardo;
> mpls@ietf.org
> Cc: Huub helvoort (huub= .van.helvoort@huawei.com); huubatwork@gmail.com
> Subjec= t: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> prote= ction protocol to transport requirements
>
> Hi, Eric.
><= br>> Let me answer your 2nd question on SD.
>
> SD detection= methods defined or proposed for packet transport networks
> can be s= ummarized as follows:
> - By OAM performance monitoring tool:
>=  =20 SD is raised if packet loss ratio exceeds a threshold during a
> mea= surement period.
>  Threshold value and measurement period are = configured by an network
> operator.
>  This detection me= thod is already defined in ITU-T G.8021 (Ethernet
> equipment spec.)<= br>

EO#  Where?  I'm not arguing that it's not in there, I= 'm just having a hard time finding it.  A search for ETH_CI_SSD doesn'= t yield much.  If I look for 'signal degrade' I see p. 131 which says = that the algorithm is defined in G.8031.  G.8031 says ' How these defe= cts are detected is the subject of the equipment Recommendations'.  I'= m looking for something like "Signal Degrade is defined as $foo packet loss= or CRC failure over $bar time"....what have I missed?


> = ; and the equipment spec for MPLS-TP can easily follow the same
> de= finition.
> - By server layer indication:
>  SD is raised if a server layer below MPLS-TP reports SD condition on
> its= own layer.
> - By CCM packet counting:
>  SD is raised i= f the loss ratio of CCM packets exceeds a threshold
> during a measur= ement period.
>
> Regardless of how to detect SD, any protectio= n switching documents
> should describe the protection switching oper= ation once such a SD is
> declared.
>
...
> Regarding = the multiple levels of SD:
> It is certainly possible to define multi= ple levels of SD.
> But, as far as the protection switching is concer= ned, it just needs to
> know if SD is signaled to protection switchin= g process or not.
> It would be a network operator's choice at what l= evel of SD he wants
> his network protection to switchover.
> I= n other words, what triggers protection switching is SD or no SD. It
>= ; is yes or no decision.


EO#  I am not aware of any document which suggests that a server layer SD should be treated as a clie= nt layer SD.  In the IP world, if we have SD on a transport interface = that is generally used to bring the interface down (i.e. SF).  This is= the sort of thing I'd like to see in more detail, as SD in the packet worl= d is a new concept and we can't just assume that it will work the same ever= ywhere because we define state machine points for it.

The point abou= t CCM is a good one.  Let's say we come up with a clever SD mechanism = with two thresholds, call them major and minor.  For discussion purpos= es they could be simple error ratios, e.g. 1:10^6 and 1:10^9.  But the= y could be more powerful than that (flow type, flow length, error burst siz= e, etc).

If we want to have SD-Major and SD-Minor inputs as separate= triggers for PSC, we may want them at different points.  Perhaps = ; (leaving out the Working path for ease of reading)

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

=
This seems like a perfectly reasonable thing to want.


Even i= f we don't have multi-tier SD, even the single-tier SD needs to be defined = before we can decide how to respond to it.

> The proposed draft c= overs SD-triggered protection no matter what kinds
> of SD detection = methods are used.
>
>
> SF can also be viewed as having m= ultiple levels of SF as the network
> operator can also make a choice= on the period/interval of CCM messages.


EO#
I'm not sure wha= t that would look like.  'Fail' is a pretty binary thing.  'Degra= de' is a continuous variable, as it can be anything from 'a little bad' to = a 'a whole lot of bad but not quite fail'.

> If CCM is disabled, = AIS from a server layer can be used as a trigger
> for protection swi= tching. So and so forth.

EO#  AIS from the server layer only gets you SD from the first hop of the underlying server path.

=


eric

> However, protection switching document does no= t define how to detect
> SF in anywhere.
> Similary, protection= switching document does not define how manual
> switch and forced sw= itch commands are initiated in a management system
> and signaled to = protection switching process.
>
> Again, in my opinion, the dra= ft on SD protection can accommodate any
> SD detection methods.
&g= t;
> Best regards,
>
> Jeong-dong
>
>
>=
>
>
>
> ________________________________
>> From : "Eric Osborne (eosborne)" <eosborne@cisco.com> Sen= t :
> 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Ger= ardo
> <alessandro.dalessandro@telecomital= ia.it>, mpls@ietf.org
> <mpls@ietf.org> Cc : Huub helvoort (huub.van.helvoort@huawei.com)
> <huub.van.helvoort@huawei.com>, huubatwork@gmail.com<= br>> <huubatwork@gmail.com> Subject : Re: [mpls] proposed= drafts for
> aligning MPLS-TP PSC linear protection protocol to tran= sport
> requirements
>
>
> Hi Alessandro-
>
> Thanks= for this; the threads I started some time back seem to have
> died d= own, it's good to get them going again.
> I have two things I never q= uite understood, can you clarify them for me?
>
> i) can you ex= plain EXER at a higher level? I'm not looking for a
> description of = the state machine changes, and I'm not looking for the
> one line "It= allows the FSM to be tested". We have all of that in the
> draft and= in the equivalent ITU specs.
>
> What I'd like to understand a= bout EXER is where it came from. The ITU
> specs that define it are p= retty hard to follow, they seem to assume
> the reader already knows = what EXER is and what problem it solves. It
> feels very much like a = mechanism used to catch a very specific
> implementation bug, back wh= en transport gear was far less debuggable
> than what we have today.
>
> No other state machines that I'm familiar with (RSV= P, LDP, BGP, OSPF,
> ISIS) have explicit signaling in them just to as= k the neighbor whether
> it *would* be broken if if were, in the futu= re, to be given a
> particular input. Part of my reluctance to get be= hind EXER has been
> that I don't feel comfortable with the idea of k= eeping a 30-year-old
> workaround in a protocol. Is there more to it = than that? Have I
> misread and misunderstood EXER? Does modern trans= port gear ever
> actually detect a problem via EXER/RR that wasn't ob= vious to the
> operator using other means?
>
>
> ii= ) Why the push to standardize the SD state changes before we've
> def= ined SD? I certainly agree that handling signal degrade is a good
> i= dea, but coming up with a definition for it has been challenging.
> W= hat happens if we change the FSM to handle it, then come up with
> something more sophisticated (say, multiple levels of SD) tha= t doesn't
> quite fit with the FSM changes?
>
>
>> thanks!
>
>
>
>
>
> eric
>=
>
> > -----Original Message-----
> > From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf
> Of
> > D'Alessandro Alessandro Gerardo
> > Sen= t: Wednesday, July 17, 2013 3:23 PM
> > To: mpls@ietf.org
> > = Cc: Huub helvoort (huub.van.helvoort@huawei.com);=
> > huubatwork@gmail.com
> >= Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> &g= t; protection protocol to transport requirements
> >
> > = Dear all,
> > we would like socializing the herebelow drafts that = were submitted
> some
> > months ago with the aim to align P= SC protocol (RFC 6378) to ITU-T
> > transport requirements. I woul= d appreciate your comments about the
> > proposed mechanisms and b= ehaviours.
> >
> > draft-rhd-mpls-tp-psc-priority-00
&= gt; > draft-cdh-mpls-tp-psc-non-revertive-00
> > draft-rhd-mpls= -tp-psc-sd-00
> > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpl= s-psc-alive-00
> >
> > The above drafts cover most of ite= ms highlighted in ITU-T liaisons
> about
> > PSC and they pr= opose solutions in line with MPLS-TP transport
> > requirements.
> > A list of main liaisons exchanged between ITU-T= and IETF with the
> > aim
> to
> > align PSC behav= ious with ITU-T transport requirements for linear
> > protection a= re given below:
> > https://datatracker.ietf.org/liaison/1162/ (= June 2012)
> > https://datatracker.ietf.org/liaison/1205/=0A
= > > (October 2012)
> > https://datatracker.ietf.org/liaison/12= 29/=0A
> > (January 2013)
> > https://datatracker.ietf.= org/liaison/1234/=0A
> > (February 2013)
> > https://d= atatracker.ietf.org/liaison/1256/=0A
> > (May 2013)
> &g= t;
> > Some details abou the proposed drafts for align PSC behavio= ur with
> > transport requirements:
> >
> > draf= t-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities
> >= between FS and SF-P (see section 4.3.2 of rfc6378).
> > Among the= others, behaviors that will be fixed with the proposed
> update
&= gt; > are:
> > Use case A) At first, working path(WP) and prote= ction path(PP) are
> > normal. Then, Forced Switch(FS) command is = issued for maintenance on
> the
> > WP and the traffic moves= from WP to PP. When Signal Fail occurs on
> > PP, service cannot = recover and is interrupted. This could occur for
> example
> &g= t; as a result of accidentally un-plugging a PP fiber.
> > Use cas= e B) If there is an existing signal fail on a protection path
> > = (SF-P),and FS command is issued by accident the traffic on WP will
> move
> > to PP.= This results in an interruption of service from which you
> > wil= l not automatically recover, because PSC should not have switched
> &= gt; the traffic from WP to PP.
> > Discussion about this draft led= to the proposal to modify RFC 4427
> that
> > was "written = correctly though lacking in detail causing mis-
> > interpretation= " that led to the current PSC set of priority that the
> > above d= raft is proposing to modified and to align to the required
> > tra= nsport behavior. draft-helvoort-ccamp-fs-priority-00 has been
> > = submitted to CCAMP for clarifying the definitions related to Manual
>= > Switch and Forced Switch and their usage relative to priorities.
&= gt; > The way this behavior has to be incorporated into the PSC has to b= e
> > discussed. The text proposes to replace the current behavior with
> > the new one. If there is consensus to procede i= n that way this can
> > bring
> to
> > a simple and= effective way to operate the protocol.
> >
> > ---------= -----------------------------------------------------------
> > --=
> > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates t= o
> > RFC6378 to change non-revertive operations to behaves in the= same
> > way irrespectively of the trigger of protection switchin= g (fault or
> operator
> > command FS, MS). Consequently an = operator command, Manual Switch to
> > Working (MS-W) a.k.a "Manua= l switch-over for recovery LSP/span" is
> also
> > added to = enable this behavior. From an operational point of view, MS
> to
&= gt; > working path has also to be supported to be able to initially alig= n
> > at both sides in case of non-revertive switching mode. MS to working
> > path is defined in RFC 5654, requirement = 83.
> >
> > The proposed MS-W command is of equal priorit= y to the existing MS-P
> > command, and there is text to handle th= e simultaneous or sequential
> > occurrence of two equal-priority = commands. This behavior, already
> > adopted in other transport ne= twork protection switching protocol,
> > can
> be
> &g= t; used for other addition to the protocol in the future.
> >
&= gt; > ------------------------------------------------------------------= --
> > --
> > draft-rhd-mpls-tp-psc-sd-00 provides extens= ions to the PSC state
> > machine to handle Signal Degrade (SD). I= t does not define SD or
> provide
> > scope around where or = how SD may be used similarly as it already
> happen
> > in t= he draft in handling other defects like SF (Signal Failure).
> > In MPLS-TP survivability framework [RFC6372], a fault condition
&g= t; > includes both Signal Fail (SF) and Signal Degrade (SD) that can be<= br>> used
> > to trigger protection switching.
> > Whi= le the standardization lack of an SD definition and detection
> > = mechanisms, the relevant behaviors in terms of protection actions
> &= gt; may already be defined.
> >
> > ---------------------= -----------------------------------------------
> > --
> >= ; draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to
&= gt; > test if the APS communication is operating correctly. In other wor= ds
> > both APS process logic including state machine and APS chan= nel on
> > protection path, without service disruption and without= affecting
> > any protection operation, unless the protection tra= nsport entity is
> > in
> use.
> > This command is documented in R84 of [RFC5654] and it is part of
> > I= TU-T transport requirements.
> > An alternative proposal is docume= nted in the Appendix B of RFC6378
> that
> > utilizes the Lo= ckout of Protection (LO) or Forced Switch (FS) in
> > combination = of OAM functionalities. However, it has some functional
> > limita= tion and has a potential risk of losing traffic as a signal
> > fa= ilure might occur during the exercise operation. In that case, LO
> &= gt; or FS has to be canceled to allow the PSC protocol to provide proper> > switching.
> > A further alternative proposal is docume= nted in draft-osborne-mpls-
> psc-
> > alive-00 that anyway = show some functional limitations because cannot
> > validate the P= SC state machine status and probably the Local Request
> > logic.<= br>> >
> >
> > The authors encourage the IETF experts to comment on these drafts,
> > eventually proposing= other options/mechanisms that can satisfy the
> same
> > re= quirements.
> > Best regards,
> > Alessandro, Huub, Jeong= -dong, Taeksid Questo messaggio e i suoi
> > allegati sono indiriz= zati esclusivamente
> alle
> > persone indicate. La diffusio= ne, copia o qualsiasi altra azione
> > derivante dalla conoscenza = di queste informazioni sono rigorosamente
> > vietate. Qualora abb= iate ricevuto questo documento per errore siete
> > cortesemente p= regati di darne immediata comunicazione al mittente e
> > di provv= edere alla sua distruzione, Grazie.
> >
> > This e-mail a= nd any attachments is confidential and may contain
> > privileged = information intended for the addressee(s) only.
> > Dissemination,= copying, printing or use by anybody else is
> unauthorised.
> > If you are not the intended recipient, please d= elete this message
> > and any attachments and advise the sender b= y return e-mail, Thanks.
> >
> > rispetta l'ambienteRispe= tta l'ambiente. Non stampare questa mail se
> non
> > =C3=A8= necessario.
>
> ______________________________________________= _
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mai= lman/listinfo/mpls=0A

__________________________________________= _____
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listin= fo/mpls=0A
_______________________________________________
mpls m= ailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
=

--1433708960-1708452960-1374630376=:6934-- From rcallon@juniper.net Tue Jul 23 19:32:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7511E81C6 for ; Tue, 23 Jul 2013 19:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.466 X-Spam-Level: X-Spam-Status: No, score=-98.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTlQwlpmoLTd for ; Tue, 23 Jul 2013 19:32:29 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0811E81BD for ; Tue, 23 Jul 2013 19:32:25 -0700 (PDT) Received: from mail151-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Wed, 24 Jul 2013 02:32:24 +0000 Received: from mail151-ch1 (localhost [127.0.0.1]) by mail151-ch1-R.bigfish.com (Postfix) with ESMTP id A9A88320185 for ; Wed, 24 Jul 2013 02:32:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah182cceh8275dh18c673h1c8fb4h1de097h1de096h8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail151-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rcallon@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1 (MessageSwitch) id 1374633077512914_23865; Wed, 24 Jul 2013 02:31:17 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail151-ch1.bigfish.com (Postfix) with ESMTP id A83C52E0059 for ; Wed, 24 Jul 2013 02:31:05 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 24 Jul 2013 02:31:05 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 23 Jul 2013 19:30:59 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Tue, 23 Jul 2013 19:30:59 -0700 Received: from DB8EHSOBE036.bigfish.com (213.199.154.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 23 Jul 2013 19:43:59 -0700 Received: from mail186-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE036.bigfish.com (10.174.4.99) with Microsoft SMTP Server id 14.1.225.22; Wed, 24 Jul 2013 02:30:53 +0000 Received: from mail186-db8 (localhost [127.0.0.1]) by mail186-db8-R.bigfish.com (Postfix) with ESMTP id 61D37B001C8 for ; Wed, 24 Jul 2013 02:30:53 +0000 (UTC) Received: from mail186-db8 (localhost.localdomain [127.0.0.1]) by mail186-db8 (MessageSwitch) id 1374633051998330_21054; Wed, 24 Jul 2013 02:30:51 +0000 (UTC) Received: from DB8EHSMHS028.bigfish.com (unknown [10.174.8.247]) by mail186-db8.bigfish.com (Postfix) with ESMTP id EE706400D8; Wed, 24 Jul 2013 02:30:51 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by DB8EHSMHS028.bigfish.com (10.174.4.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 24 Jul 2013 02:30:51 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.67]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0329.000; Wed, 24 Jul 2013 02:30:49 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Thread-Topic: MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOiBXOGyaLMJ0V/0ufIkWYEqyzEA== Date: Wed, 24 Jul 2013 02:30:48 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316D78B3ECH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 24 Jul 2013 02:32:36 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316D78B3ECH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This is to start Working Group last call on draft-ietf-mpls-tp-rosetta-sto= ne-11.txt Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have stated that= they are not aware of any IPR applicable to this draft. If anyone else in the working gr= oup is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 14, 2013. Ross for the wg co-chairs --_000_62CCD4C52ACDAD4481149BD5D8A72FD316D78B3ECH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-tp-rosetta-stone-11.txt

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have stated that they are not

aware of any IPR applicable to this draft. <= /span>If anyone else in the working group is aware of

IPRs claims against this draft, the time to disclose that is now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 14, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_62CCD4C52ACDAD4481149BD5D8A72FD316D78B3ECH1PRD0510MB355_-- From wyaacov@gmail.com Tue Jul 23 22:20:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B311E81D1 for ; Tue, 23 Jul 2013 22:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id De11zIZSEhd1 for ; Tue, 23 Jul 2013 22:20:36 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5C16111E81F0 for ; Tue, 23 Jul 2013 22:20:34 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so7670177wgh.4 for ; Tue, 23 Jul 2013 22:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bLitB4A0BeMOFR+P6wtMCTcAUkXdg9/iujdprYha8xY=; b=Q25I7LhF1nld4nyJadAYzKG+CGrql4yihNvBblEmzleF9y5cdJ8HZmvdUGzb706t4s /grletLgrCbfUC0s/LkYXUrSYFOasu7SRcOF1cp6SajEQFEDspWp/Sx9wLdG42KbCq84 unaZq5/842ddwCd+ZE+x4rpDfEtUf/9HMuZDRJyEyd3g1djT21eYJKzwMTmt17k1ZeOw Fh4M++VvXNw0X/DDMWW0Nui0OaQDYedHUbLNl/sD7509xEevO+Z9m/wBQofoE7XS8YQm fndoB147eHmTzjJzkLOTj1A0zPMDsxLMGw3FOb1UhgjF9Jm3QeATcdTN88OnatTZLDxj 04xw== MIME-Version: 1.0 X-Received: by 10.180.184.12 with SMTP id eq12mr1327556wic.8.1374643234149; Tue, 23 Jul 2013 22:20:34 -0700 (PDT) Received: by 10.194.164.164 with HTTP; Tue, 23 Jul 2013 22:20:34 -0700 (PDT) In-Reply-To: <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com> Date: Wed, 24 Jul 2013 08:20:34 +0300 Message-ID: From: Yaacov Weingarten To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3669eaa1d5d04e23b1179 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" Subject: Re: [mpls] =?utf-8?b?5Zue5aSN77yaIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p?= =?utf-8?q?ng_MPLS-TP_PSC_linear_protection_protocol_to_transport_r?= =?utf-8?q?equirements?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Jul 2013 05:20:39 -0000 --001a11c3669eaa1d5d04e23b1179 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, While I personally support the idea of including the SD support in the Linear Protection protocol, if only for compatibility with other comparable tools, I feel there is a need to add the context that caused it to be "downgraded" to place-holder status in PSC. In the original draft versions of the PSC definition, we included SD messages and described the switching operation when the system triggered an SD situation. On the assumption that there would be a way to detect some kind of SD. There were even some drafts that were proposed by different members on how to define SD and detect it for MPLS. None of these latter drafts were, however, accepted by the WG based upon the belief that SD is not relevant at the MPLS level, it is more a system-layer or physical layer issue and should be solved by those layers. In addition, regarding the idea of switching the traffic from the working to the protection path based on an SD situation on the working path was frowned upon. This was based on the question of how do we assure that the protection path is a better medium for the packet transport. Because even if you could measure and identify an SD situation on the working path, there is no way to measure it on the protection path, since it is most probably affected by the load factors involved in the packet sizes. Therefore, you are switching to a path that, at least in theory, could be a worse choice! This was the reasoning behind the downgrade of the SD signal and the note that this is for further study. I have not seen anyone in this discussion address this issue, and therefore I think it is important that we hear some justification for switching away from a working path to one that we have no better information on! I think that the justifications given until now - i.e. "this is the way it has always been done in physical layer systems" - are not sufficient to add functionality that may cause poorer performance= ! Hope this helps focus the discussion, yaacov weingarten On Wed, Jul 24, 2013 at 4:46 AM, Larry wrote: > Hi all, > > I agree with Tom and Jeong-dong. There are different reasons to cause SD, > but the result is the transport performance degrade and it is important t= o > let operators set a threshold to trigger protection switch. During the > trouble shooting, operators need tools to do fault localization. Although= t > "degrade" is a continous variable behaviour, it is a "0/1" problem after > defining the threshold. > Thank you! > > ************************************************************************* > Han Li, Ph.D > China Mobile Research Institute > 32 Xuanwumen West Street, Xicheng District, Beijing 100053, China > Fax: +86 10 63135159 > MOBILE: 13501093385 > ************************************************************************* > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A* "Huber, Thomas J." > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A* Eric Osborne (eosborne) ; "Ryoo, Jeong-dong" < > ryoo@etri.re.kr>; D'Alessandro Alessandro Gerardo < > alessandro.dalessandro@telecomitalia.it>; "mpls@ietf.org" > *=E6=8A=84=E9=80=81=EF=BC=9A* "Huub helvoort (huub.van.helvoort@huawei.co= m)" < > huub.van.helvoort@huawei.com>; "huubatwork@gmail.com" < > huubatwork@gmail.com> > *=E5=8F=91=E9=80=81=E6=97=A5=E6=9C=9F=EF=BC=9A* 2013=E5=B9=B47=E6=9C=8823= =E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C, 3:03 =E4=B8=8A=E5=8D=88 > *=E4=B8=BB=E9=A2=98:* Re: [mpls] proposed drafts for aligning MPLS-TP PSC= linear > protection protocol to transport requirements > > Hi Eric, > > You wrote: > >EO# > >I'm not sure what that would look like. 'Fail' is a pretty binary > thing. 'Degrade' is a continuous variable, as it can be anything from 'a > little bad' to a 'a whole lot of bad but not quite fail'. > > I think this may be a fundamental difference in assumptions. While it is > certainly true that degradation of a signal is a continuous variable, in > the context of protection switching in the transport network, there is a > particular value of that continuous variable that defines the threshold a= t > which the Boolean variable "signal degrade (SD)" becomes true. It is for > this reason that Jeong-dong and others are suggesting that it should be > possible to incorporate the behavior of the SD state into the PSC > definition without needing to have a precise definition of the mechanism > for measuring the degradation of a signal. Whatever the mechanism is, it > will be converted to the binary SD indication. > > Best regards, > Tom > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Osborne (eosborne) > Sent: Monday, July 22, 2013 8:36 AM > To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; mpls@ietf.org > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com > Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear > protection protocol to transport requirements > > Hi Jeong-dong, > > Thanks for the reply. Please see inline with EO#. > > > -----Original Message----- > > From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr] > > Sent: Monday, July 22, 2013 4:15 AM > > To: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo; > > mpls@ietf.org > > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com > > Subject: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear > > protection protocol to transport requirements > > > > Hi, Eric. > > > > Let me answer your 2nd question on SD. > > > > SD detection methods defined or proposed for packet transport networks > > can be summarized as follows: > > - By OAM performance monitoring tool: > > SD is raised if packet loss ratio exceeds a threshold during a > > measurement period. > > Threshold value and measurement period are configured by an network > > operator. > > This detection method is already defined in ITU-T G.8021 (Ethernet > > equipment spec.) > > > EO# Where? I'm not arguing that it's not in there, I'm just having a > hard time finding it. A search for ETH_CI_SSD doesn't yield much. If I > look for 'signal degrade' I see p. 131 which says that the algorithm is > defined in G.8031. G.8031 says ' How these defects are detected is the > subject of the equipment Recommendations'. I'm looking for something lik= e > "Signal Degrade is defined as $foo packet loss or CRC failure over $bar > time"....what have I missed? > > > > and the equipment spec for MPLS-TP can easily follow the same > > definition. > > - By server layer indication: > > SD is raised if a server layer below MPLS-TP reports SD condition on > > its own layer. > > - By CCM packet counting: > > SD is raised if the loss ratio of CCM packets exceeds a threshold > > during a measurement period. > > > > Regardless of how to detect SD, any protection switching documents > > should describe the protection switching operation once such a SD is > > declared. > > > ... > > Regarding the multiple levels of SD: > > It is certainly possible to define multiple levels of SD. > > But, as far as the protection switching is concerned, it just needs to > > know if SD is signaled to protection switching process or not. > > It would be a network operator's choice at what level of SD he wants > > his network protection to switchover. > > In other words, what triggers protection switching is SD or no SD. It > > is yes or no decision. > > > EO# I am not aware of any document which suggests that a server layer SD > should be treated as a client layer SD. In the IP world, if we have SD o= n > a transport interface that is generally used to bring the interface down > (i.e. SF). This is the sort of thing I'd like to see in more detail, as = SD > in the packet world is a new concept and we can't just assume that it wil= l > work the same everywhere because we define state machine points for it. > > The point about CCM is a good one. Let's say we come up with a clever SD > mechanism with two thresholds, call them major and minor. For discussion > purposes they could be simple error ratios, e.g. 1:10^6 and 1:10^9. But > they could be more powerful than that (flow type, flow length, error burs= t > size, etc). > > If we want to have SD-Major and SD-Minor inputs as separate triggers for > PSC, we may want them at different points. Perhaps (leaving out the > Working path for ease of reading) > > LO > FS > SF-P > SD-P-Major > MS > SD-P-Minor > > > This seems like a perfectly reasonable thing to want. > > > Even if we don't have multi-tier SD, even the single-tier SD needs to be > defined before we can decide how to respond to it. > > > The proposed draft covers SD-triggered protection no matter what kinds > > of SD detection methods are used. > > > > > > SF can also be viewed as having multiple levels of SF as the network > > operator can also make a choice on the period/interval of CCM messages. > > > EO# > I'm not sure what that would look like. 'Fail' is a pretty binary thing. > 'Degrade' is a continuous variable, as it can be anything from 'a little > bad' to a 'a whole lot of bad but not quite fail'. > > > If CCM is disabled, AIS from a server layer can be used as a trigger > > for protection switching. So and so forth. > > EO# AIS from the server layer only gets you SD from the first hop of the > underlying server path. > > > > > eric > > > However, protection switching document does not define how to detect > > SF in anywhere. > > Similary, protection switching document does not define how manual > > switch and forced switch commands are initiated in a management system > > and signaled to protection switching process. > > > > Again, in my opinion, the draft on SD protection can accommodate any > > SD detection methods. > > > > Best regards, > > > > Jeong-dong > > > > > > > > > > > > > > ________________________________ > > > > From : "Eric Osborne (eosborne)" Sent : > > 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerardo > > , mpls@ietf.org > > Cc : Huub helvoort (huub.van.helvoort@huawei.com) > > , huubatwork@gmail.com > > Subject : Re: [mpls] proposed drafts for > > aligning MPLS-TP PSC linear protection protocol to transport > > requirements > > > > > > Hi Alessandro- > > > > Thanks for this; the threads I started some time back seem to have > > died down, it's good to get them going again. > > I have two things I never quite understood, can you clarify them for me= ? > > > > i) can you explain EXER at a higher level? I'm not looking for a > > description of the state machine changes, and I'm not looking for the > > one line "It allows the FSM to be tested". We have all of that in the > > draft and in the equivalent ITU specs. > > > > What I'd like to understand about EXER is where it came from. The ITU > > specs that define it are pretty hard to follow, they seem to assume > > the reader already knows what EXER is and what problem it solves. It > > feels very much like a mechanism used to catch a very specific > > implementation bug, back when transport gear was far less debuggable > > than what we have today. > > > > No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, > > ISIS) have explicit signaling in them just to ask the neighbor whether > > it *would* be broken if if were, in the future, to be given a > > particular input. Part of my reluctance to get behind EXER has been > > that I don't feel comfortable with the idea of keeping a 30-year-old > > workaround in a protocol. Is there more to it than that? Have I > > misread and misunderstood EXER? Does modern transport gear ever > > actually detect a problem via EXER/RR that wasn't obvious to the > > operator using other means? > > > > > > ii) Why the push to standardize the SD state changes before we've > > defined SD? I certainly agree that handling signal degrade is a good > > idea, but coming up with a definition for it has been challenging. > > What happens if we change the FSM to handle it, then come up with > > something more sophisticated (say, multiple levels of SD) that doesn't > > quite fit with the FSM changes? > > > > > > > > thanks! > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > D'Alessandro Alessandro Gerardo > > > Sent: Wednesday, July 17, 2013 3:23 PM > > > To: mpls@ietf.org > > > Cc: Huub helvoort (huub.van.helvoort@huawei.com); > > > huubatwork@gmail.com > > > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear > > > protection protocol to transport requirements > > > > > > Dear all, > > > we would like socializing the herebelow drafts that were submitted > > some > > > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T > > > transport requirements. I would appreciate your comments about the > > > proposed mechanisms and behaviours. > > > > > > draft-rhd-mpls-tp-psc-priority-00 > > > draft-cdh-mpls-tp-psc-non-revertive-00 > > > draft-rhd-mpls-tp-psc-sd-00 > > > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 > > > > > > The above drafts cover most of items highlighted in ITU-T liaisons > > about > > > PSC and they propose solutions in line with MPLS-TP transport > > > requirements. > > > A list of main liaisons exchanged between ITU-T and IETF with the > > > aim > > to > > > align PSC behavious with ITU-T transport requirements for linear > > > protection are given below: > > > https://datatracker.ietf.org/liaison/1162/ (June 2012) > > > https://datatracker.ietf.org/liaison/1205/ > > > (October 2012) > > > https://datatracker.ietf.org/liaison/1229/ > > > (January 2013) > > > https://datatracker.ietf.org/liaison/1234/ > > > (February 2013) > > > https://datatracker.ietf.org/liaison/1256/ > > > (May 2013) > > > > > > Some details abou the proposed drafts for align PSC behaviour with > > > transport requirements: > > > > > > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities > > > between FS and SF-P (see section 4.3.2 of rfc6378). > > > Among the others, behaviors that will be fixed with the proposed > > update > > > are: > > > Use case A) At first, working path(WP) and protection path(PP) are > > > normal. Then, Forced Switch(FS) command is issued for maintenance on > > the > > > WP and the traffic moves from WP to PP. When Signal Fail occurs on > > > PP, service cannot recover and is interrupted. This could occur for > > example > > > as a result of accidentally un-plugging a PP fiber. > > > Use case B) If there is an existing signal fail on a protection path > > > (SF-P),and FS command is issued by accident the traffic on WP will > > move > > > to PP. This results in an interruption of service from which you > > > will not automatically recover, because PSC should not have switched > > > the traffic from WP to PP. > > > Discussion about this draft led to the proposal to modify RFC 4427 > > that > > > was "written correctly though lacking in detail causing mis- > > > interpretation" that led to the current PSC set of priority that the > > > above draft is proposing to modified and to align to the required > > > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been > > > submitted to CCAMP for clarifying the definitions related to Manual > > > Switch and Forced Switch and their usage relative to priorities. > > > The way this behavior has to be incorporated into the PSC has to be > > > discussed. The text proposes to replace the current behavior with > > > the new one. If there is consensus to procede in that way this can > > > bring > > to > > > a simple and effective way to operate the protocol. > > > > > > -------------------------------------------------------------------- > > > -- > > > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to > > > RFC6378 to change non-revertive operations to behaves in the same > > > way irrespectively of the trigger of protection switching (fault or > > operator > > > command FS, MS). Consequently an operator command, Manual Switch to > > > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is > > also > > > added to enable this behavior. From an operational point of view, MS > > to > > > working path has also to be supported to be able to initially align > > > at both sides in case of non-revertive switching mode. MS to working > > > path is defined in RFC 5654, requirement 83. > > > > > > The proposed MS-W command is of equal priority to the existing MS-P > > > command, and there is text to handle the simultaneous or sequential > > > occurrence of two equal-priority commands. This behavior, already > > > adopted in other transport network protection switching protocol, > > > can > > be > > > used for other addition to the protocol in the future. > > > > > > -------------------------------------------------------------------- > > > -- > > > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state > > > machine to handle Signal Degrade (SD). It does not define SD or > > provide > > > scope around where or how SD may be used similarly as it already > > happen > > > in the draft in handling other defects like SF (Signal Failure). > > > In MPLS-TP survivability framework [RFC6372], a fault condition > > > includes both Signal Fail (SF) and Signal Degrade (SD) that can be > > used > > > to trigger protection switching. > > > While the standardization lack of an SD definition and detection > > > mechanisms, the relevant behaviors in terms of protection actions > > > may already be defined. > > > > > > -------------------------------------------------------------------- > > > -- > > > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to > > > test if the APS communication is operating correctly. In other words > > > both APS process logic including state machine and APS channel on > > > protection path, without service disruption and without affecting > > > any protection operation, unless the protection transport entity is > > > in > > use. > > > This command is documented in R84 of [RFC5654] and it is part of > > > ITU-T transport requirements. > > > An alternative proposal is documented in the Appendix B of RFC6378 > > that > > > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in > > > combination of OAM functionalities. However, it has some functional > > > limitation and has a potential risk of losing traffic as a signal > > > failure might occur during the exercise operation. In that case, LO > > > or FS has to be canceled to allow the PSC protocol to provide proper > > > switching. > > > A further alternative proposal is documented in draft-osborne-mpls- > > psc- > > > alive-00 that anyway show some functional limitations because cannot > > > validate the PSC state machine status and probably the Local Request > > > logic. > > > > > > > > > The authors encourage the IETF experts to comment on these drafts, > > > eventually proposing other options/mechanisms that can satisfy the > > same > > > requirements. > > > Best regards, > > > Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i suoi > > > allegati sono indirizzati esclusivamente > > alle > > > persone indicate. La diffusione, copia o qualsiasi altra azione > > > derivante dalla conoscenza di queste informazioni sono rigorosamente > > > vietate. Qualora abbiate ricevuto questo documento per errore siete > > > cortesemente pregati di darne immediata comunicazione al mittente e > > > di provvedere alla sua distruzione, Grazie. > > > > > > This e-mail and any attachments is confidential and may contain > > > privileged information intended for the addressee(s) only. > > > Dissemination, copying, printing or use by anybody else is > > unauthorised. > > > If you are not the intended recipient, please delete this message > > > and any attachments and advise the sender by return e-mail, Thanks. > > > > > > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se > > non > > > =C3=A8 necessario. > > > > _______________________________________________ > > 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 > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --001a11c3669eaa1d5d04e23b1179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
=C2=A0
While I personally= support the idea of including the SD support in the Linear Protection prot= ocol, if only for compatibility with other comparable tools, I feel there i= s a need to add the context that caused it to be "downgraded" to = place-holder status in PSC.
=C2=A0
In the original draft versions of the PSC definition,= we included SD messages and described the switching operation when the sys= tem triggered an SD situation. On the assumption that there would be a way = to detect some kind of SD. There were even some drafts that were proposed b= y different members on how to define SD and detect it for MPLS. None of the= se latter drafts were, however, accepted by the WG based upon the belief th= at SD is not relevant at the MPLS level, it is more a system-layer or physi= cal layer issue and should be solved by those layers.
=C2=A0
In addition, regarding the idea of switching the traf= fic from the working to the protection path based on an SD situation on the= working path was frowned upon. This was based on the question of how do we= assure that the protection path is a better medium for the packet transpor= t. Because even if you could measure and identify an SD situation on the wo= rking path, there is no way to measure it on the protection path, since it = is most probably affected by the load factors involved in the packet sizes.= =C2=A0 Therefore, you are switching to a path that, at least in theory, cou= ld be a worse choice!
=C2=A0
This was the reasoning behind the downgrade of the SD= signal and the note that this is for further study.=C2=A0 I have not seen = anyone in this discussion address this issue, and therefore I think it is i= mportant that we hear some justification for switching away from a working = path to one that we have no better information on! I think that the justifi= cations given until now - i.e. "this is the way it has always been don= e in physical layer systems" -=C2=A0are not sufficient to add function= ality that may cause poorer performance!
=C2=A0
Hope this helps focus the discussion,
yaaco= v weingarten


On Wed, Jul 24, 2013 at 4:46 AM, Larry <larryli888@yahoo.= com.cn> wrote:
Hi all,

I= agree with Tom and=C2=A0Jeong-dong. = There are different reasons to cause SD, but the result is the transport pe= rformance degrade and it is important to let operators set a threshold to t= rigger protection switch. During the trouble shooting, operators need tools= to do fault localization. Althought "degrade" is a continous var= iable behaviour, it is a "0/1" problem after defining the threshold.
Thank you!
=C2=A0
******************************************= *******************************
Han Li, Ph.D
China Mobile Research I= nstitute
32 Xuanwumen West Street, Xicheng District, Beijing 100053, Chi= na
Fax: +86 10 63135159
MOBILE: 13501093385
*****************= ********************************************************
=E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A "Huber, Thomas J." <Tom.Huber@tellabs.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Eric Osborne (eosborne) <eosborne@cisco.com>; "Ryoo, Jeong-dong"= <ryoo@etri.re.kr>; D'Alessandro Alessandro Gerardo <alessandro.dalessandro@te= lecomitalia.it>; "mpls@ietf.org" <mpls@ietf.org>
=E6=8A=84=E9=80=81=EF=BC=9A = "Huub helvoort (huub.van.helvoort@huawei.com)" <huub.van.helvoort@huawei.com= >; "h= uubatwork@gmail.com" <huubatwork@gmail.com>
=E5=8F=91=E9=80=81=E6=97=A5=E6=9C=9F= =EF=BC=9A 2013=E5=B9=B47=E6=9C=8823=E6=97=A5, =E6=98=9F=E6=9C=9F= =E4=BA=8C, 3:03 =E4=B8=8A=E5=8D=88
= =E4=B8=BB=E9=A2=98: Re: [mpls] proposed drafts for aligning MPLS= -TP PSC linear protection protocol to transport requirements

Hi Eric,

You wrote:<= br>>EO#
>I'm not sure what that would look like.=C2=A0 'Fail' is a pretty binary thing.=C2=A0= 'Degrade' is a continuous variable, as it can be anything from = 9;a little bad' to a 'a whole lot of bad but not quite fail'.
I think this may be a fundamental difference in assumptions.=C2=A0 While it= is certainly true that degradation of a signal is a continuous variable, i= n the context of protection switching in the transport network, there is a = particular value of that continuous variable that defines the threshold at = which the Boolean variable "signal degrade (SD)" becomes true.=C2= =A0 It is for this reason that Jeong-dong and others are suggesting that it= should be possible to incorporate the behavior of the SD state into the PS= C definition without needing to have a precise definition of the mechanism = for measuring the degradation of a signal.=C2=A0 Whatever the mechanism is,= it will be converted to the binary SD indication.

Best regards,
Tom


-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osbor= ne (eosborne)
Sent: Monday, July 22, 2013 8:36 AM
To: Ryoo, Jeong-dong; D'Alessand= ro Alessandro Gerardo; m= pls@ietf.org
Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protect= ion protocol to transport requirements

Hi Jeong-dong,

=C2=A0 = Thanks for the reply.=C2=A0 Please see inline with EO#.

> -----Or= iginal Message-----
> From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr]
> Sent: Monday, July 22, 2013 4:15 AM
>= ; To: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo;
>= mpls@ietf.org
> Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com
> Subject: = RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
>
> Hi, Eric= .
>
> Let me answer your 2nd question on SD.
>
> SD= detection methods defined or proposed for packet transport networks
> can be summarized as follows:
> - By OAM performance monitoring = tool:
>=C2=A0=20 SD is raised if packet loss ratio exceeds a threshold during a
> mea= surement period.
>=C2=A0 Threshold value and measurement period are = configured by an network
> operator.
>=C2=A0 This detection me= thod is already defined in ITU-T G.8021 (Ethernet
> equipment spec.)


EO#=C2=A0 Where?=C2=A0 I'm not arguing= that it's not in there, I'm just having a hard time finding it.=C2= =A0 A search for ETH_CI_SSD doesn't yield much.=C2=A0 If I look for = 9;signal degrade' I see p. 131 which says that the algorithm is defined= in G.8031.=C2=A0 G.8031 says ' How these defects are detected is the s= ubject of the equipment Recommendations'.=C2=A0 I'm looking for som= ething like "Signal Degrade is defined as $foo packet loss or CRC fail= ure over $bar time"....what have I missed?


>=C2=A0 and the equipment spec for MPLS-TP can easily follow th= e same
> definition.
> - By server layer indication:
>=C2= =A0 SD is raised if a server layer below MPLS-TP reports SD condition on
> its= own layer.
> - By CCM packet counting:
>=C2=A0 SD is raised i= f the loss ratio of CCM packets exceeds a threshold
> during a measur= ement period.
>
> Regardless of how to detect SD, any protection switching docum= ents
> should describe the protection switching operation once such a= SD is
> declared.
>
...
> Regarding the multiple leve= ls of SD:
> It is certainly possible to define multiple levels of SD.
> But,= as far as the protection switching is concerned, it just needs to
> = know if SD is signaled to protection switching process or not.
> It w= ould be a network operator's choice at what level of SD he wants
> his network protection to switchover.
> In other words, what tri= ggers protection switching is SD or no SD. It
> is yes or no decision= .


EO#=C2=A0 I am not aware of any document which suggests that a server layer SD should be treated as a clie= nt layer SD.=C2=A0 In the IP world, if we have SD on a transport interface = that is generally used to bring the interface down (i.e. SF).=C2=A0 This is= the sort of thing I'd like to see in more detail, as SD in the packet = world is a new concept and we can't just assume that it will work the s= ame everywhere because we define state machine points for it.

The point about CCM is a good one.=C2=A0 Let's say we come up with = a clever SD mechanism with two thresholds, call them major and minor.=C2=A0= For discussion purposes they could be simple error ratios, e.g. 1:10^6 and= 1:10^9.=C2=A0 But they could be more powerful than that (flow type, flow l= ength, error burst size, etc).

If we want to have SD-Major and SD-Minor inputs as separate triggers fo= r PSC, we may want them at different points.=C2=A0 Perhaps=C2=A0 (leaving o= ut the Working path for ease of reading)

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

=
This seems like a perfectly reasonable thing to want.


Even i= f we don't have multi-tier SD, even the single-tier SD needs to be defi= ned before we can decide how to respond to it.

> The proposed draft covers SD-triggered protection no matter what k= inds
> of SD detection methods are used.
>
>
> SF c= an also be viewed as having multiple levels of SF as the network
> op= erator can also make a choice on the period/interval of CCM messages.


EO#
I'm not sure what that would look like.=C2=A0 'Fail&= #39; is a pretty binary thing.=C2=A0 'Degrade' is a continuous vari= able, as it can be anything from 'a little bad' to a 'a whole l= ot of bad but not quite fail'.

> If CCM is disabled, AIS from a server layer can be used as a trigg= er
> for protection switching. So and so forth.

EO#=C2=A0 AIS = from the server layer only gets you SD from the first hop of the underlying server path.

=


eric

> However, protection switching document does no= t define how to detect
> SF in anywhere.
> Similary, protection= switching document does not define how manual
> switch and forced switch commands are initiated in a management system=
> and signaled to protection switching process.
>
> Agai= n, in my opinion, the draft on SD protection can accommodate any
> SD= detection methods.
>
> Best regards,
>
> Jeong-dong
>
>
&g= t;
>
>
>
> ________________________________
>=
> From : "Eric Osborne (eosborne)" <eosborne@cisco.com> Sent :
> 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerard= o
> <alessandro.dalessandro@telecomitalia.it>, mpls@ietf.org
> <mpls@ietf.org> Cc : Huub helvoort (huub.van.helvoort@huawei.com)
> <huub.van.helvoort@hu= awei.com>, huubatwork@gmail.com
> <huubatwo= rk@gmail.com> Subject : Re: [mpls] proposed drafts for
> align= ing MPLS-TP PSC linear protection protocol to transport
> requirements
>
>
> Hi Alessandro-
>
> Thanks= for this; the threads I started some time back seem to have
> died d= own, it's good to get them going again.
> I have two things I nev= er quite understood, can you clarify them for me?
>
> i) can you explain EXER at a higher level? I'm not looking= for a
> description of the state machine changes, and I'm not lo= oking for the
> one line "It allows the FSM to be tested". = We have all of that in the
> draft and in the equivalent ITU specs.
>
> What I'd li= ke to understand about EXER is where it came from. The ITU
> specs th= at define it are pretty hard to follow, they seem to assume
> the rea= der already knows what EXER is and what problem it solves. It
> feels very much like a mechanism used to catch a very specific
>= implementation bug, back when transport gear was far less debuggable
&g= t; than what we have today.
>
> No other state machines that I'm familiar with = (RSVP, LDP, BGP, OSPF,
> ISIS) have explicit signaling in them just t= o ask the neighbor whether
> it *would* be broken if if were, in the = future, to be given a
> particular input. Part of my reluctance to get behind EXER has been> that I don't feel comfortable with the idea of keeping a 30-year-= old
> workaround in a protocol. Is there more to it than that? Have I=
> misread and misunderstood EXER? Does modern transport gear ever
>= ; actually detect a problem via EXER/RR that wasn't obvious to the
&= gt; operator using other means?
>
>
> ii) Why the push to= standardize the SD state changes before we've
> defined SD? I certainly agree that handling signal degrade is a good> idea, but coming up with a definition for it has been challenging.> What happens if we change the FSM to handle it, then come up with
> something more sophisticated (say, multiple levels of SD) tha= t doesn't
> quite fit with the FSM changes?
>
>
&g= t;
> thanks!
>
>
>
>
>
> eric
>
>
> > -----Original Message-----
> > From: mpls-bounces@ietf.o= rg [mailto:m= pls-bounces@ietf.org] On Behalf
> Of
> > D'Alessandro Alessandro Gerardo
> > Sent:= Wednesday, July 17, 2013 3:23 PM
> > To: mpls@ietf.org
> > Cc: Huub helvoort= (huub.va= n.helvoort@huawei.com);
> > huubatw= ork@gmail.com
> > Subject: [mpls] proposed drafts for aligning= MPLS-TP PSC linear
> > protection protocol to transport requireme= nts
> >
> > Dear all,
> > we would like socializing the= herebelow drafts that were submitted
> some
> > months ago = with the aim to align PSC protocol (RFC 6378) to ITU-T
> > transpo= rt requirements. I would appreciate your comments about the
> > proposed mechanisms and behaviours.
> >
> > dra= ft-rhd-mpls-tp-psc-priority-00
> > draft-cdh-mpls-tp-psc-non-rever= tive-00
> > draft-rhd-mpls-tp-psc-sd-00
> > draft-dj-mpls= -tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00
> >
> > The above drafts cover most of items highlighted in = ITU-T liaisons
> about
> > PSC and they propose solutions in= line with MPLS-TP transport
> > requirements.
> > A list of main liaisons exchanged between ITU-T= and IETF with the
> > aim
> to
> > align PSC behav= ious with ITU-T transport requirements for linear
> > protection a= re given below:
> > https://datatracker.ietf.org/liaison/1162/ (June 2012)
> = > https://datatracker.ietf.org/liaison/1205/
> > (October 2012)
> > https://datatracker.ietf.org/li= aison/1229/
> > (January 2013)
> > https://datatracker.ietf.org/li= aison/1234/
> > (February 2013)
> > https://datatracker.ietf.org/l= iaison/1256/
> > (May 2013)
> >
> > Some details abou th= e proposed drafts for align PSC behaviour with
> > transport requi= rements:
> >
> > draft-rhd-mpls-tp-psc-priority-00 propos= es swapping the priorities
> > between FS and SF-P (see section 4.3.2 of rfc6378).
> > = Among the others, behaviors that will be fixed with the proposed
> up= date
> > are:
> > Use case A) At first, working path(WP) = and protection path(PP) are
> > normal. Then, Forced Switch(FS) command is issued for maintenance= on
> the
> > WP and the traffic moves from WP to PP. When S= ignal Fail occurs on
> > PP, service cannot recover and is interru= pted. This could occur for
> example
> > as a result of accidentally un-plugging a PP fibe= r.
> > Use case B) If there is an existing signal fail on a protec= tion path
> > (SF-P),and FS command is issued by accident the traffic on WP will
> move
> > to PP.= This results in an interruption of service from which you
> > wil= l not automatically recover, because PSC should not have switched
> &= gt; the traffic from WP to PP.
> > Discussion about this draft led to the proposal to modify RFC 442= 7
> that
> > was "written correctly though lacking in d= etail causing mis-
> > interpretation" that led to the curren= t PSC set of priority that the
> > above draft is proposing to modified and to align to the required=
> > transport behavior. draft-helvoort-ccamp-fs-priority-00 has b= een
> > submitted to CCAMP for clarifying the definitions related = to Manual
> > Switch and Forced Switch and their usage relative to priorities.<= br>> > The way this behavior has to be incorporated into the PSC has = to be
> > discussed. The text proposes to replace the current behavior with
> > the new one. If there is consensus to procede i= n that way this can
> > bring
> to
> > a simple and= effective way to operate the protocol.
> >
> > ---------= -----------------------------------------------------------
> > --
> > draft-cdh-mpls-tp-psc-non-revertive-00 contains t= he updates to
> > RFC6378 to change non-revertive operations to be= haves in the same
> > way irrespectively of the trigger of protect= ion switching (fault or
> operator
> > command FS, MS). Consequently an operator comman= d, Manual Switch to
> > Working (MS-W) a.k.a "Manual switch-o= ver for recovery LSP/span" is
> also
> > added to enabl= e this behavior. From an operational point of view, MS
> to
> > working path has also to be supported to be able to in= itially align
> > at both sides in case of non-revertive switching mode. MS to working
> > path is defined in RFC 5654, requirement = 83.
> >
> > The proposed MS-W command is of equal priorit= y to the existing MS-P
> > command, and there is text to handle th= e simultaneous or sequential
> > occurrence of two equal-priority commands. This behavior, already=
> > adopted in other transport network protection switching proto= col,
> > can
> be
> > used for other addition to th= e protocol in the future.
> >
> > ----------------------------------------------------= ----------------
> > --
> > draft-rhd-mpls-tp-psc-sd-00 p= rovides extensions to the PSC state
> > machine to handle Signal D= egrade (SD). It does not define SD or
> provide
> > scope around where or how SD may be used similarl= y as it already
> happen
> > in the draft in handling other = defects like SF (Signal Failure).
> > In MPLS-TP survivability framework [RFC6372], a fault condition
&g= t; > includes both Signal Fail (SF) and Signal Degrade (SD) that can be<= br>> used
> > to trigger protection switching.
> > Whi= le the standardization lack of an SD definition and detection
> > mechanisms, the relevant behaviors in terms of protection actions=
> > may already be defined.
> >
> > -----------= ---------------------------------------------------------
> > -- > > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands= to
> > test if the APS communication is operating correctly. In o= ther words
> > both APS process logic including state machine and = APS channel on
> > protection path, without service disruption and without affecting=
> > any protection operation, unless the protection transport ent= ity is
> > in
> use.
> > This command is documented in R84 of [RFC5654] and it is part of
> > I= TU-T transport requirements.
> > An alternative proposal is docume= nted in the Appendix B of RFC6378
> that
> > utilizes the Lo= ckout of Protection (LO) or Forced Switch (FS) in
> > combination of OAM functionalities. However, it has some function= al
> > limitation and has a potential risk of losing traffic as a = signal
> > failure might occur during the exercise operation. In t= hat case, LO
> > or FS has to be canceled to allow the PSC protocol to provide pro= per
> > switching.
> > A further alternative proposal is = documented in draft-osborne-mpls-
> psc-
> > alive-00 that a= nyway show some functional limitations because cannot
> > validate the PSC state machine status and probably the Local Requ= est
> > logic.
> >
> >
> > The authors = encourage the IETF experts to comment on these drafts,
> > eventually proposing= other options/mechanisms that can satisfy the
> same
> > re= quirements.
> > Best regards,
> > Alessandro, Huub, Jeong= -dong, Taeksid Questo messaggio e i suoi
> > allegati sono indirizzati esclusivamente
> alle
> >= ; persone indicate. La diffusione, copia o qualsiasi altra azione
> &= gt; derivante dalla conoscenza di queste informazioni sono rigorosamente > > vietate. Qualora abbiate ricevuto questo documento per errore sie= te
> > cortesemente pregati di darne immediata comunicazione al mi= ttente e
> > di provvedere alla sua distruzione, Grazie.
> &= gt;
> > This e-mail and any attachments is confidential and may contain> > privileged information intended for the addressee(s) only.
&= gt; > Dissemination, copying, printing or use by anybody else is
> unauthorised.
> > If you are not the intended recipient, please d= elete this message
> > and any attachments and advise the sender b= y return e-mail, Thanks.
> >
> > rispetta l'ambienteR= ispetta l'ambiente. Non stampare questa mail se
> non
> > =C3=A8 necessario.
>
> __________________= _____________________________
> mpls mailing list
> mpls@ietf.org
> https://w= ww.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing= list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing lis= t
mpls@ietf.org= https://www.ietf.org/mailman/listinfo/mpls



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




--
Th= anx and BR,
yaacov

Still looking for new op= portunity
--001a11c3669eaa1d5d04e23b1179-- From wyaacov@gmail.com Wed Jul 24 01:05:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5274111E839F for ; Wed, 24 Jul 2013 01:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwTMuN-fb2MR for ; Wed, 24 Jul 2013 01:05:47 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AD5CF11E839D for ; Wed, 24 Jul 2013 01:05:46 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so93511wgg.0 for ; Wed, 24 Jul 2013 01:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l/W15nypZQgAjT1TpyC5x25CDKYKkc0xPXGA+z3zSDU=; b=0amj6NE/WdUTunxMrsqklwdDTvXQi4WaqNoQO833IXEn5x/pRjvdOIymnnc3kbywKj eLs/TtkjVdsg/I9dPj9YBsyCKbzlEgE7GfIvEdfb7T947tdtJgU40HXzptmKu06KmD8e a62FLNt5deD60L2pL5wggtNYRukOvY0PaIo/DuUjClknz9GsZoC+EN4waTWXCGsRdfkS owXZh62Z2EbXdq/ETXtQIfta56AQYWFJzS+lcCidS6Lhgjzjpl5VIW9XtxkOAvObMhGL 7YOQTRiwCaDEk0hqifHsQhPlg047sd2I7PeYH+BsQ0NshgEDGotQVqBXcKrsxy8C5+uo gZqA== MIME-Version: 1.0 X-Received: by 10.194.122.103 with SMTP id lr7mr25874462wjb.15.1374653144303; Wed, 24 Jul 2013 01:05:44 -0700 (PDT) Received: by 10.194.164.164 with HTTP; Wed, 24 Jul 2013 01:05:44 -0700 (PDT) In-Reply-To: <4itxhycgmayvx76tmodwqsj9.1374649120492@email.android.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com> <4itxhycgmayvx76tmodwqsj9.1374649120492@email.android.com> Date: Wed, 24 Jul 2013 11:05:44 +0300 Message-ID: From: Yaacov Weingarten To: "D'Alessandro Alessandro Gerardo" Content-Type: multipart/alternative; boundary=089e01175e775b11b404e23d602f Cc: "huub.van.helvoort@huawei.com" , "mpls@ietf.org" , "alessando.dalessandro@telecomitalia.it" Subject: Re: [mpls] =?utf-8?b?5Zue5aSN77yaIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p?= =?utf-8?q?ng_MPLS-TP_PSC_linear_protection_protocol_to_transport_r?= =?utf-8?q?equirements?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Jul 2013 08:05:50 -0000 --089e01175e775b11b404e23d602f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alessandro, hi I guess I was not very clear in my presentation - my point had very little to do with how to detect or measure SD but rather with what is the purpose of performing a protection switch. My understanding of the purpose is to guarantee a certain quality of service. Therefore, in the case of SF you switch to the protection path that is working to continue the service. The question in the SD case is (and was back when it was first discussed) - how do I know that the protection path will give a better quality of service when I switch over? Could I be switching to a path that is providing lower quality? And if so, why am I performing the switchover? Hope this clarifies, yaacov On Wed, Jul 24, 2013 at 10:11 AM, D'Alessandro Alessandro Gerardo < alessandro.dalessandro@telecomitalia.it> wrote: > Dear Yacov, > I understand your points but we are again moving the discussion to the > problems in defining sd and the method to detect sd neglecting the costs > that carriers have to face with in introducing such functionality later o= n > in the network. > Best regards > Alessandro > > > Inviato da Samsung Mobile > > > > -------- Messaggio originale -------- > Oggetto:Re: [mpls] =E5=9B=9E=E5=A4=8D=EF=BC=9A proposed drafts for aligni= ng MPLS-TP PSC linear > protection protocol to transport requirements > Da:Yaacov Weingarten > A:"mpls@ietf.org" > Cc:"Eric Osborne (eosborne)" ,"Ryoo, Jeong-dong" < > ryoo@etri.re.kr>,D'Alessandro Alessandro Gerardo < > alessandro.dalessandro@telecomitalia.it>,"Huub helvoort ( > huub.van.helvoort@huawei.com)" > > > > Hi all, > > While I personally support the idea of including the SD support in the > Linear Protection protocol, if only for compatibility with other comparab= le > tools, I feel there is a need to add the context that caused it to be > "downgraded" to place-holder status in PSC. > > In the original draft versions of the PSC definition, we included SD > messages and described the switching operation when the system triggered = an > SD situation. On the assumption that there would be a way to detect some > kind of SD. There were even some drafts that were proposed by different > members on how to define SD and detect it for MPLS. None of these latter > drafts were, however, accepted by the WG based upon the belief that SD is > not relevant at the MPLS level, it is more a system-layer or physical lay= er > issue and should be solved by those layers. > > In addition, regarding the idea of switching the traffic from the working > to the protection path based on an SD situation on the working path was > frowned upon. This was based on the question of how do we assure that the > protection path is a better medium for the packet transport. Because even > if you could measure and identify an SD situation on the working path, > there is no way to measure it on the protection path, since it is most > probably affected by the load factors involved in the packet sizes. > Therefore, you are switching to a path that, at least in theory, could be= a > worse choice! > > This was the reasoning behind the downgrade of the SD signal and the note > that this is for further study. I have not seen anyone in this discussio= n > address this issue, and therefore I think it is important that we hear so= me > justification for switching away from a working path to one that we have = no > better information on! I think that the justifications given until now - > i.e. "this is the way it has always been done in physical layer systems" > - are not sufficient to add functionality that may cause poorer performan= ce! > > Hope this helps focus the discussion, > yaacov weingarten > > > On Wed, Jul 24, 2013 at 4:46 AM, Larry wrote: > >> Hi all, >> >> I agree with Tom and Jeong-dong. There are different reasons to cause >> SD, but the result is the transport performance degrade and it is import= ant >> to let operators set a threshold to trigger protection switch. During th= e >> trouble shooting, operators need tools to do fault localization. Althoug= ht >> "degrade" is a continous variable behaviour, it is a "0/1" problem after >> defining the threshold. >> Thank you! >> >> ************************************************************************= * >> Han Li, Ph.D >> China Mobile Research Institute >> 32 Xuanwumen West Street, Xicheng District, Beijing 100053, China >> Fax: +86 10 63135159 >> MOBILE: 13501093385 >> ************************************************************************= * >> ------------------------------ >> *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A* "Huber, Thomas J." >> *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A* Eric Osborne (eosborne) ; "Ryoo, Jeong-dong" < >> ryoo@etri.re.kr>; D'Alessandro Alessandro Gerardo < >> alessandro.dalessandro@telecomitalia.it>; "mpls@ietf.org" >> >> *=E6=8A=84=E9=80=81=EF=BC=9A* "Huub helvoort (huub.van.helvoort@huawei.c= om)" < >> huub.van.helvoort@huawei.com>; "huubatwork@gmail.com" < >> huubatwork@gmail.com> >> *=E5=8F=91=E9=80=81=E6=97=A5=E6=9C=9F=EF=BC=9A* 2013=E5=B9=B47=E6=9C=882= 3=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C, 3:03 =E4=B8=8A=E5=8D=88 >> *=E4=B8=BB=E9=A2=98:* Re: [mpls] proposed drafts for aligning MPLS-TP PS= C linear >> protection protocol to transport requirements >> >> Hi Eric, >> >> You wrote: >> >EO# >> >I'm not sure what that would look like. 'Fail' is a pretty binary >> thing. 'Degrade' is a continuous variable, as it can be anything from '= a >> little bad' to a 'a whole lot of bad but not quite fail'. >> >> I think this may be a fundamental difference in assumptions. While it i= s >> certainly true that degradation of a signal is a continuous variable, in >> the context of protection switching in the transport network, there is a >> particular value of that continuous variable that defines the threshold = at >> which the Boolean variable "signal degrade (SD)" becomes true. It is fo= r >> this reason that Jeong-dong and others are suggesting that it should be >> possible to incorporate the behavior of the SD state into the PSC >> definition without needing to have a precise definition of the mechanism >> for measuring the degradation of a signal. Whatever the mechanism is, i= t >> will be converted to the binary SD indication. >> >> Best regards, >> Tom >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Eric Osborne (eosborne) >> Sent: Monday, July 22, 2013 8:36 AM >> To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; mpls@ietf.org >> Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com >> Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear >> protection protocol to transport requirements >> >> Hi Jeong-dong, >> >> Thanks for the reply. Please see inline with EO#. >> >> > -----Original Message----- >> > From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr] >> > Sent: Monday, July 22, 2013 4:15 AM >> > To: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo; >> > mpls@ietf.org >> > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.com >> > Subject: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear >> > protection protocol to transport requirements >> > >> > Hi, Eric. >> > >> > Let me answer your 2nd question on SD. >> > >> > SD detection methods defined or proposed for packet transport networks >> > can be summarized as follows: >> > - By OAM performance monitoring tool: >> > SD is raised if packet loss ratio exceeds a threshold during a >> > measurement period. >> > Threshold value and measurement period are configured by an network >> > operator. >> > This detection method is already defined in ITU-T G.8021 (Ethernet >> > equipment spec.) >> >> >> EO# Where? I'm not arguing that it's not in there, I'm just having a >> hard time finding it. A search for ETH_CI_SSD doesn't yield much. If I >> look for 'signal degrade' I see p. 131 which says that the algorithm is >> defined in G.8031. G.8031 says ' How these defects are detected is the >> subject of the equipment Recommendations'. I'm looking for something li= ke >> "Signal Degrade is defined as $foo packet loss or CRC failure over $bar >> time"....what have I missed? >> >> >> > and the equipment spec for MPLS-TP can easily follow the same >> > definition. >> > - By server layer indication: >> > SD is raised if a server layer below MPLS-TP reports SD condition on >> > its own layer. >> > - By CCM packet counting: >> > SD is raised if the loss ratio of CCM packets exceeds a threshold >> > during a measurement period. >> > >> > Regardless of how to detect SD, any protection switching documents >> > should describe the protection switching operation once such a SD is >> > declared. >> > >> ... >> > Regarding the multiple levels of SD: >> > It is certainly possible to define multiple levels of SD. >> > But, as far as the protection switching is concerned, it just needs to >> > know if SD is signaled to protection switching process or not. >> > It would be a network operator's choice at what level of SD he wants >> > his network protection to switchover. >> > In other words, what triggers protection switching is SD or no SD. It >> > is yes or no decision. >> >> >> EO# I am not aware of any document which suggests that a server layer S= D >> should be treated as a client layer SD. In the IP world, if we have SD = on >> a transport interface that is generally used to bring the interface down >> (i.e. SF). This is the sort of thing I'd like to see in more detail, as= SD >> in the packet world is a new concept and we can't just assume that it wi= ll >> work the same everywhere because we define state machine points for it. >> >> The point about CCM is a good one. Let's say we come up with a clever S= D >> mechanism with two thresholds, call them major and minor. For discussio= n >> purposes they could be simple error ratios, e.g. 1:10^6 and 1:10^9. But >> they could be more powerful than that (flow type, flow length, error bur= st >> size, etc). >> >> If we want to have SD-Major and SD-Minor inputs as separate triggers for >> PSC, we may want them at different points. Perhaps (leaving out the >> Working path for ease of reading) >> >> LO >> FS >> SF-P >> SD-P-Major >> MS >> SD-P-Minor >> >> >> This seems like a perfectly reasonable thing to want. >> >> >> Even if we don't have multi-tier SD, even the single-tier SD needs to be >> defined before we can decide how to respond to it. >> >> > The proposed draft covers SD-triggered protection no matter what kinds >> > of SD detection methods are used. >> > >> > >> > SF can also be viewed as having multiple levels of SF as the network >> > operator can also make a choice on the period/interval of CCM messages= . >> >> >> EO# >> I'm not sure what that would look like. 'Fail' is a pretty binary >> thing. 'Degrade' is a continuous variable, as it can be anything from '= a >> little bad' to a 'a whole lot of bad but not quite fail'. >> >> > If CCM is disabled, AIS from a server layer can be used as a trigger >> > for protection switching. So and so forth. >> >> EO# AIS from the server layer only gets you SD from the first hop of th= e >> underlying server path. >> >> >> >> >> eric >> >> > However, protection switching document does not define how to detect >> > SF in anywhere. >> > Similary, protection switching document does not define how manual >> > switch and forced switch commands are initiated in a management system >> > and signaled to protection switching process. >> > >> > Again, in my opinion, the draft on SD protection can accommodate any >> > SD detection methods. >> > >> > Best regards, >> > >> > Jeong-dong >> > >> > >> > >> > >> > >> > >> > ________________________________ >> > >> > From : "Eric Osborne (eosborne)" Sent : >> > 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerardo >> > , mpls@ietf.org >> > Cc : Huub helvoort (huub.van.helvoort@huawei.com) >> > , huubatwork@gmail.com >> > Subject : Re: [mpls] proposed drafts for >> > aligning MPLS-TP PSC linear protection protocol to transport >> > requirements >> > >> > >> > Hi Alessandro- >> > >> > Thanks for this; the threads I started some time back seem to have >> > died down, it's good to get them going again. >> > I have two things I never quite understood, can you clarify them for m= e? >> > >> > i) can you explain EXER at a higher level? I'm not looking for a >> > description of the state machine changes, and I'm not looking for the >> > one line "It allows the FSM to be tested". We have all of that in the >> > draft and in the equivalent ITU specs. >> > >> > What I'd like to understand about EXER is where it came from. The ITU >> > specs that define it are pretty hard to follow, they seem to assume >> > the reader already knows what EXER is and what problem it solves. It >> > feels very much like a mechanism used to catch a very specific >> > implementation bug, back when transport gear was far less debuggable >> > than what we have today. >> > >> > No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, >> > ISIS) have explicit signaling in them just to ask the neighbor whether >> > it *would* be broken if if were, in the future, to be given a >> > particular input. Part of my reluctance to get behind EXER has been >> > that I don't feel comfortable with the idea of keeping a 30-year-old >> > workaround in a protocol. Is there more to it than that? Have I >> > misread and misunderstood EXER? Does modern transport gear ever >> > actually detect a problem via EXER/RR that wasn't obvious to the >> > operator using other means? >> > >> > >> > ii) Why the push to standardize the SD state changes before we've >> > defined SD? I certainly agree that handling signal degrade is a good >> > idea, but coming up with a definition for it has been challenging. >> > What happens if we change the FSM to handle it, then come up with >> > something more sophisticated (say, multiple levels of SD) that doesn't >> > quite fit with the FSM changes? >> > >> > >> > >> > thanks! >> > >> > >> > >> > >> > >> > eric >> > >> > >> > > -----Original Message----- >> > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> > Of >> > > D'Alessandro Alessandro Gerardo >> > > Sent: Wednesday, July 17, 2013 3:23 PM >> > > To: mpls@ietf.org >> > > Cc: Huub helvoort (huub.van.helvoort@huawei.com); >> > > huubatwork@gmail.com >> > > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear >> > > protection protocol to transport requirements >> > > >> > > Dear all, >> > > we would like socializing the herebelow drafts that were submitted >> > some >> > > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T >> > > transport requirements. I would appreciate your comments about the >> > > proposed mechanisms and behaviours. >> > > >> > > draft-rhd-mpls-tp-psc-priority-00 >> > > draft-cdh-mpls-tp-psc-non-revertive-00 >> > > draft-rhd-mpls-tp-psc-sd-00 >> > > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 >> > > >> > > The above drafts cover most of items highlighted in ITU-T liaisons >> > about >> > > PSC and they propose solutions in line with MPLS-TP transport >> > > requirements. >> > > A list of main liaisons exchanged between ITU-T and IETF with the >> > > aim >> > to >> > > align PSC behavious with ITU-T transport requirements for linear >> > > protection are given below: >> > > https://datatracker.ietf.org/liaison/1162/ (June 2012) >> > > https://datatracker.ietf.org/liaison/1205/ >> > > (October 2012) >> > > https://datatracker.ietf.org/liaison/1229/ >> > > (January 2013) >> > > https://datatracker.ietf.org/liaison/1234/ >> > > (February 2013) >> > > https://datatracker.ietf.org/liaison/1256/ >> > > (May 2013) >> > > >> > > Some details abou the proposed drafts for align PSC behaviour with >> > > transport requirements: >> > > >> > > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities >> > > between FS and SF-P (see section 4.3.2 of rfc6378). >> > > Among the others, behaviors that will be fixed with the proposed >> > update >> > > are: >> > > Use case A) At first, working path(WP) and protection path(PP) are >> > > normal. Then, Forced Switch(FS) command is issued for maintenance on >> > the >> > > WP and the traffic moves from WP to PP. When Signal Fail occurs on >> > > PP, service cannot recover and is interrupted. This could occur for >> > example >> > > as a result of accidentally un-plugging a PP fiber. >> > > Use case B) If there is an existing signal fail on a protection path >> > > (SF-P),and FS command is issued by accident the traffic on WP will >> > move >> > > to PP. This results in an interruption of service from which you >> > > will not automatically recover, because PSC should not have switched >> > > the traffic from WP to PP. >> > > Discussion about this draft led to the proposal to modify RFC 4427 >> > that >> > > was "written correctly though lacking in detail causing mis- >> > > interpretation" that led to the current PSC set of priority that the >> > > above draft is proposing to modified and to align to the required >> > > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been >> > > submitted to CCAMP for clarifying the definitions related to Manual >> > > Switch and Forced Switch and their usage relative to priorities. >> > > The way this behavior has to be incorporated into the PSC has to be >> > > discussed. The text proposes to replace the current behavior with >> > > the new one. If there is consensus to procede in that way this can >> > > bring >> > to >> > > a simple and effective way to operate the protocol. >> > > >> > > -------------------------------------------------------------------- >> > > -- >> > > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to >> > > RFC6378 to change non-revertive operations to behaves in the same >> > > way irrespectively of the trigger of protection switching (fault or >> > operator >> > > command FS, MS). Consequently an operator command, Manual Switch to >> > > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is >> > also >> > > added to enable this behavior. From an operational point of view, MS >> > to >> > > working path has also to be supported to be able to initially align >> > > at both sides in case of non-revertive switching mode. MS to working >> > > path is defined in RFC 5654, requirement 83. >> > > >> > > The proposed MS-W command is of equal priority to the existing MS-P >> > > command, and there is text to handle the simultaneous or sequential >> > > occurrence of two equal-priority commands. This behavior, already >> > > adopted in other transport network protection switching protocol, >> > > can >> > be >> > > used for other addition to the protocol in the future. >> > > >> > > -------------------------------------------------------------------- >> > > -- >> > > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state >> > > machine to handle Signal Degrade (SD). It does not define SD or >> > provide >> > > scope around where or how SD may be used similarly as it already >> > happen >> > > in the draft in handling other defects like SF (Signal Failure). >> > > In MPLS-TP survivability framework [RFC6372], a fault condition >> > > includes both Signal Fail (SF) and Signal Degrade (SD) that can be >> > used >> > > to trigger protection switching. >> > > While the standardization lack of an SD definition and detection >> > > mechanisms, the relevant behaviors in terms of protection actions >> > > may already be defined. >> > > >> > > -------------------------------------------------------------------- >> > > -- >> > > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to >> > > test if the APS communication is operating correctly. In other words >> > > both APS process logic including state machine and APS channel on >> > > protection path, without service disruption and without affecting >> > > any protection operation, unless the protection transport entity is >> > > in >> > use. >> > > This command is documented in R84 of [RFC5654] and it is part of >> > > ITU-T transport requirements. >> > > An alternative proposal is documented in the Appendix B of RFC6378 >> > that >> > > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in >> > > combination of OAM functionalities. However, it has some functional >> > > limitation and has a potential risk of losing traffic as a signal >> > > failure might occur during the exercise operation. In that case, LO >> > > or FS has to be canceled to allow the PSC protocol to provide proper >> > > switching. >> > > A further alternative proposal is documented in draft-osborne-mpls- >> > psc- >> > > alive-00 that anyway show some functional limitations because cannot >> > > validate the PSC state machine status and probably the Local Request >> > > logic. >> > > >> > > >> > > The authors encourage the IETF experts to comment on these drafts, >> > > eventually proposing other options/mechanisms that can satisfy the >> > same >> > > requirements. >> > > Best regards, >> > > Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i suoi >> > > allegati sono indirizzati esclusivamente >> > alle >> > > persone indicate. La diffusione, copia o qualsiasi altra azione >> > > derivante dalla conoscenza di queste informazioni sono rigorosamente >> > > vietate. Qualora abbiate ricevuto questo documento per errore siete >> > > cortesemente pregati di darne immediata comunicazione al mittente e >> > > di provvedere alla sua distruzione, Grazie. >> > > >> > > This e-mail and any attachments is confidential and may contain >> > > privileged information intended for the addressee(s) only. >> > > Dissemination, copying, printing or use by anybody else is >> > unauthorised. >> > > If you are not the intended recipient, please delete this message >> > > and any attachments and advise the sender by return e-mail, Thanks. >> > > >> > > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se >> > non >> > > =C3=A8 necessario. >> > >> > _______________________________________________ >> > 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 >> >> > > > -- > Thanx and BR, > yaacov > > *Still looking for new opportunity* > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --089e01175e775b11b404e23d602f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alessandro, hi
=C2=A0
I guess I w= as not very clear in my presentation - my point had very little to do with = how to detect or measure SD but rather with what is the purpose of performi= ng a protection switch.
=C2=A0
My understanding of the purpose is to guarantee a cer= tain quality of service.=C2=A0 Therefore, in the case of SF you switch to t= he protection path that is working to continue the service.=C2=A0 The quest= ion in the SD case is (and was back when it was first discussed) - how do I= know that the protection path will give a better quality of service when I= switch over? Could I be switching to a path that is providing lower qualit= y? And if so, why am I performing the switchover?
=C2=A0
Hope this clarifies,
yaacov


On Wed, Jul 24, 2= 013 at 10:11 AM, D'Alessandro Alessandro Gerardo <= alessandro.dalessandro@telecomitalia.it> wrote:
Dear Yacov,
I understand your points but we are again moving the discussion to the= problems in defining sd and the method to detect sd neglecting the costs t= hat carriers have to face with in introducing such functionality later on i= n the network.
Best regards
Alessandro


Inviato da Samsung Mobile



-------- Messaggio originale --------
Oggetto:Re: [mpls] =E5=9B=9E=E5=A4=8D=EF=BC=9A proposed drafts for aligning= MPLS-TP PSC linear protection protocol to transport requirements
Da:Yaacov Weingarten <wyaacov@gmail.com>
A:"mpls@ietf.org" <mpls@ietf.or= g>
Cc:"Eric Osborne (eosborne)" <eosborne@cisco.com>,"Ryoo, Jeong-dong&q= uot; <ryoo@etri.re.= kr>,D'Alessandro Alessandro Gerardo <alessandro.dalessandro= @telecomitalia.it>,"Huub helvoort (huub.van.helvoort@huawei.com)&quo= t; <hu= ub.van.helvoort@huawei.com>



Hi all,
=C2=A0
While I personally support the idea of including the SD support in the= Linear Protection protocol, if only for compatibility with other comparabl= e tools, I feel there is a need to add the context that caused it to be &qu= ot;downgraded" to place-holder status in PSC.
=C2=A0
In the original draft versions of the PSC definition, we included SD m= essages and described the switching operation when the system triggered an = SD situation. On the assumption that there would be a way to detect some ki= nd of SD. There were even some drafts that were proposed by different members on how to define SD and detect it = for MPLS. None of these latter drafts were, however, accepted by the WG bas= ed upon the belief that SD is not relevant at the MPLS level, it is more a = system-layer or physical layer issue and should be solved by those layers.
=C2=A0
In addition, regarding the idea of switching the traffic from the work= ing to the protection path based on an SD situation on the working path was= frowned upon. This was based on the question of how do we assure that the = protection path is a better medium for the packet transport. Because even if you could measure and identify a= n SD situation on the working path, there is no way to measure it on the pr= otection path, since it is most probably affected by the load factors invol= ved in the packet sizes.=C2=A0 Therefore, you are switching to a path that, at least in theory, could be a worse cho= ice!
=C2=A0
This was the reasoning behind the downgrade of the SD signal and the n= ote that this is for further study.=C2=A0 I have not seen anyone in this di= scussion address this issue, and therefore I think it is important that we = hear some justification for switching away from a working path to one that we have no better information on! I t= hink that the justifications given until now - i.e. "this is the way i= t has always been done in physical layer systems" -=C2=A0are not suffi= cient to add functionality that may cause poorer performance!
=C2=A0
Hope this helps focus the discussion,
yaacov weingarten


On Wed, Jul 24, 2013 at 4:46 AM, Larry <l= arryli888@yahoo.com.cn> wrote:
Hi all,

I agree with Tom and=C2= =A0Jeong-dong. There are different re= asons to cause SD, but the result is the transport performance degrade and = it is important to let operators set a threshold to trigger protection switch. During the trouble shooting, operators need = tools to do fault localization. Althought "degrade" is a continou= s variable behaviour, it is a "0/1" problem after defining the th= reshold.
= Thank you!
=C2=A0
**********************************************************************= ***
Han Li, Ph.D
China Mobile Research Institute
32 Xuanwumen West Street, Xicheng District, Beijing 100053, China
Fax: +86 10 63135159
MOBILE: 13501093385
*************************************************************************
=E5=8F=91=E4=BB=B6= =E4=BA=BA=EF=BC=9A "Huber, Thomas J." <Tom.Huber@tellabs.com>= ;
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Eric Osborne (eosborne) <eosborne@cisco.com>; "Ryoo, Jeong-dong" = <ryoo@etri.re.kr>; D'Alessandro Alessandro Gerardo <alessandro.dalessandro@telecomitalia.it>; "mpls@ietf.org" <<= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org>
=E6=8A=84=E9=80=81=EF=BC=9A = "Huub helvoort (huub.van.helvoort@huawei.com)" <huub.van.helvoort@huawei.com= >; "huubatwork= @gmail.com" <huubatwork@gmail.com>
=E5=8F=91=E9=80=81=E6=97=A5=E6=9C=9F=EF= =BC=9A 2013=E5=B9=B47=E6=9C=8823=E6=97=A5, =E6=98=9F=E6=9C=9F=E4= =BA=8C, 3:03 =E4=B8=8A=E5=8D=88
=E4=B8=BB=E9=A2=98: Re: [mpl= s] proposed drafts for aligning MPLS-TP PSC linear protection protocol to t= ransport requirements

Hi Eric,

You wrote:
>EO#
>I'm not sure what that would look like.=C2=A0 'Fail' is a p= retty binary thing.=C2=A0 'Degrade' is a continuous variable, as it= can be anything from 'a little bad' to a 'a whole lot of bad b= ut not quite fail'.

I think this may be a fundamental difference in assumptions.=C2=A0 While it= is certainly true that degradation of a signal is a continuous variable, i= n the context of protection switching in the transport network, there is a = particular value of that continuous variable that defines the threshold at which the Boolean variable "signal degr= ade (SD)" becomes true.=C2=A0 It is for this reason that Jeong-dong an= d others are suggesting that it should be possible to incorporate the behav= ior of the SD state into the PSC definition without needing to have a precise definition of the mechanism for measuring the de= gradation of a signal.=C2=A0 Whatever the mechanism is, it will be converte= d to the binary SD indication.

Best regards,
Tom


-----Original Message-----
From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne)
Sent: Monday, July 22, 2013 8:36 AM
To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; mpls@ietf.org
Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.= com
Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protect= ion protocol to transport requirements

Hi Jeong-dong,

=C2=A0 Thanks for the reply.=C2=A0 Please see inline with EO#.

> -----Original Message-----
> From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr]
> Sent: Monday, July 22, 2013 4:15 AM
> To: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo;
> mpls@ietf.org > Cc: Huub helvoort (huub.van.helvoort@huawei.com); huubatwork@gmail.= com
> Subject: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear > protection protocol to transport requirements
>
> Hi, Eric.
>
> Let me answer your 2nd question on SD.
>
> SD detection methods defined or proposed for packet transport networks=
> can be summarized as follows:
> - By OAM performance monitoring tool:
>=C2=A0 SD is raised if packet loss ratio exceeds a threshold during a > measurement period.
>=C2=A0 Threshold value and measurement period are configured by an netw= ork
> operator.
>=C2=A0 This detection method is already defined in ITU-T G.8021 (Ethern= et
> equipment spec.)


EO#=C2=A0 Where?=C2=A0 I'm not arguing that it's not in there, I= 9;m just having a hard time finding it.=C2=A0 A search for ETH_CI_SSD doesn= 't yield much.=C2=A0 If I look for 'signal degrade' I see p. 13= 1 which says that the algorithm is defined in G.8031.=C2=A0 G.8031 says = 9; How these defects are detected is the subject of the equipment Recommendations'.= =C2=A0 I'm looking for something like "Signal Degrade is defined a= s $foo packet loss or CRC failure over $bar time"....what have I misse= d?


>=C2=A0 and the equipment spec for MPLS-TP can easily follow the same > definition.
> - By server layer indication:
>=C2=A0 SD is raised if a server layer below MPLS-TP reports SD conditio= n on
> its own layer.
> - By CCM packet counting:
>=C2=A0 SD is raised if the loss ratio of CCM packets exceeds a threshol= d
> during a measurement period.
>
> Regardless of how to detect SD, any protection switching documents
> should describe the protection switching operation once such a SD is > declared.
>
...
> Regarding the multiple levels of SD:
> It is certainly possible to define multiple levels of SD.
> But, as far as the protection switching is concerned, it just needs to=
> know if SD is signaled to protection switching process or not.
> It would be a network operator's choice at what level of SD he wan= ts
> his network protection to switchover.
> In other words, what triggers protection switching is SD or no SD. It<= br> > is yes or no decision.


EO#=C2=A0 I am not aware of any document which suggests that a server layer= SD should be treated as a client layer SD.=C2=A0 In the IP world, if we ha= ve SD on a transport interface that is generally used to bring the interfac= e down (i.e. SF).=C2=A0 This is the sort of thing I'd like to see in more detail, as SD in the packet world is a new con= cept and we can't just assume that it will work the same everywhere bec= ause we define state machine points for it.

The point about CCM is a good one.=C2=A0 Let's say we come up with a cl= ever SD mechanism with two thresholds, call them major and minor.=C2=A0 For= discussion purposes they could be simple error ratios, e.g. 1:10^6 and 1:1= 0^9.=C2=A0 But they could be more powerful than that (flow type, flow length, error burst size, etc).

If we want to have SD-Major and SD-Minor inputs as separate triggers for PS= C, we may want them at different points.=C2=A0 Perhaps=C2=A0 (leaving out t= he Working path for ease of reading)

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor


This seems like a perfectly reasonable thing to want.


Even if we don't have multi-tier SD, even the single-tier SD needs to b= e defined before we can decide how to respond to it.

> The proposed draft covers SD-triggered protection no matter what kinds=
> of SD detection methods are used.
>
>
> SF can also be viewed as having multiple levels of SF as the network > operator can also make a choice on the period/interval of CCM messages= .


EO#
I'm not sure what that would look like.=C2=A0 'Fail' is a prett= y binary thing.=C2=A0 'Degrade' is a continuous variable, as it can= be anything from 'a little bad' to a 'a whole lot of bad but n= ot quite fail'.

> If CCM is disabled, AIS from a server layer can be used as a trigger > for protection switching. So and so forth.

EO#=C2=A0 AIS from the server layer only gets you SD from the first hop of = the underlying server path.




eric

> However, protection switching document does not define how to detect > SF in anywhere.
> Similary, protection switching document does not define how manual
> switch and forced switch commands are initiated in a management system=
> and signaled to protection switching process.
>
> Again, in my opinion, the draft on SD protection can accommodate any > SD detection methods.
>
> Best regards,
>
> Jeong-dong
>
>
>
>
>
>
> ________________________________
>
> From : "Eric Osborne (eosborne)" <eosborne@cisco.com> Sent :
> 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerard= o
> <alessandro.dalessandro@telecomitalia.it>, mpls@ietf.org
> <mpls@ietf.org> Cc : Huub helvoort (huub.van.helvoort@huawei.com)
> <= huub.van.helvoort@huawei.com>, huubatwork@gmail.= com
> <huubatwo= rk@gmail.com> Subject : Re: [mpls] proposed drafts for
> aligning MPLS-TP PSC linear protection protocol to transport
> requirements
>
>
> Hi Alessandro-
>
> Thanks for this; the threads I started some time back seem to have
> died down, it's good to get them going again.
> I have two things I never quite understood, can you clarify them for m= e?
>
> i) can you explain EXER at a higher level? I'm not looking for a > description of the state machine changes, and I'm not looking for = the
> one line "It allows the FSM to be tested". We have all of th= at in the
> draft and in the equivalent ITU specs.
>
> What I'd like to understand about EXER is where it came from. The = ITU
> specs that define it are pretty hard to follow, they seem to assume > the reader already knows what EXER is and what problem it solves. It > feels very much like a mechanism used to catch a very specific
> implementation bug, back when transport gear was far less debuggable > than what we have today.
>
> No other state machines that I'm familiar with (RSVP, LDP, BGP, OS= PF,
> ISIS) have explicit signaling in them just to ask the neighbor whether=
> it *would* be broken if if were, in the future, to be given a
> particular input. Part of my reluctance to get behind EXER has been > that I don't feel comfortable with the idea of keeping a 30-year-o= ld
> workaround in a protocol. Is there more to it than that? Have I
> misread and misunderstood EXER? Does modern transport gear ever
> actually detect a problem via EXER/RR that wasn't obvious to the > operator using other means?
>
>
> ii) Why the push to standardize the SD state changes before we've<= br> > defined SD? I certainly agree that handling signal degrade is a good > idea, but coming up with a definition for it has been challenging.
> What happens if we change the FSM to handle it, then come up with
> something more sophisticated (say, multiple levels of SD) that doesn&#= 39;t
> quite fit with the FSM changes?
>
>
>
> thanks!
>
>
>
>
>
> eric
>
>
> > -----Original Message-----
> > From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
> Of
> > D'Alessandro Alessandro Gerardo
> > Sent: Wednesday, July 17, 2013 3:23 PM
> > To: mpls@ietf.= org
> > Cc: Huub helvoort (huub.van.helvoort@huawei.com);
> > huubatw= ork@gmail.com
> > Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear > > protection protocol to transport requirements
> >
> > Dear all,
> > we would like socializing the herebelow drafts that were submitte= d
> some
> > months ago with the aim to align PSC protocol (RFC 6378) to ITU-T=
> > transport requirements. I would appreciate your comments about th= e
> > proposed mechanisms and behaviours.
> >
> > draft-rhd-mpls-tp-psc-priority-00
> > draft-cdh-mpls-tp-psc-non-revertive-00
> > draft-rhd-mpls-tp-psc-sd-00
> > draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00 > >
> > The above drafts cover most of items highlighted in ITU-T liaison= s
> about
> > PSC and they propose solutions in line with MPLS-TP transport
> > requirements.
> > A list of main liaisons exchanged between ITU-T and IETF with the=
> > aim
> to
> > align PSC behavious with ITU-T transport requirements for linear<= br> > > protection are given below:
> > https://datatracker.ietf.org/liaison/1162/ (June 2012)
> > https://datatracker.ietf.org/liaison/1205/
> > (October 2012)
> > https://datatracker.ietf.org/liaison/1229/
> > (January 2013)
> > https://datatracker.ietf.org/liaison/1234/
> > (February 2013)
> > https://datatracker.ietf.org/liaison/1256/
> > (May 2013)
> >
> > Some details abou the proposed drafts for align PSC behaviour wit= h
> > transport requirements:
> >
> > draft-rhd-mpls-tp-psc-priority-00 proposes swapping the prioritie= s
> > between FS and SF-P (see section 4.3.2 of rfc6378).
> > Among the others, behaviors that will be fixed with the proposed<= br> > update
> > are:
> > Use case A) At first, working path(WP) and protection path(PP) ar= e
> > normal. Then, Forced Switch(FS) command is issued for maintenance= on
> the
> > WP and the traffic moves from WP to PP. When Signal Fail occurs o= n
> > PP, service cannot recover and is interrupted. This could occur f= or
> example
> > as a result of accidentally un-plugging a PP fiber.
> > Use case B) If there is an existing signal fail on a protection p= ath
> > (SF-P),and FS command is issued by accident the traffic on WP wil= l
> move
> > to PP. This results in an interruption of service from which you<= br> > > will not automatically recover, because PSC should not have switc= hed
> > the traffic from WP to PP.
> > Discussion about this draft led to the proposal to modify RFC 442= 7
> that
> > was "written correctly though lacking in detail causing mis-=
> > interpretation" that led to the current PSC set of priority = that the
> > above draft is proposing to modified and to align to the required=
> > transport behavior. draft-helvoort-ccamp-fs-priority-00 has been<= br> > > submitted to CCAMP for clarifying the definitions related to Manu= al
> > Switch and Forced Switch and their usage relative to priorities.<= br> > > The way this behavior has to be incorporated into the PSC has to = be
> > discussed. The text proposes to replace the current behavior with=
> > the new one. If there is consensus to procede in that way this ca= n
> > bring
> to
> > a simple and effective way to operate the protocol.
> >
> > -----------------------------------------------------------------= ---
> > --
> > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to > > RFC6378 to change non-revertive operations to behaves in the same=
> > way irrespectively of the trigger of protection switching (fault = or
> operator
> > command FS, MS). Consequently an operator command, Manual Switch = to
> > Working (MS-W) a.k.a "Manual switch-over for recovery LSP/sp= an" is
> also
> > added to enable this behavior. From an operational point of view,= MS
> to
> > working path has also to be supported to be able to initially ali= gn
> > at both sides in case of non-revertive switching mode. MS to work= ing
> > path is defined in RFC 5654, requirement 83.
> >
> > The proposed MS-W command is of equal priority to the existing MS= -P
> > command, and there is text to handle the simultaneous or sequenti= al
> > occurrence of two equal-priority commands. This behavior, already=
> > adopted in other transport network protection switching protocol,=
> > can
> be
> > used for other addition to the protocol in the future.
> >
> > -----------------------------------------------------------------= ---
> > --
> > draft-rhd-mpls-tp-psc-sd-00 provides extensions to the PSC state<= br> > > machine to handle Signal Degrade (SD). It does not define SD or > provide
> > scope around where or how SD may be used similarly as it already<= br> > happen
> > in the draft in handling other defects like SF (Signal Failure).<= br> > > In MPLS-TP survivability framework [RFC6372], a fault condition > > includes both Signal Fail (SF) and Signal Degrade (SD) that can b= e
> used
> > to trigger protection switching.
> > While the standardization lack of an SD definition and detection<= br> > > mechanisms, the relevant behaviors in terms of protection actions=
> > may already be defined.
> >
> > -----------------------------------------------------------------= ---
> > --
> > draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands= to
> > test if the APS communication is operating correctly. In other wo= rds
> > both APS process logic including state machine and APS channel on=
> > protection path, without service disruption and without affecting=
> > any protection operation, unless the protection transport entity = is
> > in
> use.
> > This command is documented in R84 of [RFC5654] and it is part of<= br> > > ITU-T transport requirements.
> > An alternative proposal is documented in the Appendix B of RFC637= 8
> that
> > utilizes the Lockout of Protection (LO) or Forced Switch (FS) in<= br> > > combination of OAM functionalities. However, it has some function= al
> > limitation and has a potential risk of losing traffic as a signal=
> > failure might occur during the exercise operation. In that case, = LO
> > or FS has to be canceled to allow the PSC protocol to provide pro= per
> > switching.
> > A further alternative proposal is documented in draft-osborne-mpl= s-
> psc-
> > alive-00 that anyway show some functional limitations because can= not
> > validate the PSC state machine status and probably the Local Requ= est
> > logic.
> >
> >
> > The authors encourage the IETF experts to comment on these drafts= ,
> > eventually proposing other options/mechanisms that can satisfy th= e
> same
> > requirements.
> > Best regards,
> > Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i suoi > > allegati sono indirizzati esclusivamente
> alle
> > persone indicate. La diffusione, copia o qualsiasi altra azione > > derivante dalla conoscenza di queste informazioni sono rigorosame= nte
> > vietate. Qualora abbiate ricevuto questo documento per errore sie= te
> > cortesemente pregati di darne immediata comunicazione al mittente= e
> > di provvedere alla sua distruzione, Grazie.
> >
> > This e-mail and any attachments is confidential and may contain > > privileged information intended for the addressee(s) only.
> > Dissemination, copying, printing or use by anybody else is
> unauthorised.
> > If you are not the intended recipient, please delete this message=
> > and any attachments and advise the sender by return e-mail, Thank= s.
> >
> > rispetta l'ambienteRispetta l'ambiente. Non stampare ques= ta mail se
> non
> > =C3=A8 necessario.
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls

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



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




--
Thanx and BR,
yaacov

Still looking for new opportunity
Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=C2=A0is= =C2=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

=3D"rispettaRispetta l'ambi= ente. Non stampare questa mail se non =C3=A8 necessario.




--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--089e01175e775b11b404e23d602f-- From ryoo@etri.re.kr Wed Jul 24 01:07:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E3811E839D for ; Wed, 24 Jul 2013 01:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJxFdi9jo2+8 for ; Wed, 24 Jul 2013 01:07:08 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD711E839B for ; Wed, 24 Jul 2013 01:07:07 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 24 Jul 2013 17:07:05 +0900 Received: from SMTP2.etri.info ([169.254.2.217]) by SMTP3.etri.info ([169.254.4.37]) with mapi id 14.01.0355.002; Wed, 24 Jul 2013 17:07:03 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: =?utf-8?B?W21wbHNdIOWbnuWkje+8miBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5n?= =?utf-8?B?IE1QTFMtVFAgUFNDIGxpbmVhciBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRy?= =?utf-8?Q?ansport_requirements?= Thread-Index: AQHOiC2JuSrcyY16oE+Ll7jFyKr/LZlzdZbc Date: Wed, 24 Jul 2013 08:07:03 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A276807F5@SMTP2.etri.info> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276807F5SMTP2etriinfo_" MIME-Version: 1.0 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" Subject: Re: [mpls] =?utf-8?b?5Zue5aSN77yaIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p?= =?utf-8?q?ng_MPLS-TP_PSC_linear_protection_protocol_to_transport_requirem?= =?utf-8?q?ents?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Jul 2013 08:07:14 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276807F5SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LCBob3cgYXJlIHlvdT8NCg0KSSB1bmRlcnN0YW5kIHlvdXIgdGVjaG5pY2FsIGNvbmNl cm5zIG9uIHRoZSBTRCBzaXR1YXRpb24gb24gdGhlIHdvcmtpbmcgcGF0aCB3aGlsZSB0aGUgcHJv dGVjdGlvbiBwYXRoIGlzIGluIGZhY3Qgd29yc2UuDQpJIGFtIG5vdCB0cnlpbmcgdG8gcmVzb2x2 ZSB0aGUgaXNzdWUgaGVyZSwgYnV0IHdoYXQgd2UgY2FuIGhhdmUgaXMgdGhhdCBhbnkgZW50aXR5 IG9yIGZ1bmN0aW9uIHRoYXQgZGV0ZWN0cyBTRCBhbmQgc2lnbmFscyB0aGUgU0QgZXZlbnQgdG8g UFNDIHByb2Nlc3MgY2FuIHRyYW5zZm9ybSB0aGUgY29udGludW91cyBTRCB2YWx1ZXMgb24gYm90 aCB3b3JraW5nIGFuZCB0cmFuc3BvcnQgcGF0aHMgaW50byBhIGJpbmFyeSBkZWNpc2lvbiwgYW5k IHNpZ25hbHMgdGhlIHJlc3VsdCB0byBQU0MgcHJvY2Vzcy4gRm9yIGV4YW1wbGUsIGlmIFNEIG9u IHdvcmtpbmcgaXMgd29yc2UgdGhhbiBTRCBvbiBwcm90ZWN0aW9uLCBpdCBjYW4gb25seSBzZW5k IFNELVcgdG8gUFNDIHByb2Nlc3MuDQpBbHNvLCB3ZSBuZWVkIHRvIGR1cGxpY2F0ZSB0aGUgdHJh ZmZpYyB0byBib3RoIHBhdGhzIGluIHRoaXMgY2FzZSwgc28gdGhhdCBib3RoIHBhdGhzIGNhbiBi ZSBtb25pdG9yZWQgd2l0aCB0aGUgc2FtZSB0cmFmZmljIGNvbmRpdGlvbi4NCkhvd2V2ZXIsIHRo aXMgaGFzdHkgYW5kIGNsdW1zeSBpZGVhIG9mIG1pbmUgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg cHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJZYWFjb3YgV2Vp bmdhcnRlbiIgPHd5YWFjb3ZAZ21haWwuY29tPg0KU2VudCA6IDIwMTMtMDctMjQgMTQ6MjA6NDAg KCArMDk6MDAgKQ0KVG8gOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KQ2MgOiBFcmlj IE9zYm9ybmUgKGVvc2Jvcm5lKSA8ZW9zYm9ybmVAY2lzY28uY29tPiwgUnlvbywgSmVvbmctZG9u ZyA8cnlvb0BldHJpLnJlLmtyPiwgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyA8YWxl c3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0PiwgSHV1YiBoZWx2b29ydCAoaHV1 Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSkgPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+ DQpTdWJqZWN0IDogUmU6IFttcGxzXSDlm57lpI3vvJogcHJvcG9zZWQgZHJhZnRzIGZvciBhbGln bmluZyBNUExTLVRQIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzDQoNCkhpIGFsbCwNCg0KV2hpbGUgSSBwZXJzb25hbGx5IHN1cHBvcnQgdGhl IGlkZWEgb2YgaW5jbHVkaW5nIHRoZSBTRCBzdXBwb3J0IGluIHRoZSBMaW5lYXIgUHJvdGVjdGlv biBwcm90b2NvbCwgaWYgb25seSBmb3IgY29tcGF0aWJpbGl0eSB3aXRoIG90aGVyIGNvbXBhcmFi bGUgdG9vbHMsIEkgZmVlbCB0aGVyZSBpcyBhIG5lZWQgdG8gYWRkIHRoZSBjb250ZXh0IHRoYXQg Y2F1c2VkIGl0IHRvIGJlICJkb3duZ3JhZGVkIiB0byBwbGFjZS1ob2xkZXIgc3RhdHVzIGluIFBT Qy4NCg0KSW4gdGhlIG9yaWdpbmFsIGRyYWZ0IHZlcnNpb25zIG9mIHRoZSBQU0MgZGVmaW5pdGlv biwgd2UgaW5jbHVkZWQgU0QgbWVzc2FnZXMgYW5kIGRlc2NyaWJlZCB0aGUgc3dpdGNoaW5nIG9w ZXJhdGlvbiB3aGVuIHRoZSBzeXN0ZW0gdHJpZ2dlcmVkIGFuIFNEIHNpdHVhdGlvbi4gT24gdGhl IGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3b3VsZCBiZSBhIHdheSB0byBkZXRlY3Qgc29tZSBraW5k IG9mIFNELiBUaGVyZSB3ZXJlIGV2ZW4gc29tZSBkcmFmdHMgdGhhdCB3ZXJlIHByb3Bvc2VkIGJ5 IGRpZmZlcmVudCBtZW1iZXJzIG9uIGhvdyB0byBkZWZpbmUgU0QgYW5kIGRldGVjdCBpdCBmb3Ig TVBMUy4gTm9uZSBvZiB0aGVzZSBsYXR0ZXIgZHJhZnRzIHdlcmUsIGhvd2V2ZXIsIGFjY2VwdGVk IGJ5IHRoZSBXRyBiYXNlZCB1cG9uIHRoZSBiZWxpZWYgdGhhdCBTRCBpcyBub3QgcmVsZXZhbnQg YXQgdGhlIE1QTFMgbGV2ZWwsIGl0IGlzIG1vcmUgYSBzeXN0ZW0tbGF5ZXIgb3IgcGh5c2ljYWwg bGF5ZXIgaXNzdWUgYW5kIHNob3VsZCBiZSBzb2x2ZWQgYnkgdGhvc2UgbGF5ZXJzLg0KDQpJbiBh ZGRpdGlvbiwgcmVnYXJkaW5nIHRoZSBpZGVhIG9mIHN3aXRjaGluZyB0aGUgdHJhZmZpYyBmcm9t IHRoZSB3b3JraW5nIHRvIHRoZSBwcm90ZWN0aW9uIHBhdGggYmFzZWQgb24gYW4gU0Qgc2l0dWF0 aW9uIG9uIHRoZSB3b3JraW5nIHBhdGggd2FzIGZyb3duZWQgdXBvbi4gVGhpcyB3YXMgYmFzZWQg b24gdGhlIHF1ZXN0aW9uIG9mIGhvdyBkbyB3ZSBhc3N1cmUgdGhhdCB0aGUgcHJvdGVjdGlvbiBw YXRoIGlzIGEgYmV0dGVyIG1lZGl1bSBmb3IgdGhlIHBhY2tldCB0cmFuc3BvcnQuIEJlY2F1c2Ug ZXZlbiBpZiB5b3UgY291bGQgbWVhc3VyZSBhbmQgaWRlbnRpZnkgYW4gU0Qgc2l0dWF0aW9uIG9u IHRoZSB3b3JraW5nIHBhdGgsIHRoZXJlIGlzIG5vIHdheSB0byBtZWFzdXJlIGl0IG9uIHRoZSBw cm90ZWN0aW9uIHBhdGgsIHNpbmNlIGl0IGlzIG1vc3QgcHJvYmFibHkgYWZmZWN0ZWQgYnkgdGhl IGxvYWQgZmFjdG9ycyBpbnZvbHZlZCBpbiB0aGUgcGFja2V0IHNpemVzLiAgVGhlcmVmb3JlLCB5 b3UgYXJlIHN3aXRjaGluZyB0byBhIHBhdGggdGhhdCwgYXQgbGVhc3QgaW4gdGhlb3J5LCBjb3Vs ZCBiZSBhIHdvcnNlIGNob2ljZSENCg0KVGhpcyB3YXMgdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhl IGRvd25ncmFkZSBvZiB0aGUgU0Qgc2lnbmFsIGFuZCB0aGUgbm90ZSB0aGF0IHRoaXMgaXMgZm9y IGZ1cnRoZXIgc3R1ZHkuICBJIGhhdmUgbm90IHNlZW4gYW55b25lIGluIHRoaXMgZGlzY3Vzc2lv biBhZGRyZXNzIHRoaXMgaXNzdWUsIGFuZCB0aGVyZWZvcmUgSSB0aGluayBpdCBpcyBpbXBvcnRh bnQgdGhhdCB3ZSBoZWFyIHNvbWUganVzdGlmaWNhdGlvbiBmb3Igc3dpdGNoaW5nIGF3YXkgZnJv bSBhIHdvcmtpbmcgcGF0aCB0byBvbmUgdGhhdCB3ZSBoYXZlIG5vIGJldHRlciBpbmZvcm1hdGlv biBvbiEgSSB0aGluayB0aGF0IHRoZSBqdXN0aWZpY2F0aW9ucyBnaXZlbiB1bnRpbCBub3cgLSBp LmUuICJ0aGlzIGlzIHRoZSB3YXkgaXQgaGFzIGFsd2F5cyBiZWVuIGRvbmUgaW4gcGh5c2ljYWwg bGF5ZXIgc3lzdGVtcyIgLSBhcmUgbm90IHN1ZmZpY2llbnQgdG8gYWRkIGZ1bmN0aW9uYWxpdHkg dGhhdCBtYXkgY2F1c2UgcG9vcmVyIHBlcmZvcm1hbmNlIQ0KDQpIb3BlIHRoaXMgaGVscHMgZm9j dXMgdGhlIGRpc2N1c3Npb24sDQp5YWFjb3Ygd2VpbmdhcnRlbg0KDQoNCk9uIFdlZCwgSnVsIDI0 LCAyMDEzIGF0IDQ6NDYgQU0sIExhcnJ5IDxsYXJyeWxpODg4QHlhaG9vLmNvbS5jbjxtYWlsdG86 bGFycnlsaTg4OEB5YWhvby5jb20uY24+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBhZ3JlZSB3aXRo IFRvbSBhbmQgSmVvbmctZG9uZy4gVGhlcmUgYXJlIGRpZmZlcmVudCByZWFzb25zIHRvIGNhdXNl IFNELCBidXQgdGhlIHJlc3VsdCBpcyB0aGUgdHJhbnNwb3J0IHBlcmZvcm1hbmNlIGRlZ3JhZGUg YW5kIGl0IGlzIGltcG9ydGFudCB0byBsZXQgb3BlcmF0b3JzIHNldCBhIHRocmVzaG9sZCB0byB0 cmlnZ2VyIHByb3RlY3Rpb24gc3dpdGNoLiBEdXJpbmcgdGhlIHRyb3VibGUgc2hvb3RpbmcsIG9w ZXJhdG9ycyBuZWVkIHRvb2xzIHRvIGRvIGZhdWx0IGxvY2FsaXphdGlvbi4gQWx0aG91Z2h0ICJk ZWdyYWRlIiBpcyBhIGNvbnRpbm91cyB2YXJpYWJsZSBiZWhhdmlvdXIsIGl0IGlzIGEgIjAvMSIg cHJvYmxlbSBhZnRlciBkZWZpbmluZyB0aGUgdGhyZXNob2xkLg0KVGhhbmsgeW91IQ0KDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQpIYW4gTGksIFBoLkQNCkNoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1 dGUNCjMyIFh1YW53dW1lbiBXZXN0IFN0cmVldCwgWGljaGVuZyBEaXN0cmljdCwgQmVpamluZyAx MDAwNTMsIENoaW5hDQpGYXg6ICs4NiAxMCA2MzEzNTE1OTx0ZWw6JTJCODYlMjAxMCUyMDYzMTM1 MTU5Pg0KTU9CSUxFOiAxMzUwMTA5MzM4NQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCuWPkeS7tuS6uu+8miAiSHViZXIsIFRob21hcyBKLiIgPFRv bS5IdWJlckB0ZWxsYWJzLmNvbTxtYWlsdG86VG9tLkh1YmVyQHRlbGxhYnMuY29tPj4NCuaUtuS7 tuS6uu+8miBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSA8ZW9zYm9ybmVAY2lzY28uY29tPG1haWx0 bzplb3Nib3JuZUBjaXNjby5jb20+PjsgIlJ5b28sIEplb25nLWRvbmciIDxyeW9vQGV0cmkucmUu a3I8bWFpbHRvOnJ5b29AZXRyaS5yZS5rcj4+OyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJh cmRvIDxhbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ8bWFpbHRvOmFsZXNz YW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4+OyAibXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4N CuaKhOmAge+8miAiSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTxt YWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT4pIiA8aHV1Yi52YW4uaGVsdm9vcnRA aHVhd2VpLmNvbTxtYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT4+OyAiaHV1YmF0 d29ya0BnbWFpbC5jb208bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPiIgPGh1dWJhdHdvcmtA Z21haWwuY29tPG1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4+DQrlj5HpgIHml6XmnJ/vvJog MjAxM+W5tDfmnIgyM+aXpSwg5pif5pyf5LqMLCAzOjAzIOS4iuWNiA0K5Li76aKYOiBSZTogW21w bHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3Rl Y3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KDQpIaSBFcmljLA0KDQpZ b3Ugd3JvdGU6DQo+RU8jDQo+SSdtIG5vdCBzdXJlIHdoYXQgdGhhdCB3b3VsZCBsb29rIGxpa2Uu ICAnRmFpbCcgaXMgYSBwcmV0dHkgYmluYXJ5IHRoaW5nLiAgJ0RlZ3JhZGUnIGlzIGEgY29udGlu dW91cyB2YXJpYWJsZSwgYXMgaXQgY2FuIGJlIGFueXRoaW5nIGZyb20gJ2EgbGl0dGxlIGJhZCcg dG8gYSAnYSB3aG9sZSBsb3Qgb2YgYmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuDQoNCkkgdGhpbmsg dGhpcyBtYXkgYmUgYSBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlIGluIGFzc3VtcHRpb25zLiAgV2hp bGUgaXQgaXMgY2VydGFpbmx5IHRydWUgdGhhdCBkZWdyYWRhdGlvbiBvZiBhIHNpZ25hbCBpcyBh IGNvbnRpbnVvdXMgdmFyaWFibGUsIGluIHRoZSBjb250ZXh0IG9mIHByb3RlY3Rpb24gc3dpdGNo aW5nIGluIHRoZSB0cmFuc3BvcnQgbmV0d29yaywgdGhlcmUgaXMgYSBwYXJ0aWN1bGFyIHZhbHVl IG9mIHRoYXQgY29udGludW91cyB2YXJpYWJsZSB0aGF0IGRlZmluZXMgdGhlIHRocmVzaG9sZCBh dCB3aGljaCB0aGUgQm9vbGVhbiB2YXJpYWJsZSAic2lnbmFsIGRlZ3JhZGUgKFNEKSIgYmVjb21l cyB0cnVlLiAgSXQgaXMgZm9yIHRoaXMgcmVhc29uIHRoYXQgSmVvbmctZG9uZyBhbmQgb3RoZXJz IGFyZSBzdWdnZXN0aW5nIHRoYXQgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGluY29ycG9yYXRl IHRoZSBiZWhhdmlvciBvZiB0aGUgU0Qgc3RhdGUgaW50byB0aGUgUFNDIGRlZmluaXRpb24gd2l0 aG91dCBuZWVkaW5nIHRvIGhhdmUgYSBwcmVjaXNlIGRlZmluaXRpb24gb2YgdGhlIG1lY2hhbmlz bSBmb3IgbWVhc3VyaW5nIHRoZSBkZWdyYWRhdGlvbiBvZiBhIHNpZ25hbC4gIFdoYXRldmVyIHRo ZSBtZWNoYW5pc20gaXMsIGl0IHdpbGwgYmUgY29udmVydGVkIHRvIHRoZSBiaW5hcnkgU0QgaW5k aWNhdGlvbi4NCg0KQmVzdCByZWdhcmRzLA0KVG9tDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpDQpTZW50OiBN b25kYXksIEp1bHkgMjIsIDIwMTMgODozNiBBTQ0KVG86IFJ5b28sIEplb25nLWRvbmc7IEQnQWxl c3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+DQpDYzogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTxt YWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT4pOyBodXViYXR3b3JrQGdtYWlsLmNv bTxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW21wbHNdIHByb3Bv c2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJv dG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KDQpIaSBKZW9uZy1kb25nLA0KDQogIFRo YW5rcyBmb3IgdGhlIHJlcGx5LiAgUGxlYXNlIHNlZSBpbmxpbmUgd2l0aCBFTyMuDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnlvbywgSmVvbmctZG9uZyBbbWFpbHRv OnJ5b29AZXRyaS5yZS5rcjxtYWlsdG86cnlvb0BldHJpLnJlLmtyPl0NCj4gU2VudDogTW9uZGF5 LCBKdWx5IDIyLCAyMDEzIDQ6MTUgQU0NCj4gVG86IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBE J0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOw0KPiBtcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPg0KPiBDYzogSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVh d2VpLmNvbTxtYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT4pOyBodXViYXR3b3Jr QGdtYWlsLmNvbTxtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20+DQo+IFN1YmplY3Q6IFJFOiBb bXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXINCj4g cHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzDQo+DQo+IEhpLCBF cmljLg0KPg0KPiBMZXQgbWUgYW5zd2VyIHlvdXIgMm5kIHF1ZXN0aW9uIG9uIFNELg0KPg0KPiBT RCBkZXRlY3Rpb24gbWV0aG9kcyBkZWZpbmVkIG9yIHByb3Bvc2VkIGZvciBwYWNrZXQgdHJhbnNw b3J0IG5ldHdvcmtzDQo+IGNhbiBiZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6DQo+IC0gQnkgT0FN IHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdG9vbDoNCj4gIFNEIGlzIHJhaXNlZCBpZiBwYWNrZXQg bG9zcyByYXRpbyBleGNlZWRzIGEgdGhyZXNob2xkIGR1cmluZyBhDQo+IG1lYXN1cmVtZW50IHBl cmlvZC4NCj4gIFRocmVzaG9sZCB2YWx1ZSBhbmQgbWVhc3VyZW1lbnQgcGVyaW9kIGFyZSBjb25m aWd1cmVkIGJ5IGFuIG5ldHdvcmsNCj4gb3BlcmF0b3IuDQo+ICBUaGlzIGRldGVjdGlvbiBtZXRo b2QgaXMgYWxyZWFkeSBkZWZpbmVkIGluIElUVS1UIEcuODAyMSAoRXRoZXJuZXQNCj4gZXF1aXBt ZW50IHNwZWMuKQ0KDQoNCkVPIyAgV2hlcmU/ICBJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5v dCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2aW5nIGEgaGFyZCB0aW1lIGZpbmRpbmcgaXQuICBBIHNl YXJjaCBmb3IgRVRIX0NJX1NTRCBkb2Vzbid0IHlpZWxkIG11Y2guICBJZiBJIGxvb2sgZm9yICdz aWduYWwgZGVncmFkZScgSSBzZWUgcC4gMTMxIHdoaWNoIHNheXMgdGhhdCB0aGUgYWxnb3JpdGht IGlzIGRlZmluZWQgaW4gRy44MDMxLiAgRy44MDMxIHNheXMgJyBIb3cgdGhlc2UgZGVmZWN0cyBh cmUgZGV0ZWN0ZWQgaXMgdGhlIHN1YmplY3Qgb2YgdGhlIGVxdWlwbWVudCBSZWNvbW1lbmRhdGlv bnMnLiAgSSdtIGxvb2tpbmcgZm9yIHNvbWV0aGluZyBsaWtlICJTaWduYWwgRGVncmFkZSBpcyBk ZWZpbmVkIGFzICRmb28gcGFja2V0IGxvc3Mgb3IgQ1JDIGZhaWx1cmUgb3ZlciAkYmFyIHRpbWUi Li4uLndoYXQgaGF2ZSBJIG1pc3NlZD8NCg0KDQo+ICBhbmQgdGhlIGVxdWlwbWVudCBzcGVjIGZv ciBNUExTLVRQIGNhbiBlYXNpbHkgZm9sbG93IHRoZSBzYW1lDQo+IGRlZmluaXRpb24uDQo+IC0g Qnkgc2VydmVyIGxheWVyIGluZGljYXRpb246DQo+ICBTRCBpcyByYWlzZWQgaWYgYSBzZXJ2ZXIg bGF5ZXIgYmVsb3cgTVBMUy1UUCByZXBvcnRzIFNEIGNvbmRpdGlvbiBvbg0KPiBpdHMgb3duIGxh eWVyLg0KPiAtIEJ5IENDTSBwYWNrZXQgY291bnRpbmc6DQo+ICBTRCBpcyByYWlzZWQgaWYgdGhl IGxvc3MgcmF0aW8gb2YgQ0NNIHBhY2tldHMgZXhjZWVkcyBhIHRocmVzaG9sZA0KPiBkdXJpbmcg YSBtZWFzdXJlbWVudCBwZXJpb2QuDQo+DQo+IFJlZ2FyZGxlc3Mgb2YgaG93IHRvIGRldGVjdCBT RCwgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50cw0KPiBzaG91bGQgZGVzY3JpYmUg dGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9wZXJhdGlvbiBvbmNlIHN1Y2ggYSBTRCBpcw0KPiBk ZWNsYXJlZC4NCj4NCi4uLg0KPiBSZWdhcmRpbmcgdGhlIG11bHRpcGxlIGxldmVscyBvZiBTRDoN Cj4gSXQgaXMgY2VydGFpbmx5IHBvc3NpYmxlIHRvIGRlZmluZSBtdWx0aXBsZSBsZXZlbHMgb2Yg U0QuDQo+IEJ1dCwgYXMgZmFyIGFzIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjb25jZXJu ZWQsIGl0IGp1c3QgbmVlZHMgdG8NCj4ga25vdyBpZiBTRCBpcyBzaWduYWxlZCB0byBwcm90ZWN0 aW9uIHN3aXRjaGluZyBwcm9jZXNzIG9yIG5vdC4NCj4gSXQgd291bGQgYmUgYSBuZXR3b3JrIG9w ZXJhdG9yJ3MgY2hvaWNlIGF0IHdoYXQgbGV2ZWwgb2YgU0QgaGUgd2FudHMNCj4gaGlzIG5ldHdv cmsgcHJvdGVjdGlvbiB0byBzd2l0Y2hvdmVyLg0KPiBJbiBvdGhlciB3b3Jkcywgd2hhdCB0cmln Z2VycyBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBTRCBvciBubyBTRC4gSXQNCj4gaXMgeWVzIG9y IG5vIGRlY2lzaW9uLg0KDQoNCkVPIyAgSSBhbSBub3QgYXdhcmUgb2YgYW55IGRvY3VtZW50IHdo aWNoIHN1Z2dlc3RzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXIgU0Qgc2hvdWxkIGJlIHRyZWF0ZWQgYXMg YSBjbGllbnQgbGF5ZXIgU0QuICBJbiB0aGUgSVAgd29ybGQsIGlmIHdlIGhhdmUgU0Qgb24gYSB0 cmFuc3BvcnQgaW50ZXJmYWNlIHRoYXQgaXMgZ2VuZXJhbGx5IHVzZWQgdG8gYnJpbmcgdGhlIGlu dGVyZmFjZSBkb3duIChpLmUuIFNGKS4gIFRoaXMgaXMgdGhlIHNvcnQgb2YgdGhpbmcgSSdkIGxp a2UgdG8gc2VlIGluIG1vcmUgZGV0YWlsLCBhcyBTRCBpbiB0aGUgcGFja2V0IHdvcmxkIGlzIGEg bmV3IGNvbmNlcHQgYW5kIHdlIGNhbid0IGp1c3QgYXNzdW1lIHRoYXQgaXQgd2lsbCB3b3JrIHRo ZSBzYW1lIGV2ZXJ5d2hlcmUgYmVjYXVzZSB3ZSBkZWZpbmUgc3RhdGUgbWFjaGluZSBwb2ludHMg Zm9yIGl0Lg0KDQpUaGUgcG9pbnQgYWJvdXQgQ0NNIGlzIGEgZ29vZCBvbmUuICBMZXQncyBzYXkg d2UgY29tZSB1cCB3aXRoIGEgY2xldmVyIFNEIG1lY2hhbmlzbSB3aXRoIHR3byB0aHJlc2hvbGRz LCBjYWxsIHRoZW0gbWFqb3IgYW5kIG1pbm9yLiAgRm9yIGRpc2N1c3Npb24gcHVycG9zZXMgdGhl eSBjb3VsZCBiZSBzaW1wbGUgZXJyb3IgcmF0aW9zLCBlLmcuIDE6MTBeNiBhbmQgMToxMF45LiAg QnV0IHRoZXkgY291bGQgYmUgbW9yZSBwb3dlcmZ1bCB0aGFuIHRoYXQgKGZsb3cgdHlwZSwgZmxv dyBsZW5ndGgsIGVycm9yIGJ1cnN0IHNpemUsIGV0YykuDQoNCklmIHdlIHdhbnQgdG8gaGF2ZSBT RC1NYWpvciBhbmQgU0QtTWlub3IgaW5wdXRzIGFzIHNlcGFyYXRlIHRyaWdnZXJzIGZvciBQU0Ms IHdlIG1heSB3YW50IHRoZW0gYXQgZGlmZmVyZW50IHBvaW50cy4gIFBlcmhhcHMgIChsZWF2aW5n IG91dCB0aGUgV29ya2luZyBwYXRoIGZvciBlYXNlIG9mIHJlYWRpbmcpDQoNCkxPDQpGUw0KU0Yt UA0KU0QtUC1NYWpvcg0KTVMNClNELVAtTWlub3INCg0KDQpUaGlzIHNlZW1zIGxpa2UgYSBwZXJm ZWN0bHkgcmVhc29uYWJsZSB0aGluZyB0byB3YW50Lg0KDQoNCkV2ZW4gaWYgd2UgZG9uJ3QgaGF2 ZSBtdWx0aS10aWVyIFNELCBldmVuIHRoZSBzaW5nbGUtdGllciBTRCBuZWVkcyB0byBiZSBkZWZp bmVkIGJlZm9yZSB3ZSBjYW4gZGVjaWRlIGhvdyB0byByZXNwb25kIHRvIGl0Lg0KDQo+IFRoZSBw cm9wb3NlZCBkcmFmdCBjb3ZlcnMgU0QtdHJpZ2dlcmVkIHByb3RlY3Rpb24gbm8gbWF0dGVyIHdo YXQga2luZHMNCj4gb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMgYXJlIHVzZWQuDQo+DQo+DQo+IFNG IGNhbiBhbHNvIGJlIHZpZXdlZCBhcyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFzIHRo ZSBuZXR3b3JrDQo+IG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlv ZC9pbnRlcnZhbCBvZiBDQ00gbWVzc2FnZXMuDQoNCg0KRU8jDQpJJ20gbm90IHN1cmUgd2hhdCB0 aGF0IHdvdWxkIGxvb2sgbGlrZS4gICdGYWlsJyBpcyBhIHByZXR0eSBiaW5hcnkgdGhpbmcuICAn RGVncmFkZScgaXMgYSBjb250aW51b3VzIHZhcmlhYmxlLCBhcyBpdCBjYW4gYmUgYW55dGhpbmcg ZnJvbSAnYSBsaXR0bGUgYmFkJyB0byBhICdhIHdob2xlIGxvdCBvZiBiYWQgYnV0IG5vdCBxdWl0 ZSBmYWlsJy4NCg0KPiBJZiBDQ00gaXMgZGlzYWJsZWQsIEFJUyBmcm9tIGEgc2VydmVyIGxheWVy IGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlcg0KPiBmb3IgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIFNv IGFuZCBzbyBmb3J0aC4NCg0KRU8jICBBSVMgZnJvbSB0aGUgc2VydmVyIGxheWVyIG9ubHkgZ2V0 cyB5b3UgU0QgZnJvbSB0aGUgZmlyc3QgaG9wIG9mIHRoZSB1bmRlcmx5aW5nIHNlcnZlciBwYXRo Lg0KDQoNCg0KDQplcmljDQoNCj4gSG93ZXZlciwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZG9jdW1l bnQgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBkZXRlY3QNCj4gU0YgaW4gYW55d2hlcmUuDQo+IFNp bWlsYXJ5LCBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93 IG1hbnVhbA0KPiBzd2l0Y2ggYW5kIGZvcmNlZCBzd2l0Y2ggY29tbWFuZHMgYXJlIGluaXRpYXRl ZCBpbiBhIG1hbmFnZW1lbnQgc3lzdGVtDQo+IGFuZCBzaWduYWxlZCB0byBwcm90ZWN0aW9uIHN3 aXRjaGluZyBwcm9jZXNzLg0KPg0KPiBBZ2FpbiwgaW4gbXkgb3BpbmlvbiwgdGhlIGRyYWZ0IG9u IFNEIHByb3RlY3Rpb24gY2FuIGFjY29tbW9kYXRlIGFueQ0KPiBTRCBkZXRlY3Rpb24gbWV0aG9k cy4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBKZW9uZy1kb25nDQo+DQo+DQo+DQo+DQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IEZyb20gOiAiRXJpYyBP c2Jvcm5lIChlb3Nib3JuZSkiIDxlb3Nib3JuZUBjaXNjby5jb208bWFpbHRvOmVvc2Jvcm5lQGNp c2NvLmNvbT4+IFNlbnQgOg0KPiAyMDEzLTA3LTIwIDAyOjQ4OjI4ICggKzA5OjAwICkgVG8gOiBE J0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvDQo+IDxhbGVzc2FuZHJvLmRhbGVzc2FuZHJv QHRlbGVjb21pdGFsaWEuaXQ8bWFpbHRvOmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0 YWxpYS5pdD4+LCBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA8bXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+IENjIDogSHV1YiBoZWx2b29ydCAoaHV1Yi52 YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTxtYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNv bT4pDQo+IDxodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPG1haWx0bzpodXViLnZhbi5oZWx2 b29ydEBodWF3ZWkuY29tPj4sIGh1dWJhdHdvcmtAZ21haWwuY29tPG1haWx0bzpodXViYXR3b3Jr QGdtYWlsLmNvbT4NCj4gPGh1dWJhdHdvcmtAZ21haWwuY29tPG1haWx0bzpodXViYXR3b3JrQGdt YWlsLmNvbT4+IFN1YmplY3QgOiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3INCj4gYWxp Z25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0 DQo+IHJlcXVpcmVtZW50cw0KPg0KPg0KPiBIaSBBbGVzc2FuZHJvLQ0KPg0KPiBUaGFua3MgZm9y IHRoaXM7IHRoZSB0aHJlYWRzIEkgc3RhcnRlZCBzb21lIHRpbWUgYmFjayBzZWVtIHRvIGhhdmUN Cj4gZGllZCBkb3duLCBpdCdzIGdvb2QgdG8gZ2V0IHRoZW0gZ29pbmcgYWdhaW4uDQo+IEkgaGF2 ZSB0d28gdGhpbmdzIEkgbmV2ZXIgcXVpdGUgdW5kZXJzdG9vZCwgY2FuIHlvdSBjbGFyaWZ5IHRo ZW0gZm9yIG1lPw0KPg0KPiBpKSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBsZXZl bD8gSSdtIG5vdCBsb29raW5nIGZvciBhDQo+IGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNo aW5lIGNoYW5nZXMsIGFuZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZQ0KPiBvbmUgbGluZSAiSXQg YWxsb3dzIHRoZSBGU00gdG8gYmUgdGVzdGVkIi4gV2UgaGF2ZSBhbGwgb2YgdGhhdCBpbiB0aGUN Cj4gZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBzcGVjcy4NCj4NCj4gV2hhdCBJJ2Qg bGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9tLiBUaGUg SVRVDQo+IHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3csIHRo ZXkgc2VlbSB0byBhc3N1bWUNCj4gdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBp cyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQNCj4gZmVlbHMgdmVyeSBtdWNoIGxpa2Ug YSBtZWNoYW5pc20gdXNlZCB0byBjYXRjaCBhIHZlcnkgc3BlY2lmaWMNCj4gaW1wbGVtZW50YXRp b24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2FzIGZhciBsZXNzIGRlYnVnZ2FibGUN Cj4gdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuDQo+DQo+IE5vIG90aGVyIHN0YXRlIG1hY2hpbmVz IHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwgQkdQLCBPU1BGLA0KPiBJU0lTKSBo YXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvciB3 aGV0aGVyDQo+IGl0ICp3b3VsZCogYmUgYnJva2VuIGlmIGlmIHdlcmUsIGluIHRoZSBmdXR1cmUs IHRvIGJlIGdpdmVuIGENCj4gcGFydGljdWxhciBpbnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNl IHRvIGdldCBiZWhpbmQgRVhFUiBoYXMgYmVlbg0KPiB0aGF0IEkgZG9uJ3QgZmVlbCBjb21mb3J0 YWJsZSB3aXRoIHRoZSBpZGVhIG9mIGtlZXBpbmcgYSAzMC15ZWFyLW9sZA0KPiB3b3JrYXJvdW5k IGluIGEgcHJvdG9jb2wuIElzIHRoZXJlIG1vcmUgdG8gaXQgdGhhbiB0aGF0PyBIYXZlIEkNCj4g bWlzcmVhZCBhbmQgbWlzdW5kZXJzdG9vZCBFWEVSPyBEb2VzIG1vZGVybiB0cmFuc3BvcnQgZ2Vh ciBldmVyDQo+IGFjdHVhbGx5IGRldGVjdCBhIHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3YXNu J3Qgb2J2aW91cyB0byB0aGUNCj4gb3BlcmF0b3IgdXNpbmcgb3RoZXIgbWVhbnM/DQo+DQo+DQo+ IGlpKSBXaHkgdGhlIHB1c2ggdG8gc3RhbmRhcmRpemUgdGhlIFNEIHN0YXRlIGNoYW5nZXMgYmVm b3JlIHdlJ3ZlDQo+IGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxpbmcg c2lnbmFsIGRlZ3JhZGUgaXMgYSBnb29kDQo+IGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0aCBhIGRl ZmluaXRpb24gZm9yIGl0IGhhcyBiZWVuIGNoYWxsZW5naW5nLg0KPiBXaGF0IGhhcHBlbnMgaWYg d2UgY2hhbmdlIHRoZSBGU00gdG8gaGFuZGxlIGl0LCB0aGVuIGNvbWUgdXAgd2l0aA0KPiBzb21l dGhpbmcgbW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRpcGxlIGxldmVscyBvZiBTRCkgdGhh dCBkb2Vzbid0DQo+IHF1aXRlIGZpdCB3aXRoIHRoZSBGU00gY2hhbmdlcz8NCj4NCj4NCj4NCj4g dGhhbmtzIQ0KPg0KPg0KPg0KPg0KPg0KPiBlcmljDQo+DQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KPiBPZg0KPiA+IEQnQWxlc3NhbmRybyBB bGVzc2FuZHJvIEdlcmFyZG8NCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgMzoy MyBQTQ0KPiA+IFRvOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+IENj OiBIdXViIGhlbHZvb3J0IChodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPG1haWx0bzpodXVi LnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPik7DQo+ID4gaHV1YmF0d29ya0BnbWFpbC5jb208bWFp bHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPg0KPiA+IFN1YmplY3Q6IFttcGxzXSBwcm9wb3NlZCBk cmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcg0KPiA+IHByb3RlY3Rpb24gcHJv dG9jb2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPiA+DQo+ID4gRGVhciBhbGwsDQo+ID4g d2Ugd291bGQgbGlrZSBzb2NpYWxpemluZyB0aGUgaGVyZWJlbG93IGRyYWZ0cyB0aGF0IHdlcmUg c3VibWl0dGVkDQo+IHNvbWUNCj4gPiBtb250aHMgYWdvIHdpdGggdGhlIGFpbSB0byBhbGlnbiBQ U0MgcHJvdG9jb2wgKFJGQyA2Mzc4KSB0byBJVFUtVA0KPiA+IHRyYW5zcG9ydCByZXF1aXJlbWVu dHMuIEkgd291bGQgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFib3V0IHRoZQ0KPiA+IHByb3Bv c2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91cnMuDQo+ID4NCj4gPiBkcmFmdC1yaGQtbXBscy10 cC1wc2MtcHJpb3JpdHktMDANCj4gPiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2 ZS0wMA0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMA0KPiA+IGRyYWZ0LWRqLW1wbHMt dHAtZXhlci1wc2MtMDEgLyBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLWFsaXZlLTAwDQo+ID4NCj4g PiBUaGUgYWJvdmUgZHJhZnRzIGNvdmVyIG1vc3Qgb2YgaXRlbXMgaGlnaGxpZ2h0ZWQgaW4gSVRV LVQgbGlhaXNvbnMNCj4gYWJvdXQNCj4gPiBQU0MgYW5kIHRoZXkgcHJvcG9zZSBzb2x1dGlvbnMg aW4gbGluZSB3aXRoIE1QTFMtVFAgdHJhbnNwb3J0DQo+ID4gcmVxdWlyZW1lbnRzLg0KPiA+IEEg bGlzdCBvZiBtYWluIGxpYWlzb25zIGV4Y2hhbmdlZCBiZXR3ZWVuIElUVS1UIGFuZCBJRVRGIHdp dGggdGhlDQo+ID4gYWltDQo+IHRvDQo+ID4gYWxpZ24gUFNDIGJlaGF2aW91cyB3aXRoIElUVS1U IHRyYW5zcG9ydCByZXF1aXJlbWVudHMgZm9yIGxpbmVhcg0KPiA+IHByb3RlY3Rpb24gYXJlIGdp dmVuIGJlbG93Og0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMTYy LyAoSnVuZSAyMDEyKQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8x MjA1Lw0KPiA+IChPY3RvYmVyIDIwMTIpDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9saWFpc29uLzEyMjkvDQo+ID4gKEphbnVhcnkgMjAxMykNCj4gPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2xpYWlzb24vMTIzNC8NCj4gPiAoRmVicnVhcnkgMjAxMykNCj4gPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni8NCj4gPiAoTWF5IDIwMTMpDQo+ ID4NCj4gPiBTb21lIGRldGFpbHMgYWJvdSB0aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQ U0MgYmVoYXZpb3VyIHdpdGgNCj4gPiB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzOg0KPiA+DQo+ID4g ZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwIHByb3Bvc2VzIHN3YXBwaW5nIHRoZSBw cmlvcml0aWVzDQo+ID4gYmV0d2VlbiBGUyBhbmQgU0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIgb2Yg cmZjNjM3OCkuDQo+ID4gQW1vbmcgdGhlIG90aGVycywgYmVoYXZpb3JzIHRoYXQgd2lsbCBiZSBm aXhlZCB3aXRoIHRoZSBwcm9wb3NlZA0KPiB1cGRhdGUNCj4gPiBhcmU6DQo+ID4gVXNlIGNhc2Ug QSkgQXQgZmlyc3QsIHdvcmtpbmcgcGF0aChXUCkgYW5kIHByb3RlY3Rpb24gcGF0aChQUCkgYXJl DQo+ID4gbm9ybWFsLiBUaGVuLCBGb3JjZWQgU3dpdGNoKEZTKSBjb21tYW5kIGlzIGlzc3VlZCBm b3IgbWFpbnRlbmFuY2Ugb24NCj4gdGhlDQo+ID4gV1AgYW5kIHRoZSB0cmFmZmljIG1vdmVzIGZy b20gV1AgdG8gUFAuIFdoZW4gU2lnbmFsIEZhaWwgb2NjdXJzIG9uDQo+ID4gUFAsIHNlcnZpY2Ug Y2Fubm90IHJlY292ZXIgYW5kIGlzIGludGVycnVwdGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvcg0K PiBleGFtcGxlDQo+ID4gYXMgYSByZXN1bHQgb2YgYWNjaWRlbnRhbGx5IHVuLXBsdWdnaW5nIGEg UFAgZmliZXIuDQo+ID4gVXNlIGNhc2UgQikgSWYgdGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFs IGZhaWwgb24gYSBwcm90ZWN0aW9uIHBhdGgNCj4gPiAoU0YtUCksYW5kIEZTIGNvbW1hbmQgaXMg aXNzdWVkIGJ5IGFjY2lkZW50IHRoZSB0cmFmZmljIG9uIFdQIHdpbGwNCj4gbW92ZQ0KPiA+IHRv IFBQLiBUaGlzIHJlc3VsdHMgaW4gYW4gaW50ZXJydXB0aW9uIG9mIHNlcnZpY2UgZnJvbSB3aGlj aCB5b3UNCj4gPiB3aWxsIG5vdCBhdXRvbWF0aWNhbGx5IHJlY292ZXIsIGJlY2F1c2UgUFNDIHNo b3VsZCBub3QgaGF2ZSBzd2l0Y2hlZA0KPiA+IHRoZSB0cmFmZmljIGZyb20gV1AgdG8gUFAuDQo+ ID4gRGlzY3Vzc2lvbiBhYm91dCB0aGlzIGRyYWZ0IGxlZCB0byB0aGUgcHJvcG9zYWwgdG8gbW9k aWZ5IFJGQyA0NDI3DQo+IHRoYXQNCj4gPiB3YXMgIndyaXR0ZW4gY29ycmVjdGx5IHRob3VnaCBs YWNraW5nIGluIGRldGFpbCBjYXVzaW5nIG1pcy0NCj4gPiBpbnRlcnByZXRhdGlvbiIgdGhhdCBs ZWQgdG8gdGhlIGN1cnJlbnQgUFNDIHNldCBvZiBwcmlvcml0eSB0aGF0IHRoZQ0KPiA+IGFib3Zl IGRyYWZ0IGlzIHByb3Bvc2luZyB0byBtb2RpZmllZCBhbmQgdG8gYWxpZ24gdG8gdGhlIHJlcXVp cmVkDQo+ID4gdHJhbnNwb3J0IGJlaGF2aW9yLiBkcmFmdC1oZWx2b29ydC1jY2FtcC1mcy1wcmlv cml0eS0wMCBoYXMgYmVlbg0KPiA+IHN1Ym1pdHRlZCB0byBDQ0FNUCBmb3IgY2xhcmlmeWluZyB0 aGUgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byBNYW51YWwNCj4gPiBTd2l0Y2ggYW5kIEZvcmNlZCBT d2l0Y2ggYW5kIHRoZWlyIHVzYWdlIHJlbGF0aXZlIHRvIHByaW9yaXRpZXMuDQo+ID4gVGhlIHdh eSB0aGlzIGJlaGF2aW9yIGhhcyB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDIGhhcyB0 byBiZQ0KPiA+IGRpc2N1c3NlZC4gVGhlIHRleHQgcHJvcG9zZXMgdG8gcmVwbGFjZSB0aGUgY3Vy cmVudCBiZWhhdmlvciB3aXRoDQo+ID4gdGhlIG5ldyBvbmUuIElmIHRoZXJlIGlzIGNvbnNlbnN1 cyB0byBwcm9jZWRlIGluIHRoYXQgd2F5IHRoaXMgY2FuDQo+ID4gYnJpbmcNCj4gdG8NCj4gPiBh IHNpbXBsZSBhbmQgZWZmZWN0aXZlIHdheSB0byBvcGVyYXRlIHRoZSBwcm90b2NvbC4NCj4gPg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0NCj4gPiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJl dmVydGl2ZS0wMCBjb250YWlucyB0aGUgdXBkYXRlcyB0bw0KPiA+IFJGQzYzNzggdG8gY2hhbmdl IG5vbi1yZXZlcnRpdmUgb3BlcmF0aW9ucyB0byBiZWhhdmVzIGluIHRoZSBzYW1lDQo+ID4gd2F5 IGlycmVzcGVjdGl2ZWx5IG9mIHRoZSB0cmlnZ2VyIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIChm YXVsdCBvcg0KPiBvcGVyYXRvcg0KPiA+IGNvbW1hbmQgRlMsIE1TKS4gQ29uc2VxdWVudGx5IGFu IG9wZXJhdG9yIGNvbW1hbmQsIE1hbnVhbCBTd2l0Y2ggdG8NCj4gPiBXb3JraW5nIChNUy1XKSBh LmsuYSAiTWFudWFsIHN3aXRjaC1vdmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiIgaXMNCj4gYWxz bw0KPiA+IGFkZGVkIHRvIGVuYWJsZSB0aGlzIGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFs IHBvaW50IG9mIHZpZXcsIE1TDQo+IHRvDQo+ID4gd29ya2luZyBwYXRoIGhhcyBhbHNvIHRvIGJl IHN1cHBvcnRlZCB0byBiZSBhYmxlIHRvIGluaXRpYWxseSBhbGlnbg0KPiA+IGF0IGJvdGggc2lk ZXMgaW4gY2FzZSBvZiBub24tcmV2ZXJ0aXZlIHN3aXRjaGluZyBtb2RlLiBNUyB0byB3b3JraW5n DQo+ID4gcGF0aCBpcyBkZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My4NCj4gPg0K PiA+IFRoZSBwcm9wb3NlZCBNUy1XIGNvbW1hbmQgaXMgb2YgZXF1YWwgcHJpb3JpdHkgdG8gdGhl IGV4aXN0aW5nIE1TLVANCj4gPiBjb21tYW5kLCBhbmQgdGhlcmUgaXMgdGV4dCB0byBoYW5kbGUg dGhlIHNpbXVsdGFuZW91cyBvciBzZXF1ZW50aWFsDQo+ID4gb2NjdXJyZW5jZSBvZiB0d28gZXF1 YWwtcHJpb3JpdHkgY29tbWFuZHMuIFRoaXMgYmVoYXZpb3IsIGFscmVhZHkNCj4gPiBhZG9wdGVk IGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3JrIHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb3RvY29s LA0KPiA+IGNhbg0KPiBiZQ0KPiA+IHVzZWQgZm9yIG90aGVyIGFkZGl0aW9uIHRvIHRoZSBwcm90 b2NvbCBpbiB0aGUgZnV0dXJlLg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+IGRy YWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMCBwcm92aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQU0Mg c3RhdGUNCj4gPiBtYWNoaW5lIHRvIGhhbmRsZSBTaWduYWwgRGVncmFkZSAoU0QpLiBJdCBkb2Vz IG5vdCBkZWZpbmUgU0Qgb3INCj4gcHJvdmlkZQ0KPiA+IHNjb3BlIGFyb3VuZCB3aGVyZSBvciBo b3cgU0QgbWF5IGJlIHVzZWQgc2ltaWxhcmx5IGFzIGl0IGFscmVhZHkNCj4gaGFwcGVuDQo+ID4g aW4gdGhlIGRyYWZ0IGluIGhhbmRsaW5nIG90aGVyIGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZh aWx1cmUpLg0KPiA+IEluIE1QTFMtVFAgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgW1JGQzYzNzJd LCBhIGZhdWx0IGNvbmRpdGlvbg0KPiA+IGluY2x1ZGVzIGJvdGggU2lnbmFsIEZhaWwgKFNGKSBh bmQgU2lnbmFsIERlZ3JhZGUgKFNEKSB0aGF0IGNhbiBiZQ0KPiB1c2VkDQo+ID4gdG8gdHJpZ2dl ciBwcm90ZWN0aW9uIHN3aXRjaGluZy4NCj4gPiBXaGlsZSB0aGUgc3RhbmRhcmRpemF0aW9uIGxh Y2sgb2YgYW4gU0QgZGVmaW5pdGlvbiBhbmQgZGV0ZWN0aW9uDQo+ID4gbWVjaGFuaXNtcywgdGhl IHJlbGV2YW50IGJlaGF2aW9ycyBpbiB0ZXJtcyBvZiBwcm90ZWN0aW9uIGFjdGlvbnMNCj4gPiBt YXkgYWxyZWFkeSBiZSBkZWZpbmVkLg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+ IGRyYWZ0LWRqLW1wbHMtdHAtZXhlci1wc2MtMDEgcHJvcG9zZXMgYWRkaW5nIHRoZSBFWEVSL1JS IGNvbW1hbmRzIHRvDQo+ID4gdGVzdCBpZiB0aGUgQVBTIGNvbW11bmljYXRpb24gaXMgb3BlcmF0 aW5nIGNvcnJlY3RseS4gSW4gb3RoZXIgd29yZHMNCj4gPiBib3RoIEFQUyBwcm9jZXNzIGxvZ2lj IGluY2x1ZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBUFMgY2hhbm5lbCBvbg0KPiA+IHByb3RlY3Rp b24gcGF0aCwgd2l0aG91dCBzZXJ2aWNlIGRpc3J1cHRpb24gYW5kIHdpdGhvdXQgYWZmZWN0aW5n DQo+ID4gYW55IHByb3RlY3Rpb24gb3BlcmF0aW9uLCB1bmxlc3MgdGhlIHByb3RlY3Rpb24gdHJh bnNwb3J0IGVudGl0eSBpcw0KPiA+IGluDQo+IHVzZS4NCj4gPiBUaGlzIGNvbW1hbmQgaXMgZG9j dW1lbnRlZCBpbiBSODQgb2YgW1JGQzU2NTRdIGFuZCBpdCBpcyBwYXJ0IG9mDQo+ID4gSVRVLVQg dHJhbnNwb3J0IHJlcXVpcmVtZW50cy4NCj4gPiBBbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBk b2N1bWVudGVkIGluIHRoZSBBcHBlbmRpeCBCIG9mIFJGQzYzNzgNCj4gdGhhdA0KPiA+IHV0aWxp emVzIHRoZSBMb2Nrb3V0IG9mIFByb3RlY3Rpb24gKExPKSBvciBGb3JjZWQgU3dpdGNoIChGUykg aW4NCj4gPiBjb21iaW5hdGlvbiBvZiBPQU0gZnVuY3Rpb25hbGl0aWVzLiBIb3dldmVyLCBpdCBo YXMgc29tZSBmdW5jdGlvbmFsDQo+ID4gbGltaXRhdGlvbiBhbmQgaGFzIGEgcG90ZW50aWFsIHJp c2sgb2YgbG9zaW5nIHRyYWZmaWMgYXMgYSBzaWduYWwNCj4gPiBmYWlsdXJlIG1pZ2h0IG9jY3Vy IGR1cmluZyB0aGUgZXhlcmNpc2Ugb3BlcmF0aW9uLiBJbiB0aGF0IGNhc2UsIExPDQo+ID4gb3Ig RlMgaGFzIHRvIGJlIGNhbmNlbGVkIHRvIGFsbG93IHRoZSBQU0MgcHJvdG9jb2wgdG8gcHJvdmlk ZSBwcm9wZXINCj4gPiBzd2l0Y2hpbmcuDQo+ID4gQSBmdXJ0aGVyIGFsdGVybmF0aXZlIHByb3Bv c2FsIGlzIGRvY3VtZW50ZWQgaW4gZHJhZnQtb3Nib3JuZS1tcGxzLQ0KPiBwc2MtDQo+ID4gYWxp dmUtMDAgdGhhdCBhbnl3YXkgc2hvdyBzb21lIGZ1bmN0aW9uYWwgbGltaXRhdGlvbnMgYmVjYXVz ZSBjYW5ub3QNCj4gPiB2YWxpZGF0ZSB0aGUgUFNDIHN0YXRlIG1hY2hpbmUgc3RhdHVzIGFuZCBw cm9iYWJseSB0aGUgTG9jYWwgUmVxdWVzdA0KPiA+IGxvZ2ljLg0KPiA+DQo+ID4NCj4gPiBUaGUg YXV0aG9ycyBlbmNvdXJhZ2UgdGhlIElFVEYgZXhwZXJ0cyB0byBjb21tZW50IG9uIHRoZXNlIGRy YWZ0cywNCj4gPiBldmVudHVhbGx5IHByb3Bvc2luZyBvdGhlciBvcHRpb25zL21lY2hhbmlzbXMg dGhhdCBjYW4gc2F0aXNmeSB0aGUNCj4gc2FtZQ0KPiA+IHJlcXVpcmVtZW50cy4NCj4gPiBCZXN0 IHJlZ2FyZHMsDQo+ID4gQWxlc3NhbmRybywgSHV1YiwgSmVvbmctZG9uZywgVGFla3NpZCBRdWVz dG8gbWVzc2FnZ2lvIGUgaSBzdW9pDQo+ID4gYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2Ns dXNpdmFtZW50ZQ0KPiBhbGxlDQo+ID4gcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwg Y29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lDQo+ID4gZGVyaXZhbnRlIGRhbGxhIGNvbm9z Y2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUNCj4gPiB2aWV0 YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3Jl IHNpZXRlDQo+ID4gY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVu aWNhemlvbmUgYWwgbWl0dGVudGUgZQ0KPiA+IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1 emlvbmUsIEdyYXppZS4NCj4gPg0KPiA+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg aXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbg0KPiA+IHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4NCj4gPiBEaXNzZW1pbmF0aW9u LCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzDQo+IHVuYXV0aG9y aXNlZC4NCj4gPiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug ZGVsZXRlIHRoaXMgbWVzc2FnZQ0KPiA+IGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCj4gPg0KPiA+IHJpc3BldHRhIGwn YW1iaWVudGVSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2UN Cj4gbm9uDQo+ID4gw6ggbmVjZXNzYXJpby4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg0KDQoNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGls bCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276807F5SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5ZYWFjb3YsIGhvdyBhcmUgeW91PzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQiPkkmbmJzcDt1bmRlcnN0YW5kIHlvdXIgdGVjaG5pY2FsIGNvbmNl cm5zIG9uIHRoZSBTRCBzaXR1YXRpb24gb24gdGhlIHdvcmtpbmcgcGF0aCB3aGlsZSZuYnNwO3Ro ZSBwcm90ZWN0aW9uIHBhdGggaXMgaW4gZmFjdCB3b3JzZS48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij5JIGFtIG5vdCB0cnlpbmcgdG8gcmVzb2x2ZSB0aGUgaXNzdWUgaGVy ZSwgYnV0IHdoYXQgd2UgY2FuIGhhdmUgaXMgdGhhdCBhbnkmbmJzcDtlbnRpdHkgb3ImbmJzcDtm dW5jdGlvbiB0aGF0IGRldGVjdHMgU0QgYW5kJm5ic3A7c2lnbmFscyZuYnNwO3RoZSBTRCBldmVu dCB0byBQU0MgcHJvY2VzcyBjYW4gdHJhbnNmb3JtIHRoZSBjb250aW51b3VzJm5ic3A7U0QgdmFs dWVzIG9uIGJvdGggd29ya2luZyBhbmQgdHJhbnNwb3J0IHBhdGhzDQogaW50byBhIGJpbmFyeSBk ZWNpc2lvbiwgYW5kIHNpZ25hbHMgdGhlJm5ic3A7cmVzdWx0IHRvIFBTQyBwcm9jZXNzLiBGb3Ig ZXhhbXBsZSwgaWYgU0Qgb24gd29ya2luZyBpcyB3b3JzZSB0aGFuIFNEIG9uIHByb3RlY3Rpb24s IGl0IGNhbiZuYnNwO29ubHkgc2VuZCBTRC1XIHRvIFBTQyBwcm9jZXNzLiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkFsc28sIHdlIG5lZWQgdG8gZHVwbGljYXRl IHRoZSB0cmFmZmljIHRvIGJvdGggcGF0aHMgaW4gdGhpcyBjYXNlLCBzbyB0aGF0Jm5ic3A7Ym90 aCBwYXRocyBjYW4gYmUgbW9uaXRvcmVkIHdpdGggdGhlIHNhbWUgdHJhZmZpYyBjb25kaXRpb24u PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SG93ZXZlciwgdGhpcyBoYXN0 eSBhbmQgY2x1bXN5IGlkZWEgb2YgbWluZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBwcm90ZWN0 aW9uIHN3aXRjaGluZy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJz cDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0IHJlZ2FyZHMsPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SmVvbmctZG9uZzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiPjxicj4NCjxicj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiIGlkPSJNYWlsU2lnbiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7WWFhY292IFdlaW5nYXJ0 ZW4mcXVvdDsgJmx0O3d5YWFjb3ZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAx My0wNy0yNCAxNDoyMDo0MCAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPm1wbHNAaWV0 Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+RXJpYyBPc2Jvcm5l IChlb3Nib3JuZSkgJmx0O2Vvc2Jvcm5lQGNpc2NvLmNvbSZndDssIFJ5b28sIEplb25nLWRvbmcg Jmx0O3J5b29AZXRyaS5yZS5rciZndDssIEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8g Jmx0O2FsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdCZndDssIEh1dWIgaGVs dm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pICZsdDtodXViLnZhbi5oZWx2b29y dEBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFttcGxzXSDlm57lpI3v vJogcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXIgcHJvdGVj dGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPGJyPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgZGlyPSJsdHIiPg0KPGRpdj5IaSBhbGws PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5XaGlsZSBJIHBlcnNvbmFsbHkgc3VwcG9y dCB0aGUgaWRlYSBvZiBpbmNsdWRpbmcgdGhlIFNEIHN1cHBvcnQgaW4gdGhlIExpbmVhciBQcm90 ZWN0aW9uIHByb3RvY29sLCBpZiBvbmx5IGZvciBjb21wYXRpYmlsaXR5IHdpdGggb3RoZXIgY29t cGFyYWJsZSB0b29scywgSSBmZWVsIHRoZXJlIGlzIGEgbmVlZCB0byBhZGQgdGhlIGNvbnRleHQg dGhhdCBjYXVzZWQgaXQgdG8gYmUgJnF1b3Q7ZG93bmdyYWRlZCZxdW90OyB0byBwbGFjZS1ob2xk ZXIgc3RhdHVzDQogaW4gUFNDLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4gdGhl IG9yaWdpbmFsIGRyYWZ0IHZlcnNpb25zIG9mIHRoZSBQU0MgZGVmaW5pdGlvbiwgd2UgaW5jbHVk ZWQgU0QgbWVzc2FnZXMgYW5kIGRlc2NyaWJlZCB0aGUgc3dpdGNoaW5nIG9wZXJhdGlvbiB3aGVu IHRoZSBzeXN0ZW0gdHJpZ2dlcmVkIGFuIFNEIHNpdHVhdGlvbi4gT24gdGhlIGFzc3VtcHRpb24g dGhhdCB0aGVyZSB3b3VsZCBiZSBhIHdheSB0byBkZXRlY3Qgc29tZSBraW5kIG9mIFNELiBUaGVy ZSB3ZXJlIGV2ZW4gc29tZSBkcmFmdHMNCiB0aGF0IHdlcmUgcHJvcG9zZWQgYnkgZGlmZmVyZW50 IG1lbWJlcnMgb24gaG93IHRvIGRlZmluZSBTRCBhbmQgZGV0ZWN0IGl0IGZvciBNUExTLiBOb25l IG9mIHRoZXNlIGxhdHRlciBkcmFmdHMgd2VyZSwgaG93ZXZlciwgYWNjZXB0ZWQgYnkgdGhlIFdH IGJhc2VkIHVwb24gdGhlIGJlbGllZiB0aGF0IFNEIGlzIG5vdCByZWxldmFudCBhdCB0aGUgTVBM UyBsZXZlbCwgaXQgaXMgbW9yZSBhIHN5c3RlbS1sYXllciBvciBwaHlzaWNhbCBsYXllciBpc3N1 ZQ0KIGFuZCBzaG91bGQgYmUgc29sdmVkIGJ5IHRob3NlIGxheWVycy48L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PkluIGFkZGl0aW9uLCByZWdhcmRpbmcgdGhlIGlkZWEgb2Ygc3dpdGNo aW5nIHRoZSB0cmFmZmljIGZyb20gdGhlIHdvcmtpbmcgdG8gdGhlIHByb3RlY3Rpb24gcGF0aCBi YXNlZCBvbiBhbiBTRCBzaXR1YXRpb24gb24gdGhlIHdvcmtpbmcgcGF0aCB3YXMgZnJvd25lZCB1 cG9uLiBUaGlzIHdhcyBiYXNlZCBvbiB0aGUgcXVlc3Rpb24gb2YgaG93IGRvIHdlIGFzc3VyZSB0 aGF0IHRoZSBwcm90ZWN0aW9uIHBhdGggaXMgYSBiZXR0ZXIgbWVkaXVtDQogZm9yIHRoZSBwYWNr ZXQgdHJhbnNwb3J0LiBCZWNhdXNlIGV2ZW4gaWYgeW91IGNvdWxkIG1lYXN1cmUgYW5kIGlkZW50 aWZ5IGFuIFNEIHNpdHVhdGlvbiBvbiB0aGUgd29ya2luZyBwYXRoLCB0aGVyZSBpcyBubyB3YXkg dG8gbWVhc3VyZSBpdCBvbiB0aGUgcHJvdGVjdGlvbiBwYXRoLCBzaW5jZSBpdCBpcyBtb3N0IHBy b2JhYmx5IGFmZmVjdGVkIGJ5IHRoZSBsb2FkIGZhY3RvcnMgaW52b2x2ZWQgaW4gdGhlIHBhY2tl dCBzaXplcy4mbmJzcDsgVGhlcmVmb3JlLA0KIHlvdSBhcmUgc3dpdGNoaW5nIHRvIGEgcGF0aCB0 aGF0LCBhdCBsZWFzdCBpbiB0aGVvcnksIGNvdWxkIGJlIGEgd29yc2UgY2hvaWNlITwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhpcyB3YXMgdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhl IGRvd25ncmFkZSBvZiB0aGUgU0Qgc2lnbmFsIGFuZCB0aGUgbm90ZSB0aGF0IHRoaXMgaXMgZm9y IGZ1cnRoZXIgc3R1ZHkuJm5ic3A7IEkgaGF2ZSBub3Qgc2VlbiBhbnlvbmUgaW4gdGhpcyBkaXNj dXNzaW9uIGFkZHJlc3MgdGhpcyBpc3N1ZSwgYW5kIHRoZXJlZm9yZSBJIHRoaW5rIGl0IGlzIGlt cG9ydGFudCB0aGF0IHdlIGhlYXIgc29tZSBqdXN0aWZpY2F0aW9uIGZvciBzd2l0Y2hpbmcNCiBh d2F5IGZyb20gYSB3b3JraW5nIHBhdGggdG8gb25lIHRoYXQgd2UgaGF2ZSBubyBiZXR0ZXIgaW5m b3JtYXRpb24gb24hIEkgdGhpbmsgdGhhdCB0aGUganVzdGlmaWNhdGlvbnMgZ2l2ZW4gdW50aWwg bm93IC0gaS5lLiAmcXVvdDt0aGlzIGlzIHRoZSB3YXkgaXQgaGFzIGFsd2F5cyBiZWVuIGRvbmUg aW4gcGh5c2ljYWwgbGF5ZXIgc3lzdGVtcyZxdW90OyAtJm5ic3A7YXJlIG5vdCBzdWZmaWNpZW50 IHRvIGFkZCBmdW5jdGlvbmFsaXR5IHRoYXQgbWF5IGNhdXNlIHBvb3Jlcg0KIHBlcmZvcm1hbmNl ITwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SG9wZSB0aGlzIGhlbHBzIGZvY3VzIHRo ZSBkaXNjdXNzaW9uLDwvZGl2Pg0KPGRpdj55YWFjb3Ygd2VpbmdhcnRlbjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+ DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBKdWwgMjQsIDIwMTMgYXQg NDo0NiBBTSwgTGFycnkgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86bGFycnls aTg4OEB5YWhvby5jb20uY24iIHRhcmdldD0iX2JsYW5rIj5sYXJyeWxpODg4QHlhaG9vLmNvbS5j bjwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxF RlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxF RlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJGT05ULUZB TUlMWTogdGltZXMgbmV3IHJvbWFuLG5ldyB5b3JrLHRpbWVzLHNlcmlmOyBGT05ULVNJWkU6IDEy cHQiPg0KPGRpdj48c3Bhbj5IaSBhbGwsPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogdHJhbnNwYXJlbnQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6 ICd0aW1lcyBuZXcgcm9tYW4nLCduZXcgeW9yaycsdGltZXMsc2VyaWY7IEZPTlQtU0laRTogMTZw eCI+DQo8c3Bhbj48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJCQUNLR1JPVU5ELUNP TE9SOiB0cmFuc3BhcmVudDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULUZBTUlMWTogJ3RpbWVz IG5ldyByb21hbicsJ25ldyB5b3JrJyx0aW1lcyxzZXJpZjsgRk9OVC1TSVpFOiAxNnB4Ij4NCjxz cGFuPjxzcGFuIHN0eWxlPSJXSElURS1TUEFDRTogcHJlLXdyYXAiPjwvc3Bhbj5JIGFncmVlIHdp dGggVG9tIGFuZCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5KZW9u Zy1kb25nLiBUaGVyZSBhcmUgZGlmZmVyZW50IHJlYXNvbnMgdG8gY2F1c2UgU0QsIGJ1dCB0aGUg cmVzdWx0IGlzIHRoZSB0cmFuc3BvcnQgcGVyZm9ybWFuY2UgZGVncmFkZSBhbmQgaXQgaXMgaW1w b3J0YW50IHRvIGxldCBvcGVyYXRvcnMgc2V0IGEgdGhyZXNob2xkDQogdG8gdHJpZ2dlciBwcm90 ZWN0aW9uIHN3aXRjaC4gRHVyaW5nIHRoZSB0cm91YmxlIHNob290aW5nLCBvcGVyYXRvcnMgbmVl ZCB0b29scyB0byBkbyBmYXVsdCBsb2NhbGl6YXRpb24uIEFsdGhvdWdodCAmcXVvdDtkZWdyYWRl JnF1b3Q7IGlzIGEgY29udGlub3VzIHZhcmlhYmxlIGJlaGF2aW91ciwgaXQgaXMgYSAmcXVvdDsw LzEmcXVvdDsgcHJvYmxlbSBhZnRlciBkZWZpbmluZyB0aGUgdGhyZXNob2xkLjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHRyYW5zcGFyZW50OyBGT05ULVNUWUxF OiBub3JtYWw7IEZPTlQtRkFNSUxZOiAndGltZXMgbmV3IHJvbWFuJywnbmV3IHlvcmsnLHRpbWVz LHNlcmlmOyBGT05ULVNJWkU6IDE2cHgiPg0KPHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PHNwYW4gc3R5bGU9IldISVRFLVNQQUNFOiBwcmUtd3JhcCI+PC9zcGFuPlRoYW5rIHlvdSE8L3Nw YW4+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+KioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjxicj4NCkhhbiBMaSwgUGguRCA8YnI+DQpDaGluYSBNb2JpbGUgUmVzZWFyY2ggSW5z dGl0dXRlPGJyPg0KMzIgWHVhbnd1bWVuIFdlc3QgU3RyZWV0LCBYaWNoZW5nIERpc3RyaWN0LCBC ZWlqaW5nIDEwMDA1MywgQ2hpbmEgPGJyPg0KRmF4OiA8YSBocmVmPSJ0ZWw6JTJCODYlMjAxMCUy MDYzMTM1MTU5IiB0YXJnZXQ9Il9ibGFuayIgdmFsdWU9IiYjNDM7ODYxMDYzMTM1MTU5Ij4mIzQz Ozg2IDEwIDYzMTM1MTU5PC9hPg0KPGJyPg0KTU9CSUxFOiAxMzUwMTA5MzM4NSA8YnI+DQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJGT05ULUZBTUlMWTogJ3RpbWVz IG5ldyByb21hbicsJ25ldyB5b3JrJyx0aW1lcyxzZXJpZjsgRk9OVC1TSVpFOiAxMnB0Ij4NCjxk aXYgc3R5bGU9IkZPTlQtRkFNSUxZOiAndGltZXMgbmV3IHJvbWFuJywnbmV3IHlvcmsnLHRpbWVz LHNlcmlmOyBGT05ULVNJWkU6IDEycHQiPg0KPGRpdiBkaXI9Imx0ciI+DQo8aHIgc2l6ZT0iMSI+ DQo8Zm9udCBmYWNlPSJBcmlhbCI+PGI+PHNwYW4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj7l j5Hku7bkurrvvJo8L3NwYW4+PC9iPiAmcXVvdDtIdWJlciwgVGhvbWFzIEouJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86VG9tLkh1YmVyQHRlbGxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+VG9t Lkh1YmVyQHRlbGxhYnMuY29tPC9hPiZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iRk9OVC1XRUlH SFQ6IGJvbGQiPuaUtuS7tuS6uu+8mjwvc3Bhbj48L2I+IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUp ICZsdDs8YSBocmVmPSJtYWlsdG86ZW9zYm9ybmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZW9zYm9ybmVAY2lzY28uY29tPC9hPiZndDs7ICZxdW90O1J5b28sIEplb25nLWRvbmcmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUua3IiIHRhcmdldD0iX2JsYW5rIj5yeW9v QGV0cmkucmUua3I8L2E+Jmd0OzsgRCdBbGVzc2FuZHJvDQogQWxlc3NhbmRybyBHZXJhcmRvICZs dDs8YSBocmVmPSJtYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0 IiB0YXJnZXQ9Il9ibGFuayI+YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0 PC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj48 c3BhbiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPuaKhOmAge+8mjwvc3Bhbj48L2I+ICZxdW90 O0h1dWIgaGVsdm9vcnQgKDxhIGhyZWY9Im1haWx0bzpodXViLnZhbi5oZWx2b29ydEBodWF3ZWku Y29tIiB0YXJnZXQ9Il9ibGFuayI+aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTwvYT4pJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb208L2E+Jmd0OzsNCiAmcXVv dDs8YSBocmVmPSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5o dXViYXR3b3JrQGdtYWlsLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpodXViYXR3 b3JrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPiZn dDsNCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+5Y+R6YCB5pel5pyf 77yaPC9zcGFuPjwvYj4gMjAxM+W5tDfmnIgyM+aXpSwg5pif5pyf5LqMLCAzOjAzIOS4iuWNiDxi cj4NCjxiPjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+5Li76aKYOjwvc3Bhbj48L2I+ IFJlOiBbbXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5l YXIgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPGJyPg0KPC9m b250PjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0KSGkgRXJpYyw8 YnI+DQo8YnI+DQpZb3Ugd3JvdGU6PGJyPg0KJmd0O0VPIzxicj4NCiZndDtJJ20gbm90IHN1cmUg d2hhdCB0aGF0IHdvdWxkIGxvb2sgbGlrZS4mbmJzcDsgJ0ZhaWwnIGlzIGEgcHJldHR5IGJpbmFy eSB0aGluZy4mbmJzcDsgJ0RlZ3JhZGUnIGlzIGEgY29udGludW91cyB2YXJpYWJsZSwgYXMgaXQg Y2FuIGJlIGFueXRoaW5nIGZyb20gJ2EgbGl0dGxlIGJhZCcgdG8gYSAnYSB3aG9sZSBsb3Qgb2Yg YmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuPGJyPg0KPGJyPg0KSSB0aGluayB0aGlzIG1heSBiZSBh IGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgaW4gYXNzdW1wdGlvbnMuJm5ic3A7IFdoaWxlIGl0IGlz IGNlcnRhaW5seSB0cnVlIHRoYXQgZGVncmFkYXRpb24gb2YgYSBzaWduYWwgaXMgYSBjb250aW51 b3VzIHZhcmlhYmxlLCBpbiB0aGUgY29udGV4dCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZyBpbiB0 aGUgdHJhbnNwb3J0IG5ldHdvcmssIHRoZXJlIGlzIGEgcGFydGljdWxhciB2YWx1ZSBvZiB0aGF0 IGNvbnRpbnVvdXMgdmFyaWFibGUNCiB0aGF0IGRlZmluZXMgdGhlIHRocmVzaG9sZCBhdCB3aGlj aCB0aGUgQm9vbGVhbiB2YXJpYWJsZSAmcXVvdDtzaWduYWwgZGVncmFkZSAoU0QpJnF1b3Q7IGJl Y29tZXMgdHJ1ZS4mbmJzcDsgSXQgaXMgZm9yIHRoaXMgcmVhc29uIHRoYXQgSmVvbmctZG9uZyBh bmQgb3RoZXJzIGFyZSBzdWdnZXN0aW5nIHRoYXQgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGlu Y29ycG9yYXRlIHRoZSBiZWhhdmlvciBvZiB0aGUgU0Qgc3RhdGUgaW50byB0aGUgUFNDIGRlZmlu aXRpb24gd2l0aG91dA0KIG5lZWRpbmcgdG8gaGF2ZSBhIHByZWNpc2UgZGVmaW5pdGlvbiBvZiB0 aGUgbWVjaGFuaXNtIGZvciBtZWFzdXJpbmcgdGhlIGRlZ3JhZGF0aW9uIG9mIGEgc2lnbmFsLiZu YnNwOyBXaGF0ZXZlciB0aGUgbWVjaGFuaXNtIGlzLCBpdCB3aWxsIGJlIGNvbnZlcnRlZCB0byB0 aGUgYmluYXJ5IFNEIGluZGljYXRpb24uPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClRv bTxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1w bHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIE9mIEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpPGJyPg0KU2VudDogTW9uZGF5LCBK dWx5IDIyLCAyMDEzIDg6MzYgQU08YnI+DQpUbzogUnlvbywgSmVvbmctZG9uZzsgRCdBbGVzc2Fu ZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4NCm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IEh1dWIgaGVsdm9vcnQg KDxhIGhyZWY9Im1haWx0bzpodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tIiB0YXJnZXQ9Il9i bGFuayI+aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTwvYT4pOw0KPGEgaHJlZj0ibWFpbHRv Omh1dWJhdHdvcmtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHV1YmF0d29ya0BnbWFpbC5j b208L2E+PGJyPg0KU3ViamVjdDogUmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWdu aW5nIE1QTFMtVFAgUFNDIGxpbmVhciBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRyYW5zcG9ydCBy ZXF1aXJlbWVudHM8YnI+DQo8YnI+DQpIaSBKZW9uZy1kb25nLDxicj4NCjxicj4NCiZuYnNwOyBU aGFua3MgZm9yIHRoZSByZXBseS4mbmJzcDsgUGxlYXNlIHNlZSBpbmxpbmUgd2l0aCBFTyMuPGJy Pg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog UnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUua3Ii IHRhcmdldD0iX2JsYW5rIj5yeW9vQGV0cmkucmUua3I8L2E+XTxicj4NCiZndDsgU2VudDogTW9u ZGF5LCBKdWx5IDIyLCAyMDEzIDQ6MTUgQU08YnI+DQomZ3Q7IFRvOiBFcmljIE9zYm9ybmUgKGVv c2Jvcm5lKTsgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzs8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IENjOiBIdXViIGhlbHZvb3J0ICg8YSBocmVmPSJtYWlsdG86aHV1Yi52YW4u aGVsdm9vcnRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh1dWIudmFuLmhlbHZvb3J0QGh1 YXdlaS5jb208L2E+KTsNCjxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPjxicj4NCiZndDsgU3ViamVjdDog UkU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVh cjxicj4NCiZndDsgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRz PGJyPg0KJmd0Ozxicj4NCiZndDsgSGksIEVyaWMuPGJyPg0KJmd0Ozxicj4NCiZndDsgTGV0IG1l IGFuc3dlciB5b3VyIDJuZCBxdWVzdGlvbiBvbiBTRC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTRCBk ZXRlY3Rpb24gbWV0aG9kcyBkZWZpbmVkIG9yIHByb3Bvc2VkIGZvciBwYWNrZXQgdHJhbnNwb3J0 IG5ldHdvcmtzPGJyPg0KJmd0OyBjYW4gYmUgc3VtbWFyaXplZCBhcyBmb2xsb3dzOjxicj4NCiZn dDsgLSBCeSBPQU0gcGVyZm9ybWFuY2UgbW9uaXRvcmluZyB0b29sOjxicj4NCiZndDsmbmJzcDsg U0QgaXMgcmFpc2VkIGlmIHBhY2tldCBsb3NzIHJhdGlvIGV4Y2VlZHMgYSB0aHJlc2hvbGQgZHVy aW5nIGE8YnI+DQomZ3Q7IG1lYXN1cmVtZW50IHBlcmlvZC48YnI+DQomZ3Q7Jm5ic3A7IFRocmVz aG9sZCB2YWx1ZSBhbmQgbWVhc3VyZW1lbnQgcGVyaW9kIGFyZSBjb25maWd1cmVkIGJ5IGFuIG5l dHdvcms8YnI+DQomZ3Q7IG9wZXJhdG9yLjxicj4NCiZndDsmbmJzcDsgVGhpcyBkZXRlY3Rpb24g bWV0aG9kIGlzIGFscmVhZHkgZGVmaW5lZCBpbiBJVFUtVCBHLjgwMjEgKEV0aGVybmV0PGJyPg0K Jmd0OyBlcXVpcG1lbnQgc3BlYy4pPGJyPg0KPGJyPg0KPGJyPg0KRU8jJm5ic3A7IFdoZXJlPyZu YnNwOyBJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0aGVyZSwgSSdtIGp1c3QgaGF2 aW5nIGEgaGFyZCB0aW1lIGZpbmRpbmcgaXQuJm5ic3A7IEEgc2VhcmNoIGZvciBFVEhfQ0lfU1NE IGRvZXNuJ3QgeWllbGQgbXVjaC4mbmJzcDsgSWYgSSBsb29rIGZvciAnc2lnbmFsIGRlZ3JhZGUn IEkgc2VlIHAuIDEzMSB3aGljaCBzYXlzIHRoYXQgdGhlIGFsZ29yaXRobSBpcyBkZWZpbmVkIGlu IEcuODAzMS4mbmJzcDsgRy44MDMxIHNheXMgJyBIb3cgdGhlc2UNCiBkZWZlY3RzIGFyZSBkZXRl Y3RlZCBpcyB0aGUgc3ViamVjdCBvZiB0aGUgZXF1aXBtZW50IFJlY29tbWVuZGF0aW9ucycuJm5i c3A7IEknbSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlrZSAmcXVvdDtTaWduYWwgRGVncmFkZSBp cyBkZWZpbmVkIGFzICRmb28gcGFja2V0IGxvc3Mgb3IgQ1JDIGZhaWx1cmUgb3ZlciAkYmFyIHRp bWUmcXVvdDsuLi4ud2hhdCBoYXZlIEkgbWlzc2VkPzxicj4NCjxicj4NCjxicj4NCiZndDsmbmJz cDsgYW5kIHRoZSBlcXVpcG1lbnQgc3BlYyBmb3IgTVBMUy1UUCBjYW4gZWFzaWx5IGZvbGxvdyB0 aGUgc2FtZTxicj4NCiZndDsgZGVmaW5pdGlvbi48YnI+DQomZ3Q7IC0gQnkgc2VydmVyIGxheWVy IGluZGljYXRpb246PGJyPg0KJmd0OyZuYnNwOyBTRCBpcyByYWlzZWQgaWYgYSBzZXJ2ZXIgbGF5 ZXIgYmVsb3cgTVBMUy1UUCByZXBvcnRzIFNEIGNvbmRpdGlvbiBvbjxicj4NCiZndDsgaXRzIG93 biBsYXllci48YnI+DQomZ3Q7IC0gQnkgQ0NNIHBhY2tldCBjb3VudGluZzo8YnI+DQomZ3Q7Jm5i c3A7IFNEIGlzIHJhaXNlZCBpZiB0aGUgbG9zcyByYXRpbyBvZiBDQ00gcGFja2V0cyBleGNlZWRz IGEgdGhyZXNob2xkPGJyPg0KJmd0OyBkdXJpbmcgYSBtZWFzdXJlbWVudCBwZXJpb2QuPGJyPg0K Jmd0Ozxicj4NCiZndDsgUmVnYXJkbGVzcyBvZiBob3cgdG8gZGV0ZWN0IFNELCBhbnkgcHJvdGVj dGlvbiBzd2l0Y2hpbmcgZG9jdW1lbnRzPGJyPg0KJmd0OyBzaG91bGQgZGVzY3JpYmUgdGhlIHBy b3RlY3Rpb24gc3dpdGNoaW5nIG9wZXJhdGlvbiBvbmNlIHN1Y2ggYSBTRCBpczxicj4NCiZndDsg ZGVjbGFyZWQuPGJyPg0KJmd0Ozxicj4NCi4uLjxicj4NCiZndDsgUmVnYXJkaW5nIHRoZSBtdWx0 aXBsZSBsZXZlbHMgb2YgU0Q6PGJyPg0KJmd0OyBJdCBpcyBjZXJ0YWlubHkgcG9zc2libGUgdG8g ZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC48YnI+DQomZ3Q7IEJ1dCwgYXMgZmFyIGFzIHRo ZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjb25jZXJuZWQsIGl0IGp1c3QgbmVlZHMgdG88YnI+ DQomZ3Q7IGtub3cgaWYgU0QgaXMgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJv Y2VzcyBvciBub3QuPGJyPg0KJmd0OyBJdCB3b3VsZCBiZSBhIG5ldHdvcmsgb3BlcmF0b3IncyBj aG9pY2UgYXQgd2hhdCBsZXZlbCBvZiBTRCBoZSB3YW50czxicj4NCiZndDsgaGlzIG5ldHdvcmsg cHJvdGVjdGlvbiB0byBzd2l0Y2hvdmVyLjxicj4NCiZndDsgSW4gb3RoZXIgd29yZHMsIHdoYXQg dHJpZ2dlcnMgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgU0Qgb3Igbm8gU0QuIEl0PGJyPg0KJmd0 OyBpcyB5ZXMgb3Igbm8gZGVjaXNpb24uPGJyPg0KPGJyPg0KPGJyPg0KRU8jJm5ic3A7IEkgYW0g bm90IGF3YXJlIG9mIGFueSBkb2N1bWVudCB3aGljaCBzdWdnZXN0cyB0aGF0IGEgc2VydmVyIGxh eWVyIFNEIHNob3VsZCBiZSB0cmVhdGVkIGFzIGEgY2xpZW50IGxheWVyIFNELiZuYnNwOyBJbiB0 aGUgSVAgd29ybGQsIGlmIHdlIGhhdmUgU0Qgb24gYSB0cmFuc3BvcnQgaW50ZXJmYWNlIHRoYXQg aXMgZ2VuZXJhbGx5IHVzZWQgdG8gYnJpbmcgdGhlIGludGVyZmFjZSBkb3duIChpLmUuIFNGKS4m bmJzcDsgVGhpcyBpcyB0aGUgc29ydCBvZiB0aGluZw0KIEknZCBsaWtlIHRvIHNlZSBpbiBtb3Jl IGRldGFpbCwgYXMgU0QgaW4gdGhlIHBhY2tldCB3b3JsZCBpcyBhIG5ldyBjb25jZXB0IGFuZCB3 ZSBjYW4ndCBqdXN0IGFzc3VtZSB0aGF0IGl0IHdpbGwgd29yayB0aGUgc2FtZSBldmVyeXdoZXJl IGJlY2F1c2Ugd2UgZGVmaW5lIHN0YXRlIG1hY2hpbmUgcG9pbnRzIGZvciBpdC48YnI+DQo8YnI+ DQpUaGUgcG9pbnQgYWJvdXQgQ0NNIGlzIGEgZ29vZCBvbmUuJm5ic3A7IExldCdzIHNheSB3ZSBj b21lIHVwIHdpdGggYSBjbGV2ZXIgU0QgbWVjaGFuaXNtIHdpdGggdHdvIHRocmVzaG9sZHMsIGNh bGwgdGhlbSBtYWpvciBhbmQgbWlub3IuJm5ic3A7IEZvciBkaXNjdXNzaW9uIHB1cnBvc2VzIHRo ZXkgY291bGQgYmUgc2ltcGxlIGVycm9yIHJhdGlvcywgZS5nLiAxOjEwXjYgYW5kIDE6MTBeOS4m bmJzcDsgQnV0IHRoZXkgY291bGQgYmUgbW9yZSBwb3dlcmZ1bCB0aGFuIHRoYXQNCiAoZmxvdyB0 eXBlLCBmbG93IGxlbmd0aCwgZXJyb3IgYnVyc3Qgc2l6ZSwgZXRjKS48YnI+DQo8YnI+DQpJZiB3 ZSB3YW50IHRvIGhhdmUgU0QtTWFqb3IgYW5kIFNELU1pbm9yIGlucHV0cyBhcyBzZXBhcmF0ZSB0 cmlnZ2VycyBmb3IgUFNDLCB3ZSBtYXkgd2FudCB0aGVtIGF0IGRpZmZlcmVudCBwb2ludHMuJm5i c3A7IFBlcmhhcHMmbmJzcDsgKGxlYXZpbmcgb3V0IHRoZSBXb3JraW5nIHBhdGggZm9yIGVhc2Ug b2YgcmVhZGluZyk8YnI+DQo8YnI+DQpMTzxicj4NCkZTPGJyPg0KU0YtUDxicj4NClNELVAtTWFq b3I8YnI+DQpNUzxicj4NClNELVAtTWlub3I8YnI+DQo8YnI+DQo8YnI+DQpUaGlzIHNlZW1zIGxp a2UgYSBwZXJmZWN0bHkgcmVhc29uYWJsZSB0aGluZyB0byB3YW50Ljxicj4NCjxicj4NCjxicj4N CkV2ZW4gaWYgd2UgZG9uJ3QgaGF2ZSBtdWx0aS10aWVyIFNELCBldmVuIHRoZSBzaW5nbGUtdGll ciBTRCBuZWVkcyB0byBiZSBkZWZpbmVkIGJlZm9yZSB3ZSBjYW4gZGVjaWRlIGhvdyB0byByZXNw b25kIHRvIGl0Ljxicj4NCjxicj4NCiZndDsgVGhlIHByb3Bvc2VkIGRyYWZ0IGNvdmVycyBTRC10 cmlnZ2VyZWQgcHJvdGVjdGlvbiBubyBtYXR0ZXIgd2hhdCBraW5kczxicj4NCiZndDsgb2YgU0Qg ZGV0ZWN0aW9uIG1ldGhvZHMgYXJlIHVzZWQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IFNGIGNhbiBhbHNvIGJlIHZpZXdlZCBhcyBoYXZpbmcgbXVsdGlwbGUgbGV2ZWxzIG9mIFNGIGFz IHRoZSBuZXR3b3JrPGJyPg0KJmd0OyBvcGVyYXRvciBjYW4gYWxzbyBtYWtlIGEgY2hvaWNlIG9u IHRoZSBwZXJpb2QvaW50ZXJ2YWwgb2YgQ0NNIG1lc3NhZ2VzLjxicj4NCjxicj4NCjxicj4NCkVP Izxicj4NCkknbSBub3Qgc3VyZSB3aGF0IHRoYXQgd291bGQgbG9vayBsaWtlLiZuYnNwOyAnRmFp bCcgaXMgYSBwcmV0dHkgYmluYXJ5IHRoaW5nLiZuYnNwOyAnRGVncmFkZScgaXMgYSBjb250aW51 b3VzIHZhcmlhYmxlLCBhcyBpdCBjYW4gYmUgYW55dGhpbmcgZnJvbSAnYSBsaXR0bGUgYmFkJyB0 byBhICdhIHdob2xlIGxvdCBvZiBiYWQgYnV0IG5vdCBxdWl0ZSBmYWlsJy48YnI+DQo8YnI+DQom Z3Q7IElmIENDTSBpcyBkaXNhYmxlZCwgQUlTIGZyb20gYSBzZXJ2ZXIgbGF5ZXIgY2FuIGJlIHVz ZWQgYXMgYSB0cmlnZ2VyPGJyPg0KJmd0OyBmb3IgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIFNvIGFu ZCBzbyBmb3J0aC48YnI+DQo8YnI+DQpFTyMmbmJzcDsgQUlTIGZyb20gdGhlIHNlcnZlciBsYXll ciBvbmx5IGdldHMgeW91IFNEIGZyb20gdGhlIGZpcnN0IGhvcCBvZiB0aGUgdW5kZXJseWluZyBz ZXJ2ZXIgcGF0aC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQplcmljPGJyPg0KPGJyPg0K Jmd0OyBIb3dldmVyLCBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZp bmUgaG93IHRvIGRldGVjdDxicj4NCiZndDsgU0YgaW4gYW55d2hlcmUuPGJyPg0KJmd0OyBTaW1p bGFyeSwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGhvdyBt YW51YWw8YnI+DQomZ3Q7IHN3aXRjaCBhbmQgZm9yY2VkIHN3aXRjaCBjb21tYW5kcyBhcmUgaW5p dGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW08YnI+DQomZ3Q7IGFuZCBzaWduYWxlZCB0byBw cm90ZWN0aW9uIHN3aXRjaGluZyBwcm9jZXNzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFnYWluLCBp biBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlvbiBjYW4gYWNjb21tb2RhdGUg YW55PGJyPg0KJmd0OyBTRCBkZXRlY3Rpb24gbWV0aG9kcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBC ZXN0IHJlZ2FyZHMsPGJyPg0KJmd0Ozxicj4NCiZndDsgSmVvbmctZG9uZzxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9t IDogJnF1b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzplb3Nib3JuZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5lb3Nib3JuZUBjaXNjby5jb208 L2E+Jmd0OyBTZW50IDo8YnI+DQomZ3Q7IDIwMTMtMDctMjAgMDI6NDg6MjggKCAmIzQzOzA5OjAw ICkgVG8gOiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvPGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdCIgdGFy Z2V0PSJfYmxhbmsiPmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdDwvYT4m Z3Q7LA0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxz QGlldGYub3JnPC9hPjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7IENjIDogSHV1YiBoZWx2b29y dCAoPGEgaHJlZj0ibWFpbHRvOmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20iIHRhcmdldD0i X2JsYW5rIj5odXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPC9hPik8YnI+DQomZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb208L2E+Jmd0OywNCjxhIGhyZWY9Im1haWx0 bzpodXViYXR3b3JrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh1dWJhdHdvcmtAZ21haWwu Y29tPC9hPjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPiZndDsgU3ViamVjdCA6 IFJlOiBbbXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvcjxicj4NCiZndDsgYWxpZ25pbmcgTVBMUy1U UCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNwb3J0PGJyPg0KJmd0OyBy ZXF1aXJlbWVudHM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgQWxlc3NhbmRyby08 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9yIHRoaXM7IHRoZSB0aHJlYWRzIEkgc3RhcnRl ZCBzb21lIHRpbWUgYmFjayBzZWVtIHRvIGhhdmU8YnI+DQomZ3Q7IGRpZWQgZG93biwgaXQncyBn b29kIHRvIGdldCB0aGVtIGdvaW5nIGFnYWluLjxicj4NCiZndDsgSSBoYXZlIHR3byB0aGluZ3Mg SSBuZXZlciBxdWl0ZSB1bmRlcnN0b29kLCBjYW4geW91IGNsYXJpZnkgdGhlbSBmb3IgbWU/PGJy Pg0KJmd0Ozxicj4NCiZndDsgaSkgY2FuIHlvdSBleHBsYWluIEVYRVIgYXQgYSBoaWdoZXIgbGV2 ZWw/IEknbSBub3QgbG9va2luZyBmb3IgYTxicj4NCiZndDsgZGVzY3JpcHRpb24gb2YgdGhlIHN0 YXRlIG1hY2hpbmUgY2hhbmdlcywgYW5kIEknbSBub3QgbG9va2luZyBmb3IgdGhlPGJyPg0KJmd0 OyBvbmUgbGluZSAmcXVvdDtJdCBhbGxvd3MgdGhlIEZTTSB0byBiZSB0ZXN0ZWQmcXVvdDsuIFdl IGhhdmUgYWxsIG9mIHRoYXQgaW4gdGhlPGJyPg0KJmd0OyBkcmFmdCBhbmQgaW4gdGhlIGVxdWl2 YWxlbnQgSVRVIHNwZWNzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgSSdkIGxpa2UgdG8gdW5k ZXJzdGFuZCBhYm91dCBFWEVSIGlzIHdoZXJlIGl0IGNhbWUgZnJvbS4gVGhlIElUVTxicj4NCiZn dDsgc3BlY3MgdGhhdCBkZWZpbmUgaXQgYXJlIHByZXR0eSBoYXJkIHRvIGZvbGxvdywgdGhleSBz ZWVtIHRvIGFzc3VtZTxicj4NCiZndDsgdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhF UiBpcyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQ8YnI+DQomZ3Q7IGZlZWxzIHZlcnkg bXVjaCBsaWtlIGEgbWVjaGFuaXNtIHVzZWQgdG8gY2F0Y2ggYSB2ZXJ5IHNwZWNpZmljPGJyPg0K Jmd0OyBpbXBsZW1lbnRhdGlvbiBidWcsIGJhY2sgd2hlbiB0cmFuc3BvcnQgZ2VhciB3YXMgZmFy IGxlc3MgZGVidWdnYWJsZTxicj4NCiZndDsgdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuPGJyPg0K Jmd0Ozxicj4NCiZndDsgTm8gb3RoZXIgc3RhdGUgbWFjaGluZXMgdGhhdCBJJ20gZmFtaWxpYXIg d2l0aCAoUlNWUCwgTERQLCBCR1AsIE9TUEYsPGJyPg0KJmd0OyBJU0lTKSBoYXZlIGV4cGxpY2l0 IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvciB3aGV0aGVyPGJyPg0K Jmd0OyBpdCAqd291bGQqIGJlIGJyb2tlbiBpZiBpZiB3ZXJlLCBpbiB0aGUgZnV0dXJlLCB0byBi ZSBnaXZlbiBhPGJyPg0KJmd0OyBwYXJ0aWN1bGFyIGlucHV0LiBQYXJ0IG9mIG15IHJlbHVjdGFu Y2UgdG8gZ2V0IGJlaGluZCBFWEVSIGhhcyBiZWVuPGJyPg0KJmd0OyB0aGF0IEkgZG9uJ3QgZmVl bCBjb21mb3J0YWJsZSB3aXRoIHRoZSBpZGVhIG9mIGtlZXBpbmcgYSAzMC15ZWFyLW9sZDxicj4N CiZndDsgd29ya2Fyb3VuZCBpbiBhIHByb3RvY29sLiBJcyB0aGVyZSBtb3JlIHRvIGl0IHRoYW4g dGhhdD8gSGF2ZSBJPGJyPg0KJmd0OyBtaXNyZWFkIGFuZCBtaXN1bmRlcnN0b29kIEVYRVI/IERv ZXMgbW9kZXJuIHRyYW5zcG9ydCBnZWFyIGV2ZXI8YnI+DQomZ3Q7IGFjdHVhbGx5IGRldGVjdCBh IHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3YXNuJ3Qgb2J2aW91cyB0byB0aGU8YnI+DQomZ3Q7 IG9wZXJhdG9yIHVzaW5nIG90aGVyIG1lYW5zPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBpaSkgV2h5IHRoZSBwdXNoIHRvIHN0YW5kYXJkaXplIHRoZSBTRCBzdGF0ZSBjaGFuZ2VzIGJl Zm9yZSB3ZSd2ZTxicj4NCiZndDsgZGVmaW5lZCBTRD8gSSBjZXJ0YWlubHkgYWdyZWUgdGhhdCBo YW5kbGluZyBzaWduYWwgZGVncmFkZSBpcyBhIGdvb2Q8YnI+DQomZ3Q7IGlkZWEsIGJ1dCBjb21p bmcgdXAgd2l0aCBhIGRlZmluaXRpb24gZm9yIGl0IGhhcyBiZWVuIGNoYWxsZW5naW5nLjxicj4N CiZndDsgV2hhdCBoYXBwZW5zIGlmIHdlIGNoYW5nZSB0aGUgRlNNIHRvIGhhbmRsZSBpdCwgdGhl biBjb21lIHVwIHdpdGg8YnI+DQomZ3Q7IHNvbWV0aGluZyBtb3JlIHNvcGhpc3RpY2F0ZWQgKHNh eSwgbXVsdGlwbGUgbGV2ZWxzIG9mIFNEKSB0aGF0IGRvZXNuJ3Q8YnI+DQomZ3Q7IHF1aXRlIGZp dCB3aXRoIHRoZSBGU00gY2hhbmdlcz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IHRoYW5rcyE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgZXJpYzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IDxhIGhyZWY9 Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFs Zjxicj4NCiZndDsgT2Y8YnI+DQomZ3Q7ICZndDsgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2Vy YXJkbzxicj4NCiZndDsgJmd0OyBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgMzoyMyBQ TTxicj4NCiZndDsgJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyBDYzogSHV1YiBoZWx2 b29ydCAoPGEgaHJlZj0ibWFpbHRvOmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20iIHRhcmdl dD0iX2JsYW5rIj5odXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPC9hPik7PGJyPg0KJmd0OyAm Z3Q7IDxhIGhyZWY9Im1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPjxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBbbXBsc10g cHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXI8YnI+DQomZ3Q7 ICZndDsgcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IERlYXIgYWxsLDxicj4NCiZndDsgJmd0OyB3ZSB3b3Vs ZCBsaWtlIHNvY2lhbGl6aW5nIHRoZSBoZXJlYmVsb3cgZHJhZnRzIHRoYXQgd2VyZSBzdWJtaXR0 ZWQ8YnI+DQomZ3Q7IHNvbWU8YnI+DQomZ3Q7ICZndDsgbW9udGhzIGFnbyB3aXRoIHRoZSBhaW0g dG8gYWxpZ24gUFNDIHByb3RvY29sIChSRkMgNjM3OCkgdG8gSVRVLVQ8YnI+DQomZ3Q7ICZndDsg dHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMg YWJvdXQgdGhlPGJyPg0KJmd0OyAmZ3Q7IHByb3Bvc2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91 cnMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1w cmlvcml0eS0wMDxicj4NCiZndDsgJmd0OyBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVy dGl2ZS0wMDxicj4NCiZndDsgJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QtMDA8YnI+DQom Z3Q7ICZndDsgZHJhZnQtZGotbXBscy10cC1leGVyLXBzYy0wMSAvIGRyYWZ0LW9zYm9ybmUtbXBs cy1wc2MtYWxpdmUtMDA8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGFib3ZlIGRy YWZ0cyBjb3ZlciBtb3N0IG9mIGl0ZW1zIGhpZ2hsaWdodGVkIGluIElUVS1UIGxpYWlzb25zPGJy Pg0KJmd0OyBhYm91dDxicj4NCiZndDsgJmd0OyBQU0MgYW5kIHRoZXkgcHJvcG9zZSBzb2x1dGlv bnMgaW4gbGluZSB3aXRoIE1QTFMtVFAgdHJhbnNwb3J0PGJyPg0KJmd0OyAmZ3Q7IHJlcXVpcmVt ZW50cy48YnI+DQomZ3Q7ICZndDsgQSBsaXN0IG9mIG1haW4gbGlhaXNvbnMgZXhjaGFuZ2VkIGJl dHdlZW4gSVRVLVQgYW5kIElFVEYgd2l0aCB0aGU8YnI+DQomZ3Q7ICZndDsgYWltPGJyPg0KJmd0 OyB0bzxicj4NCiZndDsgJmd0OyBhbGlnbiBQU0MgYmVoYXZpb3VzIHdpdGggSVRVLVQgdHJhbnNw b3J0IHJlcXVpcmVtZW50cyBmb3IgbGluZWFyPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3Rpb24gYXJl IGdpdmVuIGJlbG93Ojxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2xpYWlzb24vMTE2Mi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2xpYWlzb24vMTE2Mi88L2E+IChKdW5lIDIwMTIpPGJyPg0KJmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjA1LyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjA1Lw0K PC9hPjxicj4NCiZndDsgJmd0OyAoT2N0b2JlciAyMDEyKTxicj4NCiZndDsgJmd0OyA8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIyOS8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIyOS8NCjwvYT48YnI+ DQomZ3Q7ICZndDsgKEphbnVhcnkgMjAxMyk8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvDQo8L2E+PGJyPg0KJmd0OyAm Z3Q7IChGZWJydWFyeSAyMDEzKTxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI1Ni8NCjwvYT48YnI+DQomZ3Q7ICZndDsgKE1h eSAyMDEzKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTb21lIGRldGFpbHMgYWJvdSB0 aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQU0MgYmVoYXZpb3VyIHdpdGg8YnI+DQomZ3Q7 ICZndDsgdHJhbnNwb3J0IHJlcXVpcmVtZW50czo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwIHByb3Bvc2VzIHN3YXBwaW5nIHRo ZSBwcmlvcml0aWVzPGJyPg0KJmd0OyAmZ3Q7IGJldHdlZW4gRlMgYW5kIFNGLVAgKHNlZSBzZWN0 aW9uIDQuMy4yIG9mIHJmYzYzNzgpLjxicj4NCiZndDsgJmd0OyBBbW9uZyB0aGUgb3RoZXJzLCBi ZWhhdmlvcnMgdGhhdCB3aWxsIGJlIGZpeGVkIHdpdGggdGhlIHByb3Bvc2VkPGJyPg0KJmd0OyB1 cGRhdGU8YnI+DQomZ3Q7ICZndDsgYXJlOjxicj4NCiZndDsgJmd0OyBVc2UgY2FzZSBBKSBBdCBm aXJzdCwgd29ya2luZyBwYXRoKFdQKSBhbmQgcHJvdGVjdGlvbiBwYXRoKFBQKSBhcmU8YnI+DQom Z3Q7ICZndDsgbm9ybWFsLiBUaGVuLCBGb3JjZWQgU3dpdGNoKEZTKSBjb21tYW5kIGlzIGlzc3Vl ZCBmb3IgbWFpbnRlbmFuY2Ugb248YnI+DQomZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyBXUCBhbmQg dGhlIHRyYWZmaWMgbW92ZXMgZnJvbSBXUCB0byBQUC4gV2hlbiBTaWduYWwgRmFpbCBvY2N1cnMg b248YnI+DQomZ3Q7ICZndDsgUFAsIHNlcnZpY2UgY2Fubm90IHJlY292ZXIgYW5kIGlzIGludGVy cnVwdGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvcjxicj4NCiZndDsgZXhhbXBsZTxicj4NCiZndDsg Jmd0OyBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4tcGx1Z2dpbmcgYSBQUCBmaWJlci48 YnI+DQomZ3Q7ICZndDsgVXNlIGNhc2UgQikgSWYgdGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFs IGZhaWwgb24gYSBwcm90ZWN0aW9uIHBhdGg8YnI+DQomZ3Q7ICZndDsgKFNGLVApLGFuZCBGUyBj b21tYW5kIGlzIGlzc3VlZCBieSBhY2NpZGVudCB0aGUgdHJhZmZpYyBvbiBXUCB3aWxsPGJyPg0K Jmd0OyBtb3ZlPGJyPg0KJmd0OyAmZ3Q7IHRvIFBQLiBUaGlzIHJlc3VsdHMgaW4gYW4gaW50ZXJy dXB0aW9uIG9mIHNlcnZpY2UgZnJvbSB3aGljaCB5b3U8YnI+DQomZ3Q7ICZndDsgd2lsbCBub3Qg YXV0b21hdGljYWxseSByZWNvdmVyLCBiZWNhdXNlIFBTQyBzaG91bGQgbm90IGhhdmUgc3dpdGNo ZWQ8YnI+DQomZ3Q7ICZndDsgdGhlIHRyYWZmaWMgZnJvbSBXUCB0byBQUC48YnI+DQomZ3Q7ICZn dDsgRGlzY3Vzc2lvbiBhYm91dCB0aGlzIGRyYWZ0IGxlZCB0byB0aGUgcHJvcG9zYWwgdG8gbW9k aWZ5IFJGQyA0NDI3PGJyPg0KJmd0OyB0aGF0PGJyPg0KJmd0OyAmZ3Q7IHdhcyAmcXVvdDt3cml0 dGVuIGNvcnJlY3RseSB0aG91Z2ggbGFja2luZyBpbiBkZXRhaWwgY2F1c2luZyBtaXMtPGJyPg0K Jmd0OyAmZ3Q7IGludGVycHJldGF0aW9uJnF1b3Q7IHRoYXQgbGVkIHRvIHRoZSBjdXJyZW50IFBT QyBzZXQgb2YgcHJpb3JpdHkgdGhhdCB0aGU8YnI+DQomZ3Q7ICZndDsgYWJvdmUgZHJhZnQgaXMg cHJvcG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBhbGlnbiB0byB0aGUgcmVxdWlyZWQ8YnI+DQom Z3Q7ICZndDsgdHJhbnNwb3J0IGJlaGF2aW9yLiBkcmFmdC1oZWx2b29ydC1jY2FtcC1mcy1wcmlv cml0eS0wMCBoYXMgYmVlbjxicj4NCiZndDsgJmd0OyBzdWJtaXR0ZWQgdG8gQ0NBTVAgZm9yIGNs YXJpZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0ZWQgdG8gTWFudWFsPGJyPg0KJmd0OyAmZ3Q7 IFN3aXRjaCBhbmQgRm9yY2VkIFN3aXRjaCBhbmQgdGhlaXIgdXNhZ2UgcmVsYXRpdmUgdG8gcHJp b3JpdGllcy48YnI+DQomZ3Q7ICZndDsgVGhlIHdheSB0aGlzIGJlaGF2aW9yIGhhcyB0byBiZSBp bmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDIGhhcyB0byBiZTxicj4NCiZndDsgJmd0OyBkaXNjdXNz ZWQuIFRoZSB0ZXh0IHByb3Bvc2VzIHRvIHJlcGxhY2UgdGhlIGN1cnJlbnQgYmVoYXZpb3Igd2l0 aDxicj4NCiZndDsgJmd0OyB0aGUgbmV3IG9uZS4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHBy b2NlZGUgaW4gdGhhdCB3YXkgdGhpcyBjYW48YnI+DQomZ3Q7ICZndDsgYnJpbmc8YnI+DQomZ3Q7 IHRvPGJyPg0KJmd0OyAmZ3Q7IGEgc2ltcGxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIG9wZXJhdGUg dGhlIHByb3RvY29sLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9u LXJldmVydGl2ZS0wMCBjb250YWlucyB0aGUgdXBkYXRlcyB0bzxicj4NCiZndDsgJmd0OyBSRkM2 Mzc4IHRvIGNoYW5nZSBub24tcmV2ZXJ0aXZlIG9wZXJhdGlvbnMgdG8gYmVoYXZlcyBpbiB0aGUg c2FtZTxicj4NCiZndDsgJmd0OyB3YXkgaXJyZXNwZWN0aXZlbHkgb2YgdGhlIHRyaWdnZXIgb2Yg cHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGZhdWx0IG9yPGJyPg0KJmd0OyBvcGVyYXRvcjxicj4NCiZn dDsgJmd0OyBjb21tYW5kIEZTLCBNUykuIENvbnNlcXVlbnRseSBhbiBvcGVyYXRvciBjb21tYW5k LCBNYW51YWwgU3dpdGNoIHRvPGJyPg0KJmd0OyAmZ3Q7IFdvcmtpbmcgKE1TLVcpIGEuay5hICZx dW90O01hbnVhbCBzd2l0Y2gtb3ZlciBmb3IgcmVjb3ZlcnkgTFNQL3NwYW4mcXVvdDsgaXM8YnI+ DQomZ3Q7IGFsc288YnI+DQomZ3Q7ICZndDsgYWRkZWQgdG8gZW5hYmxlIHRoaXMgYmVoYXZpb3Iu IEZyb20gYW4gb3BlcmF0aW9uYWwgcG9pbnQgb2YgdmlldywgTVM8YnI+DQomZ3Q7IHRvPGJyPg0K Jmd0OyAmZ3Q7IHdvcmtpbmcgcGF0aCBoYXMgYWxzbyB0byBiZSBzdXBwb3J0ZWQgdG8gYmUgYWJs ZSB0byBpbml0aWFsbHkgYWxpZ248YnI+DQomZ3Q7ICZndDsgYXQgYm90aCBzaWRlcyBpbiBjYXNl IG9mIG5vbi1yZXZlcnRpdmUgc3dpdGNoaW5nIG1vZGUuIE1TIHRvIHdvcmtpbmc8YnI+DQomZ3Q7 ICZndDsgcGF0aCBpcyBkZWZpbmVkIGluIFJGQyA1NjU0LCByZXF1aXJlbWVudCA4My48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIHByb3Bvc2VkIE1TLVcgY29tbWFuZCBpcyBvZiBl cXVhbCBwcmlvcml0eSB0byB0aGUgZXhpc3RpbmcgTVMtUDxicj4NCiZndDsgJmd0OyBjb21tYW5k LCBhbmQgdGhlcmUgaXMgdGV4dCB0byBoYW5kbGUgdGhlIHNpbXVsdGFuZW91cyBvciBzZXF1ZW50 aWFsPGJyPg0KJmd0OyAmZ3Q7IG9jY3VycmVuY2Ugb2YgdHdvIGVxdWFsLXByaW9yaXR5IGNvbW1h bmRzLiBUaGlzIGJlaGF2aW9yLCBhbHJlYWR5PGJyPg0KJmd0OyAmZ3Q7IGFkb3B0ZWQgaW4gb3Ro ZXIgdHJhbnNwb3J0IG5ldHdvcmsgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdG9jb2wsPGJyPg0K Jmd0OyAmZ3Q7IGNhbjxicj4NCiZndDsgYmU8YnI+DQomZ3Q7ICZndDsgdXNlZCBmb3Igb3RoZXIg YWRkaXRpb24gdG8gdGhlIHByb3RvY29sIGluIHRoZSBmdXR1cmUuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7 IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMCBwcm92aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQ U0Mgc3RhdGU8YnI+DQomZ3Q7ICZndDsgbWFjaGluZSB0byBoYW5kbGUgU2lnbmFsIERlZ3JhZGUg KFNEKS4gSXQgZG9lcyBub3QgZGVmaW5lIFNEIG9yPGJyPg0KJmd0OyBwcm92aWRlPGJyPg0KJmd0 OyAmZ3Q7IHNjb3BlIGFyb3VuZCB3aGVyZSBvciBob3cgU0QgbWF5IGJlIHVzZWQgc2ltaWxhcmx5 IGFzIGl0IGFscmVhZHk8YnI+DQomZ3Q7IGhhcHBlbjxicj4NCiZndDsgJmd0OyBpbiB0aGUgZHJh ZnQgaW4gaGFuZGxpbmcgb3RoZXIgZGVmZWN0cyBsaWtlIFNGIChTaWduYWwgRmFpbHVyZSkuPGJy Pg0KJmd0OyAmZ3Q7IEluIE1QTFMtVFAgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgW1JGQzYzNzJd LCBhIGZhdWx0IGNvbmRpdGlvbjxicj4NCiZndDsgJmd0OyBpbmNsdWRlcyBib3RoIFNpZ25hbCBG YWlsIChTRikgYW5kIFNpZ25hbCBEZWdyYWRlIChTRCkgdGhhdCBjYW4gYmU8YnI+DQomZ3Q7IHVz ZWQ8YnI+DQomZ3Q7ICZndDsgdG8gdHJpZ2dlciBwcm90ZWN0aW9uIHN3aXRjaGluZy48YnI+DQom Z3Q7ICZndDsgV2hpbGUgdGhlIHN0YW5kYXJkaXphdGlvbiBsYWNrIG9mIGFuIFNEIGRlZmluaXRp b24gYW5kIGRldGVjdGlvbjxicj4NCiZndDsgJmd0OyBtZWNoYW5pc21zLCB0aGUgcmVsZXZhbnQg YmVoYXZpb3JzIGluIHRlcm1zIG9mIHByb3RlY3Rpb24gYWN0aW9uczxicj4NCiZndDsgJmd0OyBt YXkgYWxyZWFkeSBiZSBkZWZpbmVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBkcmFmdC1kai1tcGxzLXRw LWV4ZXItcHNjLTAxIHByb3Bvc2VzIGFkZGluZyB0aGUgRVhFUi9SUiBjb21tYW5kcyB0bzxicj4N CiZndDsgJmd0OyB0ZXN0IGlmIHRoZSBBUFMgY29tbXVuaWNhdGlvbiBpcyBvcGVyYXRpbmcgY29y cmVjdGx5LiBJbiBvdGhlciB3b3Jkczxicj4NCiZndDsgJmd0OyBib3RoIEFQUyBwcm9jZXNzIGxv Z2ljIGluY2x1ZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBUFMgY2hhbm5lbCBvbjxicj4NCiZndDsg Jmd0OyBwcm90ZWN0aW9uIHBhdGgsIHdpdGhvdXQgc2VydmljZSBkaXNydXB0aW9uIGFuZCB3aXRo b3V0IGFmZmVjdGluZzxicj4NCiZndDsgJmd0OyBhbnkgcHJvdGVjdGlvbiBvcGVyYXRpb24sIHVu bGVzcyB0aGUgcHJvdGVjdGlvbiB0cmFuc3BvcnQgZW50aXR5IGlzPGJyPg0KJmd0OyAmZ3Q7IGlu PGJyPg0KJmd0OyB1c2UuPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgY29tbWFuZCBpcyBkb2N1bWVudGVk IGluIFI4NCBvZiBbUkZDNTY1NF0gYW5kIGl0IGlzIHBhcnQgb2Y8YnI+DQomZ3Q7ICZndDsgSVRV LVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cy48YnI+DQomZ3Q7ICZndDsgQW4gYWx0ZXJuYXRpdmUg cHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbiB0aGUgQXBwZW5kaXggQiBvZiBSRkM2Mzc4PGJyPg0K Jmd0OyB0aGF0PGJyPg0KJmd0OyAmZ3Q7IHV0aWxpemVzIHRoZSBMb2Nrb3V0IG9mIFByb3RlY3Rp b24gKExPKSBvciBGb3JjZWQgU3dpdGNoIChGUykgaW48YnI+DQomZ3Q7ICZndDsgY29tYmluYXRp b24gb2YgT0FNIGZ1bmN0aW9uYWxpdGllcy4gSG93ZXZlciwgaXQgaGFzIHNvbWUgZnVuY3Rpb25h bDxicj4NCiZndDsgJmd0OyBsaW1pdGF0aW9uIGFuZCBoYXMgYSBwb3RlbnRpYWwgcmlzayBvZiBs b3NpbmcgdHJhZmZpYyBhcyBhIHNpZ25hbDxicj4NCiZndDsgJmd0OyBmYWlsdXJlIG1pZ2h0IG9j Y3VyIGR1cmluZyB0aGUgZXhlcmNpc2Ugb3BlcmF0aW9uLiBJbiB0aGF0IGNhc2UsIExPPGJyPg0K Jmd0OyAmZ3Q7IG9yIEZTIGhhcyB0byBiZSBjYW5jZWxlZCB0byBhbGxvdyB0aGUgUFNDIHByb3Rv Y29sIHRvIHByb3ZpZGUgcHJvcGVyPGJyPg0KJmd0OyAmZ3Q7IHN3aXRjaGluZy48YnI+DQomZ3Q7 ICZndDsgQSBmdXJ0aGVyIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gZHJh ZnQtb3Nib3JuZS1tcGxzLTxicj4NCiZndDsgcHNjLTxicj4NCiZndDsgJmd0OyBhbGl2ZS0wMCB0 aGF0IGFueXdheSBzaG93IHNvbWUgZnVuY3Rpb25hbCBsaW1pdGF0aW9ucyBiZWNhdXNlIGNhbm5v dDxicj4NCiZndDsgJmd0OyB2YWxpZGF0ZSB0aGUgUFNDIHN0YXRlIG1hY2hpbmUgc3RhdHVzIGFu ZCBwcm9iYWJseSB0aGUgTG9jYWwgUmVxdWVzdDxicj4NCiZndDsgJmd0OyBsb2dpYy48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGF1dGhvcnMgZW5jb3Vy YWdlIHRoZSBJRVRGIGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFmdHMsPGJyPg0KJmd0 OyAmZ3Q7IGV2ZW50dWFsbHkgcHJvcG9zaW5nIG90aGVyIG9wdGlvbnMvbWVjaGFuaXNtcyB0aGF0 IGNhbiBzYXRpc2Z5IHRoZTxicj4NCiZndDsgc2FtZTxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVu dHMuPGJyPg0KJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgQWxlc3NhbmRy bywgSHV1YiwgSmVvbmctZG9uZywgVGFla3NpZCBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pPGJy Pg0KJmd0OyAmZ3Q7IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGU8YnI+ DQomZ3Q7IGFsbGU8YnI+DQomZ3Q7ICZndDsgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9u ZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lPGJyPg0KJmd0OyAmZ3Q7IGRlcml2YW50 ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1l bnRlPGJyPg0KJmd0OyAmZ3Q7IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVz dG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGU8YnI+DQomZ3Q7ICZndDsgY29ydGVzZW1lbnRl IHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZTxi cj4NCiZndDsgJmd0OyBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUu PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbjxicj4NCiZndDsgJmd0OyBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuPGJy Pg0KJmd0OyAmZ3Q7IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBh bnlib2R5IGVsc2UgaXM8YnI+DQomZ3Q7IHVuYXV0aG9yaXNlZC48YnI+DQomZ3Q7ICZndDsgSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l c3NhZ2U8YnI+DQomZ3Q7ICZndDsgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBz ZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyByaXNwZXR0YSBsJ2FtYmllbnRlUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJl IHF1ZXN0YSBtYWlsIHNlPGJyPg0KJmd0OyBub248YnI+DQomZ3Q7ICZndDsgw6ggbmVjZXNzYXJp by48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PGJyPg0KPGJyPg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48YnI+DQo8YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxi cj4NCjxkaXYgZGlyPSJsdHIiPlRoYW54IGFuZCBCUiwNCjxkaXY+eWFhY292PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48aT5TdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHk8 L2k+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A276807F5SMTP2etriinfo_-- From Malcolm.BETTS@zte.com.cn Wed Jul 24 08:16:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5940F11E81DD; Wed, 24 Jul 2013 08:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.55 X-Spam-Level: X-Spam-Status: No, score=-93.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTvT3DffbODZ; Wed, 24 Jul 2013 08:15:57 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79B11E80FC; Wed, 24 Jul 2013 08:15:42 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 48E7691BF0; Wed, 24 Jul 2013 23:14:24 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 43D91757092; Wed, 24 Jul 2013 23:14:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6OFEUX8095614; Wed, 24 Jul 2013 23:14:30 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local>, <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A276800CA@SMTP2.etri.info> <20ECF67871905846A80F77F8F4A275721028A440@xmb-rcd-x09.cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B0168AABF4E72@EX-NAP.tellabs-west.tellabsinc.net> <1374630376.6934.YahooMailNeo@web15606.mail.cnb.yahoo.com> To: Larry MIME-Version: 1.0 X-KeepSent: 3FCD712C:FEF4EBA7-85257BB2:005355AE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 24 Jul 2013 11:14:25 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-24 23:14:29, Serialize complete at 2013-07-24 23:14:29 Content-Type: multipart/alternative; boundary="=_alternative 0053BF9285257BB2_=" X-MAIL: mse02.zte.com.cn r6OFEUX8095614 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" , "huubatwork@gmail.com" , mpls-bounces@ietf.org Subject: Re: [mpls] =?gb2312?b?u9i4tKO6ICBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWdu?= =?gb2312?b?aW5nIE1QTFMtVFAgUFNDIGxpbmVhciBwcm90ZWN0aW9uIHByb3RvY29sIHRv?= =?gb2312?b?IHRyYW5zcG9ydCByZXF1aXJlbWVudHM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Jul 2013 15:16:01 -0000 This is a multipart message in MIME format. --=_alternative 0053BF9285257BB2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFncmVlIGZvciB0aGUgcmVhc29ucyBzdGF0ZWQgYnkgVG9tLCBKZW9uZy1k b25nIGFuZCBIYW4sIGFsc28gdGhpcyANCmFwcHJvYWNoIGFsaWducyB0aGUgYmVoYXZpb3VyIG9m IE1QTDpTLVRQIGxpbmVhciBwcm90ZWN0aW9uIHdpdGggdGhlIA0KYmVoYXZpb3VyIG9mIG90aGVy IChTREgsIE9UTiwgRXRoZXJuZXQpIGxpbmVhciBwcm90ZWN0aW9uIHN3aXRjaGluZyANCmFscmVh ZHkgZGVwbG95ZWQgaW4gdGhlIG5ldHdvcmsuICBBcyBzdGF0ZWQgaW4gc29tZSBwcmV2aW91cyBs aWFpc29uIA0Kc3RhdGVtZW50cyBmcm9tIHRoZSBJVFUgYWxpZ25tZW50IHdpdGggZXhpc3Rpbmcg QVBTIHNjaGVtZXMgaXMgYSBrZXkgDQpvYmplY3RpdmUuDQoNClJlZ2FyZHMsDQoNCk1hbGNvbG0N Cg0KDQoNCg0KTGFycnkgPGxhcnJ5bGk4ODhAeWFob28uY29tLmNuPiANClNlbnQgYnk6IG1wbHMt Ym91bmNlc0BpZXRmLm9yZw0KMjMvMDcvMjAxMyAwOTo0NiBQTQ0KUGxlYXNlIHJlc3BvbmQgdG8N CkxhcnJ5IDxsYXJyeWxpODg4QHlhaG9vLmNvbS5jbj4NCg0KDQpUbw0KIkh1YmVyLCBUaG9tYXMg Si4iIDxUb20uSHViZXJAdGVsbGFicy5jb20+LCAiRXJpYyBPc2Jvcm5lIFwoZW9zYm9ybmVcKSIg DQo8ZW9zYm9ybmVAY2lzY28uY29tPiwgIlJ5b28sIEplb25nLWRvbmciIDxyeW9vQGV0cmkucmUu a3I+LCBEJ0FsZXNzYW5kcm8gDQpBbGVzc2FuZHJvIEdlcmFyZG8gPGFsZXNzYW5kcm8uZGFsZXNz YW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4sIA0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3Jn Pg0KY2MNCiJIdXViIGhlbHZvb3J0IFwoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbVwpIiAN CjxodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPiwgImh1dWJhdHdvcmtAZ21haWwuY29tIiAN CjxodXViYXR3b3JrQGdtYWlsLmNvbT4NClN1YmplY3QNClttcGxzXSC72Li0o7ogIHByb3Bvc2Vk IGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gDQpwcm90 b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzDQoNCg0KDQoNCg0KDQpIaSBhbGwsDQoNCkkg YWdyZWUgd2l0aCBUb20gYW5kIEplb25nLWRvbmcuIFRoZXJlIGFyZSBkaWZmZXJlbnQgcmVhc29u cyB0byBjYXVzZSBTRCwgDQpidXQgdGhlIHJlc3VsdCBpcyB0aGUgdHJhbnNwb3J0IHBlcmZvcm1h bmNlIGRlZ3JhZGUgYW5kIGl0IGlzIGltcG9ydGFudCB0byANCmxldCBvcGVyYXRvcnMgc2V0IGEg dGhyZXNob2xkIHRvIHRyaWdnZXIgcHJvdGVjdGlvbiBzd2l0Y2guIER1cmluZyB0aGUgDQp0cm91 YmxlIHNob290aW5nLCBvcGVyYXRvcnMgbmVlZCB0b29scyB0byBkbyBmYXVsdCBsb2NhbGl6YXRp b24uIEFsdGhvdWdodCANCiJkZWdyYWRlIiBpcyBhIGNvbnRpbm91cyB2YXJpYWJsZSBiZWhhdmlv dXIsIGl0IGlzIGEgIjAvMSIgcHJvYmxlbSBhZnRlciANCmRlZmluaW5nIHRoZSB0aHJlc2hvbGQu DQpUaGFuayB5b3UhDQogDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpIYW4gTGksIFBoLkQgDQpDaGluYSBN b2JpbGUgUmVzZWFyY2ggSW5zdGl0dXRlDQozMiBYdWFud3VtZW4gV2VzdCBTdHJlZXQsIFhpY2hl bmcgRGlzdHJpY3QsIEJlaWppbmcgMTAwMDUzLCBDaGluYSANCkZheDogKzg2IDEwIDYzMTM1MTU5 IA0KTU9CSUxFOiAxMzUwMTA5MzM4NSANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCreivP7Iy6O6ICJIdWJl ciwgVGhvbWFzIEouIiA8VG9tLkh1YmVyQHRlbGxhYnMuY29tPg0KytW8/sjLo7ogRXJpYyBPc2Jv cm5lIChlb3Nib3JuZSkgPGVvc2Jvcm5lQGNpc2NvLmNvbT47ICJSeW9vLCBKZW9uZy1kb25nIiAN CjxyeW9vQGV0cmkucmUua3I+OyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIA0KPGFs ZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdD47ICJtcGxzQGlldGYub3JnIiA8 bXBsc0BpZXRmLm9yZz4gDQoNCrOty82juiAiSHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9v cnRAaHVhd2VpLmNvbSkiIA0KPGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20+OyAiaHV1YmF0 d29ya0BnbWFpbC5jb20iIA0KPGh1dWJhdHdvcmtAZ21haWwuY29tPiANCreiy83I1cbao7ogMjAx M8TqN9TCMjPI1Swg0MfG2rb+LCAzOjAzIMnPzucNCtb3zOI6IFJlOiBbbXBsc10gcHJvcG9zZWQg ZHJhZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXIgDQpwcm90ZWN0aW9uIHByb3Rv Y29sIHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHMNCg0KSGkgRXJpYywNCg0KWW91IHdyb3RlOg0K PkVPIw0KPkknbSBub3Qgc3VyZSB3aGF0IHRoYXQgd291bGQgbG9vayBsaWtlLiAgJ0ZhaWwnIGlz IGEgcHJldHR5IGJpbmFyeSB0aGluZy4gDQogJ0RlZ3JhZGUnIGlzIGEgY29udGludW91cyB2YXJp YWJsZSwgYXMgaXQgY2FuIGJlIGFueXRoaW5nIGZyb20gJ2EgbGl0dGxlIA0KYmFkJyB0byBhICdh IHdob2xlIGxvdCBvZiBiYWQgYnV0IG5vdCBxdWl0ZSBmYWlsJy4NCg0KSSB0aGluayB0aGlzIG1h eSBiZSBhIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgaW4gYXNzdW1wdGlvbnMuICBXaGlsZSBpdCBp cyANCmNlcnRhaW5seSB0cnVlIHRoYXQgZGVncmFkYXRpb24gb2YgYSBzaWduYWwgaXMgYSBjb250 aW51b3VzIHZhcmlhYmxlLCBpbiANCnRoZSBjb250ZXh0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5n IGluIHRoZSB0cmFuc3BvcnQgbmV0d29yaywgdGhlcmUgaXMgYSANCnBhcnRpY3VsYXIgdmFsdWUg b2YgdGhhdCBjb250aW51b3VzIHZhcmlhYmxlIHRoYXQgZGVmaW5lcyB0aGUgdGhyZXNob2xkIGF0 IA0Kd2hpY2ggdGhlIEJvb2xlYW4gdmFyaWFibGUgInNpZ25hbCBkZWdyYWRlIChTRCkiIGJlY29t ZXMgdHJ1ZS4gIEl0IGlzIGZvciANCnRoaXMgcmVhc29uIHRoYXQgSmVvbmctZG9uZyBhbmQgb3Ro ZXJzIGFyZSBzdWdnZXN0aW5nIHRoYXQgaXQgc2hvdWxkIGJlIA0KcG9zc2libGUgdG8gaW5jb3Jw b3JhdGUgdGhlIGJlaGF2aW9yIG9mIHRoZSBTRCBzdGF0ZSBpbnRvIHRoZSBQU0MgDQpkZWZpbml0 aW9uIHdpdGhvdXQgbmVlZGluZyB0byBoYXZlIGEgcHJlY2lzZSBkZWZpbml0aW9uIG9mIHRoZSBt ZWNoYW5pc20gDQpmb3IgbWVhc3VyaW5nIHRoZSBkZWdyYWRhdGlvbiBvZiBhIHNpZ25hbC4gIFdo YXRldmVyIHRoZSBtZWNoYW5pc20gaXMsIGl0IA0Kd2lsbCBiZSBjb252ZXJ0ZWQgdG8gdGhlIGJp bmFyeSBTRCBpbmRpY2F0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpUb20NCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpFcmljIE9zYm9ybmUgKGVvc2Jvcm5l KQ0KU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDg6MzYgQU0NClRvOiBSeW9vLCBKZW9uZy1k b25nOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBtcGxzQGlldGYub3JnDQpDYzog SHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSk7IGh1dWJhdHdvcmtA Z21haWwuY29tDQpTdWJqZWN0OiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p bmcgTVBMUy1UUCBQU0MgbGluZWFyIA0KcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQg cmVxdWlyZW1lbnRzDQoNCkhpIEplb25nLWRvbmcsDQoNCiAgVGhhbmtzIGZvciB0aGUgcmVwbHku ICBQbGVhc2Ugc2VlIGlubGluZSB3aXRoIEVPIy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBSeW9vLCBKZW9uZy1kb25nIFttYWlsdG86cnlvb0BldHJpLnJlLmtyXQ0K PiBTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgNDoxNSBBTQ0KPiBUbzogRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSk7IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87DQo+IG1wbHNAaWV0 Zi5vcmcNCj4gQ2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20p OyBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiBTdWJqZWN0OiBSRTogW21wbHNdIHByb3Bvc2VkIGRy YWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyDQo+IHByb3RlY3Rpb24gcHJvdG9j b2wgdG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50cw0KPg0KPiBIaSwgRXJpYy4NCj4NCj4gTGV0IG1l IGFuc3dlciB5b3VyIDJuZCBxdWVzdGlvbiBvbiBTRC4NCj4NCj4gU0QgZGV0ZWN0aW9uIG1ldGhv ZHMgZGVmaW5lZCBvciBwcm9wb3NlZCBmb3IgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3Jrcw0KPiBj YW4gYmUgc3VtbWFyaXplZCBhcyBmb2xsb3dzOg0KPiAtIEJ5IE9BTSBwZXJmb3JtYW5jZSBtb25p dG9yaW5nIHRvb2w6DQo+ICBTRCBpcyByYWlzZWQgaWYgcGFja2V0IGxvc3MgcmF0aW8gZXhjZWVk cyBhIHRocmVzaG9sZCBkdXJpbmcgYQ0KPiBtZWFzdXJlbWVudCBwZXJpb2QuDQo+ICBUaHJlc2hv bGQgdmFsdWUgYW5kIG1lYXN1cmVtZW50IHBlcmlvZCBhcmUgY29uZmlndXJlZCBieSBhbiBuZXR3 b3JrDQo+IG9wZXJhdG9yLg0KPiAgVGhpcyBkZXRlY3Rpb24gbWV0aG9kIGlzIGFscmVhZHkgZGVm aW5lZCBpbiBJVFUtVCBHLjgwMjEgKEV0aGVybmV0DQo+IGVxdWlwbWVudCBzcGVjLikNCg0KDQpF TyMgIFdoZXJlPyAgSSdtIG5vdCBhcmd1aW5nIHRoYXQgaXQncyBub3QgaW4gdGhlcmUsIEknbSBq dXN0IGhhdmluZyBhIA0KaGFyZCB0aW1lIGZpbmRpbmcgaXQuICBBIHNlYXJjaCBmb3IgRVRIX0NJ X1NTRCBkb2Vzbid0IHlpZWxkIG11Y2guICBJZiBJIA0KbG9vayBmb3IgJ3NpZ25hbCBkZWdyYWRl JyBJIHNlZSBwLiAxMzEgd2hpY2ggc2F5cyB0aGF0IHRoZSBhbGdvcml0aG0gaXMgDQpkZWZpbmVk IGluIEcuODAzMS4gIEcuODAzMSBzYXlzICcgSG93IHRoZXNlIGRlZmVjdHMgYXJlIGRldGVjdGVk IGlzIHRoZSANCnN1YmplY3Qgb2YgdGhlIGVxdWlwbWVudCBSZWNvbW1lbmRhdGlvbnMnLiAgSSdt IGxvb2tpbmcgZm9yIHNvbWV0aGluZyBsaWtlIA0KIlNpZ25hbCBEZWdyYWRlIGlzIGRlZmluZWQg YXMgJGZvbyBwYWNrZXQgbG9zcyBvciBDUkMgZmFpbHVyZSBvdmVyICRiYXIgDQp0aW1lIi4uLi53 aGF0IGhhdmUgSSBtaXNzZWQ/DQoNCg0KPiAgYW5kIHRoZSBlcXVpcG1lbnQgc3BlYyBmb3IgTVBM Uy1UUCBjYW4gZWFzaWx5IGZvbGxvdyB0aGUgc2FtZQ0KPiBkZWZpbml0aW9uLg0KPiAtIEJ5IHNl cnZlciBsYXllciBpbmRpY2F0aW9uOg0KPiAgU0QgaXMgcmFpc2VkIGlmIGEgc2VydmVyIGxheWVy IGJlbG93IE1QTFMtVFAgcmVwb3J0cyBTRCBjb25kaXRpb24gb24NCj4gaXRzIG93biBsYXllci4N Cj4gLSBCeSBDQ00gcGFja2V0IGNvdW50aW5nOg0KPiAgU0QgaXMgcmFpc2VkIGlmIHRoZSBsb3Nz IHJhdGlvIG9mIENDTSBwYWNrZXRzIGV4Y2VlZHMgYSB0aHJlc2hvbGQNCj4gZHVyaW5nIGEgbWVh c3VyZW1lbnQgcGVyaW9kLg0KPg0KPiBSZWdhcmRsZXNzIG9mIGhvdyB0byBkZXRlY3QgU0QsIGFu eSBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudHMNCj4gc2hvdWxkIGRlc2NyaWJlIHRoZSBw cm90ZWN0aW9uIHN3aXRjaGluZyBvcGVyYXRpb24gb25jZSBzdWNoIGEgU0QgaXMNCj4gZGVjbGFy ZWQuDQo+DQouLi4NCj4gUmVnYXJkaW5nIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgU0Q6DQo+IEl0 IGlzIGNlcnRhaW5seSBwb3NzaWJsZSB0byBkZWZpbmUgbXVsdGlwbGUgbGV2ZWxzIG9mIFNELg0K PiBCdXQsIGFzIGZhciBhcyB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgY29uY2VybmVkLCBp dCBqdXN0IG5lZWRzIHRvDQo+IGtub3cgaWYgU0QgaXMgc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBz d2l0Y2hpbmcgcHJvY2VzcyBvciBub3QuDQo+IEl0IHdvdWxkIGJlIGEgbmV0d29yayBvcGVyYXRv cidzIGNob2ljZSBhdCB3aGF0IGxldmVsIG9mIFNEIGhlIHdhbnRzDQo+IGhpcyBuZXR3b3JrIHBy b3RlY3Rpb24gdG8gc3dpdGNob3Zlci4NCj4gSW4gb3RoZXIgd29yZHMsIHdoYXQgdHJpZ2dlcnMg cHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgU0Qgb3Igbm8gU0QuIEl0DQo+IGlzIHllcyBvciBubyBk ZWNpc2lvbi4NCg0KDQpFTyMgIEkgYW0gbm90IGF3YXJlIG9mIGFueSBkb2N1bWVudCB3aGljaCBz dWdnZXN0cyB0aGF0IGEgc2VydmVyIGxheWVyIFNEIA0Kc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYSBj bGllbnQgbGF5ZXIgU0QuICBJbiB0aGUgSVAgd29ybGQsIGlmIHdlIGhhdmUgU0Qgb24gDQphIHRy YW5zcG9ydCBpbnRlcmZhY2UgdGhhdCBpcyBnZW5lcmFsbHkgdXNlZCB0byBicmluZyB0aGUgaW50 ZXJmYWNlIGRvd24gDQooaS5lLiBTRikuICBUaGlzIGlzIHRoZSBzb3J0IG9mIHRoaW5nIEknZCBs aWtlIHRvIHNlZSBpbiBtb3JlIGRldGFpbCwgYXMgDQpTRCBpbiB0aGUgcGFja2V0IHdvcmxkIGlz IGEgbmV3IGNvbmNlcHQgYW5kIHdlIGNhbid0IGp1c3QgYXNzdW1lIHRoYXQgaXQgDQp3aWxsIHdv cmsgdGhlIHNhbWUgZXZlcnl3aGVyZSBiZWNhdXNlIHdlIGRlZmluZSBzdGF0ZSBtYWNoaW5lIHBv aW50cyBmb3IgDQppdC4NCg0KVGhlIHBvaW50IGFib3V0IENDTSBpcyBhIGdvb2Qgb25lLiAgTGV0 J3Mgc2F5IHdlIGNvbWUgdXAgd2l0aCBhIGNsZXZlciBTRCANCm1lY2hhbmlzbSB3aXRoIHR3byB0 aHJlc2hvbGRzLCBjYWxsIHRoZW0gbWFqb3IgYW5kIG1pbm9yLiAgRm9yIGRpc2N1c3Npb24gDQpw dXJwb3NlcyB0aGV5IGNvdWxkIGJlIHNpbXBsZSBlcnJvciByYXRpb3MsIGUuZy4gMToxMF42IGFu ZCAxOjEwXjkuICBCdXQgDQp0aGV5IGNvdWxkIGJlIG1vcmUgcG93ZXJmdWwgdGhhbiB0aGF0IChm bG93IHR5cGUsIGZsb3cgbGVuZ3RoLCBlcnJvciBidXJzdCANCnNpemUsIGV0YykuDQoNCklmIHdl IHdhbnQgdG8gaGF2ZSBTRC1NYWpvciBhbmQgU0QtTWlub3IgaW5wdXRzIGFzIHNlcGFyYXRlIHRy aWdnZXJzIGZvciANClBTQywgd2UgbWF5IHdhbnQgdGhlbSBhdCBkaWZmZXJlbnQgcG9pbnRzLiAg UGVyaGFwcyAgKGxlYXZpbmcgb3V0IHRoZSANCldvcmtpbmcgcGF0aCBmb3IgZWFzZSBvZiByZWFk aW5nKQ0KDQpMTw0KRlMNClNGLVANClNELVAtTWFqb3INCk1TDQpTRC1QLU1pbm9yDQoNCg0KVGhp cyBzZWVtcyBsaWtlIGEgcGVyZmVjdGx5IHJlYXNvbmFibGUgdGhpbmcgdG8gd2FudC4NCg0KDQpF dmVuIGlmIHdlIGRvbid0IGhhdmUgbXVsdGktdGllciBTRCwgZXZlbiB0aGUgc2luZ2xlLXRpZXIg U0QgbmVlZHMgdG8gYmUgDQpkZWZpbmVkIGJlZm9yZSB3ZSBjYW4gZGVjaWRlIGhvdyB0byByZXNw b25kIHRvIGl0Lg0KDQo+IFRoZSBwcm9wb3NlZCBkcmFmdCBjb3ZlcnMgU0QtdHJpZ2dlcmVkIHBy b3RlY3Rpb24gbm8gbWF0dGVyIHdoYXQga2luZHMNCj4gb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMg YXJlIHVzZWQuDQo+DQo+DQo+IFNGIGNhbiBhbHNvIGJlIHZpZXdlZCBhcyBoYXZpbmcgbXVsdGlw bGUgbGV2ZWxzIG9mIFNGIGFzIHRoZSBuZXR3b3JrDQo+IG9wZXJhdG9yIGNhbiBhbHNvIG1ha2Ug YSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBvZiBDQ00gbWVzc2FnZXMuDQoNCg0KRU8j DQpJJ20gbm90IHN1cmUgd2hhdCB0aGF0IHdvdWxkIGxvb2sgbGlrZS4gICdGYWlsJyBpcyBhIHBy ZXR0eSBiaW5hcnkgdGhpbmcuIA0KJ0RlZ3JhZGUnIGlzIGEgY29udGludW91cyB2YXJpYWJsZSwg YXMgaXQgY2FuIGJlIGFueXRoaW5nIGZyb20gJ2EgbGl0dGxlIA0KYmFkJyB0byBhICdhIHdob2xl IGxvdCBvZiBiYWQgYnV0IG5vdCBxdWl0ZSBmYWlsJy4NCg0KPiBJZiBDQ00gaXMgZGlzYWJsZWQs IEFJUyBmcm9tIGEgc2VydmVyIGxheWVyIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlcg0KPiBmb3Ig cHJvdGVjdGlvbiBzd2l0Y2hpbmcuIFNvIGFuZCBzbyBmb3J0aC4NCg0KRU8jICBBSVMgZnJvbSB0 aGUgc2VydmVyIGxheWVyIG9ubHkgZ2V0cyB5b3UgU0QgZnJvbSB0aGUgZmlyc3QgaG9wIG9mIHRo ZSANCnVuZGVybHlpbmcgc2VydmVyIHBhdGguDQoNCg0KDQoNCmVyaWMNCg0KPiBIb3dldmVyLCBw cm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGRldGVj dA0KPiBTRiBpbiBhbnl3aGVyZS4NCj4gU2ltaWxhcnksIHByb3RlY3Rpb24gc3dpdGNoaW5nIGRv Y3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgbWFudWFsDQo+IHN3aXRjaCBhbmQgZm9yY2VkIHN3 aXRjaCBjb21tYW5kcyBhcmUgaW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW0NCj4gYW5k IHNpZ25hbGVkIHRvIHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb2Nlc3MuDQo+DQo+IEFnYWluLCBp biBteSBvcGluaW9uLCB0aGUgZHJhZnQgb24gU0QgcHJvdGVjdGlvbiBjYW4gYWNjb21tb2RhdGUg YW55DQo+IFNEIGRldGVjdGlvbiBtZXRob2RzLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+IEpl b25nLWRvbmcNCj4NCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4NCj4gRnJvbSA6ICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNp c2NvLmNvbT4gU2VudCA6DQo+IDIwMTMtMDctMjAgMDI6NDg6MjggKCArMDk6MDAgKSBUbyA6IEQn QWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9A dGVsZWNvbWl0YWxpYS5pdD4sIG1wbHNAaWV0Zi5vcmcNCj4gPG1wbHNAaWV0Zi5vcmc+IENjIDog SHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSkNCj4gPGh1dWIudmFu LmhlbHZvb3J0QGh1YXdlaS5jb20+LCBodXViYXR3b3JrQGdtYWlsLmNvbQ0KPiA8aHV1YmF0d29y a0BnbWFpbC5jb20+IFN1YmplY3QgOiBSZTogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3INCj4g YWxpZ25pbmcgTVBMUy1UUCBQU0MgbGluZWFyIHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNw b3J0DQo+IHJlcXVpcmVtZW50cw0KPg0KPg0KPiBIaSBBbGVzc2FuZHJvLQ0KPg0KPiBUaGFua3Mg Zm9yIHRoaXM7IHRoZSB0aHJlYWRzIEkgc3RhcnRlZCBzb21lIHRpbWUgYmFjayBzZWVtIHRvIGhh dmUNCj4gZGllZCBkb3duLCBpdCdzIGdvb2QgdG8gZ2V0IHRoZW0gZ29pbmcgYWdhaW4uDQo+IEkg aGF2ZSB0d28gdGhpbmdzIEkgbmV2ZXIgcXVpdGUgdW5kZXJzdG9vZCwgY2FuIHlvdSBjbGFyaWZ5 IHRoZW0gZm9yIG1lPw0KPg0KPiBpKSBjYW4geW91IGV4cGxhaW4gRVhFUiBhdCBhIGhpZ2hlciBs ZXZlbD8gSSdtIG5vdCBsb29raW5nIGZvciBhDQo+IGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBt YWNoaW5lIGNoYW5nZXMsIGFuZCBJJ20gbm90IGxvb2tpbmcgZm9yIHRoZQ0KPiBvbmUgbGluZSAi SXQgYWxsb3dzIHRoZSBGU00gdG8gYmUgdGVzdGVkIi4gV2UgaGF2ZSBhbGwgb2YgdGhhdCBpbiB0 aGUNCj4gZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBzcGVjcy4NCj4NCj4gV2hhdCBJ J2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9tLiBU aGUgSVRVDQo+IHNwZWNzIHRoYXQgZGVmaW5lIGl0IGFyZSBwcmV0dHkgaGFyZCB0byBmb2xsb3cs IHRoZXkgc2VlbSB0byBhc3N1bWUNCj4gdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhF UiBpcyBhbmQgd2hhdCBwcm9ibGVtIGl0IHNvbHZlcy4gSXQNCj4gZmVlbHMgdmVyeSBtdWNoIGxp a2UgYSBtZWNoYW5pc20gdXNlZCB0byBjYXRjaCBhIHZlcnkgc3BlY2lmaWMNCj4gaW1wbGVtZW50 YXRpb24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2FzIGZhciBsZXNzIGRlYnVnZ2Fi bGUNCj4gdGhhbiB3aGF0IHdlIGhhdmUgdG9kYXkuDQo+DQo+IE5vIG90aGVyIHN0YXRlIG1hY2hp bmVzIHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAsIExEUCwgQkdQLCBPU1BGLA0KPiBJU0lT KSBoYXZlIGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJv ciB3aGV0aGVyDQo+IGl0ICp3b3VsZCogYmUgYnJva2VuIGlmIGlmIHdlcmUsIGluIHRoZSBmdXR1 cmUsIHRvIGJlIGdpdmVuIGENCj4gcGFydGljdWxhciBpbnB1dC4gUGFydCBvZiBteSByZWx1Y3Rh bmNlIHRvIGdldCBiZWhpbmQgRVhFUiBoYXMgYmVlbg0KPiB0aGF0IEkgZG9uJ3QgZmVlbCBjb21m b3J0YWJsZSB3aXRoIHRoZSBpZGVhIG9mIGtlZXBpbmcgYSAzMC15ZWFyLW9sZA0KPiB3b3JrYXJv dW5kIGluIGEgcHJvdG9jb2wuIElzIHRoZXJlIG1vcmUgdG8gaXQgdGhhbiB0aGF0PyBIYXZlIEkN Cj4gbWlzcmVhZCBhbmQgbWlzdW5kZXJzdG9vZCBFWEVSPyBEb2VzIG1vZGVybiB0cmFuc3BvcnQg Z2VhciBldmVyDQo+IGFjdHVhbGx5IGRldGVjdCBhIHByb2JsZW0gdmlhIEVYRVIvUlIgdGhhdCB3 YXNuJ3Qgb2J2aW91cyB0byB0aGUNCj4gb3BlcmF0b3IgdXNpbmcgb3RoZXIgbWVhbnM/DQo+DQo+ DQo+IGlpKSBXaHkgdGhlIHB1c2ggdG8gc3RhbmRhcmRpemUgdGhlIFNEIHN0YXRlIGNoYW5nZXMg YmVmb3JlIHdlJ3ZlDQo+IGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxp bmcgc2lnbmFsIGRlZ3JhZGUgaXMgYSBnb29kDQo+IGlkZWEsIGJ1dCBjb21pbmcgdXAgd2l0aCBh IGRlZmluaXRpb24gZm9yIGl0IGhhcyBiZWVuIGNoYWxsZW5naW5nLg0KPiBXaGF0IGhhcHBlbnMg aWYgd2UgY2hhbmdlIHRoZSBGU00gdG8gaGFuZGxlIGl0LCB0aGVuIGNvbWUgdXAgd2l0aA0KPiBz b21ldGhpbmcgbW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRpcGxlIGxldmVscyBvZiBTRCkg dGhhdCBkb2Vzbid0DQo+IHF1aXRlIGZpdCB3aXRoIHRoZSBGU00gY2hhbmdlcz8NCj4NCj4NCj4N Cj4gdGhhbmtzIQ0KPg0KPg0KPg0KPg0KPg0KPiBlcmljDQo+DQo+DQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+IEQnQWxlc3NhbmRybyBB bGVzc2FuZHJvIEdlcmFyZG8NCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgMzoy MyBQTQ0KPiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gQ2M6IEh1dWIgaGVsdm9vcnQgKGh1dWIu dmFuLmhlbHZvb3J0QGh1YXdlaS5jb20pOw0KPiA+IGh1dWJhdHdvcmtAZ21haWwuY29tDQo+ID4g U3ViamVjdDogW21wbHNdIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25pbmcgTVBMUy1UUCBQU0Mg bGluZWFyDQo+ID4gcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRz DQo+ID4NCj4gPiBEZWFyIGFsbCwNCj4gPiB3ZSB3b3VsZCBsaWtlIHNvY2lhbGl6aW5nIHRoZSBo ZXJlYmVsb3cgZHJhZnRzIHRoYXQgd2VyZSBzdWJtaXR0ZWQNCj4gc29tZQ0KPiA+IG1vbnRocyBh Z28gd2l0aCB0aGUgYWltIHRvIGFsaWduIFBTQyBwcm90b2NvbCAoUkZDIDYzNzgpIHRvIElUVS1U DQo+ID4gdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgY29t bWVudHMgYWJvdXQgdGhlDQo+ID4gcHJvcG9zZWQgbWVjaGFuaXNtcyBhbmQgYmVoYXZpb3Vycy4N Cj4gPg0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMA0KPiA+IGRyYWZ0LWNk aC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwDQo+ID4gZHJhZnQtcmhkLW1wbHMtdHAtcHNj LXNkLTAwDQo+ID4gZHJhZnQtZGotbXBscy10cC1leGVyLXBzYy0wMSAvIGRyYWZ0LW9zYm9ybmUt bXBscy1wc2MtYWxpdmUtMDANCj4gPg0KPiA+IFRoZSBhYm92ZSBkcmFmdHMgY292ZXIgbW9zdCBv ZiBpdGVtcyBoaWdobGlnaHRlZCBpbiBJVFUtVCBsaWFpc29ucw0KPiBhYm91dA0KPiA+IFBTQyBh bmQgdGhleSBwcm9wb3NlIHNvbHV0aW9ucyBpbiBsaW5lIHdpdGggTVBMUy1UUCB0cmFuc3BvcnQN Cj4gPiByZXF1aXJlbWVudHMuDQo+ID4gQSBsaXN0IG9mIG1haW4gbGlhaXNvbnMgZXhjaGFuZ2Vk IGJldHdlZW4gSVRVLVQgYW5kIElFVEYgd2l0aCB0aGUNCj4gPiBhaW0NCj4gdG8NCj4gPiBhbGln biBQU0MgYmVoYXZpb3VzIHdpdGggSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBmb3IgbGlu ZWFyDQo+ID4gcHJvdGVjdGlvbiBhcmUgZ2l2ZW4gYmVsb3c6DQo+ID4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9saWFpc29uLzExNjIvIChKdW5lIDIwMTIpDQo+ID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMDUvIA0KPiA+IChPY3RvYmVyIDIwMTIpDQo+ID4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMjkvIA0KPiA+IChKYW51YXJ5 IDIwMTMpDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvIA0K PiA+IChGZWJydWFyeSAyMDEzKQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlh aXNvbi8xMjU2LyANCj4gPiAoTWF5IDIwMTMpDQo+ID4NCj4gPiBTb21lIGRldGFpbHMgYWJvdSB0 aGUgcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbiBQU0MgYmVoYXZpb3VyIHdpdGgNCj4gPiB0cmFu c3BvcnQgcmVxdWlyZW1lbnRzOg0KPiA+DQo+ID4gZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9y aXR5LTAwIHByb3Bvc2VzIHN3YXBwaW5nIHRoZSBwcmlvcml0aWVzDQo+ID4gYmV0d2VlbiBGUyBh bmQgU0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIgb2YgcmZjNjM3OCkuDQo+ID4gQW1vbmcgdGhlIG90 aGVycywgYmVoYXZpb3JzIHRoYXQgd2lsbCBiZSBmaXhlZCB3aXRoIHRoZSBwcm9wb3NlZA0KPiB1 cGRhdGUNCj4gPiBhcmU6DQo+ID4gVXNlIGNhc2UgQSkgQXQgZmlyc3QsIHdvcmtpbmcgcGF0aChX UCkgYW5kIHByb3RlY3Rpb24gcGF0aChQUCkgYXJlDQo+ID4gbm9ybWFsLiBUaGVuLCBGb3JjZWQg U3dpdGNoKEZTKSBjb21tYW5kIGlzIGlzc3VlZCBmb3IgbWFpbnRlbmFuY2Ugb24NCj4gdGhlDQo+ ID4gV1AgYW5kIHRoZSB0cmFmZmljIG1vdmVzIGZyb20gV1AgdG8gUFAuIFdoZW4gU2lnbmFsIEZh aWwgb2NjdXJzIG9uDQo+ID4gUFAsIHNlcnZpY2UgY2Fubm90IHJlY292ZXIgYW5kIGlzIGludGVy cnVwdGVkLiBUaGlzIGNvdWxkIG9jY3VyIGZvcg0KPiBleGFtcGxlDQo+ID4gYXMgYSByZXN1bHQg b2YgYWNjaWRlbnRhbGx5IHVuLXBsdWdnaW5nIGEgUFAgZmliZXIuDQo+ID4gVXNlIGNhc2UgQikg SWYgdGhlcmUgaXMgYW4gZXhpc3Rpbmcgc2lnbmFsIGZhaWwgb24gYSBwcm90ZWN0aW9uIHBhdGgN Cj4gPiAoU0YtUCksYW5kIEZTIGNvbW1hbmQgaXMgaXNzdWVkIGJ5IGFjY2lkZW50IHRoZSB0cmFm ZmljIG9uIFdQIHdpbGwNCj4gbW92ZQ0KPiA+IHRvIFBQLiBUaGlzIHJlc3VsdHMgaW4gYW4gaW50 ZXJydXB0aW9uIG9mIHNlcnZpY2UgZnJvbSB3aGljaCB5b3UNCj4gPiB3aWxsIG5vdCBhdXRvbWF0 aWNhbGx5IHJlY292ZXIsIGJlY2F1c2UgUFNDIHNob3VsZCBub3QgaGF2ZSBzd2l0Y2hlZA0KPiA+ IHRoZSB0cmFmZmljIGZyb20gV1AgdG8gUFAuDQo+ID4gRGlzY3Vzc2lvbiBhYm91dCB0aGlzIGRy YWZ0IGxlZCB0byB0aGUgcHJvcG9zYWwgdG8gbW9kaWZ5IFJGQyA0NDI3DQo+IHRoYXQNCj4gPiB3 YXMgIndyaXR0ZW4gY29ycmVjdGx5IHRob3VnaCBsYWNraW5nIGluIGRldGFpbCBjYXVzaW5nIG1p cy0NCj4gPiBpbnRlcnByZXRhdGlvbiIgdGhhdCBsZWQgdG8gdGhlIGN1cnJlbnQgUFNDIHNldCBv ZiBwcmlvcml0eSB0aGF0IHRoZQ0KPiA+IGFib3ZlIGRyYWZ0IGlzIHByb3Bvc2luZyB0byBtb2Rp ZmllZCBhbmQgdG8gYWxpZ24gdG8gdGhlIHJlcXVpcmVkDQo+ID4gdHJhbnNwb3J0IGJlaGF2aW9y LiBkcmFmdC1oZWx2b29ydC1jY2FtcC1mcy1wcmlvcml0eS0wMCBoYXMgYmVlbg0KPiA+IHN1Ym1p dHRlZCB0byBDQ0FNUCBmb3IgY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byBN YW51YWwNCj4gPiBTd2l0Y2ggYW5kIEZvcmNlZCBTd2l0Y2ggYW5kIHRoZWlyIHVzYWdlIHJlbGF0 aXZlIHRvIHByaW9yaXRpZXMuDQo+ID4gVGhlIHdheSB0aGlzIGJlaGF2aW9yIGhhcyB0byBiZSBp bmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDIGhhcyB0byBiZQ0KPiA+IGRpc2N1c3NlZC4gVGhlIHRl eHQgcHJvcG9zZXMgdG8gcmVwbGFjZSB0aGUgY3VycmVudCBiZWhhdmlvciB3aXRoDQo+ID4gdGhl IG5ldyBvbmUuIElmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBwcm9jZWRlIGluIHRoYXQgd2F5IHRo aXMgY2FuDQo+ID4gYnJpbmcNCj4gdG8NCj4gPiBhIHNpbXBsZSBhbmQgZWZmZWN0aXZlIHdheSB0 byBvcGVyYXRlIHRoZSBwcm90b2NvbC4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0NCj4g PiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMCBjb250YWlucyB0aGUgdXBk YXRlcyB0bw0KPiA+IFJGQzYzNzggdG8gY2hhbmdlIG5vbi1yZXZlcnRpdmUgb3BlcmF0aW9ucyB0 byBiZWhhdmVzIGluIHRoZSBzYW1lDQo+ID4gd2F5IGlycmVzcGVjdGl2ZWx5IG9mIHRoZSB0cmln Z2VyIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIChmYXVsdCBvcg0KPiBvcGVyYXRvcg0KPiA+IGNv bW1hbmQgRlMsIE1TKS4gQ29uc2VxdWVudGx5IGFuIG9wZXJhdG9yIGNvbW1hbmQsIE1hbnVhbCBT d2l0Y2ggdG8NCj4gPiBXb3JraW5nIChNUy1XKSBhLmsuYSAiTWFudWFsIHN3aXRjaC1vdmVyIGZv ciByZWNvdmVyeSBMU1Avc3BhbiIgaXMNCj4gYWxzbw0KPiA+IGFkZGVkIHRvIGVuYWJsZSB0aGlz IGJlaGF2aW9yLiBGcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcsIE1TDQo+IHRvDQo+ ID4gd29ya2luZyBwYXRoIGhhcyBhbHNvIHRvIGJlIHN1cHBvcnRlZCB0byBiZSBhYmxlIHRvIGlu aXRpYWxseSBhbGlnbg0KPiA+IGF0IGJvdGggc2lkZXMgaW4gY2FzZSBvZiBub24tcmV2ZXJ0aXZl IHN3aXRjaGluZyBtb2RlLiBNUyB0byB3b3JraW5nDQo+ID4gcGF0aCBpcyBkZWZpbmVkIGluIFJG QyA1NjU0LCByZXF1aXJlbWVudCA4My4NCj4gPg0KPiA+IFRoZSBwcm9wb3NlZCBNUy1XIGNvbW1h bmQgaXMgb2YgZXF1YWwgcHJpb3JpdHkgdG8gdGhlIGV4aXN0aW5nIE1TLVANCj4gPiBjb21tYW5k LCBhbmQgdGhlcmUgaXMgdGV4dCB0byBoYW5kbGUgdGhlIHNpbXVsdGFuZW91cyBvciBzZXF1ZW50 aWFsDQo+ID4gb2NjdXJyZW5jZSBvZiB0d28gZXF1YWwtcHJpb3JpdHkgY29tbWFuZHMuIFRoaXMg YmVoYXZpb3IsIGFscmVhZHkNCj4gPiBhZG9wdGVkIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3Jr IHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb3RvY29sLA0KPiA+IGNhbg0KPiBiZQ0KPiA+IHVzZWQg Zm9yIG90aGVyIGFkZGl0aW9uIHRvIHRoZSBwcm90b2NvbCBpbiB0aGUgZnV0dXJlLg0KPiA+DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMCBw cm92aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQU0Mgc3RhdGUNCj4gPiBtYWNoaW5lIHRvIGhhbmRs ZSBTaWduYWwgRGVncmFkZSAoU0QpLiBJdCBkb2VzIG5vdCBkZWZpbmUgU0Qgb3INCj4gcHJvdmlk ZQ0KPiA+IHNjb3BlIGFyb3VuZCB3aGVyZSBvciBob3cgU0QgbWF5IGJlIHVzZWQgc2ltaWxhcmx5 IGFzIGl0IGFscmVhZHkNCj4gaGFwcGVuDQo+ID4gaW4gdGhlIGRyYWZ0IGluIGhhbmRsaW5nIG90 aGVyIGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZhaWx1cmUpLg0KPiA+IEluIE1QTFMtVFAgc3Vy dml2YWJpbGl0eSBmcmFtZXdvcmsgW1JGQzYzNzJdLCBhIGZhdWx0IGNvbmRpdGlvbg0KPiA+IGlu Y2x1ZGVzIGJvdGggU2lnbmFsIEZhaWwgKFNGKSBhbmQgU2lnbmFsIERlZ3JhZGUgKFNEKSB0aGF0 IGNhbiBiZQ0KPiB1c2VkDQo+ID4gdG8gdHJpZ2dlciBwcm90ZWN0aW9uIHN3aXRjaGluZy4NCj4g PiBXaGlsZSB0aGUgc3RhbmRhcmRpemF0aW9uIGxhY2sgb2YgYW4gU0QgZGVmaW5pdGlvbiBhbmQg ZGV0ZWN0aW9uDQo+ID4gbWVjaGFuaXNtcywgdGhlIHJlbGV2YW50IGJlaGF2aW9ycyBpbiB0ZXJt cyBvZiBwcm90ZWN0aW9uIGFjdGlvbnMNCj4gPiBtYXkgYWxyZWFkeSBiZSBkZWZpbmVkLg0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+IGRyYWZ0LWRqLW1wbHMtdHAtZXhlci1wc2Mt MDEgcHJvcG9zZXMgYWRkaW5nIHRoZSBFWEVSL1JSIGNvbW1hbmRzIHRvDQo+ID4gdGVzdCBpZiB0 aGUgQVBTIGNvbW11bmljYXRpb24gaXMgb3BlcmF0aW5nIGNvcnJlY3RseS4gSW4gb3RoZXIgd29y ZHMNCj4gPiBib3RoIEFQUyBwcm9jZXNzIGxvZ2ljIGluY2x1ZGluZyBzdGF0ZSBtYWNoaW5lIGFu ZCBBUFMgY2hhbm5lbCBvbg0KPiA+IHByb3RlY3Rpb24gcGF0aCwgd2l0aG91dCBzZXJ2aWNlIGRp c3J1cHRpb24gYW5kIHdpdGhvdXQgYWZmZWN0aW5nDQo+ID4gYW55IHByb3RlY3Rpb24gb3BlcmF0 aW9uLCB1bmxlc3MgdGhlIHByb3RlY3Rpb24gdHJhbnNwb3J0IGVudGl0eSBpcw0KPiA+IGluDQo+ IHVzZS4NCj4gPiBUaGlzIGNvbW1hbmQgaXMgZG9jdW1lbnRlZCBpbiBSODQgb2YgW1JGQzU2NTRd IGFuZCBpdCBpcyBwYXJ0IG9mDQo+ID4gSVRVLVQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4NCj4g PiBBbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIHRoZSBBcHBlbmRpeCBC IG9mIFJGQzYzNzgNCj4gdGhhdA0KPiA+IHV0aWxpemVzIHRoZSBMb2Nrb3V0IG9mIFByb3RlY3Rp b24gKExPKSBvciBGb3JjZWQgU3dpdGNoIChGUykgaW4NCj4gPiBjb21iaW5hdGlvbiBvZiBPQU0g ZnVuY3Rpb25hbGl0aWVzLiBIb3dldmVyLCBpdCBoYXMgc29tZSBmdW5jdGlvbmFsDQo+ID4gbGlt aXRhdGlvbiBhbmQgaGFzIGEgcG90ZW50aWFsIHJpc2sgb2YgbG9zaW5nIHRyYWZmaWMgYXMgYSBz aWduYWwNCj4gPiBmYWlsdXJlIG1pZ2h0IG9jY3VyIGR1cmluZyB0aGUgZXhlcmNpc2Ugb3BlcmF0 aW9uLiBJbiB0aGF0IGNhc2UsIExPDQo+ID4gb3IgRlMgaGFzIHRvIGJlIGNhbmNlbGVkIHRvIGFs bG93IHRoZSBQU0MgcHJvdG9jb2wgdG8gcHJvdmlkZSBwcm9wZXINCj4gPiBzd2l0Y2hpbmcuDQo+ ID4gQSBmdXJ0aGVyIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlzIGRvY3VtZW50ZWQgaW4gZHJhZnQt b3Nib3JuZS1tcGxzLQ0KPiBwc2MtDQo+ID4gYWxpdmUtMDAgdGhhdCBhbnl3YXkgc2hvdyBzb21l IGZ1bmN0aW9uYWwgbGltaXRhdGlvbnMgYmVjYXVzZSBjYW5ub3QNCj4gPiB2YWxpZGF0ZSB0aGUg UFNDIHN0YXRlIG1hY2hpbmUgc3RhdHVzIGFuZCBwcm9iYWJseSB0aGUgTG9jYWwgUmVxdWVzdA0K PiA+IGxvZ2ljLg0KPiA+DQo+ID4NCj4gPiBUaGUgYXV0aG9ycyBlbmNvdXJhZ2UgdGhlIElFVEYg ZXhwZXJ0cyB0byBjb21tZW50IG9uIHRoZXNlIGRyYWZ0cywNCj4gPiBldmVudHVhbGx5IHByb3Bv c2luZyBvdGhlciBvcHRpb25zL21lY2hhbmlzbXMgdGhhdCBjYW4gc2F0aXNmeSB0aGUNCj4gc2Ft ZQ0KPiA+IHJlcXVpcmVtZW50cy4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gQWxlc3NhbmRybywg SHV1YiwgSmVvbmctZG9uZywgVGFla3NpZCBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pDQo+ID4g YWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZQ0KPiBhbGxlDQo+ID4gcGVy c29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXpp b25lDQo+ID4gZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9u aSBzb25vIHJpZ29yb3NhbWVudGUNCj4gPiB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlDQo+ID4gY29ydGVzZW1lbnRlIHBy ZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZQ0KPiA+ IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4gPg0KPiA+IFRo aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29u dGFpbg0KPiA+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4NCj4gPiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzDQo+IHVuYXV0aG9yaXNlZC4NCj4gPiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZQ0KPiA+IGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy4NCj4gPg0KPiA+IHJpc3BldHRhIGwnYW1iaWVudGVSaXNwZXR0YSBsJ2FtYmllbnRl LiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2UNCj4gbm9uDQo+ID4gqKggbmVjZXNzYXJpby4N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxz QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFp bGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg0KDQo= --=_alternative 0053BF9285257BB2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgZm9yIHRoZSByZWFzb25zIHN0 YXRlZCBieSBUb20sDQpKZW9uZy1kb25nIGFuZCBIYW4sIGFsc28gdGhpcyBhcHByb2FjaCBhbGln bnMgdGhlIGJlaGF2aW91ciBvZiBNUEw6Uy1UUA0KbGluZWFyIHByb3RlY3Rpb24gd2l0aCB0aGUg YmVoYXZpb3VyIG9mIG90aGVyIChTREgsIE9UTiwgRXRoZXJuZXQpIGxpbmVhcg0KcHJvdGVjdGlv biBzd2l0Y2hpbmcgYWxyZWFkeSBkZXBsb3llZCBpbiB0aGUgbmV0d29yay4gJm5ic3A7QXMgc3Rh dGVkIGluDQpzb21lIHByZXZpb3VzIGxpYWlzb24gc3RhdGVtZW50cyBmcm9tIHRoZSBJVFUgYWxp Z25tZW50IHdpdGggZXhpc3RpbmcgQVBTDQpzY2hlbWVzIGlzIGEga2V5IG9iamVjdGl2ZS48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NYWxjb2xtPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PkxhcnJ5ICZsdDtsYXJyeWxpODg4QHlhaG9vLmNvbS5jbiZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNlbnQgYnk6IG1wbHMtYm91bmNlc0BpZXRm Lm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMy8wNy8yMDEz IDA5OjQ2IFBNPC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJn Y29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UGxlYXNlIHJlc3BvbmQgdG88YnI+DQpMYXJyeSAmbHQ7bGFycnlsaTg4OEB5YWhvby5j b20uY24mZ3Q7PC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NjMlPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtIdWJlciwgVGhvbWFzIEouJnF1b3Q7ICZs dDtUb20uSHViZXJAdGVsbGFicy5jb20mZ3Q7LA0KJnF1b3Q7RXJpYyBPc2Jvcm5lIFwoZW9zYm9y bmVcKSZxdW90OyAmbHQ7ZW9zYm9ybmVAY2lzY28uY29tJmd0OywgJnF1b3Q7UnlvbywNCkplb25n LWRvbmcmcXVvdDsgJmx0O3J5b29AZXRyaS5yZS5rciZndDssIEQnQWxlc3NhbmRybyBBbGVzc2Fu ZHJvIEdlcmFyZG8NCiZsdDthbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQm Z3Q7LCAmcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7DQombHQ7bXBsc0BpZXRmLm9yZyZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDtIdXViIGhlbHZvb3J0IFwoaHV1Yi52YW4uaGVsdm9vcnRAaHVh d2VpLmNvbVwpJnF1b3Q7DQombHQ7aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbSZndDssICZx dW90O2h1dWJhdHdvcmtAZ21haWwuY29tJnF1b3Q7DQombHQ7aHV1YmF0d29ya0BnbWFpbC5jb20m Z3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbXBsc10gu9i4tKO6ICZuYnNwO3Byb3Bvc2VkIGRy YWZ0cw0KZm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhciBwcm90ZWN0aW9uIHByb3RvY29s IHRvIHRyYW5zcG9ydCByZXF1aXJlbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iUm9tYW4iPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SSBhZ3JlZSB3aXRoIFRv bSBhbmQgSmVvbmctZG9uZy4NClRoZXJlIGFyZSBkaWZmZXJlbnQgcmVhc29ucyB0byBjYXVzZSBT RCwgYnV0IHRoZSByZXN1bHQgaXMgdGhlIHRyYW5zcG9ydA0KcGVyZm9ybWFuY2UgZGVncmFkZSBh bmQgaXQgaXMgaW1wb3J0YW50IHRvIGxldCBvcGVyYXRvcnMgc2V0IGEgdGhyZXNob2xkDQp0byB0 cmlnZ2VyIHByb3RlY3Rpb24gc3dpdGNoLiBEdXJpbmcgdGhlIHRyb3VibGUgc2hvb3RpbmcsIG9w ZXJhdG9ycyBuZWVkDQp0b29scyB0byBkbyBmYXVsdCBsb2NhbGl6YXRpb24uIEFsdGhvdWdodCAm cXVvdDtkZWdyYWRlJnF1b3Q7IGlzIGEgY29udGlub3VzDQp2YXJpYWJsZSBiZWhhdmlvdXIsIGl0 IGlzIGEgJnF1b3Q7MC8xJnF1b3Q7IHByb2JsZW0gYWZ0ZXIgZGVmaW5pbmcgdGhlDQp0aHJlc2hv bGQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoYW5r IHlvdSE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj4qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KSGFu IExpLCBQaC5EIDxicj4NCkNoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGU8YnI+DQozMiBY dWFud3VtZW4gV2VzdCBTdHJlZXQsIFhpY2hlbmcgRGlzdHJpY3QsIEJlaWppbmcgMTAwMDUzLCBD aGluYSA8YnI+DQpGYXg6ICs4NiAxMCA2MzEzNTE1OSA8YnI+DQpNT0JJTEU6IDEzNTAxMDkzMzg1 IDxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+DQo8YnI+DQo8aHI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48Yj63orz+yMujujwvYj4gJnF1b3Q7SHViZXIsIFRob21hcyBKLiZxdW90Ow0K Jmx0O1RvbS5IdWJlckB0ZWxsYWJzLmNvbSZndDs8Yj48YnI+DQrK1bz+yMujujwvYj4gRXJpYyBP c2Jvcm5lIChlb3Nib3JuZSkgJmx0O2Vvc2Jvcm5lQGNpc2NvLmNvbSZndDs7ICZxdW90O1J5b28s DQpKZW9uZy1kb25nJnF1b3Q7ICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7OyBEJ0FsZXNzYW5kcm8g QWxlc3NhbmRybyBHZXJhcmRvDQombHQ7YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRh bGlhLml0Jmd0OzsgJnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90Ow0KJmx0O21wbHNAaWV0Zi5vcmcm Z3Q7IDxiPjxicj4NCrOty82jujwvYj4gJnF1b3Q7SHV1YiBoZWx2b29ydCAoaHV1Yi52YW4uaGVs dm9vcnRAaHVhd2VpLmNvbSkmcXVvdDsNCiZsdDtodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29t Jmd0OzsgJnF1b3Q7aHV1YmF0d29ya0BnbWFpbC5jb20mcXVvdDsNCiZsdDtodXViYXR3b3JrQGdt YWlsLmNvbSZndDsgPGI+PGJyPg0Kt6LLzcjVxtqjujwvYj4gMjAxM8TqN9TCMjPI1Swg0MfG2rb+ LCAzOjAzIMnPzuc8Yj48YnI+DQrW98ziOjwvYj4gUmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMg Zm9yIGFsaWduaW5nIE1QTFMtVFAgUFNDIGxpbmVhcg0KcHJvdGVjdGlvbiBwcm90b2NvbCB0byB0 cmFuc3BvcnQgcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxicj4NCkhpIEVyaWMsPGJyPg0KPGJyPg0KWW91IHdyb3RlOjxicj4NCiZn dDtFTyM8YnI+DQomZ3Q7SSdtIG5vdCBzdXJlIHdoYXQgdGhhdCB3b3VsZCBsb29rIGxpa2UuICZu YnNwOydGYWlsJyBpcyBhIHByZXR0eSBiaW5hcnkNCnRoaW5nLiAmbmJzcDsnRGVncmFkZScgaXMg YSBjb250aW51b3VzIHZhcmlhYmxlLCBhcyBpdCBjYW4gYmUgYW55dGhpbmcNCmZyb20gJ2EgbGl0 dGxlIGJhZCcgdG8gYSAnYSB3aG9sZSBsb3Qgb2YgYmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuPGJy Pg0KPGJyPg0KSSB0aGluayB0aGlzIG1heSBiZSBhIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgaW4g YXNzdW1wdGlvbnMuICZuYnNwO1doaWxlDQppdCBpcyBjZXJ0YWlubHkgdHJ1ZSB0aGF0IGRlZ3Jh ZGF0aW9uIG9mIGEgc2lnbmFsIGlzIGEgY29udGludW91cyB2YXJpYWJsZSwNCmluIHRoZSBjb250 ZXh0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nIGluIHRoZSB0cmFuc3BvcnQgbmV0d29yaywgdGhl cmUNCmlzIGEgcGFydGljdWxhciB2YWx1ZSBvZiB0aGF0IGNvbnRpbnVvdXMgdmFyaWFibGUgdGhh dCBkZWZpbmVzIHRoZSB0aHJlc2hvbGQNCmF0IHdoaWNoIHRoZSBCb29sZWFuIHZhcmlhYmxlICZx dW90O3NpZ25hbCBkZWdyYWRlIChTRCkmcXVvdDsgYmVjb21lcyB0cnVlLg0KJm5ic3A7SXQgaXMg Zm9yIHRoaXMgcmVhc29uIHRoYXQgSmVvbmctZG9uZyBhbmQgb3RoZXJzIGFyZSBzdWdnZXN0aW5n IHRoYXQNCml0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBpbmNvcnBvcmF0ZSB0aGUgYmVoYXZpb3Ig b2YgdGhlIFNEIHN0YXRlIGludG8NCnRoZSBQU0MgZGVmaW5pdGlvbiB3aXRob3V0IG5lZWRpbmcg dG8gaGF2ZSBhIHByZWNpc2UgZGVmaW5pdGlvbiBvZiB0aGUNCm1lY2hhbmlzbSBmb3IgbWVhc3Vy aW5nIHRoZSBkZWdyYWRhdGlvbiBvZiBhIHNpZ25hbC4gJm5ic3A7V2hhdGV2ZXIgdGhlDQptZWNo YW5pc20gaXMsIGl0IHdpbGwgYmUgY29udmVydGVkIHRvIHRoZSBiaW5hcnkgU0QgaW5kaWNhdGlv bi48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KVG9tPGJyPg0KPGJyPg0KPGJyPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48dT5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NClttYWlsdG86PC9mb250PjxhIGhyZWY9 Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+bXBscy1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+XQ0KT24gQmVoYWxmIE9mIEVy aWMgT3Nib3JuZSAoZW9zYm9ybmUpPGJyPg0KU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDg6 MzYgQU08YnI+DQpUbzogUnlvbywgSmVvbmctZG9uZzsgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8g R2VyYXJkbzsgPC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5tcGxzQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KQ2M6IEh1 dWIgaGVsdm9vcnQgKDwvZm9udD48YSBocmVmPW1haWx0bzpodXViLnZhbi5oZWx2b29ydEBodWF3 ZWkuY29tPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+ aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPik7DQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aHV1YmF0d29y a0BnbWFpbC5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48dT5odXViYXR3b3JrQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NClN1YmplY3Q6IFJlOiBbbXBsc10gcHJvcG9zZWQgZHJh ZnRzIGZvciBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXIgcHJvdGVjdGlvbg0KcHJvdG9jb2wg dG8gdHJhbnNwb3J0IHJlcXVpcmVtZW50czxicj4NCjxicj4NCkhpIEplb25nLWRvbmcsPGJyPg0K PGJyPg0KICZuYnNwO1RoYW5rcyBmb3IgdGhlIHJlcGx5LiAmbmJzcDtQbGVhc2Ugc2VlIGlubGlu ZSB3aXRoIEVPIy48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyBGcm9tOiBSeW9vLCBKZW9uZy1kb25nIFttYWlsdG86PC9mb250PjxhIGhyZWY9bWFp bHRvOnJ5b29AZXRyaS5yZS5rcj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjx1PnJ5b29AZXRyaS5yZS5rcjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPl08YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgSnVseSAyMiwg MjAxMyA0OjE1IEFNPGJyPg0KJmd0OyBUbzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IEQnQWxl c3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87PGJyPg0KJmd0OyA8L2ZvbnQ+PGEgaHJlZj1tYWls dG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48YnI+DQomZ3Q7IENjOiBIdXViIGhlbHZvb3J0ICg8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh1dWIudmFuLmhlbHZvb3J0QGh1YXdl aS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4p Ow0KPC9mb250PjxhIGhyZWY9bWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHV1YmF0d29ya0BnbWFpbC5j b208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+ DQomZ3Q7IFN1YmplY3Q6IFJFOiBbbXBsc10gcHJvcG9zZWQgZHJhZnRzIGZvciBhbGlnbmluZyBN UExTLVRQIFBTQyBsaW5lYXI8YnI+DQomZ3Q7IHByb3RlY3Rpb24gcHJvdG9jb2wgdG8gdHJhbnNw b3J0IHJlcXVpcmVtZW50czxicj4NCiZndDs8YnI+DQomZ3Q7IEhpLCBFcmljLjxicj4NCiZndDs8 YnI+DQomZ3Q7IExldCBtZSBhbnN3ZXIgeW91ciAybmQgcXVlc3Rpb24gb24gU0QuPGJyPg0KJmd0 Ozxicj4NCiZndDsgU0QgZGV0ZWN0aW9uIG1ldGhvZHMgZGVmaW5lZCBvciBwcm9wb3NlZCBmb3Ig cGFja2V0IHRyYW5zcG9ydCBuZXR3b3Jrczxicj4NCiZndDsgY2FuIGJlIHN1bW1hcml6ZWQgYXMg Zm9sbG93czo8YnI+DQomZ3Q7IC0gQnkgT0FNIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcgdG9vbDo8 YnI+DQomZ3Q7ICZuYnNwO1NEIGlzIHJhaXNlZCBpZiBwYWNrZXQgbG9zcyByYXRpbyBleGNlZWRz IGEgdGhyZXNob2xkIGR1cmluZw0KYTxicj4NCiZndDsgbWVhc3VyZW1lbnQgcGVyaW9kLjxicj4N CiZndDsgJm5ic3A7VGhyZXNob2xkIHZhbHVlIGFuZCBtZWFzdXJlbWVudCBwZXJpb2QgYXJlIGNv bmZpZ3VyZWQgYnkgYW4NCm5ldHdvcms8YnI+DQomZ3Q7IG9wZXJhdG9yLjxicj4NCiZndDsgJm5i c3A7VGhpcyBkZXRlY3Rpb24gbWV0aG9kIGlzIGFscmVhZHkgZGVmaW5lZCBpbiBJVFUtVCBHLjgw MjEgKEV0aGVybmV0PGJyPg0KJmd0OyBlcXVpcG1lbnQgc3BlYy4pPGJyPg0KPGJyPg0KPGJyPg0K RU8jICZuYnNwO1doZXJlPyAmbmJzcDtJJ20gbm90IGFyZ3VpbmcgdGhhdCBpdCdzIG5vdCBpbiB0 aGVyZSwgSSdtIGp1c3QNCmhhdmluZyBhIGhhcmQgdGltZSBmaW5kaW5nIGl0LiAmbmJzcDtBIHNl YXJjaCBmb3IgRVRIX0NJX1NTRCBkb2Vzbid0IHlpZWxkDQptdWNoLiAmbmJzcDtJZiBJIGxvb2sg Zm9yICdzaWduYWwgZGVncmFkZScgSSBzZWUgcC4gMTMxIHdoaWNoIHNheXMgdGhhdA0KdGhlIGFs Z29yaXRobSBpcyBkZWZpbmVkIGluIEcuODAzMS4gJm5ic3A7Ry44MDMxIHNheXMgJyBIb3cgdGhl c2UgZGVmZWN0cw0KYXJlIGRldGVjdGVkIGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBlcXVpcG1lbnQg UmVjb21tZW5kYXRpb25zJy4gJm5ic3A7SSdtDQpsb29raW5nIGZvciBzb21ldGhpbmcgbGlrZSAm cXVvdDtTaWduYWwgRGVncmFkZSBpcyBkZWZpbmVkIGFzICRmb28gcGFja2V0DQpsb3NzIG9yIENS QyBmYWlsdXJlIG92ZXIgJGJhciB0aW1lJnF1b3Q7Li4uLndoYXQgaGF2ZSBJIG1pc3NlZD88YnI+ DQo8YnI+DQo8YnI+DQomZ3Q7ICZuYnNwO2FuZCB0aGUgZXF1aXBtZW50IHNwZWMgZm9yIE1QTFMt VFAgY2FuIGVhc2lseSBmb2xsb3cgdGhlIHNhbWU8YnI+DQomZ3Q7IGRlZmluaXRpb24uPGJyPg0K Jmd0OyAtIEJ5IHNlcnZlciBsYXllciBpbmRpY2F0aW9uOjxicj4NCiZndDsgJm5ic3A7U0QgaXMg cmFpc2VkIGlmIGEgc2VydmVyIGxheWVyIGJlbG93IE1QTFMtVFAgcmVwb3J0cyBTRCBjb25kaXRp b24NCm9uPGJyPg0KJmd0OyBpdHMgb3duIGxheWVyLjxicj4NCiZndDsgLSBCeSBDQ00gcGFja2V0 IGNvdW50aW5nOjxicj4NCiZndDsgJm5ic3A7U0QgaXMgcmFpc2VkIGlmIHRoZSBsb3NzIHJhdGlv IG9mIENDTSBwYWNrZXRzIGV4Y2VlZHMgYSB0aHJlc2hvbGQ8YnI+DQomZ3Q7IGR1cmluZyBhIG1l YXN1cmVtZW50IHBlcmlvZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRsZXNzIG9mIGhvdyB0 byBkZXRlY3QgU0QsIGFueSBwcm90ZWN0aW9uIHN3aXRjaGluZyBkb2N1bWVudHM8YnI+DQomZ3Q7 IHNob3VsZCBkZXNjcmliZSB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb3BlcmF0aW9uIG9uY2Ug c3VjaCBhIFNEDQppczxicj4NCiZndDsgZGVjbGFyZWQuPGJyPg0KJmd0Ozxicj4NCi4uLjxicj4N CiZndDsgUmVnYXJkaW5nIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgU0Q6PGJyPg0KJmd0OyBJdCBp cyBjZXJ0YWlubHkgcG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIGxldmVscyBvZiBTRC48YnI+ DQomZ3Q7IEJ1dCwgYXMgZmFyIGFzIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjb25jZXJu ZWQsIGl0IGp1c3QgbmVlZHMNCnRvPGJyPg0KJmd0OyBrbm93IGlmIFNEIGlzIHNpZ25hbGVkIHRv IHByb3RlY3Rpb24gc3dpdGNoaW5nIHByb2Nlc3Mgb3Igbm90Ljxicj4NCiZndDsgSXQgd291bGQg YmUgYSBuZXR3b3JrIG9wZXJhdG9yJ3MgY2hvaWNlIGF0IHdoYXQgbGV2ZWwgb2YgU0QgaGUgd2Fu dHM8YnI+DQomZ3Q7IGhpcyBuZXR3b3JrIHByb3RlY3Rpb24gdG8gc3dpdGNob3Zlci48YnI+DQom Z3Q7IEluIG90aGVyIHdvcmRzLCB3aGF0IHRyaWdnZXJzIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlz IFNEIG9yIG5vIFNELg0KSXQ8YnI+DQomZ3Q7IGlzIHllcyBvciBubyBkZWNpc2lvbi48YnI+DQo8 YnI+DQo8YnI+DQpFTyMgJm5ic3A7SSBhbSBub3QgYXdhcmUgb2YgYW55IGRvY3VtZW50IHdoaWNo IHN1Z2dlc3RzIHRoYXQgYSBzZXJ2ZXIgbGF5ZXINClNEIHNob3VsZCBiZSB0cmVhdGVkIGFzIGEg Y2xpZW50IGxheWVyIFNELiAmbmJzcDtJbiB0aGUgSVAgd29ybGQsIGlmIHdlDQpoYXZlIFNEIG9u IGEgdHJhbnNwb3J0IGludGVyZmFjZSB0aGF0IGlzIGdlbmVyYWxseSB1c2VkIHRvIGJyaW5nIHRo ZSBpbnRlcmZhY2UNCmRvd24gKGkuZS4gU0YpLiAmbmJzcDtUaGlzIGlzIHRoZSBzb3J0IG9mIHRo aW5nIEknZCBsaWtlIHRvIHNlZSBpbiBtb3JlDQpkZXRhaWwsIGFzIFNEIGluIHRoZSBwYWNrZXQg d29ybGQgaXMgYSBuZXcgY29uY2VwdCBhbmQgd2UgY2FuJ3QganVzdCBhc3N1bWUNCnRoYXQgaXQg d2lsbCB3b3JrIHRoZSBzYW1lIGV2ZXJ5d2hlcmUgYmVjYXVzZSB3ZSBkZWZpbmUgc3RhdGUgbWFj aGluZSBwb2ludHMNCmZvciBpdC48YnI+DQo8YnI+DQpUaGUgcG9pbnQgYWJvdXQgQ0NNIGlzIGEg Z29vZCBvbmUuICZuYnNwO0xldCdzIHNheSB3ZSBjb21lIHVwIHdpdGggYSBjbGV2ZXINClNEIG1l Y2hhbmlzbSB3aXRoIHR3byB0aHJlc2hvbGRzLCBjYWxsIHRoZW0gbWFqb3IgYW5kIG1pbm9yLiAm bmJzcDtGb3INCmRpc2N1c3Npb24gcHVycG9zZXMgdGhleSBjb3VsZCBiZSBzaW1wbGUgZXJyb3Ig cmF0aW9zLCBlLmcuIDE6MTBeNiBhbmQNCjE6MTBeOS4gJm5ic3A7QnV0IHRoZXkgY291bGQgYmUg bW9yZSBwb3dlcmZ1bCB0aGFuIHRoYXQgKGZsb3cgdHlwZSwgZmxvdw0KbGVuZ3RoLCBlcnJvciBi dXJzdCBzaXplLCBldGMpLjxicj4NCjxicj4NCklmIHdlIHdhbnQgdG8gaGF2ZSBTRC1NYWpvciBh bmQgU0QtTWlub3IgaW5wdXRzIGFzIHNlcGFyYXRlIHRyaWdnZXJzIGZvcg0KUFNDLCB3ZSBtYXkg d2FudCB0aGVtIGF0IGRpZmZlcmVudCBwb2ludHMuICZuYnNwO1BlcmhhcHMgJm5ic3A7KGxlYXZp bmcNCm91dCB0aGUgV29ya2luZyBwYXRoIGZvciBlYXNlIG9mIHJlYWRpbmcpPGJyPg0KPGJyPg0K TE88YnI+DQpGUzxicj4NClNGLVA8YnI+DQpTRC1QLU1ham9yPGJyPg0KTVM8YnI+DQpTRC1QLU1p bm9yPGJyPg0KPGJyPg0KPGJyPg0KVGhpcyBzZWVtcyBsaWtlIGEgcGVyZmVjdGx5IHJlYXNvbmFi bGUgdGhpbmcgdG8gd2FudC48YnI+DQo8YnI+DQo8YnI+DQpFdmVuIGlmIHdlIGRvbid0IGhhdmUg bXVsdGktdGllciBTRCwgZXZlbiB0aGUgc2luZ2xlLXRpZXIgU0QgbmVlZHMgdG8gYmUNCmRlZmlu ZWQgYmVmb3JlIHdlIGNhbiBkZWNpZGUgaG93IHRvIHJlc3BvbmQgdG8gaXQuPGJyPg0KPGJyPg0K Jmd0OyBUaGUgcHJvcG9zZWQgZHJhZnQgY292ZXJzIFNELXRyaWdnZXJlZCBwcm90ZWN0aW9uIG5v IG1hdHRlciB3aGF0IGtpbmRzPGJyPg0KJmd0OyBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBhcmUg dXNlZC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgU0YgY2FuIGFsc28gYmUgdmlld2Vk IGFzIGhhdmluZyBtdWx0aXBsZSBsZXZlbHMgb2YgU0YgYXMgdGhlIG5ldHdvcms8YnI+DQomZ3Q7 IG9wZXJhdG9yIGNhbiBhbHNvIG1ha2UgYSBjaG9pY2Ugb24gdGhlIHBlcmlvZC9pbnRlcnZhbCBv ZiBDQ00gbWVzc2FnZXMuPGJyPg0KPGJyPg0KPGJyPg0KRU8jPGJyPg0KSSdtIG5vdCBzdXJlIHdo YXQgdGhhdCB3b3VsZCBsb29rIGxpa2UuICZuYnNwOydGYWlsJyBpcyBhIHByZXR0eSBiaW5hcnkN CnRoaW5nLiAmbmJzcDsnRGVncmFkZScgaXMgYSBjb250aW51b3VzIHZhcmlhYmxlLCBhcyBpdCBj YW4gYmUgYW55dGhpbmcNCmZyb20gJ2EgbGl0dGxlIGJhZCcgdG8gYSAnYSB3aG9sZSBsb3Qgb2Yg YmFkIGJ1dCBub3QgcXVpdGUgZmFpbCcuPGJyPg0KPGJyPg0KJmd0OyBJZiBDQ00gaXMgZGlzYWJs ZWQsIEFJUyBmcm9tIGEgc2VydmVyIGxheWVyIGNhbiBiZSB1c2VkIGFzIGEgdHJpZ2dlcjxicj4N CiZndDsgZm9yIHByb3RlY3Rpb24gc3dpdGNoaW5nLiBTbyBhbmQgc28gZm9ydGguPGJyPg0KPGJy Pg0KRU8jICZuYnNwO0FJUyBmcm9tIHRoZSBzZXJ2ZXIgbGF5ZXIgb25seSBnZXRzIHlvdSBTRCBm cm9tIHRoZSBmaXJzdCBob3ANCm9mIHRoZSB1bmRlcmx5aW5nIHNlcnZlciBwYXRoLjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCmVyaWM8YnI+DQo8YnI+DQomZ3Q7IEhvd2V2ZXIsIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBob3cgdG8gZGV0ZWN0PGJy Pg0KJmd0OyBTRiBpbiBhbnl3aGVyZS48YnI+DQomZ3Q7IFNpbWlsYXJ5LCBwcm90ZWN0aW9uIHN3 aXRjaGluZyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgaG93IG1hbnVhbDxicj4NCiZndDsgc3dp dGNoIGFuZCBmb3JjZWQgc3dpdGNoIGNvbW1hbmRzIGFyZSBpbml0aWF0ZWQgaW4gYSBtYW5hZ2Vt ZW50IHN5c3RlbTxicj4NCiZndDsgYW5kIHNpZ25hbGVkIHRvIHByb3RlY3Rpb24gc3dpdGNoaW5n IHByb2Nlc3MuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWdhaW4sIGluIG15IG9waW5pb24sIHRoZSBk cmFmdCBvbiBTRCBwcm90ZWN0aW9uIGNhbiBhY2NvbW1vZGF0ZSBhbnk8YnI+DQomZ3Q7IFNEIGRl dGVjdGlvbiBtZXRob2RzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQom Z3Q7PGJyPg0KJmd0OyBKZW9uZy1kb25nPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb20gOiAmcXVvdDtFcmljIE9zYm9y bmUgKGVvc2Jvcm5lKSZxdW90OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmVvc2Jvcm5lQGNp c2NvLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1 PmVvc2Jvcm5lQGNpc2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiZndDsNClNlbnQgOjxicj4NCiZndDsgMjAxMy0wNy0yMCAwMjo0ODoyOCAo ICswOTowMCApIFRvIDogRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzxicj4NCiZndDsg Jmx0OzwvZm9udD48YSBocmVmPW1haWx0bzphbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21p dGFsaWEuaXQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 dT5hbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mZ3Q7LA0KPC9mb250PjxhIGhyZWY9 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KJmd0OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRv Om1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+Jmd0Ow0KQ2MgOiBIdXViIGhlbHZvb3J0ICg8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb208 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4pPGJyPg0K Jmd0OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5j b20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5odXVi LnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jmd0OywNCjwvZm9udD48YSBocmVmPW1haWx0bzpodXViYXR3b3Jr QGdtYWlsLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pjx1Pmh1dWJhdHdvcmtAZ21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KJmd0OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmh1 dWJhdHdvcmtAZ21haWwuY29tPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHU+aHV1YmF0d29ya0BnbWFpbC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mZ3Q7DQpTdWJqZWN0IDogUmU6IFttcGxzXSBwcm9w b3NlZCBkcmFmdHMgZm9yPGJyPg0KJmd0OyBhbGlnbmluZyBNUExTLVRQIFBTQyBsaW5lYXIgcHJv dGVjdGlvbiBwcm90b2NvbCB0byB0cmFuc3BvcnQ8YnI+DQomZ3Q7IHJlcXVpcmVtZW50czxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBBbGVzc2FuZHJvLTxicj4NCiZndDs8YnI+DQom Z3Q7IFRoYW5rcyBmb3IgdGhpczsgdGhlIHRocmVhZHMgSSBzdGFydGVkIHNvbWUgdGltZSBiYWNr IHNlZW0gdG8gaGF2ZTxicj4NCiZndDsgZGllZCBkb3duLCBpdCdzIGdvb2QgdG8gZ2V0IHRoZW0g Z29pbmcgYWdhaW4uPGJyPg0KJmd0OyBJIGhhdmUgdHdvIHRoaW5ncyBJIG5ldmVyIHF1aXRlIHVu ZGVyc3Rvb2QsIGNhbiB5b3UgY2xhcmlmeSB0aGVtIGZvcg0KbWU/PGJyPg0KJmd0Ozxicj4NCiZn dDsgaSkgY2FuIHlvdSBleHBsYWluIEVYRVIgYXQgYSBoaWdoZXIgbGV2ZWw/IEknbSBub3QgbG9v a2luZyBmb3IgYTxicj4NCiZndDsgZGVzY3JpcHRpb24gb2YgdGhlIHN0YXRlIG1hY2hpbmUgY2hh bmdlcywgYW5kIEknbSBub3QgbG9va2luZyBmb3INCnRoZTxicj4NCiZndDsgb25lIGxpbmUgJnF1 b3Q7SXQgYWxsb3dzIHRoZSBGU00gdG8gYmUgdGVzdGVkJnF1b3Q7LiBXZSBoYXZlIGFsbCBvZg0K dGhhdCBpbiB0aGU8YnI+DQomZ3Q7IGRyYWZ0IGFuZCBpbiB0aGUgZXF1aXZhbGVudCBJVFUgc3Bl Y3MuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0 IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBmcm9tLiBUaGUNCklUVTxicj4NCiZndDsgc3BlY3MgdGhh dCBkZWZpbmUgaXQgYXJlIHByZXR0eSBoYXJkIHRvIGZvbGxvdywgdGhleSBzZWVtIHRvIGFzc3Vt ZTxicj4NCiZndDsgdGhlIHJlYWRlciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBpcyBhbmQgd2hh dCBwcm9ibGVtIGl0IHNvbHZlcy4NCkl0PGJyPg0KJmd0OyBmZWVscyB2ZXJ5IG11Y2ggbGlrZSBh IG1lY2hhbmlzbSB1c2VkIHRvIGNhdGNoIGEgdmVyeSBzcGVjaWZpYzxicj4NCiZndDsgaW1wbGVt ZW50YXRpb24gYnVnLCBiYWNrIHdoZW4gdHJhbnNwb3J0IGdlYXIgd2FzIGZhciBsZXNzIGRlYnVn Z2FibGU8YnI+DQomZ3Q7IHRoYW4gd2hhdCB3ZSBoYXZlIHRvZGF5Ljxicj4NCiZndDs8YnI+DQom Z3Q7IE5vIG90aGVyIHN0YXRlIG1hY2hpbmVzIHRoYXQgSSdtIGZhbWlsaWFyIHdpdGggKFJTVlAs IExEUCwgQkdQLCBPU1BGLDxicj4NCiZndDsgSVNJUykgaGF2ZSBleHBsaWNpdCBzaWduYWxpbmcg aW4gdGhlbSBqdXN0IHRvIGFzayB0aGUgbmVpZ2hib3Igd2hldGhlcjxicj4NCiZndDsgaXQgKndv dWxkKiBiZSBicm9rZW4gaWYgaWYgd2VyZSwgaW4gdGhlIGZ1dHVyZSwgdG8gYmUgZ2l2ZW4gYTxi cj4NCiZndDsgcGFydGljdWxhciBpbnB1dC4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdldCBi ZWhpbmQgRVhFUiBoYXMgYmVlbjxicj4NCiZndDsgdGhhdCBJIGRvbid0IGZlZWwgY29tZm9ydGFi bGUgd2l0aCB0aGUgaWRlYSBvZiBrZWVwaW5nIGEgMzAteWVhci1vbGQ8YnI+DQomZ3Q7IHdvcmth cm91bmQgaW4gYSBwcm90b2NvbC4gSXMgdGhlcmUgbW9yZSB0byBpdCB0aGFuIHRoYXQ/IEhhdmUg STxicj4NCiZndDsgbWlzcmVhZCBhbmQgbWlzdW5kZXJzdG9vZCBFWEVSPyBEb2VzIG1vZGVybiB0 cmFuc3BvcnQgZ2VhciBldmVyPGJyPg0KJmd0OyBhY3R1YWxseSBkZXRlY3QgYSBwcm9ibGVtIHZp YSBFWEVSL1JSIHRoYXQgd2Fzbid0IG9idmlvdXMgdG8gdGhlPGJyPg0KJmd0OyBvcGVyYXRvciB1 c2luZyBvdGhlciBtZWFucz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgaWkpIFdoeSB0 aGUgcHVzaCB0byBzdGFuZGFyZGl6ZSB0aGUgU0Qgc3RhdGUgY2hhbmdlcyBiZWZvcmUgd2UndmU8 YnI+DQomZ3Q7IGRlZmluZWQgU0Q/IEkgY2VydGFpbmx5IGFncmVlIHRoYXQgaGFuZGxpbmcgc2ln bmFsIGRlZ3JhZGUgaXMgYSBnb29kPGJyPg0KJmd0OyBpZGVhLCBidXQgY29taW5nIHVwIHdpdGgg YSBkZWZpbml0aW9uIGZvciBpdCBoYXMgYmVlbiBjaGFsbGVuZ2luZy48YnI+DQomZ3Q7IFdoYXQg aGFwcGVucyBpZiB3ZSBjaGFuZ2UgdGhlIEZTTSB0byBoYW5kbGUgaXQsIHRoZW4gY29tZSB1cCB3 aXRoPGJyPg0KJmd0OyBzb21ldGhpbmcgbW9yZSBzb3BoaXN0aWNhdGVkIChzYXksIG11bHRpcGxl IGxldmVscyBvZiBTRCkgdGhhdCBkb2Vzbid0PGJyPg0KJmd0OyBxdWl0ZSBmaXQgd2l0aCB0aGUg RlNNIGNoYW5nZXM/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyB0aGFu a3MhPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IGVyaWM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiA8L2ZvbnQ+PGEgaHJlZj0ibWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48dT5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NClttYWlsdG86PC9mb250PjxhIGhy ZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+bXBscy1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+XQ0KT24gQmVoYWxmPGJy Pg0KJmd0OyBPZjxicj4NCiZndDsgJmd0OyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRv PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyAzOjIzIFBNPGJy Pg0KJmd0OyAmZ3Q7IFRvOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pm1wbHNAaWV0Zi5v cmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+ DQomZ3Q7ICZndDsgQ2M6IEh1dWIgaGVsdm9vcnQgKDwvZm9udD48YSBocmVmPW1haWx0bzpodXVi LnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHU+aHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbTwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPik7PGJyPg0KJmd0OyAmZ3Q7 IDwvZm9udD48YSBocmVmPW1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh1dWJhdHdvcmtAZ21haWwuY29t PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0K Jmd0OyAmZ3Q7IFN1YmplY3Q6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nIE1Q TFMtVFAgUFNDIGxpbmVhcjxicj4NCiZndDsgJmd0OyBwcm90ZWN0aW9uIHByb3RvY29sIHRvIHRy YW5zcG9ydCByZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRGVhciBh bGwsPGJyPg0KJmd0OyAmZ3Q7IHdlIHdvdWxkIGxpa2Ugc29jaWFsaXppbmcgdGhlIGhlcmViZWxv dyBkcmFmdHMgdGhhdCB3ZXJlIHN1Ym1pdHRlZDxicj4NCiZndDsgc29tZTxicj4NCiZndDsgJmd0 OyBtb250aHMgYWdvIHdpdGggdGhlIGFpbSB0byBhbGlnbiBQU0MgcHJvdG9jb2wgKFJGQyA2Mzc4 KSB0byBJVFUtVDxicj4NCiZndDsgJmd0OyB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzLiBJIHdvdWxk IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBhYm91dA0KdGhlPGJyPg0KJmd0OyAmZ3Q7IHByb3Bv c2VkIG1lY2hhbmlzbXMgYW5kIGJlaGF2aW91cnMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMDxicj4NCiZndDsgJmd0OyBkcmFm dC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMDxicj4NCiZndDsgJmd0OyBkcmFmdC1y aGQtbXBscy10cC1wc2Mtc2QtMDA8YnI+DQomZ3Q7ICZndDsgZHJhZnQtZGotbXBscy10cC1leGVy LXBzYy0wMSAvIGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtYWxpdmUtMDA8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgVGhlIGFib3ZlIGRyYWZ0cyBjb3ZlciBtb3N0IG9mIGl0ZW1zIGhpZ2hs aWdodGVkIGluIElUVS1UIGxpYWlzb25zPGJyPg0KJmd0OyBhYm91dDxicj4NCiZndDsgJmd0OyBQ U0MgYW5kIHRoZXkgcHJvcG9zZSBzb2x1dGlvbnMgaW4gbGluZSB3aXRoIE1QTFMtVFAgdHJhbnNw b3J0PGJyPg0KJmd0OyAmZ3Q7IHJlcXVpcmVtZW50cy48YnI+DQomZ3Q7ICZndDsgQSBsaXN0IG9m IG1haW4gbGlhaXNvbnMgZXhjaGFuZ2VkIGJldHdlZW4gSVRVLVQgYW5kIElFVEYgd2l0aA0KdGhl PGJyPg0KJmd0OyAmZ3Q7IGFpbTxicj4NCiZndDsgdG88YnI+DQomZ3Q7ICZndDsgYWxpZ24gUFND IGJlaGF2aW91cyB3aXRoIElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMgZm9yIGxpbmVhcjxi cj4NCiZndDsgJmd0OyBwcm90ZWN0aW9uIGFyZSBnaXZlbiBiZWxvdzo8YnI+DQomZ3Q7ICZndDsg PC9mb250PjxhIGhyZWY9aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzExNjIv IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48dT5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTE2Mi88L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCihKdW5lIDIwMTIp PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48YSBocmVmPWh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbGlhaXNvbi8xMjA1LyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFp c29uLzEyMDUvDQo8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48YnI+DQomZ3Q7ICZndDsgKE9jdG9iZXIgMjAxMik8YnI+DQomZ3Q7ICZndDsgPC9mb250 PjxhIGhyZWY9aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMjkvIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 dT5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIyOS8NCjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiZndDsgJmd0OyAo SmFudWFyeSAyMDEzKTxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PGEgaHJlZj1odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIzNC8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbGlhaXNvbi8xMjM0Lw0KPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KJmd0OyAmZ3Q7IChGZWJydWFyeSAyMDEzKTxicj4NCiZn dDsgJmd0OyA8L2ZvbnQ+PGEgaHJlZj1odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlz b24vMTI1Ni8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjx1Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjU2 Lw0KPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJy Pg0KJmd0OyAmZ3Q7IChNYXkgMjAxMyk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU29t ZSBkZXRhaWxzIGFib3UgdGhlIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ24gUFNDIGJlaGF2aW91 cg0Kd2l0aDxicj4NCiZndDsgJmd0OyB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzOjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDAgcHJv cG9zZXMgc3dhcHBpbmcgdGhlIHByaW9yaXRpZXM8YnI+DQomZ3Q7ICZndDsgYmV0d2VlbiBGUyBh bmQgU0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIgb2YgcmZjNjM3OCkuPGJyPg0KJmd0OyAmZ3Q7IEFt b25nIHRoZSBvdGhlcnMsIGJlaGF2aW9ycyB0aGF0IHdpbGwgYmUgZml4ZWQgd2l0aCB0aGUgcHJv cG9zZWQ8YnI+DQomZ3Q7IHVwZGF0ZTxicj4NCiZndDsgJmd0OyBhcmU6PGJyPg0KJmd0OyAmZ3Q7 IFVzZSBjYXNlIEEpIEF0IGZpcnN0LCB3b3JraW5nIHBhdGgoV1ApIGFuZCBwcm90ZWN0aW9uIHBh dGgoUFApDQphcmU8YnI+DQomZ3Q7ICZndDsgbm9ybWFsLiBUaGVuLCBGb3JjZWQgU3dpdGNoKEZT KSBjb21tYW5kIGlzIGlzc3VlZCBmb3IgbWFpbnRlbmFuY2UNCm9uPGJyPg0KJmd0OyB0aGU8YnI+ DQomZ3Q7ICZndDsgV1AgYW5kIHRoZSB0cmFmZmljIG1vdmVzIGZyb20gV1AgdG8gUFAuIFdoZW4g U2lnbmFsIEZhaWwgb2NjdXJzDQpvbjxicj4NCiZndDsgJmd0OyBQUCwgc2VydmljZSBjYW5ub3Qg cmVjb3ZlciBhbmQgaXMgaW50ZXJydXB0ZWQuIFRoaXMgY291bGQgb2NjdXINCmZvcjxicj4NCiZn dDsgZXhhbXBsZTxicj4NCiZndDsgJmd0OyBhcyBhIHJlc3VsdCBvZiBhY2NpZGVudGFsbHkgdW4t cGx1Z2dpbmcgYSBQUCBmaWJlci48YnI+DQomZ3Q7ICZndDsgVXNlIGNhc2UgQikgSWYgdGhlcmUg aXMgYW4gZXhpc3Rpbmcgc2lnbmFsIGZhaWwgb24gYSBwcm90ZWN0aW9uDQpwYXRoPGJyPg0KJmd0 OyAmZ3Q7IChTRi1QKSxhbmQgRlMgY29tbWFuZCBpcyBpc3N1ZWQgYnkgYWNjaWRlbnQgdGhlIHRy YWZmaWMgb24gV1ANCndpbGw8YnI+DQomZ3Q7IG1vdmU8YnI+DQomZ3Q7ICZndDsgdG8gUFAuIFRo aXMgcmVzdWx0cyBpbiBhbiBpbnRlcnJ1cHRpb24gb2Ygc2VydmljZSBmcm9tIHdoaWNoDQp5b3U8 YnI+DQomZ3Q7ICZndDsgd2lsbCBub3QgYXV0b21hdGljYWxseSByZWNvdmVyLCBiZWNhdXNlIFBT QyBzaG91bGQgbm90IGhhdmUgc3dpdGNoZWQ8YnI+DQomZ3Q7ICZndDsgdGhlIHRyYWZmaWMgZnJv bSBXUCB0byBQUC48YnI+DQomZ3Q7ICZndDsgRGlzY3Vzc2lvbiBhYm91dCB0aGlzIGRyYWZ0IGxl ZCB0byB0aGUgcHJvcG9zYWwgdG8gbW9kaWZ5IFJGQw0KNDQyNzxicj4NCiZndDsgdGhhdDxicj4N CiZndDsgJmd0OyB3YXMgJnF1b3Q7d3JpdHRlbiBjb3JyZWN0bHkgdGhvdWdoIGxhY2tpbmcgaW4g ZGV0YWlsIGNhdXNpbmcNCm1pcy08YnI+DQomZ3Q7ICZndDsgaW50ZXJwcmV0YXRpb24mcXVvdDsg dGhhdCBsZWQgdG8gdGhlIGN1cnJlbnQgUFNDIHNldCBvZiBwcmlvcml0eQ0KdGhhdCB0aGU8YnI+ DQomZ3Q7ICZndDsgYWJvdmUgZHJhZnQgaXMgcHJvcG9zaW5nIHRvIG1vZGlmaWVkIGFuZCB0byBh bGlnbiB0byB0aGUgcmVxdWlyZWQ8YnI+DQomZ3Q7ICZndDsgdHJhbnNwb3J0IGJlaGF2aW9yLiBk cmFmdC1oZWx2b29ydC1jY2FtcC1mcy1wcmlvcml0eS0wMCBoYXMgYmVlbjxicj4NCiZndDsgJmd0 OyBzdWJtaXR0ZWQgdG8gQ0NBTVAgZm9yIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb25zIHJlbGF0 ZWQgdG8NCk1hbnVhbDxicj4NCiZndDsgJmd0OyBTd2l0Y2ggYW5kIEZvcmNlZCBTd2l0Y2ggYW5k IHRoZWlyIHVzYWdlIHJlbGF0aXZlIHRvIHByaW9yaXRpZXMuPGJyPg0KJmd0OyAmZ3Q7IFRoZSB3 YXkgdGhpcyBiZWhhdmlvciBoYXMgdG8gYmUgaW5jb3Jwb3JhdGVkIGludG8gdGhlIFBTQyBoYXMN CnRvIGJlPGJyPg0KJmd0OyAmZ3Q7IGRpc2N1c3NlZC4gVGhlIHRleHQgcHJvcG9zZXMgdG8gcmVw bGFjZSB0aGUgY3VycmVudCBiZWhhdmlvcg0Kd2l0aDxicj4NCiZndDsgJmd0OyB0aGUgbmV3IG9u ZS4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHByb2NlZGUgaW4gdGhhdCB3YXkgdGhpcw0KY2Fu PGJyPg0KJmd0OyAmZ3Q7IGJyaW5nPGJyPg0KJmd0OyB0bzxicj4NCiZndDsgJmd0OyBhIHNpbXBs ZSBhbmQgZWZmZWN0aXZlIHdheSB0byBvcGVyYXRlIHRoZSBwcm90b2NvbC48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgLS08YnI+DQomZ3Q7 ICZndDsgZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAgY29udGFpbnMgdGhl IHVwZGF0ZXMgdG88YnI+DQomZ3Q7ICZndDsgUkZDNjM3OCB0byBjaGFuZ2Ugbm9uLXJldmVydGl2 ZSBvcGVyYXRpb25zIHRvIGJlaGF2ZXMgaW4gdGhlDQpzYW1lPGJyPg0KJmd0OyAmZ3Q7IHdheSBp cnJlc3BlY3RpdmVseSBvZiB0aGUgdHJpZ2dlciBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZyAoZmF1 bHQNCm9yPGJyPg0KJmd0OyBvcGVyYXRvcjxicj4NCiZndDsgJmd0OyBjb21tYW5kIEZTLCBNUyku IENvbnNlcXVlbnRseSBhbiBvcGVyYXRvciBjb21tYW5kLCBNYW51YWwgU3dpdGNoDQp0bzxicj4N CiZndDsgJmd0OyBXb3JraW5nIChNUy1XKSBhLmsuYSAmcXVvdDtNYW51YWwgc3dpdGNoLW92ZXIg Zm9yIHJlY292ZXJ5IExTUC9zcGFuJnF1b3Q7DQppczxicj4NCiZndDsgYWxzbzxicj4NCiZndDsg Jmd0OyBhZGRlZCB0byBlbmFibGUgdGhpcyBiZWhhdmlvci4gRnJvbSBhbiBvcGVyYXRpb25hbCBw b2ludCBvZiB2aWV3LA0KTVM8YnI+DQomZ3Q7IHRvPGJyPg0KJmd0OyAmZ3Q7IHdvcmtpbmcgcGF0 aCBoYXMgYWxzbyB0byBiZSBzdXBwb3J0ZWQgdG8gYmUgYWJsZSB0byBpbml0aWFsbHkNCmFsaWdu PGJyPg0KJmd0OyAmZ3Q7IGF0IGJvdGggc2lkZXMgaW4gY2FzZSBvZiBub24tcmV2ZXJ0aXZlIHN3 aXRjaGluZyBtb2RlLiBNUyB0bw0Kd29ya2luZzxicj4NCiZndDsgJmd0OyBwYXRoIGlzIGRlZmlu ZWQgaW4gUkZDIDU2NTQsIHJlcXVpcmVtZW50IDgzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBUaGUgcHJvcG9zZWQgTVMtVyBjb21tYW5kIGlzIG9mIGVxdWFsIHByaW9yaXR5IHRvIHRo ZSBleGlzdGluZw0KTVMtUDxicj4NCiZndDsgJmd0OyBjb21tYW5kLCBhbmQgdGhlcmUgaXMgdGV4 dCB0byBoYW5kbGUgdGhlIHNpbXVsdGFuZW91cyBvciBzZXF1ZW50aWFsPGJyPg0KJmd0OyAmZ3Q7 IG9jY3VycmVuY2Ugb2YgdHdvIGVxdWFsLXByaW9yaXR5IGNvbW1hbmRzLiBUaGlzIGJlaGF2aW9y LCBhbHJlYWR5PGJyPg0KJmd0OyAmZ3Q7IGFkb3B0ZWQgaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdv cmsgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcHJvdG9jb2wsPGJyPg0KJmd0OyAmZ3Q7IGNhbjxicj4N CiZndDsgYmU8YnI+DQomZ3Q7ICZndDsgdXNlZCBmb3Igb3RoZXIgYWRkaXRpb24gdG8gdGhlIHBy b3RvY29sIGluIHRoZSBmdXR1cmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LXJoZC1tcGxzLXRw LXBzYy1zZC0wMCBwcm92aWRlcyBleHRlbnNpb25zIHRvIHRoZSBQU0Mgc3RhdGU8YnI+DQomZ3Q7 ICZndDsgbWFjaGluZSB0byBoYW5kbGUgU2lnbmFsIERlZ3JhZGUgKFNEKS4gSXQgZG9lcyBub3Qg ZGVmaW5lIFNEDQpvcjxicj4NCiZndDsgcHJvdmlkZTxicj4NCiZndDsgJmd0OyBzY29wZSBhcm91 bmQgd2hlcmUgb3IgaG93IFNEIG1heSBiZSB1c2VkIHNpbWlsYXJseSBhcyBpdCBhbHJlYWR5PGJy Pg0KJmd0OyBoYXBwZW48YnI+DQomZ3Q7ICZndDsgaW4gdGhlIGRyYWZ0IGluIGhhbmRsaW5nIG90 aGVyIGRlZmVjdHMgbGlrZSBTRiAoU2lnbmFsIEZhaWx1cmUpLjxicj4NCiZndDsgJmd0OyBJbiBN UExTLVRQIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIFtSRkM2MzcyXSwgYSBmYXVsdCBjb25kaXRp b248YnI+DQomZ3Q7ICZndDsgaW5jbHVkZXMgYm90aCBTaWduYWwgRmFpbCAoU0YpIGFuZCBTaWdu YWwgRGVncmFkZSAoU0QpIHRoYXQgY2FuDQpiZTxicj4NCiZndDsgdXNlZDxicj4NCiZndDsgJmd0 OyB0byB0cmlnZ2VyIHByb3RlY3Rpb24gc3dpdGNoaW5nLjxicj4NCiZndDsgJmd0OyBXaGlsZSB0 aGUgc3RhbmRhcmRpemF0aW9uIGxhY2sgb2YgYW4gU0QgZGVmaW5pdGlvbiBhbmQgZGV0ZWN0aW9u PGJyPg0KJmd0OyAmZ3Q7IG1lY2hhbmlzbXMsIHRoZSByZWxldmFudCBiZWhhdmlvcnMgaW4gdGVy bXMgb2YgcHJvdGVjdGlvbiBhY3Rpb25zPGJyPg0KJmd0OyAmZ3Q7IG1heSBhbHJlYWR5IGJlIGRl ZmluZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0 OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LWRqLW1wbHMtdHAtZXhlci1wc2MtMDEgcHJv cG9zZXMgYWRkaW5nIHRoZSBFWEVSL1JSIGNvbW1hbmRzDQp0bzxicj4NCiZndDsgJmd0OyB0ZXN0 IGlmIHRoZSBBUFMgY29tbXVuaWNhdGlvbiBpcyBvcGVyYXRpbmcgY29ycmVjdGx5LiBJbiBvdGhl cg0Kd29yZHM8YnI+DQomZ3Q7ICZndDsgYm90aCBBUFMgcHJvY2VzcyBsb2dpYyBpbmNsdWRpbmcg c3RhdGUgbWFjaGluZSBhbmQgQVBTIGNoYW5uZWwNCm9uPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3Rp b24gcGF0aCwgd2l0aG91dCBzZXJ2aWNlIGRpc3J1cHRpb24gYW5kIHdpdGhvdXQgYWZmZWN0aW5n PGJyPg0KJmd0OyAmZ3Q7IGFueSBwcm90ZWN0aW9uIG9wZXJhdGlvbiwgdW5sZXNzIHRoZSBwcm90 ZWN0aW9uIHRyYW5zcG9ydCBlbnRpdHkNCmlzPGJyPg0KJmd0OyAmZ3Q7IGluPGJyPg0KJmd0OyB1 c2UuPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgY29tbWFuZCBpcyBkb2N1bWVudGVkIGluIFI4NCBvZiBb UkZDNTY1NF0gYW5kIGl0IGlzIHBhcnQNCm9mPGJyPg0KJmd0OyAmZ3Q7IElUVS1UIHRyYW5zcG9y dCByZXF1aXJlbWVudHMuPGJyPg0KJmd0OyAmZ3Q7IEFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIGlz IGRvY3VtZW50ZWQgaW4gdGhlIEFwcGVuZGl4IEIgb2YgUkZDNjM3ODxicj4NCiZndDsgdGhhdDxi cj4NCiZndDsgJmd0OyB1dGlsaXplcyB0aGUgTG9ja291dCBvZiBQcm90ZWN0aW9uIChMTykgb3Ig Rm9yY2VkIFN3aXRjaCAoRlMpDQppbjxicj4NCiZndDsgJmd0OyBjb21iaW5hdGlvbiBvZiBPQU0g ZnVuY3Rpb25hbGl0aWVzLiBIb3dldmVyLCBpdCBoYXMgc29tZSBmdW5jdGlvbmFsPGJyPg0KJmd0 OyAmZ3Q7IGxpbWl0YXRpb24gYW5kIGhhcyBhIHBvdGVudGlhbCByaXNrIG9mIGxvc2luZyB0cmFm ZmljIGFzIGEgc2lnbmFsPGJyPg0KJmd0OyAmZ3Q7IGZhaWx1cmUgbWlnaHQgb2NjdXIgZHVyaW5n IHRoZSBleGVyY2lzZSBvcGVyYXRpb24uIEluIHRoYXQgY2FzZSwNCkxPPGJyPg0KJmd0OyAmZ3Q7 IG9yIEZTIGhhcyB0byBiZSBjYW5jZWxlZCB0byBhbGxvdyB0aGUgUFNDIHByb3RvY29sIHRvIHBy b3ZpZGUNCnByb3Blcjxicj4NCiZndDsgJmd0OyBzd2l0Y2hpbmcuPGJyPg0KJmd0OyAmZ3Q7IEEg ZnVydGhlciBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBpcyBkb2N1bWVudGVkIGluIGRyYWZ0LW9zYm9y bmUtbXBscy08YnI+DQomZ3Q7IHBzYy08YnI+DQomZ3Q7ICZndDsgYWxpdmUtMDAgdGhhdCBhbnl3 YXkgc2hvdyBzb21lIGZ1bmN0aW9uYWwgbGltaXRhdGlvbnMgYmVjYXVzZQ0KY2Fubm90PGJyPg0K Jmd0OyAmZ3Q7IHZhbGlkYXRlIHRoZSBQU0Mgc3RhdGUgbWFjaGluZSBzdGF0dXMgYW5kIHByb2Jh Ymx5IHRoZSBMb2NhbA0KUmVxdWVzdDxicj4NCiZndDsgJmd0OyBsb2dpYy48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGF1dGhvcnMgZW5jb3VyYWdlIHRo ZSBJRVRGIGV4cGVydHMgdG8gY29tbWVudCBvbiB0aGVzZSBkcmFmdHMsPGJyPg0KJmd0OyAmZ3Q7 IGV2ZW50dWFsbHkgcHJvcG9zaW5nIG90aGVyIG9wdGlvbnMvbWVjaGFuaXNtcyB0aGF0IGNhbiBz YXRpc2Z5DQp0aGU8YnI+DQomZ3Q7IHNhbWU8YnI+DQomZ3Q7ICZndDsgcmVxdWlyZW1lbnRzLjxi cj4NCiZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IEFsZXNzYW5kcm8sIEh1 dWIsIEplb25nLWRvbmcsIFRhZWtzaWQgUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaTxicj4NCiZn dDsgJmd0OyBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlPGJyPg0KJmd0 OyBhbGxlPGJyPg0KJmd0OyAmZ3Q7IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNv cGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZTxicj4NCiZndDsgJmd0OyBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZTxi cj4NCiZndDsgJmd0OyB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlDQpzaWV0ZTxicj4NCiZndDsgJmd0OyBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZQ0KZTxicj4N CiZndDsgJmd0OyBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbjxicj4NCiZndDsgJmd0OyBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuPGJyPg0K Jmd0OyAmZ3Q7IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnli b2R5IGVsc2UgaXM8YnI+DQomZ3Q7IHVuYXV0aG9yaXNlZC48YnI+DQomZ3Q7ICZndDsgSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3Nh Z2U8YnI+DQomZ3Q7ICZndDsgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyByaXNwZXR0YSBsJ2FtYmllbnRlUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1 ZXN0YSBtYWlsDQpzZTxicj4NCiZndDsgbm9uPGJyPg0KJmd0OyAmZ3Q7IKioIG5lY2Vzc2FyaW8u PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8L2ZvbnQ+ PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQomZ3Q7IDwvZm9udD48YSBocmVmPWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PC9m b250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJy Pg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzptcGxzQGlldGYub3JnPjxmb250IHNpemU9MyBj b2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+bXBsc0BpZXRmLm9yZzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+ PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cm1wbHMgbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzptcGxzQGll dGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+ bXBsc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1h aWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz48dHQ+PGZvbnQgc2l6ZT0y Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvZm9udD48L3R0Pjwv YT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0053BF9285257BB2_=-- From Malcolm.BETTS@zte.com.cn Wed Jul 24 08:24:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBFC11E8248; Wed, 24 Jul 2013 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.043 X-Spam-Level: X-Spam-Status: No, score=-95.043 tagged_above=-999 required=5 tests=[AWL=1.493, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mevPLF3GNQx; Wed, 24 Jul 2013 08:24:13 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05211E8153; Wed, 24 Jul 2013 08:23:06 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id EF10E9211D; Wed, 24 Jul 2013 23:22:28 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 15E7C757218; Wed, 24 Jul 2013 23:22:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6OFMbfc000167; Wed, 24 Jul 2013 23:22:37 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <51EDBC18.4060104@gmail.com> References: <22257C41A415324A984CD03D63344E271F1B7A8B@TELMBA002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A2757210288D02@xmb-rcd-x09.cisco.com> <51ED1541.70108@gmail.com> <20ECF67871905846A80F77F8F4A275721028A463@xmb-rcd-x09.cisco.com> <51EDBC18.4060104@gmail.com> To: huubatwork@gmail.com MIME-Version: 1.0 X-KeepSent: BEC3442D:1D2724E1-85257BB2:0053FEB9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 24 Jul 2013 11:22:33 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-24 23:22:36, Serialize complete at 2013-07-24 23:22:36 Content-Type: multipart/alternative; boundary="=_alternative 00547E5685257BB2_=" X-MAIL: mse02.zte.com.cn r6OFMbfc000167 Cc: "Huub helvoort \(huub.van.helvoort@huawei.com\)" , "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Jul 2013 15:24:18 -0000 This is a multipart message in MIME format. --=_alternative 00547E5685257BB2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggdGhlIHBvaW50cyByYWlzZWQgYnkgSHV1Yi4gT25lIGZ1 cnRoZXIgY29uc2lkZXJhdGlvbiwgaW4gYSANCnR5cGljYWwgbmV0d29yayB3aXRob3V0IHRoZSBl eGVyY2lzZXIgdGhlIEFQUyB3aWxsIGVzc2VudGlhbGx5IHNpdCBpbiBhbiANCmlkbGUgc3RhdGUg c2VuZGluZyAia2VlcCBhbGl2ZSIgbWVzc2FnZXMgZm9yIHllYXJzLCB1bnRpbCBhIGZhdWx0IGlz IA0KZGV0ZWN0ZWQgb24gdGhlIHdvcmtpbmcgcGF0aC4gIEF0IHRoaXMgdGltZSBBUFMgbXVzdCAi d2FrZSB1cCIgYW5kIGV4ZWN1dGUgDQphIHN3aXRjaCB0byBwcm90ZWN0aW9uLiBUaGUgcHVycG9z ZSBvZiB0aGUgZXhlcmNpc2VyIGlzIHRvIHZlcmlmeSB0aGF0IHRoZSANCkFQUyBzdGF0ZSBtYWNo aW5lIGhhcyBub3Qgc3VmZmVyZWQgc29tZSBvYnNjdXJlIGZhdWx0IGNvbmRpdGlvbiB3aGljaCAN Cm90aGVyd2lzZSB3b3VsZCByZW1haW4gdW5kZXRlY3RlZCB1bnRpbCBhIHNlY29uZCBmYXVsdCBv Y2N1cnMuICBJdCBpcyANCnRoZXNlICJzaWxlbnQgZmFpbHVyZXMiIGNhdXNlIHNlcnZpY2Ugb3V0 YWdlcy4NCg0KUmVnYXJkcywNCg0KTWFsY29sbQ0KDQoNCg0KDQpIdXViIHZhbiBIZWx2b29ydCA8 aHV1YmF0d29ya0BnbWFpbC5jb20+IA0KU2VudCBieTogbXBscy1ib3VuY2VzQGlldGYub3JnDQoy Mi8wNy8yMDEzIDA3OjExIFBNDQpQbGVhc2UgcmVzcG9uZCB0bw0KaHV1YmF0d29ya0BnbWFpbC5j b20NCg0KDQpUbw0KIkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29t Pg0KY2MNCiJIdXViIGhlbHZvb3J0IFwoaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNvbVwpIiAN CjxodXViLnZhbi5oZWx2b29ydEBodWF3ZWkuY29tPiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGll dGYub3JnPg0KU3ViamVjdA0KUmU6IFttcGxzXSBwcm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5n IE1QTFMtVFAgUFNDIGxpbmVhciBwcm90ZWN0aW9uIA0KcHJvdG9jb2wgdG8gdHJhbnNwb3J0IHJl cXVpcmVtZW50cw0KDQoNCg0KDQoNCg0KSGVsbG8gRXJpYywNCg0KWW91IHJlcGxpZWQ6DQoNCiA+ IElubGluZSB3aXRoIEVPIywgdHJpbW1lZCBhIGJpdC4NCg0KTXkgcmVzcG9uc2UgaW5saW5lIFtI dXViMl0NCg0KPj4NCj4+IFRoZXJlIHdhcyBhdHdvIHdlZWsgSVRVLVQgcGxlbmFyeSBtZWV0aW5n LCBhbmQgYWZ0ZXIgdGhhdCBJIHRvb2sNCj4+IChhbmQgc3RpbGwgaGF2ZSkgYSBob2xpZGF5Lg0K Pg0KPiBJZiB5b3UncmUgb24gaG9saWRheSwgd2h5IGFyZSB5b3Ugd29ya2luZz8NCg0KW0h1dWIy XSBJdCBpcyB0b28gaG90IG91dHNpZGUsIGFuZCBJIGhhZCBkdWcgb3V0IG15IGxvZ2Jvb2tzIGZy b20NCmJlZm9yZSAxOTg0LCBJIHdhbnQgdG8gdG8gcmV0dXJuIHRvIHN0b3JhZ2UgYXMgc29vbiBh cyBwb3NzaWJsZSAgXl9eDQoNCj4gIEkgdGhvdWdodCB0aGF0IHdhcyBhIHVuaXF1ZWx5IEFtZXJp Y2FuIHRyYWl0Lg0KDQpbSHV1YjJdIG1heWJlIGl0IGlzIGluZmVjdGlvdXMuLi4NCg0KPiBJcyB0 aGlzIHN0dWZmIHRoYXQgbXVjaCBmdW4gdG8geW91PyA6KQ0KDQpbSHV1YjJdIG15IHdpZmUgZG9l cyBub3QgbGlrZSB0aGUgcGlsZXMgb2YgbG9nYm9va3MgYW5kIEkgbGlrZQ0KdG8gc2hhcmUgbXkg a25vd2xlZGdlDQoNCj4gLi4uDQo+DQo+Pj4gaSkgY2FuIHlvdSBleHBsYWluIEVYRVIgYXQgYSBo aWdoZXIgbGV2ZWw/ICBJJ20gbm90IGxvb2tpbmcgZm9yIGENCj4+PiBkZXNjcmlwdGlvbiBvZiB0 aGUgc3RhdGUgbWFjaGluZSBjaGFuZ2VzLCBhbmQgSSdtIG5vdCBsb29raW5nIGZvciB0aGUNCj4+ PiBvbmUgbGluZSAiSXQgYWxsb3dzIHRoZSBGU00gdG8gYmUgdGVzdGVkIi4gIFdlIGhhdmUgYWxs IG9mIHRoYXQgaW4NCj4+PiB0aGUgZHJhZnQgYW5kIGluIHRoZSBlcXVpdmFsZW50IElUVSBzcGVj cy4NCj4+Pg0KPj4+IFdoYXQgSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCBhYm91dCBFWEVSIGlzIHdo ZXJlIGl0IGNhbWUgZnJvbS4gIFRoZQ0KPj4+IElUVSBzcGVjcyB0aGF0IGRlZmluZSBpdCBhcmUg cHJldHR5IGhhcmQgdG8gZm9sbG93LCB0aGV5IHNlZW0gdG8NCj4+PiBhc3N1bWUgdGhlIHJlYWRl ciBhbHJlYWR5IGtub3dzIHdoYXQgRVhFUiBpcyBhbmQgd2hhdCBwcm9ibGVtIGl0DQo+Pj4gc29s dmVzLiAgSXQgZmVlbHMgdmVyeSBtdWNoIGxpa2UgYSBtZWNoYW5pc20gdXNlZCB0byBjYXRjaCBh IHZlcnkNCj4+PiBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBidWcsIGJhY2sgd2hlbiB0cmFuc3Bv cnQgZ2VhciB3YXMgZmFyIGxlc3MNCj4+PiBkZWJ1Z2dhYmxlIHRoYW4gd2hhdCB3ZSBoYXZlIHRv ZGF5Lg0KPj4NCj4+IFtIdXViXSBFWEVSIHdhcyBub3QgZGVzaWduZWQvaW50ZW5kZWQgdG8gYmUg dXNlZCBmb3IgYnVnIGZpbmRpbmcNCj4+IGFsdGhvdWdoIGl0IHdpbGwgZGV0ZWN0IHByb2JsZW1z IHdpdGggaW1wbGVtZW50YXRpb24uDQo+Pg0KPj4gW0h1dWJdIEVYRVIgd2FzIGRlc2lnbmVkIHRv IHZlcmlmeSB0aGF0IHRoZSBzdGF0ZS1tYWNoaW5lIGF0IHRoZQ0KPj4gZmFyIGVuZCBpcyBhYmxl IHRvIHJlc3BvbmQgdG8gQVBTL1BTQyBtZXNzYWdlcyBpdCByZWNlaXZlcyBmcm9tDQo+PiB0aGUg bG9jYWwgZW5kLg0KPj4gRXZlbiB0aG91Z2ggc3RhdGUtbWFjaGluZXMgc2hvdWxkIGJlIHRlc3Rl ZCBleHRlbnNpdmVseSwgdGhlcmUgaXMNCj4+IG5vIDEwMCUgd2FycmFudHkuIEl0IGNhbiBzdGls bCBoYXZlIHN0b3BwZWQgZHVlIHRvIGV4dGVybmFsDQo+PiBjaXJjdW1zdGFuY2VzLCBiZSBpbiBh IGRlYWRsb2NrIGR1ZSB0byB1bmZvcnNlZW4gb3JkZXIgb2YgZXZlbnRzLA0KPj4gZXRjLg0KPg0K PiBFTyMgIEkgYWdyZWUgd2l0aCB5b3VyIGxhc3QgdHdvIHN0YXRlbWVudHMuICBUbyBtZSwgdGhv dWdoLCB0aGF0DQogPiB2ZXJ5IHRleHQgaXMgYSByZWFzb25hYmxlIGFyZ3VtZW50IGFnYWluc3Qg RVhFUi4NCiA+IFRoZXJlIGlzIG5vIG1lY2hhbmlzbSB3aXRoaW4gYSBwcm90b2NvbCB3aGljaCBj YW4gZ3VhcmFudGVlIHRoYXQNCiA+IHRoZSBlbnRpcmUgc3RhdGUgbWFjaGluZSBpcyAxMDAlIHBl cmZlY3QuDQoNCltIdXViMl0gaW5kZWVkDQoNCj4gQSBub2RlIGNvdWxkIGJlIGFibGUgdG8gcmVz cG9uZCB0byBFWEVSL1JSIGJ1dCBiZSB1bmFibGUgdG8gcHJvY2Vzcw0KID4gYSByZWFsIGZhaWx1 cmUgcHJvcGVybHksIGVpdGhlciBkdWUgdG8gYnVnIG9yIHRvIChhcyB5b3UgaW5kaWNhdGUpDQog PiBzb21lIHVuZm9yc2VlbiBjb21iaW5hdGlvbiBvZiBleHRlcm5hbCBldmVudHMuDQoNCltIdXVi Ml0gaW4gdGhlIGNhc2UgeW91IGRlc2NyaWJlIHRoZSBub2RlIGhhcyB0byBzZW5kIHBlcmlvZGlj YWwNCk5SIF9BTkRfIHJlc3BvbmQgdG8gdGhlIEVYRVIgd2hpbGUgbm90IHJlc3BvbmRpbmcgdG8g YSByZWFsIFNGL1NELA0KdGhpcyB3b3VsZCBiZSBhIHZlcnkgY29tcGxleCBzdGF0ZS1tYWNoaW5l IGZhdWx0Lg0KDQo+IFRoZSBjbGFzcyBvZiBwcm9ibGVtcyB3aGljaCBFWEVSIGNhbiBjYXRjaCBi dXQgd2hpY2ggd2lsbCBub3QgYmUNCiA+IGRldGVjdGFibGUgYnkgb3RoZXIgbWVhbnMgKGUuZy4g Q0MvQ1YsIHNlZSBiZWxvdykgc2VlbXMgcHJldHR5IHNtYWxsLg0KDQpbSHV1YjJdIHRoZSBFWEVS IHdpbGwgZGV0ZWN0IHRoZSBtb3N0IGNvbW1vbiAic3R1Y2stYXQiIHByb2JsZW1zLg0KDQo+IElu IHRoZSB0cmFuc3BvcnQgd29ybGQsIHdoYXQgc29ydCBvZiBwcm9ibGVtcyBkb2VzIEVYRVIgX2Fj dHVhbGx5IGZpbmRfPw0KID4gIEknbSBub3QgYXNraW5nIGFib3V0IHRoaW5ncyBpdCBfY291bGRf IGZpbmQsIGJ1dCB0aGluZ3MgdGhhdCBpdCANCipkb2VzKi4NCg0KW0h1dWIyXSBzdHVjay1hdCwg ZGVhZGxvY2sNCg0KPj4gW0h1dWJdIG5vdGUgdGhhdCBBUFMvUFNDIHNob3VsZCBjb250aW51ZSB0 byBvcGVyYXRlIGV2ZW4gaWYgbm8NCj4+IGNvbnRyb2wgcGxhbmUgaXMgYXZhaWxhYmxlLg0KPg0K PiBFTyMgIEkgYWdyZWUsIGJ1dCB0aGlzIGlzIG5vdCByZWxldmFudCB0byB0aGUgZGlzY3Vzc2lv biBhdCBoYW5kLg0KID4gTG90cyBvZiB3b3JrIHdhcyBkb25lIGluIFRQIHRvIGVuc3VyZSB0aGF0 IGl0IHdvdWxkIGZ1bmN0aW9uIHdpdGhvdXQNCiA+IHRoZSBhYmlsaXR5IHRvIGZvcndhcmQgSVAg cGFja2V0cyAod2hpY2ggSSB0aGluayBpcyB3aGF0IHlvdSBtZWFuIGJ5DQogPiAnbm8gY29udHJv bCBwbGFuZScpLiAgTm9uZSBvZiB0aGF0IGhhcyBhbnl0aGluZyB0byBkbyB3aXRoIHRoZSBzZXQN CiA+IG9mIG1lc3NhZ2VzIGFuZCBzdGF0ZXMgaW4gUFNDLg0KDQpbSHV1YjJdIEkgZGlkIG1lYW4g dG8gc2F5IHRoYXQgdGhlIGV4ZXJjaXNlIHJlcXVlc3QgY2Fhbm90IGJlIHNlbnQNCnZpYSB0aGUg Y29udHJvbCBwbGFuZSwgc28gaXQgc2hvdWxkIGJlIGluIHRoZSBkYXRhcGxhbmUuIFNpbmNlIHRo ZQ0KQVBTL1BTQyBzdGF0ZS1tYWNoaW5lIGlzIGV4ZXJjaXNlZCB0aGUgRVhFUiBjb21tYW5kIHNo b3VsZCBiZSBwYXJ0DQpvZiB0aGUgQVBTL1BTQyBwcm90b2NvbC4NCg0KPj4gVGhlIEVYRVIgaXMg dG8gZW5hYmxlIGFuIG9wZXJhdG9yIHRvDQo+PiB0YWtlIGNvcnJlY3RpdmUgYWN0aW9uIGJlZm9y ZSBhIHByb3RlY3Rpb24gc3dpdGNoIHJlcXVlc3QgZmFpbHMNCj4+IGFuZCB0aGUgNTBtcyBzd2l0 Y2ggdGltZSBpcyBub3QgbWV0Lg0KPj4NCj4+PiBObyBvdGhlciBzdGF0ZSBtYWNoaW5lcyB0aGF0 IEknbSBmYW1pbGlhciB3aXRoIChSU1ZQLCBMRFAsIEJHUCwgT1NQRiwNCj4+PiBJU0lTKSBoYXZl IGV4cGxpY2l0IHNpZ25hbGluZyBpbiB0aGVtIGp1c3QgdG8gYXNrIHRoZSBuZWlnaGJvcg0KPj4+ IHdoZXRoZXIgaXQgKndvdWxkKiBiZSBicm9rZW4gaWYgaWYgd2VyZSwgaW4gdGhlIGZ1dHVyZSwg dG8gYmUgZ2l2ZW4gYQ0KPj4+IHBhcnRpY3VsYXIgaW5wdXQuDQo+Pg0KPj4gW0h1dWJdIEFsbCB0 aGVzZSByZWx5IG9uIGEgY29udHJvbCBwbGFuZSwgc29tZSBvZiB0aGVuIGluY2x1ZGUNCj4+ICJr ZWVwYWxpdmUiIG1lc3NhZ2VzIHRvIHNlZSBpZiB0aGUgZmFyIGVuZCByZXNwb25kcy4NCj4NCj4g RU8jICBQU0MgaGFzIGtlZXBhbGl2ZXM7IHNlZSBzZWN0aW9uIDQuMSBvZiByZmM2Mzc4IC0gIlRo ZSBwdXJwb3NlIG9mDQogPiB0aGUgY29udGludWFsIG1lc3NhZ2VzIGlzIHRvIHZlcmlmeSB0aGF0 IHRoZSBQU0Mgc2Vzc2lvbiBpcyBzdGlsbCANCmFsaXZlLiINCg0KW0h1dWIyXSBpdCBvbmx5IHBy b3ZlcyB0aGF0IHRoZSBzdGF0ZS1tYWNoaW5lIGNhbiBzZW5kIE5SIHByaW9kaWNhbGx5LA0KaXQg ZG9lcyBub3QgcHJvdmUgdGhhdCBpdCB3aWwgcmVzcG9uZCB0byBhbnkgZXh0ZXJuYWwvcmVtb3Rl IGV2ZW50cy4NClRoZSBFWEVSIHdpbGwgZ2l2ZSBtdWNoIG1vcmUgY29uZmlkZW5jZSBvZiBiZWlu ZyBhbGl2ZS4NCg0KPiBUaGUgbmV4dCBzZW50ZW5jZSBzYXlzICJJZiBubyB2YWxpZCBQU0MgbWVz c2FnZSBpcyByZWNlaXZlZCwgb3ZlciBhDQogPiBwZXJpb2Qgb2Ygc2V2ZXJhbCBjb250aW51YWwg bWVzc2FnZXMgaW50ZXJ2YWxzLCB0aGUgbGFzdCB2YWxpZA0KID4gcmVjZWl2ZWQgbWVzc2FnZSBy ZW1haW5zIGFwcGxpY2FibGUuIiAgQXMgYW4gaW1wbGVtZW50b3IsIHdoYXQgdGhhdA0KID4gbWVh bnMgdG8gbWUgaXMgdGhhdCBJIHRpbWUgb3V0IG9ubHkgYWZ0ZXIgdGhlIGxvc3Mgb2YgYSBmZXcN CiA+IHJldHJhbnNtaXNzaW9ucy4NCg0KW0h1dWIyXSB5ZXMsIHRoaXMgaXMgcGFydCBpZiB0aGUg UERVIHZhbGlkYXRpb24gcHJvY2Vzcw0KDQo+Pj4gUGFydCBvZiBteSByZWx1Y3RhbmNlIHRvIGdl dCBiZWhpbmQgRVhFUiBoYXMgYmVlbg0KPj4+IHRoYXQgSSBkb24ndCBmZWVsIGNvbWZvcnRhYmxl IHdpdGggdGhlIGlkZWEgb2Yga2VlcGluZyBhIDMwLXllYXItb2xkDQo+Pj4gd29ya2Fyb3VuZCBp biBhIHByb3RvY29sLg0KPj4NCj4+IFtIdXViXSBpdCBpcyBOT1QgYSB3b3JrYXJvdW5kLCBpdCBp cyBhbiBlc3NlbnRpYWwgcGFydCBvZiB0aGUNCj4+IHByb3RvY29sLg0KPg0KPiBFTyMgIEluIGEg VERNIHdvcmxkLCBJIGNhbiBzZWUgdGhpcyBwb2ludC4gIEFQUyBpcyBjYXJyaWVkIGluIHRoZQ0K ID4gZnJhbWUgaGVhZGVyLCBzbyB0aGUgcmVjZWlwdCBvZiBhbiBBUFMgbWVzc2FnZSBkb2Vzbid0 IG1lYW4gdGhhdA0KID4gdGhlcmUncyBhbnkgaW50ZWxsaWdlbmNlIGJlaGluZCBpdCBhcyBpdCBj b3VsZCBqdXN0IGJlIHRoZSBoYXJkd2FyZQ0KID4gcmVwZWF0aW5nIHRoZSBsYXN0IEFQUyBvdmVy aGVhZCB0aGF0IGl0IHNlbnQuICBJZiBhIFBTQyBtZXNzYWdlIGlzDQogPiBzZW50IGl0IG11c3Qg aGF2ZSBiZWVuIHNlbnQgZGVsaWJlcmF0ZWx5LCBhcyBkdXJpbmcgc3RlYWR5IHN0YXRlDQogPiB3 ZSBoYXZlIHBlcmlvZGljIHJldHJhbnNtaXNzaW9ucy4gIERvIHlvdSBhZ3JlZT8NCg0KW0h1dWIy XSBzaW1pbGFybHkgaGFyZHdhcmUgKG9yIHNvZnR3YXJlKSBjYW4gY29udGlvdW91c2x5IHNlbmQN Ck5SIG1lc3NhZ2VzLiBTbyBJIGFncmVlIHRoYXQgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3 ZWVuIFRETQ0KYW5kIHBhY2tldCBBUFMvUFNDLg0KDQo+Pj4gSXMgdGhlcmUgbW9yZSB0byBpdCB0 aGFuIHRoYXQ/ICBIYXZlIEkNCj4+PiBtaXNyZWFkIGFuZCBtaXN1bmRlcnN0b29kIEVYRVI/ICBE b2VzIG1vZGVybiB0cmFuc3BvcnQgZ2VhciBldmVyDQo+Pj4gYWN0dWFsbHkgZGV0ZWN0IGEgcHJv YmxlbSB2aWEgRVhFUi9SUiB0aGF0IHdhc24ndCBvYnZpb3VzIHRvIHRoZQ0KPj4+IG9wZXJhdG9y IHVzaW5nIG90aGVyIG1lYW5zPw0KPj4NCj4+IFtIdXViXSBpZiB0aGVyZSBpcyBubyBjb250cm9s IHBsYW5lIEkgaGF2ZSBubyBvdGhlciBtZWFucy4NCj4+IFdoYXQgbWVhbnMgYXJlIGF2YWlsYWJs ZSB0byB2ZXJpZnkgaWYgYSBzdGF0ZS1tYWNoaW5lIHRoYXQgaXMNCj4+IGluIGEgc3RhYmxlIHN0 YXRlIGlzIHN0aWxsIGZ1bmN0aW9uaW5nPw0KPg0KPiBFTyMgIFBlcmlvZGljIHJldHJhbnNtaXNz aW9uIG9mIGN1cnJlbnQgc3RhdGUgYnkgdGhlIHJlbW90ZSBzaWRlLg0KID4gVGhpcyBwZXJmb3Jt cyB0aGUgZXhhY3Qgc2FtZSBmdW5jdGlvbiBhcyBhIGtlZXBhbGl2ZSBpbiBhbnkgb3RoZXINCiA+ IHByb3RvY29sLCBhbmQgSSB0aGluayB3ZSBhZ3JlZSB0aGF0IHRoZSBrZWVwYWxpdmUgZnVuY3Rp b24gaW4NCiA+IHByb3RvY29scyBzdWNoIGFzIE9TUEYgaXMgc3VmZmljaWVudCB0byBlbnN1cmUg dGhlIHNhbml0eSBvZiB0aGUNCiA+IHJlbW90ZSBlbmQuDQoNCltIdXViMl0gc2VlIGFib3ZlIGZv ciB0aGUgcG9zc2liaWx0eSBvZiBzdHVjay1hdCByZXBlYXRpbmcgb25seQ0KdGhlIE5SIG1lc3Nh Z2UuDQoNCj4gTWFueSwgbWFueSBwcm90b2NvbHMgdXNlIGtlZXBhbGl2ZXMgYXMgYSBzb3J0IG9m IGJlbHQtYW5kLXN1c3BlbmRlcnMNCiA+IGZhaWx1cmUgZGV0ZWN0aW9uIG1lY2hhbmlzbS4gIElu IHRoZSBJUCB3b3JsZCB0aGVzZSBtZWNoYW5pc21zIGFyZQ0KID4gZmFyLCBmYXIgbGVzcyB1c2Vm dWwgdGhhbiB0aGV5IHVzZWQgdG8gYmUgYXMgd2Ugbm93IGhhdmUgQkZELg0KDQpbSHV1YjJdIEkg d291bGQgY29uc2lkZXIgdGhlICJoZWxsbyIgbWVzc2FnZSB0byBoYXZlIHRoZSBzYW1lIHB1cnBv c2UNCmFzIHRoZSBFWEVSIG1lc3NhZ2U6IGNoZWNrIGlmIHRoZSByZW1vdGUgQkZEIHNlc3Npb24g aXMgc3RpbGwgdXAuDQoNCj4gVGhhdCBicmluZ3MgdXMgdG8gQ0MvQ1YuICAgTG90cyBvZiB3b3Jr IHdhcyBkb25lIHRvIGVuc3VyZSB0aGF0IGl0DQogPiBkaWQgbm90IHJlcXVpcmUgSVAgdG8gZnVu Y3Rpb24uICBJIGNhbm5ub3QgYmVsaWV2ZSB0aGF0IGFueSBUUA0KID4gaW1wbGVtZW50YXRpb24g d291bGQgc2hpcCB3aXRob3V0IHNvbWUgc29ydCBvZiBDQy9DViwgYW5kIGlzbid0DQogPiB0aGF0 IGEgc3Ryb25nIGVub3VnaCBtZWNoYW5pc20gdG8gZGV0ZWN0IHRoZSBmYWlsdXJlIG9mIHRoZSBy ZW1vdGUNCiA+IGVuZD8NCg0KW0h1dWIyXSBDQy9DViBvbmx5IGNoZWNrcyB0aGUgY29uZHVjdGl2 aXR5IGFuZCBjb25uZWN0aXZpdHkgb2YgYSBwYXRoDQpJdCBoYXMgbm8gcmVsYXRpb24gYXQgYWxs IHdpdGggdGhlIEFQUy9QU0Mgc3RhdGUtbWFjaGluZSBvdGhlciB0aGFuDQppbiBjYXNlIENDL0NW IGNhdXNlcyBhIHNpZ25hbCBmYWlsIGRlZmVjdCB0aGUgcmVzdWx0aW5nIFNGIGV2ZW50DQp0cmln Z2VycyB0aGUgQVBTL1BTQyBzdGF0ZS1tYWNoaW5lLg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCg0K LS0gDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KICAgICAgICAgICAgICAgx+u8x9eho6zE48rHtsDSu87etv61xKOsvs3P 8cbky/vDv9K7uPbIy9K70fkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --=_alternative 00547E5685257BB2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCB0aGUgcG9pbnRzIHJh aXNlZCBieSBIdXViLg0KT25lIGZ1cnRoZXIgY29uc2lkZXJhdGlvbiwgaW4gYSB0eXBpY2FsIG5l dHdvcmsgd2l0aG91dCB0aGUgZXhlcmNpc2VyIHRoZQ0KQVBTIHdpbGwgZXNzZW50aWFsbHkgc2l0 IGluIGFuIGlkbGUgc3RhdGUgc2VuZGluZyAmcXVvdDtrZWVwIGFsaXZlJnF1b3Q7DQptZXNzYWdl cyBmb3IgeWVhcnMsIHVudGlsIGEgZmF1bHQgaXMgZGV0ZWN0ZWQgb24gdGhlIHdvcmtpbmcgcGF0 aC4gJm5ic3A7QXQNCnRoaXMgdGltZSBBUFMgbXVzdCAmcXVvdDt3YWtlIHVwJnF1b3Q7IGFuZCBl eGVjdXRlIGEgc3dpdGNoIHRvIHByb3RlY3Rpb24uDQpUaGUgcHVycG9zZSBvZiB0aGUgZXhlcmNp c2VyIGlzIHRvIHZlcmlmeSB0aGF0IHRoZSBBUFMgc3RhdGUgbWFjaGluZSBoYXMNCm5vdCBzdWZm ZXJlZCBzb21lIG9ic2N1cmUgZmF1bHQgY29uZGl0aW9uIHdoaWNoIG90aGVyd2lzZSB3b3VsZCBy ZW1haW4NCnVuZGV0ZWN0ZWQgdW50aWwgYSBzZWNvbmQgZmF1bHQgb2NjdXJzLiAmbmJzcDtJdCBp cyB0aGVzZSAmcXVvdDtzaWxlbnQNCmZhaWx1cmVzJnF1b3Q7IGNhdXNlIHNlcnZpY2Ugb3V0YWdl cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2Fy ZHMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NYWxj b2xtPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkh1dWIgdmFuIEhlbHZvb3J0ICZsdDtodXViYXR3b3JrQGdtYWlsLmNvbSZndDs8L2I+ DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNlbnQgYnk6IG1w bHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMi8wNy8yMDEzIDA3OjExIFBNPC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+UGxlYXNlIHJlc3BvbmQgdG88YnI+DQpodXViYXR3b3JrQGdt YWlsLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkmcXVv dDsNCiZsdDtlb3Nib3JuZUBjaXNjby5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7SHV1 YiBoZWx2b29ydCBcKGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb21cKSZxdW90Ow0KJmx0O2h1 dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb20mZ3Q7LCAmcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7 ICZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzXSBw cm9wb3NlZCBkcmFmdHMgZm9yIGFsaWduaW5nDQpNUExTLVRQIFBTQyBsaW5lYXIgcHJvdGVjdGlv biBwcm90b2NvbCB0byB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IZWxsbyBFcmljLDxicj4NCjxi cj4NCllvdSByZXBsaWVkOjxicj4NCjxicj4NCiAmZ3Q7IElubGluZSB3aXRoIEVPIywgdHJpbW1l ZCBhIGJpdC48YnI+DQo8YnI+DQpNeSByZXNwb25zZSBpbmxpbmUgW0h1dWIyXTxicj4NCjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlcmUgd2FzIGF0d28gd2VlayBJVFUtVCBwbGVuYXJ5 IG1lZXRpbmcsIGFuZCBhZnRlciB0aGF0IEkgdG9vazxicj4NCiZndDsmZ3Q7IChhbmQgc3RpbGwg aGF2ZSkgYSBob2xpZGF5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHlvdSdyZSBvbiBob2xpZGF5 LCB3aHkgYXJlIHlvdSB3b3JraW5nPzxicj4NCjxicj4NCltIdXViMl0gSXQgaXMgdG9vIGhvdCBv dXRzaWRlLCBhbmQgSSBoYWQgZHVnIG91dCBteSBsb2dib29rcyBmcm9tPGJyPg0KYmVmb3JlIDE5 ODQsIEkgd2FudCB0byB0byByZXR1cm4gdG8gc3RvcmFnZSBhcyBzb29uIGFzIHBvc3NpYmxlICZu YnNwO15fXjxicj4NCjxicj4NCiZndDsgJm5ic3A7SSB0aG91Z2h0IHRoYXQgd2FzIGEgdW5pcXVl bHkgQW1lcmljYW4gdHJhaXQuPGJyPg0KPGJyPg0KW0h1dWIyXSBtYXliZSBpdCBpcyBpbmZlY3Rp b3VzLi4uPGJyPg0KPGJyPg0KJmd0OyBJcyB0aGlzIHN0dWZmIHRoYXQgbXVjaCBmdW4gdG8geW91 PyA6KTxicj4NCjxicj4NCltIdXViMl0gbXkgd2lmZSBkb2VzIG5vdCBsaWtlIHRoZSBwaWxlcyBv ZiBsb2dib29rcyBhbmQgSSBsaWtlPGJyPg0KdG8gc2hhcmUgbXkga25vd2xlZGdlPGJyPg0KPGJy Pg0KJmd0OyAuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IGkpIGNhbiB5b3UgZXhwbGFp biBFWEVSIGF0IGEgaGlnaGVyIGxldmVsPyAmbmJzcDtJJ20gbm90IGxvb2tpbmcNCmZvciBhPGJy Pg0KJmd0OyZndDsmZ3Q7IGRlc2NyaXB0aW9uIG9mIHRoZSBzdGF0ZSBtYWNoaW5lIGNoYW5nZXMs IGFuZCBJJ20gbm90IGxvb2tpbmcNCmZvciB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgb25lIGxpbmUg JnF1b3Q7SXQgYWxsb3dzIHRoZSBGU00gdG8gYmUgdGVzdGVkJnF1b3Q7LiAmbmJzcDtXZQ0KaGF2 ZSBhbGwgb2YgdGhhdCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgZHJhZnQgYW5kIGluIHRoZSBl cXVpdmFsZW50IElUVSBzcGVjcy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg V2hhdCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIGFib3V0IEVYRVIgaXMgd2hlcmUgaXQgY2FtZSBm cm9tLg0KJm5ic3A7VGhlPGJyPg0KJmd0OyZndDsmZ3Q7IElUVSBzcGVjcyB0aGF0IGRlZmluZSBp dCBhcmUgcHJldHR5IGhhcmQgdG8gZm9sbG93LCB0aGV5IHNlZW0NCnRvPGJyPg0KJmd0OyZndDsm Z3Q7IGFzc3VtZSB0aGUgcmVhZGVyIGFscmVhZHkga25vd3Mgd2hhdCBFWEVSIGlzIGFuZCB3aGF0 IHByb2JsZW0NCml0PGJyPg0KJmd0OyZndDsmZ3Q7IHNvbHZlcy4gJm5ic3A7SXQgZmVlbHMgdmVy eSBtdWNoIGxpa2UgYSBtZWNoYW5pc20gdXNlZCB0bw0KY2F0Y2ggYSB2ZXJ5PGJyPg0KJmd0OyZn dDsmZ3Q7IHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGJ1ZywgYmFjayB3aGVuIHRyYW5zcG9ydCBn ZWFyIHdhcw0KZmFyIGxlc3M8YnI+DQomZ3Q7Jmd0OyZndDsgZGVidWdnYWJsZSB0aGFuIHdoYXQg d2UgaGF2ZSB0b2RheS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFtIdXViXSBFWEVSIHdh cyBub3QgZGVzaWduZWQvaW50ZW5kZWQgdG8gYmUgdXNlZCBmb3IgYnVnIGZpbmRpbmc8YnI+DQom Z3Q7Jmd0OyBhbHRob3VnaCBpdCB3aWxsIGRldGVjdCBwcm9ibGVtcyB3aXRoIGltcGxlbWVudGF0 aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgW0h1dWJdIEVYRVIgd2FzIGRlc2lnbmVk IHRvIHZlcmlmeSB0aGF0IHRoZSBzdGF0ZS1tYWNoaW5lIGF0IHRoZTxicj4NCiZndDsmZ3Q7IGZh ciBlbmQgaXMgYWJsZSB0byByZXNwb25kIHRvIEFQUy9QU0MgbWVzc2FnZXMgaXQgcmVjZWl2ZXMg ZnJvbTxicj4NCiZndDsmZ3Q7IHRoZSBsb2NhbCBlbmQuPGJyPg0KJmd0OyZndDsgRXZlbiB0aG91 Z2ggc3RhdGUtbWFjaGluZXMgc2hvdWxkIGJlIHRlc3RlZCBleHRlbnNpdmVseSwgdGhlcmUNCmlz PGJyPg0KJmd0OyZndDsgbm8gMTAwJSB3YXJyYW50eS4gSXQgY2FuIHN0aWxsIGhhdmUgc3RvcHBl ZCBkdWUgdG8gZXh0ZXJuYWw8YnI+DQomZ3Q7Jmd0OyBjaXJjdW1zdGFuY2VzLCBiZSBpbiBhIGRl YWRsb2NrIGR1ZSB0byB1bmZvcnNlZW4gb3JkZXIgb2YgZXZlbnRzLDxicj4NCiZndDsmZ3Q7IGV0 Yy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBFTyMgJm5ic3A7SSBhZ3JlZSB3aXRoIHlvdXIgbGFzdCB0 d28gc3RhdGVtZW50cy4gJm5ic3A7VG8gbWUsIHRob3VnaCwNCnRoYXQ8YnI+DQogJmd0OyB2ZXJ5 IHRleHQgaXMgYSByZWFzb25hYmxlIGFyZ3VtZW50IGFnYWluc3QgRVhFUi48YnI+DQogJmd0OyBU aGVyZSBpcyBubyBtZWNoYW5pc20gd2l0aGluIGEgcHJvdG9jb2wgd2hpY2ggY2FuIGd1YXJhbnRl ZSB0aGF0PGJyPg0KICZndDsgdGhlIGVudGlyZSBzdGF0ZSBtYWNoaW5lIGlzIDEwMCUgcGVyZmVj dC48YnI+DQo8YnI+DQpbSHV1YjJdIGluZGVlZDxicj4NCjxicj4NCiZndDsgQSBub2RlIGNvdWxk IGJlIGFibGUgdG8gcmVzcG9uZCB0byBFWEVSL1JSIGJ1dCBiZSB1bmFibGUgdG8gcHJvY2Vzczxi cj4NCiAmZ3Q7IGEgcmVhbCBmYWlsdXJlIHByb3Blcmx5LCBlaXRoZXIgZHVlIHRvIGJ1ZyBvciB0 byAoYXMgeW91IGluZGljYXRlKTxicj4NCiAmZ3Q7IHNvbWUgdW5mb3JzZWVuIGNvbWJpbmF0aW9u IG9mIGV4dGVybmFsIGV2ZW50cy48YnI+DQo8YnI+DQpbSHV1YjJdIGluIHRoZSBjYXNlIHlvdSBk ZXNjcmliZSB0aGUgbm9kZSBoYXMgdG8gc2VuZCBwZXJpb2RpY2FsPGJyPg0KTlIgX0FORF8gcmVz cG9uZCB0byB0aGUgRVhFUiB3aGlsZSBub3QgcmVzcG9uZGluZyB0byBhIHJlYWwgU0YvU0QsPGJy Pg0KdGhpcyB3b3VsZCBiZSBhIHZlcnkgY29tcGxleCBzdGF0ZS1tYWNoaW5lIGZhdWx0Ljxicj4N Cjxicj4NCiZndDsgVGhlIGNsYXNzIG9mIHByb2JsZW1zIHdoaWNoIEVYRVIgY2FuIGNhdGNoIGJ1 dCB3aGljaCB3aWxsIG5vdCBiZTxicj4NCiAmZ3Q7IGRldGVjdGFibGUgYnkgb3RoZXIgbWVhbnMg KGUuZy4gQ0MvQ1YsIHNlZSBiZWxvdykgc2VlbXMgcHJldHR5IHNtYWxsLjxicj4NCjxicj4NCltI dXViMl0gdGhlIEVYRVIgd2lsbCBkZXRlY3QgdGhlIG1vc3QgY29tbW9uICZxdW90O3N0dWNrLWF0 JnF1b3Q7IHByb2JsZW1zLjxicj4NCjxicj4NCiZndDsgSW4gdGhlIHRyYW5zcG9ydCB3b3JsZCwg d2hhdCBzb3J0IG9mIHByb2JsZW1zIGRvZXMgRVhFUiBfYWN0dWFsbHkNCmZpbmRfPzxicj4NCiAm Z3Q7ICZuYnNwO0knbSBub3QgYXNraW5nIGFib3V0IHRoaW5ncyBpdCBfY291bGRfIGZpbmQsIGJ1 dCB0aGluZ3MgdGhhdA0KaXQgKmRvZXMqLjxicj4NCjxicj4NCltIdXViMl0gc3R1Y2stYXQsIGRl YWRsb2NrPGJyPg0KPGJyPg0KJmd0OyZndDsgW0h1dWJdIG5vdGUgdGhhdCBBUFMvUFNDIHNob3Vs ZCBjb250aW51ZSB0byBvcGVyYXRlIGV2ZW4gaWYgbm88YnI+DQomZ3Q7Jmd0OyBjb250cm9sIHBs YW5lIGlzIGF2YWlsYWJsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBFTyMgJm5ic3A7SSBhZ3JlZSwg YnV0IHRoaXMgaXMgbm90IHJlbGV2YW50IHRvIHRoZSBkaXNjdXNzaW9uIGF0IGhhbmQuPGJyPg0K ICZndDsgTG90cyBvZiB3b3JrIHdhcyBkb25lIGluIFRQIHRvIGVuc3VyZSB0aGF0IGl0IHdvdWxk IGZ1bmN0aW9uIHdpdGhvdXQ8YnI+DQogJmd0OyB0aGUgYWJpbGl0eSB0byBmb3J3YXJkIElQIHBh Y2tldHMgKHdoaWNoIEkgdGhpbmsgaXMgd2hhdCB5b3UgbWVhbg0KYnk8YnI+DQogJmd0OyAnbm8g Y29udHJvbCBwbGFuZScpLiAmbmJzcDtOb25lIG9mIHRoYXQgaGFzIGFueXRoaW5nIHRvIGRvIHdp dGggdGhlDQpzZXQ8YnI+DQogJmd0OyBvZiBtZXNzYWdlcyBhbmQgc3RhdGVzIGluIFBTQy48YnI+ DQo8YnI+DQpbSHV1YjJdIEkgZGlkIG1lYW4gdG8gc2F5IHRoYXQgdGhlIGV4ZXJjaXNlIHJlcXVl c3QgY2Fhbm90IGJlIHNlbnQ8YnI+DQp2aWEgdGhlIGNvbnRyb2wgcGxhbmUsIHNvIGl0IHNob3Vs ZCBiZSBpbiB0aGUgZGF0YXBsYW5lLiBTaW5jZSB0aGU8YnI+DQpBUFMvUFNDIHN0YXRlLW1hY2hp bmUgaXMgZXhlcmNpc2VkIHRoZSBFWEVSIGNvbW1hbmQgc2hvdWxkIGJlIHBhcnQ8YnI+DQpvZiB0 aGUgQVBTL1BTQyBwcm90b2NvbC48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUaGUgRVhFUiBpcyB0byBl bmFibGUgYW4gb3BlcmF0b3IgdG88YnI+DQomZ3Q7Jmd0OyB0YWtlIGNvcnJlY3RpdmUgYWN0aW9u IGJlZm9yZSBhIHByb3RlY3Rpb24gc3dpdGNoIHJlcXVlc3QgZmFpbHM8YnI+DQomZ3Q7Jmd0OyBh bmQgdGhlIDUwbXMgc3dpdGNoIHRpbWUgaXMgbm90IG1ldC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBObyBvdGhlciBzdGF0ZSBtYWNoaW5lcyB0aGF0IEknbSBmYW1pbGlhciB3aXRo IChSU1ZQLCBMRFAsDQpCR1AsIE9TUEYsPGJyPg0KJmd0OyZndDsmZ3Q7IElTSVMpIGhhdmUgZXhw bGljaXQgc2lnbmFsaW5nIGluIHRoZW0ganVzdCB0byBhc2sgdGhlIG5laWdoYm9yPGJyPg0KJmd0 OyZndDsmZ3Q7IHdoZXRoZXIgaXQgKndvdWxkKiBiZSBicm9rZW4gaWYgaWYgd2VyZSwgaW4gdGhl IGZ1dHVyZSwgdG8NCmJlIGdpdmVuIGE8YnI+DQomZ3Q7Jmd0OyZndDsgcGFydGljdWxhciBpbnB1 dC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFtIdXViXSBBbGwgdGhlc2UgcmVseSBvbiBh IGNvbnRyb2wgcGxhbmUsIHNvbWUgb2YgdGhlbiBpbmNsdWRlPGJyPg0KJmd0OyZndDsgJnF1b3Q7 a2VlcGFsaXZlJnF1b3Q7IG1lc3NhZ2VzIHRvIHNlZSBpZiB0aGUgZmFyIGVuZCByZXNwb25kcy48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBFTyMgJm5ic3A7UFNDIGhhcyBrZWVwYWxpdmVzOyBzZWUgc2Vj dGlvbiA0LjEgb2YgcmZjNjM3OCAtICZxdW90O1RoZQ0KcHVycG9zZSBvZjxicj4NCiAmZ3Q7IHRo ZSBjb250aW51YWwgbWVzc2FnZXMgaXMgdG8gdmVyaWZ5IHRoYXQgdGhlIFBTQyBzZXNzaW9uIGlz IHN0aWxsDQphbGl2ZS4mcXVvdDs8YnI+DQo8YnI+DQpbSHV1YjJdIGl0IG9ubHkgcHJvdmVzIHRo YXQgdGhlIHN0YXRlLW1hY2hpbmUgY2FuIHNlbmQgTlIgcHJpb2RpY2FsbHksPGJyPg0KaXQgZG9l cyBub3QgcHJvdmUgdGhhdCBpdCB3aWwgcmVzcG9uZCB0byBhbnkgZXh0ZXJuYWwvcmVtb3RlIGV2 ZW50cy48YnI+DQpUaGUgRVhFUiB3aWxsIGdpdmUgbXVjaCBtb3JlIGNvbmZpZGVuY2Ugb2YgYmVp bmcgYWxpdmUuPGJyPg0KPGJyPg0KJmd0OyBUaGUgbmV4dCBzZW50ZW5jZSBzYXlzICZxdW90O0lm IG5vIHZhbGlkIFBTQyBtZXNzYWdlIGlzIHJlY2VpdmVkLA0Kb3ZlciBhPGJyPg0KICZndDsgcGVy aW9kIG9mIHNldmVyYWwgY29udGludWFsIG1lc3NhZ2VzIGludGVydmFscywgdGhlIGxhc3QgdmFs aWQ8YnI+DQogJmd0OyByZWNlaXZlZCBtZXNzYWdlIHJlbWFpbnMgYXBwbGljYWJsZS4mcXVvdDsg Jm5ic3A7QXMgYW4gaW1wbGVtZW50b3IsDQp3aGF0IHRoYXQ8YnI+DQogJmd0OyBtZWFucyB0byBt ZSBpcyB0aGF0IEkgdGltZSBvdXQgb25seSBhZnRlciB0aGUgbG9zcyBvZiBhIGZldzxicj4NCiAm Z3Q7IHJldHJhbnNtaXNzaW9ucy48YnI+DQo8YnI+DQpbSHV1YjJdIHllcywgdGhpcyBpcyBwYXJ0 IGlmIHRoZSBQRFUgdmFsaWRhdGlvbiBwcm9jZXNzPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7IFBh cnQgb2YgbXkgcmVsdWN0YW5jZSB0byBnZXQgYmVoaW5kIEVYRVIgaGFzIGJlZW48YnI+DQomZ3Q7 Jmd0OyZndDsgdGhhdCBJIGRvbid0IGZlZWwgY29tZm9ydGFibGUgd2l0aCB0aGUgaWRlYSBvZiBr ZWVwaW5nIGEgMzAteWVhci1vbGQ8YnI+DQomZ3Q7Jmd0OyZndDsgd29ya2Fyb3VuZCBpbiBhIHBy b3RvY29sLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgW0h1dWJdIGl0IGlzIE5PVCBhIHdv cmthcm91bmQsIGl0IGlzIGFuIGVzc2VudGlhbCBwYXJ0IG9mIHRoZTxicj4NCiZndDsmZ3Q7IHBy b3RvY29sLjxicj4NCiZndDs8YnI+DQomZ3Q7IEVPIyAmbmJzcDtJbiBhIFRETSB3b3JsZCwgSSBj YW4gc2VlIHRoaXMgcG9pbnQuICZuYnNwO0FQUyBpcyBjYXJyaWVkDQppbiB0aGU8YnI+DQogJmd0 OyBmcmFtZSBoZWFkZXIsIHNvIHRoZSByZWNlaXB0IG9mIGFuIEFQUyBtZXNzYWdlIGRvZXNuJ3Qg bWVhbiB0aGF0PGJyPg0KICZndDsgdGhlcmUncyBhbnkgaW50ZWxsaWdlbmNlIGJlaGluZCBpdCBh cyBpdCBjb3VsZCBqdXN0IGJlIHRoZSBoYXJkd2FyZTxicj4NCiAmZ3Q7IHJlcGVhdGluZyB0aGUg bGFzdCBBUFMgb3ZlcmhlYWQgdGhhdCBpdCBzZW50LiAmbmJzcDtJZiBhIFBTQyBtZXNzYWdlDQpp czxicj4NCiAmZ3Q7IHNlbnQgaXQgbXVzdCBoYXZlIGJlZW4gc2VudCBkZWxpYmVyYXRlbHksIGFz IGR1cmluZyBzdGVhZHkgc3RhdGU8YnI+DQogJmd0OyB3ZSBoYXZlIHBlcmlvZGljIHJldHJhbnNt aXNzaW9ucy4gJm5ic3A7RG8geW91IGFncmVlPzxicj4NCjxicj4NCltIdXViMl0gc2ltaWxhcmx5 IGhhcmR3YXJlIChvciBzb2Z0d2FyZSkgY2FuIGNvbnRpb3VvdXNseSBzZW5kPGJyPg0KTlIgbWVz c2FnZXMuIFNvIEkgYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gVERN PGJyPg0KYW5kIHBhY2tldCBBUFMvUFNDLjxicj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyBJcyB0aGVy ZSBtb3JlIHRvIGl0IHRoYW4gdGhhdD8gJm5ic3A7SGF2ZSBJPGJyPg0KJmd0OyZndDsmZ3Q7IG1p c3JlYWQgYW5kIG1pc3VuZGVyc3Rvb2QgRVhFUj8gJm5ic3A7RG9lcyBtb2Rlcm4gdHJhbnNwb3J0 DQpnZWFyIGV2ZXI8YnI+DQomZ3Q7Jmd0OyZndDsgYWN0dWFsbHkgZGV0ZWN0IGEgcHJvYmxlbSB2 aWEgRVhFUi9SUiB0aGF0IHdhc24ndCBvYnZpb3VzDQp0byB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsg b3BlcmF0b3IgdXNpbmcgb3RoZXIgbWVhbnM/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBb SHV1Yl0gaWYgdGhlcmUgaXMgbm8gY29udHJvbCBwbGFuZSBJIGhhdmUgbm8gb3RoZXIgbWVhbnMu PGJyPg0KJmd0OyZndDsgV2hhdCBtZWFucyBhcmUgYXZhaWxhYmxlIHRvIHZlcmlmeSBpZiBhIHN0 YXRlLW1hY2hpbmUgdGhhdCBpczxicj4NCiZndDsmZ3Q7IGluIGEgc3RhYmxlIHN0YXRlIGlzIHN0 aWxsIGZ1bmN0aW9uaW5nPzxicj4NCiZndDs8YnI+DQomZ3Q7IEVPIyAmbmJzcDtQZXJpb2RpYyBy ZXRyYW5zbWlzc2lvbiBvZiBjdXJyZW50IHN0YXRlIGJ5IHRoZSByZW1vdGUgc2lkZS48YnI+DQog Jmd0OyBUaGlzIHBlcmZvcm1zIHRoZSBleGFjdCBzYW1lIGZ1bmN0aW9uIGFzIGEga2VlcGFsaXZl IGluIGFueSBvdGhlcjxicj4NCiAmZ3Q7IHByb3RvY29sLCBhbmQgSSB0aGluayB3ZSBhZ3JlZSB0 aGF0IHRoZSBrZWVwYWxpdmUgZnVuY3Rpb24gaW48YnI+DQogJmd0OyBwcm90b2NvbHMgc3VjaCBh cyBPU1BGIGlzIHN1ZmZpY2llbnQgdG8gZW5zdXJlIHRoZSBzYW5pdHkgb2YgdGhlPGJyPg0KICZn dDsgcmVtb3RlIGVuZC48YnI+DQo8YnI+DQpbSHV1YjJdIHNlZSBhYm92ZSBmb3IgdGhlIHBvc3Np YmlsdHkgb2Ygc3R1Y2stYXQgcmVwZWF0aW5nIG9ubHk8YnI+DQp0aGUgTlIgbWVzc2FnZS48YnI+ DQo8YnI+DQomZ3Q7IE1hbnksIG1hbnkgcHJvdG9jb2xzIHVzZSBrZWVwYWxpdmVzIGFzIGEgc29y dCBvZiBiZWx0LWFuZC1zdXNwZW5kZXJzPGJyPg0KICZndDsgZmFpbHVyZSBkZXRlY3Rpb24gbWVj aGFuaXNtLiAmbmJzcDtJbiB0aGUgSVAgd29ybGQgdGhlc2UgbWVjaGFuaXNtcw0KYXJlPGJyPg0K ICZndDsgZmFyLCBmYXIgbGVzcyB1c2VmdWwgdGhhbiB0aGV5IHVzZWQgdG8gYmUgYXMgd2Ugbm93 IGhhdmUgQkZELjxicj4NCjxicj4NCltIdXViMl0gSSB3b3VsZCBjb25zaWRlciB0aGUgJnF1b3Q7 aGVsbG8mcXVvdDsgbWVzc2FnZSB0byBoYXZlIHRoZSBzYW1lDQpwdXJwb3NlPGJyPg0KYXMgdGhl IEVYRVIgbWVzc2FnZTogY2hlY2sgaWYgdGhlIHJlbW90ZSBCRkQgc2Vzc2lvbiBpcyBzdGlsbCB1 cC48YnI+DQo8YnI+DQomZ3Q7IFRoYXQgYnJpbmdzIHVzIHRvIENDL0NWLiAmbmJzcDsgTG90cyBv ZiB3b3JrIHdhcyBkb25lIHRvIGVuc3VyZSB0aGF0DQppdDxicj4NCiAmZ3Q7IGRpZCBub3QgcmVx dWlyZSBJUCB0byBmdW5jdGlvbi4gJm5ic3A7SSBjYW5ubm90IGJlbGlldmUgdGhhdCBhbnkNClRQ PGJyPg0KICZndDsgaW1wbGVtZW50YXRpb24gd291bGQgc2hpcCB3aXRob3V0IHNvbWUgc29ydCBv ZiBDQy9DViwgYW5kIGlzbid0PGJyPg0KICZndDsgdGhhdCBhIHN0cm9uZyBlbm91Z2ggbWVjaGFu aXNtIHRvIGRldGVjdCB0aGUgZmFpbHVyZSBvZiB0aGUgcmVtb3RlPGJyPg0KICZndDsgZW5kPzxi cj4NCjxicj4NCltIdXViMl0gQ0MvQ1Ygb25seSBjaGVja3MgdGhlIGNvbmR1Y3Rpdml0eSBhbmQg Y29ubmVjdGl2aXR5IG9mIGEgcGF0aDxicj4NCkl0IGhhcyBubyByZWxhdGlvbiBhdCBhbGwgd2l0 aCB0aGUgQVBTL1BTQyBzdGF0ZS1tYWNoaW5lIG90aGVyIHRoYW48YnI+DQppbiBjYXNlIENDL0NW IGNhdXNlcyBhIHNpZ25hbCBmYWlsIGRlZmVjdCB0aGUgcmVzdWx0aW5nIFNGIGV2ZW50PGJyPg0K dHJpZ2dlcnMgdGhlIEFQUy9QU0Mgc3RhdGUtbWFjaGluZS48YnI+DQo8YnI+DQpSZWdhcmRzLCBI dXViLjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDH67zH16GjrMTjyse2 wNK7zt62/rXEo6y+zc/xxuTL+8O/0ru49sjL0rvR+Txicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQpt cGxzQGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9 Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00547E5685257BB2_=-- From ietf-secretariat-reply@ietf.org Thu Jul 25 03:36:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8B21F8FCE for ; Thu, 25 Jul 2013 03:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99YYDWZLY3+2 for ; Thu, 25 Jul 2013 03:36:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3321F9AB3 for ; Thu, 25 Jul 2013 03:36:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130725103655.21560.98418.idtracker@ietfa.amsl.com> Date: Thu, 25 Jul 2013 03:36:55 -0700 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 25 Jul 2013 10:36:56 -0000 Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for publication", set due date to November 2013 from July 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From loa@pi.nu Thu Jul 25 06:27:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9209921F9ADD for ; Thu, 25 Jul 2013 06:27:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH6dc9lnNhFR for ; Thu, 25 Jul 2013 06:27:06 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E821F9A13 for ; Thu, 25 Jul 2013 06:27:06 -0700 (PDT) Received: from [95.209.164.252] (95.209.164.252.mobile.tre.se [95.209.164.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D2D881801274; Thu, 25 Jul 2013 15:27:05 +0200 (CEST) Message-ID: <51F127A9.4040009@pi.nu> Date: Thu, 25 Jul 2013 15:27:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel , "VIGOUREUX, MARTIN (MARTIN)" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" References: <51D40986.1040709@pi.nu> In-Reply-To: <51D40986.1040709@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] losed wg poll - Re: draft-wijnands-mpls-mldp-node-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, 25 Jul 2013 13:27:14 -0000 Working Group, this poll has been closed and we have a new working group document. Can the authors please re-post the draft as draft-ietf-mpls-mldp-node-protection-00 as soon as the the pre-Berlin cut-off is lifted. /Loa for the wg co-chairs On 2013-07-03 13:22, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-node-protection as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends July 17, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/ipr/1727/ > https://datatracker.ietf.org/ipr/2116/ > > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Thu Jul 25 06:31:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DB21F9B18 for ; Thu, 25 Jul 2013 06:31:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4EGQsqjCKkF for ; Thu, 25 Jul 2013 06:31:45 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id AA9DA21F8CB4 for ; Thu, 25 Jul 2013 06:31:39 -0700 (PDT) Received: from [95.209.164.252] (95.209.164.252.mobile.tre.se [95.209.164.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E7E0B1801274; Thu, 25 Jul 2013 15:31:38 +0200 (CEST) Message-ID: <51F128BA.7010104@pi.nu> Date: Thu, 25 Jul 2013 15:31:38 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel , "VIGOUREUX, MARTIN (MARTIN)" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" References: <51D40986.1040709@pi.nu> <51F127A9.4040009@pi.nu> In-Reply-To: <51F127A9.4040009@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closed wg poll - Re: draft-wijnands-mpls-mldp-node-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, 25 Jul 2013 13:31:50 -0000 Now with improved subject line :) /Loa On 2013-07-25 15:27, Loa Andersson wrote: > Working Group, > > this poll has been closed and we have a new working group document. > > Can the authors please re-post the draft as > draft-ietf-mpls-mldp-node-protection-00 > as soon as the the pre-Berlin cut-off is lifted. > > /Loa > for the wg co-chairs > > On 2013-07-03 13:22, Loa Andersson wrote: >> Working Group, >> >> This is to start a two week poll on adopting >> draft-wijnands-mpls-mldp-node-protection as an MPLS working >> group document. >> >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls at ietf.org). Please give a technical >> motivation for your support/not support, especially if you think that >> the document should not be adopted as a working group document. >> >> This poll ends July 17, 2013. >> >> There are two IPR claims against this document: >> >> https://datatracker.ietf.org/ipr/1727/ >> https://datatracker.ietf.org/ipr/2116/ >> >> >> The authors has stated on the working group mailing list >> that they are not aware of any other IPR claims against this draft. >> >> However if you are on the the mpls working group mailing list and >> aware of IPR that relates to this draft, the time to disclose >> this is now. >> >> /Loa >> (mpls wg co-chair) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Thu Jul 25 07:53:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F39021F9B26 for ; Thu, 25 Jul 2013 07:53:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkaLhQWlDZ-U for ; Thu, 25 Jul 2013 07:53:22 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD8921F9B1B for ; Thu, 25 Jul 2013 07:53:19 -0700 (PDT) Received: from [95.209.164.252] (95.209.164.252.mobile.tre.se [95.209.164.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F1AAB1800272; Thu, 25 Jul 2013 16:53:16 +0200 (CEST) Message-ID: <51F13BDD.9080704@pi.nu> Date: Thu, 25 Jul 2013 16:53:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-seamless-mpls.all@tools.ietf.org Subject: [mpls] IPR poll on draft-ietf-mpls-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 25 Jul 2013 14:53:28 -0000 Working Group, The authors of draft-ietf-mpls-seamless-mpls has told the working group chairs that the draft is ready to be working group last called. We have not poll for IPRs on this draft earlier. Before starting the the wglc we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mpls? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ietf-secretariat-reply@ietf.org Fri Jul 26 02:19:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3294B21F8449 for ; Fri, 26 Jul 2013 02:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN6qwDO6ea1P for ; Fri, 26 Jul 2013 02:19:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 751DE21F852D for ; Fri, 26 Jul 2013 02:19:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130726091933.1847.45995.idtracker@ietfa.amsl.com> Date: Fri, 26 Jul 2013 02:19:33 -0700 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Jul 2013 09:19:34 -0000 Changed milestone "Submit draft-jjwl-mpls-mldp-hsmp for publication", set description to "Submit draft-ietf-mpls-mldp-hsmp for publication". URL: http://datatracker.ietf.org/wg/mpls/charter/ From Internet-Drafts@ietf.org Fri Jul 26 07:23:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94F021F9675; Fri, 26 Jul 2013 07:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g2xctVhsuIh; Fri, 26 Jul 2013 07:23:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96021F8F07; Fri, 26 Jul 2013 07:23:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130726142340.8175.55455.idtracker@ietfa.amsl.com> Date: Fri, 26 Jul 2013 07:23:40 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-ethernet-addressing-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: Fri, 26 Jul 2013 14:23:41 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Next-Hop Ethernet Addressing Author(s) : D. Frost, et al Filename : draft-ietf-mpls-tp-ethernet-addressing Pages : 9 Date : July 26, 2013 The Multiprotocol Label Switching (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 presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ethernet-addressing-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-ethernet-addressing"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-07-26072340.I-D@ietf.org> --NextPart-- From curtis@ipv6.occnc.com Fri Jul 26 10:45:22 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C611E80FB for ; Fri, 26 Jul 2013 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-6MMWg46T4v for ; Fri, 26 Jul 2013 10:45:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 716B311E811B for ; Fri, 26 Jul 2013 10:45:16 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r6QHhwjG065662; Fri, 26 Jul 2013 13:43:58 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> To: Ross Callon From: Curtis Villamizar In-reply-to: Your message of "Wed, 17 Jul 2013 03:43:08 -0000." <62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01@CH1PRD0510MB355.namprd05.prod.outlook.com> Date: Fri, 26 Jul 2013 13:43:58 -0400 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 17:45:23 -0000 In message <62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01@CH1PRD0510MB355.namprd05.prod.outlook.com> Ross Callon writes: > Reminder, please send responses to the MPLS WG email list. > > Thanks, Ross > > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Tuesday, July 16, 2013 1:00 PM > To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 > > Working Group, > > This is to start Working Group last call on > draft-ietf-mpls-special-purpose-labels-03 > > Please send your comments to the mpls working group mailing list > (mpls@ietf.org). > > Please send both technical comments, and (if you are happy with the > document as is) also send indications of support. > > There are no IPR claims against this draft. The co-authors have > earlier stated that they are not aware of any IPR applicable to this > draft. > > If anyone else in the working group is aware of IPRs claims against > this draft, the time to disclose that is now. > > Due to the upcoming IETF meeting in Berlin, this last call will be > extended by an extra week (which implies that the last call will be > ongoing during the IETF meeting). This working group last call will > end on August 6, 2013. > > Ross > for the wg co-chairs Ross, authors, I really don't see the value of using 7 as an extended special purpose label. Values 0-6 and 8-15 of the extended special purpose label registry are set aside as reserved; these MUST NOT appear in the data plane. Label 7 (when received) retains its meaning as ELI whether a regular or an extended special purpose label; this is to simplify the logic for transit LSRs looking for entropy labels. However, an LSR wishing to insert an entropy label SHOULD insert label 7 as a regular special purpose label, not as an extended special purpose label. Why insert 15 ELI EL rather than ELI EL. If only new LSR insert EL, why not make the MUST not apply to use of 0-15 as extended special purpose labels. I suggest replacing with: Values 0-15 of the extended special purpose label registry are set aside as reserved; these MUST NOT appear in the data plane. This would also change table 1. I would also drop bullet 3 from the list in IANA Considerations. That bullet contains the text "Note: any new allocation from the Special Purpose MPLS Label Values registry MUST also say whether the same value needs to be reserved in the Extended Special Purpose MPLS Label Values registry." BTW "extension label" has a acronym collision with entropy label, unless we abbreviate extension label XL. ESP labels might also be a good acronym Extended Special Purpose MPLS Label. The acronym collision with existing use of ESP might actually make sense, particularly in regard to the experimental ESP range. :-) It might help to introduce the acronyms "XL" and "ESP label" or "ESPL" in this document. Right now the document does not say what an LSR should do if it encounters an unknown (to it) ESP label. This should require a separate section entitled "Forwarding Packets with Unknown Extension Labels". If this label is deep in the stack, the it seems that the best action would be to always ignore it. In thinking about what an LSR should do, there are two possibilities if the unknown ESP label hits the top of the stack. One possibility is drop the packet. The other is pop the XL and ESP and process the next label or BOS. One way to accomplish that would be to reserve a range for each of these two possibilities. Tabel 1 becomes. +---------------+----------------------------------------------+ | Range | Allocation Policy | +---------------+----------------------------------------------+ | 0 - 15 | Reserved. Not to be allocated. MUST NOT | | | appear in the data plane. | | | | | 16 - 127 | Standards Action (drop packet if unknown) | | | | | 128 - 239 | Standards Action (pop XL and ESP if unknown) | | | | | 240 - 247 | Experimental (drop packet if unknown) | | | | | 248 - 255 | Experimental (pop XL and ESP if unknown) | | | | | 256 - 1048575 | Reserved | +---------------+----------------------------------------------+ The experimental ESP space could also be split in the same way. The experimental space is small. Maybe that's good. Only if we think there might be a reason to drop a packet with unknown ESP label deep in the stack would we want to further split the space to include that possibility. If there is no concensus behind the changes I've suggested here, then I support the document going forward. I would prefer that the suggested changes be seriously considered. Curtis From iesg-secretary@ietf.org Sat Jul 27 09:29:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5621F9AD3; Sat, 27 Jul 2013 09:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd+3iW5HR82p; Sat, 27 Jul 2013 09:29:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D0621F9AE9; Sat, 27 Jul 2013 09:29:56 -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: 4.60p1 Message-ID: <20130727162956.25584.9856.idtracker@ietfa.amsl.com> Date: Sat, 27 Jul 2013 09:29:56 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS-TP Next-Hop Ethernet Addressing' to Proposed Standard (draft-ietf-mpls-tp-ethernet-addressing-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: Sat, 27 Jul 2013 16:29:57 -0000 The IESG has approved the following document: - 'MPLS-TP Next-Hop Ethernet Addressing' (draft-ietf-mpls-tp-ethernet-addressing-08.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ethernet-addressing/ Technical Summary This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. Working Group Summary: There is good support in the working group for this draft. There were no significant controversies in progression of the document. Last call comments were constructive technical comments and the document has been updated accordingly. Document Quality: We know of intentions to implement this protocol. Since it is carried over the "MPLS G-ACh Advertisement Protocol", most implementers are in waiting mode for the assignemnt of the ACh type for that protocol. There is a downward references to RFC 2469 "A Caution On The Canonical Ordering Of Link-Layer Addresses". Personnel: Loa Andersson (loa@pi.nu) is the document shepherd. Adrian Farrel (adrian@olddog.uk) is the responsible AD. From agmalis@gmail.com Sat Jul 27 13:23:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5F21F8F3C for ; Sat, 27 Jul 2013 13:23:21 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crw1ZQ1Yxb-D for ; Sat, 27 Jul 2013 13:23:19 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3286321F8C3E for ; Sat, 27 Jul 2013 13:23:18 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so2809756wes.23 for ; Sat, 27 Jul 2013 13:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aPw/BHbqgm2M5x/1Aaf0RjDHjYeHWUWrqoUKdMRd210=; b=qBaS/iTmLhfXVy8LqGuR7fOgjYeHGMxSzuuHwaMrxaUcOSI7qfKhwsMAgQyyA0Q6i1 Yt+nH9d7JlsTQHT8tDqKyX95H41JRcag/4/nl1e9Z++q6yCdPMLpjANZG/6QH6T3MMeA DEd7dkXc6W18Kb8nZcQLR+20Ob67daT66kIdrGmnUW83QnMhNGXBGhMmcxfZgecbkdce 46rastMjAAQm8DREdSMD7xn4DiFFLOYadto22/WSo+HynvE4jDsPGxKeRBrJK192BA3r CAGm5MUGULBhSKSccCIcoLgA5ff6aJI4GE2ZJk5YOhqb68pylezGC/0mzaSZ1wMS7K6Q xUuQ== X-Received: by 10.194.9.101 with SMTP id y5mr38400791wja.86.1374956597075; Sat, 27 Jul 2013 13:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.255.20 with HTTP; Sat, 27 Jul 2013 13:22:55 -0700 (PDT) In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> From: "Andrew G. Malis" Date: Sat, 27 Jul 2013 22:22:55 +0200 Message-ID: To: Ross Callon Content-Type: multipart/alternative; boundary=047d7b5d50588ce62c04e28407cc Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 27 Jul 2013 20:23:21 -0000 --047d7b5d50588ce62c04e28407cc Content-Type: text/plain; charset=ISO-8859-1 No technical comments, just very glad to see it in WG last call, and I support publication. Cheers, Andy On Wed, Jul 24, 2013 at 4:30 AM, Ross Callon wrote: > Working Group,**** > > **** > > This is to start Working Group last call on > draft-ietf-mpls-tp-rosetta-stone-11.txt**** > > **** > > Please send your comments to the mpls working group mailing list ( > mpls@ietf.org).**** > > **** > > Please send both technical comments, and (if you are happy with the > document as is) **** > > also send indications of support.**** > > **** > > There are no IPR claims against this draft. The co-authors have stated > that they are not**** > > aware of any IPR applicable to this draft. If anyone else in the working > group is aware of **** > > IPRs claims against this draft, the time to disclose that is now.**** > > **** > > Due to the upcoming IETF meeting in Berlin, this last call will be > extended by an extra week **** > > (which implies that the last call will be ongoing during the IETF > meeting). This working group **** > > last call will end on August 14, 2013.**** > > **** > > Ross**** > > for the wg co-chairs**** > > ** ** > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --047d7b5d50588ce62c04e28407cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No technical comments, just very glad to see it = in WG last call, and I support publication.

Cheers,
A= ndy



On Wed, Jul 24, 2013 at 4:30 AM, Ross Callon <rcallon@juniper.net&g= t; wrote:

Working Group,

=A0

This = is to start Working Group last call on=A0 draft-ietf-mpls-tp-rosetta-stone-11.txt

=A0

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

=A0

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

=A0

There are no IPR claims against this dr= aft. The co-authors have stated that they are not

aware of any IPR applicable to this draft. <= /span>If anyone else in the working group is aware of

IPRs claims against this draft, the time to disclose that is now.

=A0

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 14, 2013.

=A0

Ross

for the wg co-chairs

=A0<= /p>


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


--047d7b5d50588ce62c04e28407cc-- From ietf-secretariat-reply@ietf.org Sun Jul 28 04:48:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73FC21F8FA1 for ; Sun, 28 Jul 2013 04:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlmTL1K8r6Od; Sun, 28 Jul 2013 04:48:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A6621F90CC; Sun, 28 Jul 2013 04:48:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org, mpls-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130728114816.19737.57753.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 04:48:16 -0700 From: IETF Secretariat Subject: [mpls] State changed: charter-ietf-mpls-05-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: Sun, 28 Jul 2013 11:48:16 -0000 State changed to Internal review. URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/ From wwwrun@rfc-editor.org Sun Jul 28 17:55:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B4F21F9EAA for ; Sun, 28 Jul 2013 17:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOcAvNPWUxrR for ; Sun, 28 Jul 2013 17:55:54 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42921F9EA8 for ; Sun, 28 Jul 2013 17:55:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 724A06210F; Sun, 28 Jul 2013 17:52:34 -0700 (PDT) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20130729005234.724A06210F@rfc-editor.org> Date: Sun, 28 Jul 2013 17:52:34 -0700 (PDT) Cc: mpls@ietf.org, renatowestphal@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC3031 (3689) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 29 Jul 2013 00:55:58 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=3689 -------------------------------------- Type: Technical Reported by: Renato Westphal Section: 5.2.1 Original Text ------------- 6. This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection. 7. Corrected Text -------------- 6. This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection. 7. Notes ----- If the "Request Procedure" is different than "Request Never", then a "NotAvailable Procedure" should be specified. In this case, the "Request Retry" procedure is the right option for Downstream on Demand. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From gregory.mirsky@ericsson.com Mon Jul 29 00:58:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE99921F9963 for ; Mon, 29 Jul 2013 00:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXaaZw7wpDnB for ; Mon, 29 Jul 2013 00:58:37 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5113E21F9948 for ; Mon, 29 Jul 2013 00:58:37 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-9b-51f620acad65 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0E.C0.13034.CA026F15; Mon, 29 Jul 2013 09:58:36 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 03:58:36 -0400 From: Gregory Mirsky To: Pignataro cpignata , "mpls@ietf.org" Thread-Topic: MPLS-TP in draft-george-mpls-ipv6-only-gap-01 Thread-Index: Ac6MMWzurZPrtX9PTtuUHRNin3V5Iw== Date: Mon, 29 Jul 2013 07:58:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6B5BA9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B6B5BA9eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPuO4ahW+BBn/mW1l8ereDxeLW0pWs DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfG9vX3GQsuiVRcermNpYFxjWAXIyeHhICJ xNbTv5ggbDGJC/fWs3UxcnEICRxllLizcgIzhLOcUWLp1z52kCo2ASOJFxt7wGwRAR+Jr7d3 s4LYwgJmEmu6jzNCxK0lTt5fAmXrSZzdtAFsA4uAqsTx1duBhnJw8Ar4Snw+VQoSZgRa/P3U GrASZgFxiVtP5kMdJCCxZM95ZghbVOLl43+sELayxJIn+1kg6vMlPnV+YQOxeQUEJU7OfMIy gVFoFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbGIE RsMxCTbdHYx7XloeYpTmYFES512ldyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2MQq1Vt x+3PD+ZOTTc+bilsyPb8qn6rTlLNcemsxaLcS9bevJbp9p47+kvKZKV1z0/Wx2zz7OC9mnfo /PJfhiyL9Yp2rlTry9p13ZNxr5nJ6369Vb9Zgv9MaemV9pjWbG9/8JOi5qasM+Vd/yesV9NN fH/0jilLkuwSxiKGZRFHngeo/72onqPEUpyRaKjFXFScCAAC5HvmVAIAAA== Subject: [mpls] MPLS-TP in draft-george-mpls-ipv6-only-gap-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, 29 Jul 2013 07:58:44 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B6B5BA9eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, I think that Section 3.3.3 MPLS-TP should clarify that use of Control Plane= in MPLS-TP networks is optional, not "not required" as currently stated. A= nd since GMPLS RSVP-TE and T-LDP are signaling protocols for MPLS-TP LSP an= d MPLS-TP PW respectively all gaps for IPv6 identified for both are equally= applicable in MPLS-TP networks. I think that MPLS-TP OAM section will likely to give review of impact of IP= v6 only control network addressing on Data Plane, i.e. Source MEP ID TLV in= CV, but on OAM configuration by RSVP-TE and LSP Ping. In addition need to = review: * MPLS-TP Linear Protection (with PSC); * 1:n * at least mention, shared protection * Ring Protection Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B6B5BA9eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et. al,
I think that Section 3.3.3 MPLS-TP should clarify that use of Control = Plane in MPLS-TP networks is optional, not "not required" as curr= ently stated. And since GMPLS RSVP-TE and T-LDP are signaling protocols for= MPLS-TP LSP and MPLS-TP PW respectively all gaps for IPv6 identified for both are equally applicable in MPLS-TP network= s.
I think that MPLS-TP OAM section will likely to give review of impact = of IPv6 only control network addressing on Data Plane, i.e. Source MEP ID T= LV in CV, but on OAM configuration by RSVP-TE and LSP Ping. In addition nee= d to review:
  • MPLS-TP Linear Protection (with PSC);
  • 1:n
  • at least ment= ion, shared protection
  • Ring Protection
 
        Regards,
           &nbs= p;    Greg
 
 --_000_7347100B5761DC41A166AC17F22DF1121B6B5BA9eusaamb103erics_-- From Malcolm.BETTS@zte.com.cn Mon Jul 29 01:04:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D821F9D92; Mon, 29 Jul 2013 01:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.82 X-Spam-Level: X-Spam-Status: No, score=-98.82 tagged_above=-999 required=5 tests=[AWL=3.777, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM++n9cj+Q1p; Mon, 29 Jul 2013 01:04:30 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E38D321F9B21; Mon, 29 Jul 2013 01:04:17 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A381520759; Mon, 29 Jul 2013 16:03:44 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 502377366A1; Mon, 29 Jul 2013 16:03:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6T83iNk078202; Mon, 29 Jul 2013 16:03:44 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> To: Ross Callon MIME-Version: 1.0 X-KeepSent: 22E05CC5:4FDB1FBB-85257BB7:002C34BC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Mon, 29 Jul 2013 04:03:42 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-29 16:03:32, Serialize complete at 2013-07-29 16:03:32 Content-Type: multipart/alternative; boundary="=_alternative 002C4F0685257BB7_=" X-MAIL: mse02.zte.com.cn r6T83iNk078202 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 29 Jul 2013 08:04:34 -0000 This is a multipart message in MIME format. --=_alternative 002C4F0685257BB7_= Content-Type: text/plain; charset="US-ASCII" No technical comments, this is a very useful draft, I support publication. Regards, Malcolm Ross Callon Sent by: mpls-bounces@ietf.org 23/07/2013 10:30 PM To "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" cc "mpls-chairs@tools.ietf.org" Subject [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Working Group, This is to start Working Group last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Please send your comments to the mpls working group mailing list ( mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended by an extra week (which implies that the last call will be ongoing during the IETF meeting). This working group last call will end on August 14, 2013. Ross for the wg co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 002C4F0685257BB7_= Content-Type: text/html; charset="US-ASCII" No technical comments, this is a very useful draft, I support publication.

Regards,

Malcolm



Ross Callon <rcallon@juniper.net>
Sent by: mpls-bounces@ietf.org

23/07/2013 10:30 PM

To
"mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" <draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org>
cc
"mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject
[mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt





Working Group,
 
This is to start Working Group last call on  draft-ietf-mpls-tp-rosetta-stone-11.txt
 
Please send your comments to the mpls working group mailing list (mpls@ietf.org).
 
Please send both technical comments, and (if you are happy with the document as is)
also send indications of support.
 
There are no IPR claims against this draft. The co-authors have stated that they are not
aware of any IPR applicable to this draft. If anyone else in the working group is aware of
IPRs claims against this draft, the time to disclose that is now.
 
Due to the upcoming IETF meeting in Berlin, this last call will be extended by an extra week
(which implies that the last call will be ongoing during the IETF meeting). This working group
last call will end on August 14, 2013.
 
Ross
for the wg co-chairs
 _______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 002C4F0685257BB7_=-- From huubatwork@gmail.com Mon Jul 29 01:27:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1721F9EE0 for ; Mon, 29 Jul 2013 01:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfyevcIx6gqU for ; Mon, 29 Jul 2013 01:27:55 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 45D7C21F9EFE for ; Mon, 29 Jul 2013 01:26:34 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so4586752pad.16 for ; Mon, 29 Jul 2013 01:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding; bh=t+Pr+OJile7pOwvygEmAq5rfiAOqbk15xvupkQmTdeI=; b=PsIIANQONzxW6oUbVGRw03bXjgkYacH5xyZ6Q4jqem28C6Oa9xMRY2V/T0G8WZFR9H lNwa1kqo0EhWi+YvRC5fPU6ByhIglzxPcblH6PBI7ulh1/KbH9mpocC4TZsXmG9cCLRM iKrIywz2KktdAj1TBYFWMmTN+c+vwsxKSfYMQBRepUJCcPPNx1/6I+YkeS2lqyUhdedH uI2UgjebNQr+9VR2Htx56iog51lBJm+VHtvsfTUK9X1Yz2nsMJqb5eO5lxxfx9D4ycCO vfzeK3Br5BgcR702ekDBUHks+9yK7rg3uV+9CiSbB3I/7UUKBuc/q5UFQJK1xFpNVPk7 nyiA== X-Received: by 10.68.221.138 with SMTP id qe10mr66434815pbc.103.1375086390974; Mon, 29 Jul 2013 01:26:30 -0700 (PDT) Received: from dhcp-175c.meeting.ietf.org ([2001:df8:0:16:980d:f18c:aeaa:46ac]) by mx.google.com with ESMTPSA id sz6sm19457961pab.5.2013.07.29.01.26.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:26:30 -0700 (PDT) Message-ID: <51F62737.3020505@gmail.com> Date: Mon, 29 Jul 2013 10:26:31 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" References: <51DFBCAE.1090904@gmail.com> In-Reply-To: <51DFBCAE.1090904@gmail.com> X-Forwarded-Message-Id: <51DFBCAE.1090904@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt 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: Mon, 29 Jul 2013 08:27:57 -0000 Hello MPLS, I noticed that I did not send this notification to the MPLS list at the same time as I sent it to CCAMP. This concerns/addresses priorities in linear protection. Best regards, Huub. -------- Original Message -------- Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt Date: Fri, 12 Jul 2013 10:22:06 +0200 From: Huub van Helvoort Reply-To: huubatwork@gmail.com To: CCAMP Hello CCAMP, Based on the messages on the MPLS list: http://www.ietf.org/mail-archive/web/mpls/current/msg09913.html http://www.ietf.org/mail-archive/web/mpls/current/msg09916.html I have created and uploaded the draft below. Comments are appreciated. Best regards, Huub. -------- Original Message -------- Subject: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt Date: Fri, 12 Jul 2013 01:01:39 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Update Forced Switch Priority Author(s) : Huub van Helvoort Filename : draft-helvoort-ccamp-fs-priority-00.txt Pages : 4 Date : 2013-07-12 Abstract: This document clarifies the definitions related to Manual Switch and Forced Switch. This document updates RFC 4427. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-helvoort-ccamp-fs-priority There's also a htmlized version available at: http://tools.ietf.org/html/draft-helvoort-ccamp-fs-priority-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 From wyaacov@gmail.com Mon Jul 29 03:11:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6121E8094; Mon, 29 Jul 2013 03:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdWIJaRVDFTY; Mon, 29 Jul 2013 03:11:15 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9900411E80D3; Mon, 29 Jul 2013 03:11:14 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so4020403wgh.3 for ; Mon, 29 Jul 2013 03:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kpRMZW/ockb7qFuJ8RVM4YEVUksMyBgDVPmGw9EwRJ0=; b=nocRnGJmjDpZyMz4fXSs84AcnVwdQIEDr/Wa/9V0KsIuJS1/oorsjyKM2nqOZPGzhi pq8UEmYpsF1CT8t8+KNBBIwZR8RdSYrVgemNPI22WGnrKA2wEOVJj4CBlq/aRIF9sdvK bokPtWiDL3Hg6j8vp/PKJ3/e4eOKhdYGW6d/vsxzzgbGQls5O2QrH96eB7+iqy2XpPhb qEqcFKseXj0VWC4qzzBuaxez18yIIoOBxfWTawgIVI1tADyk3gdsPhdKUZKGyUX/LdnP uJChGkZGjFMQLdJkLaNj+ehJs7f56Hyf/FhGZvPytY/8blVIMbHxdA8A+ha4z5UXJVxV 9wqg== MIME-Version: 1.0 X-Received: by 10.194.19.130 with SMTP id f2mr41881574wje.22.1375092673713; Mon, 29 Jul 2013 03:11:13 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Mon, 29 Jul 2013 03:11:13 -0700 (PDT) In-Reply-To: <51F62737.3020505@gmail.com> References: <51DFBCAE.1090904@gmail.com> <51F62737.3020505@gmail.com> Date: Mon, 29 Jul 2013 13:11:13 +0300 Message-ID: From: Yaacov Weingarten To: huubatwork@gmail.com, ccamp@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d4dae599c0e04e2a3b64d Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-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, 29 Jul 2013 10:11:16 -0000 --047d7b5d4dae599c0e04e2a3b64d Content-Type: text/plain; charset=ISO-8859-1 Hi, While I understand (and to a certain extent support) the purpose of this document, I am not sure that the note that you are proposing in Section 2 of the document really clarifies the definitions of what are the priorities. Based on the Rosetta Stone document - a "Communication Channel" is any logical connection between NEs that may be used for management or control plane applications. In theory this includes (to my understanding) any use of the GACH as defined for MPLS-TP (e.g. any OAM functionality). Your note states: "For 1+1 protection schemes (which do not use a communication channel)" - - what are these? Is there a protection scheme for MPLS-TP that do not use a communication channel - for example for CC or CV messages? If you meant to say that they are not dependent upon a coordination protocol (similar to the statement in the ITU documentation that refers to APS) then I suggest that you clearly state this. - However, are you adding a blanket statement that 1+1 protection schemes do not use a coordination protocol? This is news to me, since to the best of my recollection both ITU Ethernet Linear Protection and RFC6378 define support for 1+1 protection, don't they? Might I suggest that you adhere more closely to the language of the ITU definition and state that if a coordination protocol is being used then SF-P priority is higher than FS. Hope this helps, yaacov weingarten On Mon, Jul 29, 2013 at 11:26 AM, Huub van Helvoort wrote: > Hello MPLS, > > I noticed that I did not send this notification to the MPLS > list at the same time as I sent it to CCAMP. > > This concerns/addresses priorities in linear protection. > > Best regards, Huub. > > -------- Original Message -------- > Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-**priority-00.txt > Date: Fri, 12 Jul 2013 10:22:06 +0200 > From: Huub van Helvoort > Reply-To: huubatwork@gmail.com > To: CCAMP > > Hello CCAMP, > > Based on the messages on the MPLS list: > http://www.ietf.org/mail-**archive/web/mpls/current/**msg09913.html > http://www.ietf.org/mail-**archive/web/mpls/current/**msg09916.html > > I have created and uploaded the draft below. > Comments are appreciated. > > Best regards, Huub. > > -------- Original Message -------- > Subject: I-D Action: draft-helvoort-ccamp-fs-**priority-00.txt > Date: Fri, 12 Jul 2013 01:01:39 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Update Forced Switch Priority > Author(s) : Huub van Helvoort > Filename : draft-helvoort-ccamp-fs-**priority-00.txt > Pages : 4 > Date : 2013-07-12 > > Abstract: > This document clarifies the definitions related to Manual Switch and > Forced Switch. This document updates RFC 4427. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/**doc/draft-helvoort-ccamp-fs-**priority > > There's also a htmlized version available at: > http://tools.ietf.org/html/**draft-helvoort-ccamp-fs-**priority-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-**drafts/ > > ______________________________**_________________ > 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 > > > > > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5d4dae599c0e04e2a3b64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
While I understand (and t= o a certain extent support) the purpose of this document, I am not sure tha= t the note that you are proposing in Section 2 of the document really clari= fies the definitions of what are the priorities.
=A0
Based on the Rosetta Stone document - a "Communicat= ion Channel" is any logical connection between NEs that may be used fo= r management or control plane applications. In theory this includes (to my = understanding) any use of the GACH as defined for MPLS-TP (e.g. any OAM fun= ctionality).
=A0
Your note states: "For 1+1 protection schemes (whic= h do not use a communication channel)" -
  • what are these?= Is there a protection scheme for MPLS-TP that do not use a communication c= hannel - for example for CC or CV messages? If you meant to say that they a= re not dependent upon a coordination protocol (similar to the statement in = the ITU documentation that refers to APS) then I suggest that you clearly s= tate this.
  • However, are you adding a blanket statement that 1+1 protection schemes= do not use a coordination protocol? This is news to me, since to the best = of my recollection both ITU Ethernet Linear Protection and RFC6378 define s= upport for 1+1 protection, don't they?
Might I suggest that you adhere more closely to the language of t= he ITU definition and state that if a coordination protocol is being used t= hen SF-P priority is higher than FS.
=A0
Hope this hel= ps,
yaacov weingarten


On Mon, Jul 29, 2013 at 11:26 AM, Huub van Helvoort <h= uubatwork@gmail.com> wrote:
Hello MPLS,

I noticed that I did not send this notification to the MPLS
list at the same time as I sent it to CCAMP.

This concerns/addresses priorities in linear protection.

Best regards, Huub.

-------- Original Message --------
Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt Date: Fri, 12 Jul 2013 10:22:06 +0200
From: Huub van Helvoort <huubatwork@gmail.com>
Reply-To: huubatw= ork@gmail.com
To: CCAMP <ccamp@iet= f.org>

Hello CCAMP,

Based on the messages on the MPLS list:
http://www.ietf.org/mail-archive/web/mpls/current= /msg09913.html
http://www.ietf.org/mail-archive/web/mpls/current= /msg09916.html

I have created and uploaded the draft below.
Comments are appreciated.

Best regards, Huub.

-------- Original Message --------
Subject: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt
Date: Fri, 12 Jul 2013 01:01:39 -0700
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Update Forced Switch Priority =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Huub van Helvoort
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-helvoort-ccamp-fs-pr= iority-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 4
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-12

Abstract:
=A0 =A0This document clarifies the definitions related to Manual Switch and=
=A0 =A0Forced Switch. This document updates RFC 4427.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-helvoort= -ccamp-fs-priority

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-helvoort-ccamp-fs= -priority-00


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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




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



--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--047d7b5d4dae599c0e04e2a3b64d-- From ietf-ipr@ietf.org Mon Jul 29 03:13:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA421E808C; Mon, 29 Jul 2013 03:13:58 -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.200, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD0otkaRFOrN; Mon, 29 Jul 2013 03:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BD821F9C72; Mon, 29 Jul 2013 03:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: tao.chou@huawei.com, boris.zhang@telus.com, quintin.zhao@huawei.com, emily.chen220@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729101357.10838.54256.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 03:13:57 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-zhao-mpls-mldp-protections-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, 29 Jul 2013 10:13:58 -0000 Dear Tao Chou, Telus Communications, Quintin Zhao, Emily Chen: An IPR disclosure that pertains to your Internet-Draft entitled "P2MP Based mLDP Node Protection Mechanisms for mLDP LSP" (draft-zhao-mpls-mldp-protect= ions) was submitted to the IETF Secretariat on 2013-07-28 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2150/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-zhao-mp= ls- mldp-protections-05.""); The IETF Secretariat From internet-drafts@ietf.org Mon Jul 29 06:47:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA021F9F0A; Mon, 29 Jul 2013 06:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbP1qlKhJPtW; Mon, 29 Jul 2013 06:47:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6749A21F9EEE; Mon, 29 Jul 2013 06:47:07 -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: 4.60p1 Message-ID: <20130729134707.7147.28829.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 06:47:07 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-12.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, 29 Jul 2013 13:47:11 -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 Gro= up of the IETF. Title : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen Wei Cao So Ning Frederic Jounay Simon Delord Filename : draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Pages : 20 Date : 2013-07-29 Abstract: This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-= ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-ls= p-ping-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huubatwork@gmail.com Mon Jul 29 07:33:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C560221F9A38; Mon, 29 Jul 2013 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Jdaj-pqJezc; Mon, 29 Jul 2013 07:33:45 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5221F9E43; Mon, 29 Jul 2013 07:33:35 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r11so1243813pdi.13 for ; Mon, 29 Jul 2013 07:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ri+oHjodlGMBptY2BfPNGAull3zPz9OVIFTUNFV2m1M=; b=FWh5P/MKOpobMreqHvSZ5vLMqrTtj7Zx5g6IDsAxriZSJeYrbqwn2WWaYTwgi4DGeV Y89TXLYo2WkLYtukUydG+uP6pPSFGezLxlRg3SNr+/BJmwr7UbwQ/ipKP1KcVEAYYa2g VJG2EJo3a8bpkKyRo3v2+9+mJOaUPkhSxuzV2FRI+fcabeueEGlABZW8Yz+yjzT/W0Ga 1zJO2ZTq8LhQY/n48HD1PfwTv0H5Ogd4/vVTQ8EnyqkonaOGAolZASLPUJZBpRu+Y+E1 2mLXdWmw4zxd0KJlH28HrEKld7Q9BRuYjBv9IY/XCy46n7MqQ8H43PSab+s8UIJHeP7J CshQ== X-Received: by 10.68.12.97 with SMTP id x1mr844471pbb.150.1375108414069; Mon, 29 Jul 2013 07:33:34 -0700 (PDT) Received: from dhcp-175c.meeting.ietf.org (dhcp-175c.meeting.ietf.org. [130.129.23.92]) by mx.google.com with ESMTPSA id vi8sm77284815pbc.31.2013.07.29.07.33.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 07:33:33 -0700 (PDT) Message-ID: <51F67D39.1000907@gmail.com> Date: Mon, 29 Jul 2013 16:33:29 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 References: <51DFBCAE.1090904@gmail.com> <51F62737.3020505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , ccamp@ietf.org Subject: Re: [mpls] Fwd: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt 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: Mon, 29 Jul 2013 14:33:59 -0000 Yaacov, hi, You wrote: > While I understand (and to a certain extent support) the purpose of this > document, I am not sure that the note that you are proposing in Section > 2 of the document really clarifies the definitions of what are the > priorities. OK, I hope you mean that more clarification is needed for when the priority FS over SF-P or SF-P over FS are used. > Based on the Rosetta Stone document - a "Communication Channel" is any > logical connection between NEs that may be used for management or > control plane applications. In theory this includes (to my > understanding) any use of the GACH as defined for MPLS-TP (e.g. any OAM > functionality). I think I understand the confusion. I wanted to make a difference between protection switching applications that rely on a control plane, and protection switching applications that rely on an in-band protocol which fate shares with the protection path. > Your note states: "For 1+1 protection schemes (which do not use a > communication channel)" - > > * what are these? Is there a protection scheme for MPLS-TP that do not > use a communication channel - for example for CC or CV messages? If > you meant to say that they are not dependent upon a coordination > protocol (similar to the statement in the ITU documentation that > refers to APS) then I suggest that you clearly state this. As I explained above I wanted to differentiate between a coordination protocol that uses a control plane, and one that fate shares with the protection path. > * However, are you adding a blanket statement that 1+1 protection > schemes do not use a coordination protocol? This is news to me, > since to the best of my recollection both ITU Ethernet Linear > Protection and RFC6378 define support for 1+1 protection, don't they? This was not my intention. > Might I suggest that you adhere more closely to the language of the ITU > definition and state that if a coordination protocol is being used then > SF-P priority is higher than FS. I will try to captuture this more clearly. > Hope this helps, It did, thanks, Huub. ======= > On Mon, Jul 29, 2013 at 11:26 AM, Huub van Helvoort > > wrote: > > Hello MPLS, > > I noticed that I did not send this notification to the MPLS > list at the same time as I sent it to CCAMP. > > This concerns/addresses priorities in linear protection. > > Best regards, Huub. > > -------- Original Message -------- > Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-__priority-00.txt > Date: Fri, 12 Jul 2013 10:22:06 +0200 > From: Huub van Helvoort > > Reply-To: huubatwork@gmail.com > To: CCAMP > > > Hello CCAMP, > > Based on the messages on the MPLS list: > http://www.ietf.org/mail-__archive/web/mpls/current/__msg09913.html > > http://www.ietf.org/mail-__archive/web/mpls/current/__msg09916.html > > > I have created and uploaded the draft below. > Comments are appreciated. > > Best regards, Huub. > > -------- Original Message -------- > Subject: I-D Action: draft-helvoort-ccamp-fs-__priority-00.txt > Date: Fri, 12 Jul 2013 01:01:39 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Update Forced Switch Priority > Author(s) : Huub van Helvoort > Filename : draft-helvoort-ccamp-fs-__priority-00.txt > Pages : 4 > Date : 2013-07-12 > > Abstract: > This document clarifies the definitions related to Manual Switch and > Forced Switch. This document updates RFC 4427. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/__doc/draft-helvoort-ccamp-fs-__priority > > There's also a htmlized version available at: > http://tools.ietf.org/html/__draft-helvoort-ccamp-fs-__priority-00 > > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-__drafts/ > > > _________________________________________________ > 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 > > > > > > _________________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/__listinfo/mpls > > > > > > -- > Thanx and BR, > yaacov > > /Still looking for new opportunity/ -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From huubatwork@gmail.com Mon Jul 29 08:12:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3921F11E8103 for ; Mon, 29 Jul 2013 08:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkYUe-IDY-rn for ; Mon, 29 Jul 2013 08:12:48 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E011E80EE for ; Mon, 29 Jul 2013 08:12:41 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so5516961pdi.30 for ; Mon, 29 Jul 2013 08:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding; bh=En1UiOCOzgsY5AjPtaunMN+DPlO/0o2d/+RXavPY4ew=; b=lIbe/i53WkrGLkidauYrg4L27nAtYojLFS669D2kSi7XVDa8RY/jZ7SjEL+Vs2BXPy pdjIwkNt/kfGddSb/i0RXlkiPivsRdt4AGDiahVAxYWoHIsDL/IO/5dc82fKn8uzusXv 32jA0HD8xbcCy/jc9q4zMm2aFxJ3gnegKUqOeL+TYcWBTpb9pcUM4zozXs3Q4FcZG2Yo YuZtvqDToNf52RF+ruwV9iL4+mJqLbvEQK+I9f88weh2BHDExeiNJUYYlYNRIYANCG0P rp6VFGmTxSc/jU0Y78v2fyFN5OMHau7knB+MjGN8Qyb/ZZ8pe/y+et0SKD7pSXgWNdq2 JMnw== X-Received: by 10.68.209.196 with SMTP id mo4mr68722296pbc.114.1375110761481; Mon, 29 Jul 2013 08:12:41 -0700 (PDT) Received: from dhcp-175c.meeting.ietf.org ([2001:df8:0:16:110f:4150:5a44:f5cb]) by mx.google.com with ESMTPSA id iu7sm30765342pbc.8.2013.07.29.08.12.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 08:12:40 -0700 (PDT) Message-ID: <51F68662.90700@gmail.com> Date: Mon, 29 Jul 2013 17:12:34 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" References: <20130729144943.25577.47185.idtracker@ietfa.amsl.com> In-Reply-To: <20130729144943.25577.47185.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130729144943.25577.47185.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: [CCAMP] New Liaison Statement, "Liaison Statement on Corrigendum of OTN terminology Recommendation" 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: Mon, 29 Jul 2013 15:12:49 -0000 This liaison with Corrigendum to G.870 may be of interest to MPLS too. Regards, Huub. -------- Original Message -------- Subject: [CCAMP] New Liaison Statement, "Liaison Statement on Corrigendum of OTN terminology Recommendation" Date: Mon, 29 Jul 2013 07:49:43 -0700 From: Liaison Statement Management Tool To: Lou Berger , Deborah Brungard CC: Common Control and Measurement Plane Discussion List Title: Liaison Statement on Corrigendum of OTN terminology Recommendation Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1270/ From: ITU-T SG 15 (Yoshinori Koike ) To: Common Control and Measurement Plane (Lou Berger , Deborah Brungard ) Cc: Stewart Bryant ,Adrian Farrel ,Common Control and Measurement Plane Discussion List ,John Drake ,Scott Mansfield Reponse Contact: Technical Contact: Purpose: For information Body: Attachments: Liaison Statement on Corrigendum of OTN terminology Recommendation https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t-sg-15-ccamp-liaison-statement-on-corrigendum-of-otn-terminology-recommendation-attachment-1.pdf Draft Corrigendum 1 to Recommendation ITU-T G.870/Y.1352 (2012) (for Consent, July 2013) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t-sg-15-ccamp-liaison-statement-on-corrigendum-of-otn-terminology-recommendation-attachment-2.pdf _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lsmt@ietf.org Tue Jul 30 01:33:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DEB21F9E21; Tue, 30 Jul 2013 01:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQmBGqzxOHLY; Tue, 30 Jul 2013 01:33:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1621E80D4; Tue, 30 Jul 2013 01:31:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730083101.27257.1127.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 01:31:01 -0700 Cc: Multiprotocol Label Switching Discussion List Subject: [mpls] New Liaison Statement, "Liaison Statement on linear protection switching for MPLS-TP (reply to COM15-LS84r1-E / IETF LS-1256)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 30 Jul 2013 08:33:03 -0000 Title: Liaison Statement on linear protection switching for MPLS-TP (reply = to COM15-LS84r1-E / IETF LS-1256) Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1272/ Please reply by 2013-09-23 From: ITU-T SG 15 (Tom Huber ) To: Multiprotocol Label Switching (Loa Andersson , George Swallo= w , Ross Callon ) Cc: Stewart Bryant ,Adrian Farrel = ,Multiprotocol Label Switching Discussion List ,John Drake <= jdrake@juniper.net>,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For action Body: = Attachments: Liaison Statement on linear protection switching for MPLS-TP (reply to = COM15-LS84r1-E / IETF LS-1256) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-linear-protection-switching-for-mpls-tp-re= ply-to-com15-ls84r1-e-ietf-ls-1256-attachment-1.pdf From lsmt@ietf.org Tue Jul 30 02:48:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA6211E81C4; Tue, 30 Jul 2013 02:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEaDe53Jm+yj; Tue, 30 Jul 2013 02:48:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF33D11E80DF; Tue, 30 Jul 2013 02:48:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730094815.29626.27262.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 02:48:15 -0700 Cc: Multiprotocol Label Switching Discussion List Subject: [mpls] New Liaison Statement, "Liaison Statement on initiating the Approval process for MPLS-TP Recommendations" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 30 Jul 2013 09:48:17 -0000 Title: Liaison Statement on initiating the Approval process for MPLS-TP Rec= ommendations Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1273/ From: ITU-T SG 15 (Huub van Helvoort ) To: Multiprotocol Label Switching (Loa Andersson , George Swallo= w , Ross Callon ) Cc: Stewart Bryant ,Adrian Farrel = ,Multiprotocol Label Switching Discussion List ,John Drake <= jdrake@juniper.net>,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For information Body: = Attachments: Liaison Statement on initiating the Approval process for MPLS-TP Recomm= endations https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-1.pdf Draft Amendment 1 to Recommendation ITU-T G.8113.2/Y.1372.2 (2012) (for= Determination, July 2013) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-2.pdf Draft revised Recommendation ITU-T G.8121/Y.1381 (for Consent, July 201= 3) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-3.pdf Draft new Recommendation ITU-T G.8121.1/Y.1381.1 (for Consent, July 201= 3) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-4.pdf Draft new Recommendation ITU-T G.8121.2/Y.1381.2 (for Consent, July 201= 3) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-5.pdf Draft Amendment 1 to Recommendation ITU-T G.8113.1/Y.1372.1 (2012) (for= Determination, July 2013) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-6.pdf Draft Amendment 2 to Recommendation ITU-T G.8151/Y.1374 (2012) (for Con= sent, July 2013) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-initiating-the-approval-process-for-mpls-t= p-recommendations-attachment-7.pdf From lsmt@ietf.org Tue Jul 30 03:03:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0260311E81C9; Tue, 30 Jul 2013 03:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJZMCNovggqj; Tue, 30 Jul 2013 03:02:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5717211E80D5; Tue, 30 Jul 2013 03:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730100259.14179.15369.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 03:02:59 -0700 Cc: Multiprotocol Label Switching Discussion List Subject: [mpls] New Liaison Statement, "Liaison statement on clarifying Point to Multi Point (P2MP) combinations (to IETF PWE3 and MPLS WGs) " X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 30 Jul 2013 10:03:01 -0000 Title: Liaison statement on clarifying Point to Multi Point (P2MP) combinat= ions (to IETF PWE3 and MPLS WGs) Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1275/ Please reply by 2013-12-01 From: ITU-T SG 15 (Stephen Shew ) To: Multiprotocol Label Switching (Loa Andersson , George Swallo= w , Ross Callon ) Cc: Stewart Bryant ,Adrian Farrel = ,Multiprotocol Label Switching Discussion List ,John Drake <= jdrake@juniper.net>,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For action Body: = Attachments: Liaison statement on clarifying Point to Multi Point (P2MP) combination= s (to IETF PWE3 and MPLS WGs) = https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-clarifying-point-to-multi-point-p2mp-combi= nations-to-ietf-pwe3-and-mpls-wgs-attachment-1.pdf From lsmt@ietf.org Tue Jul 30 03:33:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6411E81DB; Tue, 30 Jul 2013 03:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTCbevbHbT94; Tue, 30 Jul 2013 03:33:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EDC11E80D1; Tue, 30 Jul 2013 03:33:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730103332.3514.95841.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 03:33:32 -0700 Cc: Multiprotocol Label Switching Discussion List Subject: [mpls] New Liaison Statement, "Liaison Statement on the SG15 OTNT Standardization Work Plan - mpls" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 30 Jul 2013 10:33:32 -0000 Title: Liaison Statement on the SG15 OTNT Standardization Work Plan - mpls Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1278/ Please reply by 2014-03-07 From: ITU-T SG 15 (Yoshinori Koike ) To: Multiprotocol Label Switching (Loa Andersson , George Swallo= w , Ross Callon ) Cc: Stewart Bryant ,Adrian Farrel = ,Multiprotocol Label Switching Discussion List ,John Drake <= jdrake@juniper.net>,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For comment Body: = Attachments: Liaison Statement on the SG15 OTNT Standardization Work Plan https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-the-sg15-otnt-standardization-work-plan-mp= ls-attachment-1.pdf Draft Revised Optical Transport Networks & Technologies Standardization= Work Plan, Issue 17 https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-mpls-liaison-statement-on-the-sg15-otnt-standardization-work-plan-mp= ls-attachment-2.pdf From wwwrun@rfc-editor.org Tue Jul 30 07:13:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED6E21E80C2; Tue, 30 Jul 2013 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjAaMV8FMvTn; Tue, 30 Jul 2013 07:13:53 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E98C821E80C0; Tue, 30 Jul 2013 07:13:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 213E36210F; Tue, 30 Jul 2013 07:10:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130730141028.213E36210F@rfc-editor.org> Date: Tue, 30 Jul 2013 07:10:28 -0700 (PDT) Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6974 on Applicability of MPLS Transport Profile for Ring Topologies X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 30 Jul 2013 14:13:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6974 Title: Applicability of MPLS Transport Profile for Ring Topologies Author: Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai Status: Informational Stream: IETF Date: July 2013 Mailbox: wyaacov@gmail.com, stbryant@cisco.com, daniele.ceccarelli@ericsson.com, diego.caviglia@ericsson.com, francesco.fondelli@ericsson.com, corsi.marco@gmail.com, wu.bo@zte.com.cn, dai.xuehui@zte.com.cn Pages: 30 Characters: 69318 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-ring-protection-06.txt URL: http://www.rfc-editor.org/rfc/rfc6974.txt This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-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/search/rfc_search.php 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 internet-drafts@ietf.org Wed Jul 31 01:05:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECED21F9C7A; Wed, 31 Jul 2013 01:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2AeP-C7w+Rj; Wed, 31 Jul 2013 01:05:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D109D21F9B11; Wed, 31 Jul 2013 01:05:13 -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: 4.60p1 Message-ID: <20130731080513.23388.306.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 01:05:13 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-retire-ach-tlv-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, 31 Jul 2013 08:05:14 -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 Gro= up of the IETF. Title : Retiring TLVs from the Associated Channel Header of the = MPLS Generic Associated Channel Author(s) : Adrian Farrel Stewart Bryant Filename : draft-ietf-mpls-retire-ach-tlv-03.txt Pages : 5 Date : 2013-07-31 Abstract: The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-retire-ach-tlv-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Wed Jul 31 01:10:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912FC21F9E83 for ; Wed, 31 Jul 2013 01:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSic4dyUeQl0 for ; Wed, 31 Jul 2013 01:09:47 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 813F521F9DCA for ; Wed, 31 Jul 2013 01:09:46 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6V89h8p016897; Wed, 31 Jul 2013 09:09:43 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6V89dve016787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 09:09:40 +0100 From: "Adrian Farrel" To: References: <20130731080514.23388.72605.idtracker@ietfa.amsl.com> In-Reply-To: <20130731080514.23388.72605.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 09:09:38 +0100 Message-ID: <03ba01ce8dc5$4ef7cee0$ece76ca0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCwEsXylSITabAWcJcp1UwrnRTLpoWCT0w Content-Language: en-gb Cc: draft-ietf-mpls-retire-ach-tlv@tools.ietf.org, mpls-chairs@tools.ietf.org, spencerdawkins.ietf@gmail.com Subject: Re: [mpls] New Version Notification - draft-ietf-mpls-retire-ach-tlv-03.txt 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, 31 Jul 2013 08:10:07 -0000 Hi, IETF last call completed with comments only from the IANA. This new revision cleans up the actions on removal of information from = the registry to ensure that there is a pointer to this document so that = people chasing where the missing information has gone to they can find = this document. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 31 July 2013 09:05 > To: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-retire-ach-tlv@tools.ietf.org; > spencerdawkins.ietf@gmail.com > Subject: New Version Notification - = draft-ietf-mpls-retire-ach-tlv-03.txt >=20 >=20 > A new version (-03) has been submitted for = draft-ietf-mpls-retire-ach-tlv: > = http://www.ietf.org/internet-drafts/draft-ietf-mpls-retire-ach-tlv-03.txt= >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-retire-ach-tlv-03 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. From xuxiaohu@huawei.com Wed Jul 31 01:25:41 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153AC21F9C52 for ; Wed, 31 Jul 2013 01:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.692 X-Spam-Level: X-Spam-Status: No, score=-4.692 tagged_above=-999 required=5 tests=[AWL=1.907, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36h+UaOSc5lZ for ; Wed, 31 Jul 2013 01:25:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F302621F9223 for ; Wed, 31 Jul 2013 01:24:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATY58882; Wed, 31 Jul 2013 08:24:48 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 09:24:13 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 09:24:23 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 16:24:16 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: The concept of MPLS source labels Thread-Index: AQHOjcdY7V80ARCTM0S4TEL9yXX/yA== Date: Wed, 31 Jul 2013 08:24:16 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAA35@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] The concept of MPLS source labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 31 Jul 2013 08:25:42 -0000 Hi all, As I said at the mic, the concept of source labels has been successfully us= ed in the ATM MPLS paradigm ten years before, which is contained in the VCI= field so as to address the ATM cell merge issue. Hence it seems safe to s= ay that the concept of source labels is workable. Identifying the source of the received MPLS packet is valuable for the curr= ent non-ATM MPLS paragigm as well. Besides the MPLS performance measurement= use case as mentioned in the draft, it is useful for the multicast VPN ser= vice as well. AFAIK, one of the major reason that LDP-based MP2P LSPs can n= ot be used in the ingress replicaiton mode of multicast VPN service is it's= hard for the egress PE to identify the ingress PE of a given received pack= et for the multicast RPF check purpose. Best regards, Xiaohu= From internet-drafts@ietf.org Wed Jul 31 01:36:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C721E8053; Wed, 31 Jul 2013 01:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqcBO6rxy9fA; Wed, 31 Jul 2013 01:36:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979F821F9AFD; Wed, 31 Jul 2013 01:28:14 -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: 4.60p1 Message-ID: <20130731082814.10175.17899.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 01:28:14 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-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: Wed, 31 Jul 2013 08:36:31 -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 Gro= up of the IETF. Title : Per-Interface MIP Addressing Requirements and Design Con= siderations Author(s) : Adrian Farrel Hideki Endo Rolf Winter Yoshinori Koike Manuel Paul Filename : draft-ietf-mpls-tp-mip-mep-map-08.txt Pages : 12 Date : 2013-07-31 Abstract: The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stephane.litkowski@orange.com Wed Jul 31 02:30:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7C21F99B7 for ; Wed, 31 Jul 2013 02:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.958 X-Spam-Level: * X-Spam-Status: No, score=1.958 tagged_above=-999 required=5 tests=[AWL=-1.895, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmGETx8IA5qD for ; Wed, 31 Jul 2013 02:30:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15F21F84A8 for ; Wed, 31 Jul 2013 02:30:36 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B12882DCBCF; Wed, 31 Jul 2013 11:30:19 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9196623804B; Wed, 31 Jul 2013 11:30:19 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 31 Jul 2013 11:30:19 +0200 From: To: "draft-li-mpls-seamless-mpls-mbb@tools.ietf.org" Date: Wed, 31 Jul 2013 11:30:18 +0200 Thread-Topic: Comments on draft-li-mpls-seamless-mpls-mbb Thread-Index: Ac6N0JH00DeBxXsIQmGlvg4hQ51lDQ== Message-ID: <6143_1375263019_51F8D92B_6143_488_1_EEE55384044474429A926C625D0FCC81095804E59D@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/related; boundary="_005_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "mpls@ietf.org" Subject: [mpls] Comments on draft-li-mpls-seamless-mpls-mbb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 31 Jul 2013 09:30:44 -0000 --_005_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_ Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_" --_000_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Could you elaborate on what is the requirement for RSVP-TE ? Is it only FRR= ? Based on what can I read in the draft, I think it would be good if you look= at Segment Routing solution drafts . I think most of your concerns would be addressed by introducing such soluti= on : - 100% FRR - no scaling issue concern compared to TE - no configuration issue - natural stitching with BGP 3107 [http://www.orange.com/sirius/logos_mail/orange_logo.gif] Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com [http://www.orange.com/sirius/logos_mail/ampersand.gif] ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Could you= elaborate=20 on what is the requirement for RSVP-TE ? Is it only FRR ?
 
Based on = what can I=20 read in the draft, I think it would be good if you look at Segment Routing= =20 solution drafts .
I think m= ost of your=20 concerns would be addressed by introducing such solution :
- 100%=20 FRR
- no scal= ing issue=20 concern compared to TE
- no conf= iguration=20 issue
- natural= stitching=20 with BGP 3107
 
 
 
=

Stephane=20 Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational=20 Engineering & Support IPTAC for RAEI network

Orange=20 Expert Network of Future
t=E9l. +33 2 23 28 49 83

mob.=20 +33 6 37 86 97 52
stephane.litkowski@orange.com=

 
_____________________________________________________=
____________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_-- --_005_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_ Content-Type: image/gif; name="orange_logo.gif" Content-Description: orange_logo.gif Content-Disposition: inline; filename="orange_logo.gif"; size=1264; creation-date="Wed, 31 Jul 2013 09:30:19 GMT"; modification-date="Wed, 31 Jul 2013 09:30:19 GMT" Content-Location: http://www.orange.com/sirius/logos_mail/orange_logo.gif Content-Transfer-Encoding: base64 R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== --_005_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_ Content-Type: image/gif; name="ampersand.gif" Content-Description: ampersand.gif Content-Disposition: inline; filename="ampersand.gif"; size=1081; creation-date="Wed, 31 Jul 2013 09:30:19 GMT"; modification-date="Wed, 31 Jul 2013 09:30:19 GMT" Content-Location: http://www.orange.com/sirius/logos_mail/ampersand.gif Content-Transfer-Encoding: base64 R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== --_005_EEE55384044474429A926C625D0FCC81095804E59DPUEXCB2Fnante_-- From iesg-secretary@ietf.org Wed Jul 31 02:48:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3509121F9F44; Wed, 31 Jul 2013 02:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR+J2rQ8o+CV; Wed, 31 Jul 2013 02:48:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34C21F8F09; Wed, 31 Jul 2013 02:48:47 -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: 4.60p1 Sender: Message-ID: <20130731094847.1312.52261.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 02:48:47 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Per-Interface MIP Addressing Requirements and Design Considerations) 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, 31 Jul 2013 09:48:48 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Per-Interface MIP Addressing Requirements and Design Considerations' as 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 2013-08-21. 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 Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/ballot/ No IPR declarations have been submitted directly on this I-D. From kvivek@broadcom.com Wed Jul 31 03:54:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9375A11E817A; Wed, 31 Jul 2013 03:54:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGVg7ZOriMhF; Wed, 31 Jul 2013 03:54:52 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9519711E8177; Wed, 31 Jul 2013 03:54:50 -0700 (PDT) Received: from [10.9.208.55] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 31 Jul 2013 03:48:36 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 31 Jul 2013 03:54:40 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 31 Jul 2013 03:54:40 -0700 From: "Vivek Kumar" To: "ietf@ietf.org" , IETF-Announce Thread-Topic: [mpls] Last Call: (Per-Interface MIP Addressing Requirements and Design Considerations) to Informational RFC Thread-Index: AQHOjdNux/GOoGjWDU6B2XZkLqx4o5l+md1Q Date: Wed, 31 Jul 2013 10:54:39 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC42AE28738@SJEXCHMB09.corp.ad.broadcom.com> References: <20130731094847.1312.52261.idtracker@ietfa.amsl.com> In-Reply-To: <20130731094847.1312.52261.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DE6340E1R070934870-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Per-Interface MIP Addressing Requirements and Design Considerations) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 31 Jul 2013 10:54:56 -0000 Hi Authors, In the terminology section ( section 3) of draft , the in-mip and out-mip = are defined using forwarding engine as reference . But the term forwarding engine has not been explained in terminology sectio= n. Since the forwarding engine ( FW) is used in all the diagram in the dra= ft , I feel it will be helpful if you could add some description in termino= logy section to state what does the forwarding engine means here . =20 Regards, Vivek =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: Wednesday, July 31, 2013 3:19 PM To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Per-Int= erface MIP Addressing Requirements and Design Considerations) to Informatio= nal RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Per-Interface MIP Addressing Requirements and Design Considerations' as 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 2013-08-21. 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 Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From zzhang@juniper.net Wed Jul 31 04:19:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2211511E80EC for ; Wed, 31 Jul 2013 04:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYe+j1Uu-ITj for ; Wed, 31 Jul 2013 04:19:00 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id E7BCE21E80E0 for ; Wed, 31 Jul 2013 04:18:59 -0700 (PDT) Received: from mail145-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 11:18:58 +0000 Received: from mail145-tx2 (localhost [127.0.0.1]) by mail145-tx2-R.bigfish.com (Postfix) with ESMTP id B6D38400307 for ; Wed, 31 Jul 2013 11:18:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542I1432I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail145-tx2: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=zzhang@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail145-tx2 (localhost.localdomain [127.0.0.1]) by mail145-tx2 (MessageSwitch) id 1375269537110923_8804; Wed, 31 Jul 2013 11:18:57 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.225]) by mail145-tx2.bigfish.com (Postfix) with ESMTP id 171EFE0046 for ; Wed, 31 Jul 2013 11:18:57 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.54) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 11:18:56 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 04:18:56 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Wed, 31 Jul 2013 04:18:46 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.250) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 04:22:53 -0700 Received: from mail49-db9-R.bigfish.com (10.174.16.248) by DB9EHSOBE036.bigfish.com (10.174.14.99) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 11:18:44 +0000 Received: from mail49-db9 (localhost [127.0.0.1]) by mail49-db9-R.bigfish.com (Postfix) with ESMTP id 52BA23C025F for ; Wed, 31 Jul 2013 11:18:44 +0000 (UTC) Received: from mail49-db9 (localhost.localdomain [127.0.0.1]) by mail49-db9 (MessageSwitch) id 137526952360396_3645; Wed, 31 Jul 2013 11:18:43 +0000 (UTC) Received: from DB9EHSMHS001.bigfish.com (unknown [10.174.16.233]) by mail49-db9.bigfish.com (Postfix) with ESMTP id 09B2520046; Wed, 31 Jul 2013 11:18:43 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by DB9EHSMHS001.bigfish.com (10.174.14.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 11:18:41 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.55]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 11:18:31 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Xuxiaohu , "mpls@ietf.org" Thread-Topic: [mpls] The concept of MPLS source labels Thread-Index: AQHOjdNC0YF+X8cA7kWO3P9+GnhADJl+ombg Date: Wed, 31 Jul 2013 11:18:31 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A83B815832@BY2PRD0510MB389.namprd05.prod.outlook.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAA35@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAA35@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] The concept of MPLS source labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 31 Jul 2013 11:19:07 -0000 Xiaohui, Although not documented explicitly, MVPN Ingress Replication can use downst= ream-allocated labels to distinguish the sender PE - an egress PE just need= to allocate different labels for different ingress PEs. A draft that clarifies the Ingress Replication, including the above mention= ed label allocation behavior, is already in the work. Jeffrey > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > Sent: Wednesday, July 31, 2013 10:24 AM > To: mpls@ietf.org > Subject: [mpls] The concept of MPLS source labels >=20 > Hi all, >=20 > As I said at the mic, the concept of source labels has been > successfully used in the ATM MPLS paradigm ten years before, which is > contained in the VCI field so as to address the ATM cell merge issue. > Hence it seems safe to say that the concept of source labels is > workable. >=20 > Identifying the source of the received MPLS packet is valuable for the > current non-ATM MPLS paragigm as well. Besides the MPLS performance > measurement use case as mentioned in the draft, it is useful for the > multicast VPN service as well. AFAIK, one of the major reason that LDP- > based MP2P LSPs can not be used in the ingress replicaiton mode of > multicast VPN service is it's hard for the egress PE to identify the > ingress PE of a given received packet for the multicast RPF check > purpose. >=20 > Best regards, > Xiaohu From xuxiaohu@huawei.com Wed Jul 31 04:58:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818B21F9B7F for ; Wed, 31 Jul 2013 04:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=-2.764, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUA62hiRh3CU for ; Wed, 31 Jul 2013 04:58:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81BDE21F9C88 for ; Wed, 31 Jul 2013 04:57:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVP31837; Wed, 31 Jul 2013 11:57:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 12:56:50 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 12:57:00 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 19:56:56 +0800 From: Xuxiaohu To: "Jeffrey (Zhaohui) Zhang" , "mpls@ietf.org" Thread-Topic: [mpls] The concept of MPLS source labels Thread-Index: AQHOjcdY7V80ARCTM0S4TEL9yXX/yJl+HbSAgACPPcM= Date: Wed, 31 Jul 2013 11:56:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAB19@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAA35@NKGEML512-MBS.china.huawei.com>, <0BF0FCC78340F147BE76A6F5762318A83B815832@BY2PRD0510MB389.namprd05.prod.outlook.com> In-Reply-To: <0BF0FCC78340F147BE76A6F5762318A83B815832@BY2PRD0510MB389.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.44.60] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] =?gb2312?b?tPC4tDogIFRoZSBjb25jZXB0IG9mIE1QTFMgc291cmNl?= =?gb2312?b?IGxhYmVscw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 31 Jul 2013 11:58:05 -0000 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEplZmZy ZXkgKFpoYW9odWkpIFpoYW5nIFt6emhhbmdAanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxM8Tq N9TCMzHI1SAxOToxOA0Ktb06IFh1eGlhb2h1OyBtcGxzQGlldGYub3JnDQrW98ziOiBSRTogW21w bHNdIFRoZSBjb25jZXB0IG9mIE1QTFMgc291cmNlIGxhYmVscw0KDQpYaWFvaHVpLA0KDQpBbHRo b3VnaCBub3QgZG9jdW1lbnRlZCBleHBsaWNpdGx5LCBNVlBOIEluZ3Jlc3MgUmVwbGljYXRpb24g Y2FuIHVzZSBkb3duc3RyZWFtLWFsbG9jYXRlZCBsYWJlbHMgdG8gZGlzdGluZ3Vpc2ggdGhlIHNl bmRlciBQRSAtIGFuIGVncmVzcyBQRSBqdXN0IG5lZWQgdG8gYWxsb2NhdGUgZGlmZmVyZW50IGxh YmVscyBmb3IgZGlmZmVyZW50IGluZ3Jlc3MgUEVzLg0KDQpbWGlhb2h1XSBJbiBmYWN0LCBJIGhh ZCBwcm9wb3NlZCB0aGF0IGlkZWEgYWJvdXQgZWlnaHQgeWVhcnMgYmVmb3JlLiBTZWUgc2VjdGlv biAyLjIuIEVzdGFibGlzaG1lbnQgb2YgZnVsbC1tZXNoZWQgcHNldWRvLXdpcmVzIG9mIHRoZSBm b2xsb3dpbmcgZHJhZnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL2RyYWZ0LXh1LWwzdnBu LTI1NDdiaXMtbWNhc3QtMDAucGRmDQoNClhpYW9odQ0KDQoNCkEgZHJhZnQgdGhhdCBjbGFyaWZp ZXMgdGhlIEluZ3Jlc3MgUmVwbGljYXRpb24sIGluY2x1ZGluZyB0aGUgYWJvdmUgbWVudGlvbmVk IGxhYmVsIGFsbG9jYXRpb24gYmVoYXZpb3IsIGlzIGFscmVhZHkgaW4gdGhlIHdvcmsuDQoNCkpl ZmZyZXkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBYdXhpYW9odSBb bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMSwg MjAxMyAxMDoyNCBBTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBsc10gVGhl IGNvbmNlcHQgb2YgTVBMUyBzb3VyY2UgbGFiZWxzDQo+DQo+IEhpIGFsbCwNCj4NCj4gQXMgSSBz YWlkIGF0IHRoZSBtaWMsIHRoZSBjb25jZXB0IG9mIHNvdXJjZSBsYWJlbHMgaGFzIGJlZW4NCj4g c3VjY2Vzc2Z1bGx5IHVzZWQgaW4gdGhlIEFUTSBNUExTIHBhcmFkaWdtIHRlbiB5ZWFycyBiZWZv cmUsIHdoaWNoIGlzDQo+IGNvbnRhaW5lZCBpbiB0aGUgVkNJIGZpZWxkIHNvIGFzIHRvIGFkZHJl c3MgdGhlIEFUTSBjZWxsIG1lcmdlIGlzc3VlLg0KPiBIZW5jZSBpdCBzZWVtcyBzYWZlIHRvIHNh eSB0aGF0IHRoZSBjb25jZXB0IG9mIHNvdXJjZSBsYWJlbHMgaXMNCj4gd29ya2FibGUuDQo+DQo+ IElkZW50aWZ5aW5nIHRoZSBzb3VyY2Ugb2YgdGhlIHJlY2VpdmVkIE1QTFMgcGFja2V0IGlzIHZh bHVhYmxlIGZvciB0aGUNCj4gY3VycmVudCBub24tQVRNIE1QTFMgcGFyYWdpZ20gYXMgd2VsbC4g QmVzaWRlcyB0aGUgTVBMUyBwZXJmb3JtYW5jZQ0KPiBtZWFzdXJlbWVudCB1c2UgY2FzZSBhcyBt ZW50aW9uZWQgaW4gdGhlIGRyYWZ0LCBpdCBpcyB1c2VmdWwgZm9yIHRoZQ0KPiBtdWx0aWNhc3Qg VlBOIHNlcnZpY2UgYXMgd2VsbC4gQUZBSUssIG9uZSBvZiB0aGUgbWFqb3IgcmVhc29uIHRoYXQg TERQLQ0KPiBiYXNlZCBNUDJQIExTUHMgY2FuIG5vdCBiZSB1c2VkIGluIHRoZSBpbmdyZXNzIHJl cGxpY2FpdG9uIG1vZGUgb2YNCj4gbXVsdGljYXN0IFZQTiBzZXJ2aWNlIGlzIGl0J3MgaGFyZCBm b3IgdGhlIGVncmVzcyBQRSB0byBpZGVudGlmeSB0aGUNCj4gaW5ncmVzcyBQRSBvZiBhIGdpdmVu IHJlY2VpdmVkIHBhY2tldCBmb3IgdGhlIG11bHRpY2FzdCBSUEYgY2hlY2sNCj4gcHVycG9zZS4N Cj4NCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHU= From zzhang@juniper.net Wed Jul 31 05:28:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C2011E817A for ; Wed, 31 Jul 2013 05:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[AWL=-4.122, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gjDdjwUFlcL for ; Wed, 31 Jul 2013 05:28:45 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 969E611E8172 for ; Wed, 31 Jul 2013 05:28:41 -0700 (PDT) Received: from mail188-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 12:28:40 +0000 Received: from mail188-db8 (localhost [127.0.0.1]) by mail188-db8-R.bigfish.com (Postfix) with ESMTP id DE969700137 for ; Wed, 31 Jul 2013 12:28:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz9371Ic89bh148cI542I1432I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h5eeeK8275dh1de097hz2fh2a8h683h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail188-db8: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=zzhang@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail188-db8 (localhost.localdomain [127.0.0.1]) by mail188-db8 (MessageSwitch) id 1375273717799165_17173; Wed, 31 Jul 2013 12:28:37 +0000 (UTC) Received: from DB8EHSMHS024.bigfish.com (unknown [10.174.8.241]) by mail188-db8.bigfish.com (Postfix) with ESMTP id BF4AA940047 for ; Wed, 31 Jul 2013 12:28:37 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by DB8EHSMHS024.bigfish.com (10.174.4.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 12:28:37 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 05:28:09 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Wed, 31 Jul 2013 05:28:09 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 05:41:06 -0700 Received: from mail1-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 12:28:08 +0000 Received: from mail1-co1 (localhost [127.0.0.1]) by mail1-co1-R.bigfish.com (Postfix) with ESMTP id 231808E0105 for ; Wed, 31 Jul 2013 12:28:08 +0000 (UTC) Received: from mail1-co1 (localhost.localdomain [127.0.0.1]) by mail1-co1 (MessageSwitch) id 1375273685582586_11207; Wed, 31 Jul 2013 12:28:05 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.250]) by mail1-co1.bigfish.com (Postfix) with ESMTP id 8A8A67E0192; Wed, 31 Jul 2013 12:28:05 +0000 (UTC) Received: from BY2PRD0510HT001.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 12:28:04 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.55]) by BY2PRD0510HT001.namprd05.prod.outlook.com ([10.255.84.36]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 12:28:02 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Xuxiaohu , "mpls@ietf.org" Thread-Topic: [mpls] The concept of MPLS source labels Thread-Index: AQHOjdNC0YF+X8cA7kWO3P9+GnhADJl+ombggAAMDoCAAAe8wA== Date: Wed, 31 Jul 2013 12:28:01 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A83B817AE4@BY2PRD0510MB389.namprd05.prod.outlook.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAA35@NKGEML512-MBS.china.huawei.com>, <0BF0FCC78340F147BE76A6F5762318A83B815832@BY2PRD0510MB389.namprd05.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAB19@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DAB19@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] The concept of MPLS source labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 31 Jul 2013 12:28:55 -0000 WGlhb2h1LA0KDQpUaGFua3MgZm9yIHBvaW50aW5nIHRoYXQgb3V0Lg0KDQpJIHdhcyBtb3JlIHRv IHNwZWFrIGFib3V0IHdoZXRoZXIgTVZQTiBJbmdyZXNzIFJlcGxpY2F0aW9uIG5lZWRzIHRoZSBz b3VyY2UgbGFiZWwgb3Igbm90LCBhbmQgdGhlIG1lbnRpb25pbmcgb2YgdGhlIGRyYWZ0IGluIHRo ZSB3b3JrIHdhcyBzYXkgdGhhdCAid2Uga25vdyB3ZSBuZWVkIHRvIGRvY3VtZW50IGl0IGFuZCBp dCdzIGJlaW5nIHdvcmtlZCBvbiIuDQoNCkplZmZyZXkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMSwgMjAxMyAxOjU3IFBNDQo+IFRvOiBKZWZmcmV5ICha aGFvaHVpKSBaaGFuZzsgbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiC08Li0OiBbbXBsc10gVGhl IGNvbmNlcHQgb2YgTVBMUyBzb3VyY2UgbGFiZWxzDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiC3orz+yMs6IEplZmZyZXkgKFpoYW9odWkpIFpo YW5nIFt6emhhbmdAanVuaXBlci5uZXRdDQo+ILeiy83KsbzkOiAyMDEzxOo31MIzMcjVIDE5OjE4 DQo+ILW9OiBYdXhpYW9odTsgbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSRTogW21wbHNdIFRoZSBj b25jZXB0IG9mIE1QTFMgc291cmNlIGxhYmVscw0KPiANCj4gWGlhb2h1aSwNCj4gDQo+IEFsdGhv dWdoIG5vdCBkb2N1bWVudGVkIGV4cGxpY2l0bHksIE1WUE4gSW5ncmVzcyBSZXBsaWNhdGlvbiBj YW4gdXNlDQo+IGRvd25zdHJlYW0tYWxsb2NhdGVkIGxhYmVscyB0byBkaXN0aW5ndWlzaCB0aGUg c2VuZGVyIFBFIC0gYW4gZWdyZXNzIFBFDQo+IGp1c3QgbmVlZCB0byBhbGxvY2F0ZSBkaWZmZXJl bnQgbGFiZWxzIGZvciBkaWZmZXJlbnQgaW5ncmVzcyBQRXMuDQo+IA0KPiBbWGlhb2h1XSBJbiBm YWN0LCBJIGhhZCBwcm9wb3NlZCB0aGF0IGlkZWEgYWJvdXQgZWlnaHQgeWVhcnMgYmVmb3JlLg0K PiBTZWUgc2VjdGlvbiAyLjIuIEVzdGFibGlzaG1lbnQgb2YgZnVsbC1tZXNoZWQgcHNldWRvLXdp cmVzIG9mIHRoZQ0KPiBmb2xsb3dpbmcgZHJhZnQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9w ZGYvZHJhZnQteHUtbDN2cG4tMjU0N2Jpcy1tY2FzdC0wMC5wZGYNCj4gDQo+IFhpYW9odQ0KPiAN Cj4gDQo+IEEgZHJhZnQgdGhhdCBjbGFyaWZpZXMgdGhlIEluZ3Jlc3MgUmVwbGljYXRpb24sIGlu Y2x1ZGluZyB0aGUgYWJvdmUNCj4gbWVudGlvbmVkIGxhYmVsIGFsbG9jYXRpb24gYmVoYXZpb3Is IGlzIGFscmVhZHkgaW4gdGhlIHdvcmsuDQo+IA0KPiBKZWZmcmV5DQo+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBo dWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMSwgMjAxMyAxMDoyNCBBTQ0K PiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogW21wbHNdIFRoZSBjb25jZXB0IG9m IE1QTFMgc291cmNlIGxhYmVscw0KPiA+DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gQXMgSSBzYWlk IGF0IHRoZSBtaWMsIHRoZSBjb25jZXB0IG9mIHNvdXJjZSBsYWJlbHMgaGFzIGJlZW4NCj4gPiBz dWNjZXNzZnVsbHkgdXNlZCBpbiB0aGUgQVRNIE1QTFMgcGFyYWRpZ20gdGVuIHllYXJzIGJlZm9y ZSwgd2hpY2ggaXMNCj4gPiBjb250YWluZWQgaW4gdGhlIFZDSSBmaWVsZCBzbyBhcyB0byBhZGRy ZXNzIHRoZSBBVE0gY2VsbCBtZXJnZSBpc3N1ZS4NCj4gPiBIZW5jZSBpdCBzZWVtcyBzYWZlIHRv IHNheSB0aGF0IHRoZSBjb25jZXB0IG9mIHNvdXJjZSBsYWJlbHMgaXMNCj4gPiB3b3JrYWJsZS4N Cj4gPg0KPiA+IElkZW50aWZ5aW5nIHRoZSBzb3VyY2Ugb2YgdGhlIHJlY2VpdmVkIE1QTFMgcGFj a2V0IGlzIHZhbHVhYmxlIGZvcg0KPiB0aGUNCj4gPiBjdXJyZW50IG5vbi1BVE0gTVBMUyBwYXJh Z2lnbSBhcyB3ZWxsLiBCZXNpZGVzIHRoZSBNUExTIHBlcmZvcm1hbmNlDQo+ID4gbWVhc3VyZW1l bnQgdXNlIGNhc2UgYXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCwgaXQgaXMgdXNlZnVsIGZvciB0 aGUNCj4gPiBtdWx0aWNhc3QgVlBOIHNlcnZpY2UgYXMgd2VsbC4gQUZBSUssIG9uZSBvZiB0aGUg bWFqb3IgcmVhc29uIHRoYXQNCj4gTERQLQ0KPiA+IGJhc2VkIE1QMlAgTFNQcyBjYW4gbm90IGJl IHVzZWQgaW4gdGhlIGluZ3Jlc3MgcmVwbGljYWl0b24gbW9kZSBvZg0KPiA+IG11bHRpY2FzdCBW UE4gc2VydmljZSBpcyBpdCdzIGhhcmQgZm9yIHRoZSBlZ3Jlc3MgUEUgdG8gaWRlbnRpZnkgdGhl DQo+ID4gaW5ncmVzcyBQRSBvZiBhIGdpdmVuIHJlY2VpdmVkIHBhY2tldCBmb3IgdGhlIG11bHRp Y2FzdCBSUEYgY2hlY2sNCj4gPiBwdXJwb3NlLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+ IFhpYW9odQ0K From huubatwork@gmail.com Wed Jul 31 08:07:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03C21F9F6F; Wed, 31 Jul 2013 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUvUgSYrXMWN; Wed, 31 Jul 2013 08:07:44 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3E21F9F13; Wed, 31 Jul 2013 08:07:43 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so880575pbc.32 for ; Wed, 31 Jul 2013 08:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=D9d5NFdatKiIbv/MtW7gpZqZDAL0qgmDp9rYmjwrHl0=; b=JXX+pSOlzoVsSlrJPjfOBsm9bQauALUvWUuZblADOmGWu6LHhB3C9BNkYXnjhGbd0x qbWq1ijC9vtgTK6f7QkPd9RsMWYEUBp65vzzKaDMeHJYLdHeU0vFS9ZfJbTCY3/kQKja wIlnFUgukzgSMdSldc0RqRjfZexQEf0ZQOPbEofvA+6zivdA9I5m1/m1J9Cyt7ZQNz9I m6jUh1bMi7+cm+4+5PTt+w5XfRFS0jKs15RLgrQeDdprAJoNv5UUXHvL5sQL6sbRQxok RcTE3lx/DA4WECpDAbq4K+nB/hnoQe3o1wROmskFvu0qTP3On3rSDHpIOfL3nq2rZCqG BAGw== X-Received: by 10.66.142.42 with SMTP id rt10mr62624584pab.1.1375283263194; Wed, 31 Jul 2013 08:07:43 -0700 (PDT) Received: from dhcp-175c.meeting.ietf.org (dhcp-175c.meeting.ietf.org. [130.129.23.92]) by mx.google.com with ESMTPSA id eq5sm2692762pbc.15.2013.07.31.08.07.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 08:07:42 -0700 (PDT) Message-ID: <51F9283C.6020204@gmail.com> Date: Wed, 31 Jul 2013 17:07:40 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP , "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] follow-up draft-helvoort.ccamp-fs-priority 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: Wed, 31 Jul 2013 15:07:44 -0000 All, Following up on the discussion in the ccamp WG after the presentation of draft-helvoort.ccamp-fs-priority where Lou pointed out that RFC4427 does not define the actual order of the priorities: I discussed this with the interested parties and we reached the conclusion that updates to PSC (draft-rhd-mpls-tp-psc-priority) can be made without updating RFC4427. Best regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样