From nobody Wed Mar 1 01:50:49 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 641061294C6; Wed, 1 Mar 2017 01:50:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148836184840.19406.2812005962714427993.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 01:50:48 -0800 Archived-At: Cc: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Stephen Farrell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:50:48 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-mpls-residence-time-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ben Kaduk's fine secdir review [1] and the resulting discussion with authors made me very confident that this one only needed a cursory read from me. Thanks to all for that! [1] https://mailarchive.ietf.org/arch/search/?email_list=secdir&gbt=1&index=KaiVCjdJVovCj049ksWXoot6B98 From nobody Wed Mar 1 06:34:52 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296D21294D6; Wed, 1 Mar 2017 06:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MRiyQEYMkmO; Wed, 1 Mar 2017 06:34:50 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B162129490; Wed, 1 Mar 2017 06:34:50 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id n11so777830wma.0; Wed, 01 Mar 2017 06:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=R0SNWJG4rSh5sDHyxXjP7DPr86Nhvp5L7eMtElsv9gM=; b=Pp5YKJr07MGgrDivxV1hr4zZaZbUmgnMAqdP7fmAyMwQx7vj5dW2A651jZ9rT/sY+H LfFMGKTU9tktFlw+RUex1G2nhcQRwLzUoBM4GcnWTsFa+nlRTTc7qdvOsrbVa9jVgocG Z39xW+zYOVLjj/fJZ45eSsrFVmv6M8O0ikk5qP4at6oX5PxiU5yCqhvTrC4B7ieuBkX9 El2yljhJhhwxMsqrB1ljttSIlPKUw3762/1lnriMop0232Swn1I4x+2NYdk1PpKUU6JI vfTjZZtTenrRrVXlMyM/GaGka9asB03llCAPCXM6Of1T+liNMWeyDFZgXOls8q8LeFYe ZOyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=R0SNWJG4rSh5sDHyxXjP7DPr86Nhvp5L7eMtElsv9gM=; b=GQYTHFlQmESx78h40dlaSmiO0HW3ezGoshG9yEPXCTL9BpPmJXzo4ViQFIJD+lLAkp J+3Tjvdn6JZD/dCqFZ04PPjKPSZVRsjG6XpruNnfu47YLggkJ7OBiyQV+AJnS+v7c2WH DzVyqaJtFouBBCIA6vI8mHfTnX7V+cg2kBUGb6D+jxgnDPlqkgWY9mo6zzyD0HP6Aw1e S5jbAwszXZGYpy/Ew54AYJfIV1WmoxkCUdpyJ4rqQ1OJXZaBK3829L/k7FT8fiughGx9 7NojdoyqHx4KHq7CruyNJuIlmVVeGwPUFeZQC3Iw+fudhEpza7EHPqn/RKC12VF0A5vx /HDA== X-Gm-Message-State: AMke39keYjJnpIj6OQCBshgRU3mxQpCP5lH+y+Y81tlRZPmpBPtm/9mPA3H6s9nZ/GUTcw== X-Received: by 10.28.61.11 with SMTP id k11mr3852918wma.119.1488378889138; Wed, 01 Mar 2017 06:34:49 -0800 (PST) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id x25sm6902757wrx.27.2017.03.01.06.34.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 06:34:48 -0800 (PST) References: <61927891-c2ba-df7a-9661-7a8d06a5eaad@pi.nu> To: Loa Andersson , David Sinicrope , "draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org" From: Huub van Helvoort Message-ID: <726f667b-7812-c6b4-63f4-5cce30e0cc0b@gmail.com> Date: Wed, 1 Mar 2017 15:34:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <61927891-c2ba-df7a-9661-7a8d06a5eaad@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Shepherd Writeup update for draft-ietf-mpls-tp-temporal-hitless-psm-12 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 14:34:52 -0000 Hej Loa, [snipping to the relevant part] >> The document shepherd has reviewed the document, and the document >> >> has been updated in response to his comments. At WG chair request >> Huub > > hmmm - sent the request to Huub, but I think I did it as a co-author. I did send my comments after review to the authors directly for them to update draft and upload a new version of the draft. >> van Helvoort has also done a grammatical review of the document. In >> addition Rtg Dir Review was performed and liaisons to ITU-T SG15 >> generated to inform them of the draft and its intent to describe >> different MPLS-TP OAM requirements those communicated from ITU-T >> previously. Cheers, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Wed Mar 1 08:48:54 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04716129550; Wed, 1 Mar 2017 08:48:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 08:48:53 -0800 Archived-At: Cc: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:48:53 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-residence-time-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- High level comment: Maybe extend the security section a bit and describe what can happen in the worse case if the value has been modified to a too high or too low value; and maybe even given some guidance on performing additional checks to figure out if a given value is reasonable for a given path or not. Questions: - Can you explain why PTPType, Port ID, and Sequence ID are needed in the PTP Sub-TLV format if those values are already in the PTP packet itself that follows? - Why is it necessary to define PTP sub-TLV (and have a registry for one value only)? Are you expecting to see more values here? What would those values be? - Similar to Spencer's question: Why don't you also define a Sub-TLV format for NTP? - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with values defined as follows: * 0b001..." Maybe I don't understand what a bit-map field is here but these are more then 3 bits...? - also sec 4.3.: "Value contains variable number of bit-map fields so that overall number of bits in the fields equals Length * 8." However there is no field 'Value' in the figure... Also the following explanation about future bit-maps is really confusing to me; why don't you just say that the rest as indicated by the length field must be padded with zeros...? - Should section 4.8 maybe be a subsection of 4.7? This part confused me a bit because the example seems to be generic but the rest is RSVP-TE specific, right? Maybe move the example as a separate section before or after the whole section 4...? Nits: - Maybe change to title to: Residence Time Measurement (RTM) in MPLS network - There are (still) some not spelled out abbreviations (LDP, PW); in turn others are extended twice (e.g. PTP)... - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also indicate it as optional in the figure: Sub-TLV (optional) From nobody Wed Mar 1 15:05:58 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9DD129412; Wed, 1 Mar 2017 15:05:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 15:05:52 -0800 Archived-At: Cc: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:05:52 -0000 Alia Atlas has entered the following ballot position for draft-ietf-mpls-residence-time-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for a clear document. I think that this should be a straightforward Discuss to better clarify. In Section 4.8.1, it says "The RTM Set sub-object contains an ordered list, from egress node to ingress node, of the RTM capable nodes along the LSP's path." but the sub-TLVs (as most clearly indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant to be a list of interfaces. It isn't clear whether these are supposed to be the egress interface, the ingress interface, or just any interface - or why sending just a Router ID wouldn't be sufficient. There is no indication as to whether it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one to use. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA isn't defined. While I understand that a normative reference isn't desirable - instead of "left for future study", it would be better to say that the sub-TLV should use the same format as in Sec 4.3 and that the type allocation and full details are left to a future document. This is exactly how gaps are created for networks running only IPv6. If draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementations and had a clear time-frame for how and when to progress, this would also be a Discuss. From nobody Wed Mar 1 15:16:41 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4647129412; Wed, 1 Mar 2017 15:16:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 15:16:39 -0800 Archived-At: Cc: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:16:40 -0000 Ben Campbell has entered the following ballot position for draft-ietf-mpls-residence-time-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objection, but do have some a few minor comments: Substantive: -2.1, 4th paragraph from end: Can you offer guidance on what might constitute a reasonably bound wait time?\ -2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same message? Editorial: - Abstract: The last paragraph is a single, long sentence. Please consider breaking it into simpler sentences. - 2.1, paragraph 9: "This bit, once it is set by a two- step mode device, MUST stay set accordingly": Can that MUST be stated in process terms? That is, MUST NOT unset this bit..." -2.1, paragraph 11: "Without loss of generality should note that handling of Sync event messages..." : I don't follow the sentence; are words missing and/or out of order? -- "Following outlines handling of PTP Sync event message by the two-step RTM node.": I think there's a missing "the" at the start. It's absence completely changes the meaning of "following outlines"-- as written it seem like the verb is "following", but I think you mean it to be "outlines". -- I have trouble matching some pronouns to their antecedents in the rest of the paragraph. From nobody Wed Mar 1 23:01:12 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F0512943C; Wed, 1 Mar 2017 23:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8R_D9hxeoV8; Wed, 1 Mar 2017 23:01:09 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC09E1293F4; Wed, 1 Mar 2017 23:01:09 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id f192so34698818oic.3; Wed, 01 Mar 2017 23:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s9pRdFqU93/PbNxWkVR6Dr7ynpSwatJ0BZ1OnG/l9yM=; b=DfRx2Hw49JrY0w6XH7D5hH+/SLCmG7w1b+Tf6dSMWbElBhoEw3bEgKuyQHXM48teha frPmTHH6OuoVshV8tOWuZsecN4m6LeDy5f0eyzhbQZ7Gj39F/kIB7uWThZF8gDlIB/Os 0yi1WS4RCujZ71jlLu5DwEALYk4UvZnnsp89esnAMsRNCqs1QxmIZIDX9De2HdikBI5X ZqsCBSxmR3cXQvkIBi/szPZmwEv3JYG9QgHbKp4uAoGvnPRBMtv63GECJXrnqVDebYTs e9l2jXam/1CW15hjyhQjwEXDI4xRGAb8z5Niv5CgWZvIWZQ2MYd4UXE/kfmBckbzFdM0 /S7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s9pRdFqU93/PbNxWkVR6Dr7ynpSwatJ0BZ1OnG/l9yM=; b=PG+VqBuEd0HmzqL92xcXETg9OMYn9DuwCPd/gy1hREUDRNkbABvQKfwoIsr47GqXhe zOC0yPNbqEF5XrSqhW4W6mUQlQ6eJC3UoDXbgvij/W2TaMX9QEBKiJVStAnDYyu8T72Z ayqtDSMn1cVx8/LRIkGjNCY47aK2tOqKZUZK3ytqcuNhDo9h1tJbvHbBE6kKm5TCAQiC RO9L6SnAMw8+1E9cRw/ciwJcUtb5cWYP+Gvyozf/adT7M50/CBU7C/xm5Dg1qX1yv0rv jVMNzkv31Pnde2e/UtaevP7XqLQyrutCVYVJ1L7l1wIIzQmIA5T/dU1veheCQlCCCasJ 8jag== X-Gm-Message-State: AMke39kTepFr75eM5iywOaK4E8/gJf/Hl3qPgvMF7rpEwDcIjNtpYME46gnIk+tzp/k2+BxOGIsxiAaIVVwsig== X-Received: by 10.202.239.2 with SMTP id n2mr6901882oih.157.1488438069067; Wed, 01 Mar 2017 23:01:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Wed, 1 Mar 2017 23:01:08 -0800 (PST) In-Reply-To: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> References: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 1 Mar 2017 23:01:08 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=94eb2c0931da6088050549b9feab Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 07:01:11 -0000 --94eb2c0931da6088050549b9feab Content-Type: text/plain; charset=UTF-8 Hi Alia, thank you for your thorough review and the comments. Please find my responses in-line tagged GIM>>. Regards, Greg On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-mpls-residence-time-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for a clear document. I think that this should be a > straightforward Discuss to better clarify. > > In Section 4.8.1, it says "The RTM Set sub-object contains an ordered > list, from egress node to > ingress node, of the RTM capable nodes along the LSP's path." but the > sub-TLVs (as most clearly > indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant > to be a list of interfaces. > GIM>> I think that the text, e.g. by stating "The Length is always 12" and the Figure 10 are clear that only one interface can be listed in the sub-TLV. And the same is true for other sub-TLVs. > It isn't clear whether these are supposed to be the egress interface, the > ingress interface, or just any > interface GIM>> In order for the process described in section 4.8 to work RTM node MUST use the same ID in RTM_SET sub-TLV as in RRO subobject. > - or why sending just a Router ID wouldn't be sufficient. > There is no indication as to whether > it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same > node or how to select which one > to use. > GIM>> Selection should follow election of ID for corresponding subobject in RRO. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA > isn't defined. While I understand that a normative reference isn't > desirable - instead of "left for future study", it would be better to say > that the sub-TLV should use the same format as in Sec 4.3 and that the > type allocation and full details are left to a future document. This is > exactly how gaps are created for networks running only IPv6. If > draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementations > and had a clear time-frame for how and when to progress, this would also > be a Discuss. > GIM>> I agree that your proposal narrows the gap for IPv6 extension for RTM capability advertisement. Will apply the text you've suggested in the next version. Hope OSPF WG agrees to this change. --94eb2c0931da6088050549b9feab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,
thank you for your thorough review and the co= mments. Please find my responses in-line tagged GIM>>.

=
Regards,
Greg

On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas <akatlas= @gmail.com> wrote:
Alia Atlas has entered the following ballot position for
draft-ietf-mpls-residence-time-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for a clear document.=C2=A0 I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered<= br> list, from egress node to
=C2=A0 =C2=A0ingress node, of the RTM capable nodes along the LSP's pat= h." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.=C2=A0 Unnumbered Interface Sub-TLV" are ac= tually meant
to be a list of interfaces.
GIM>> I think that t= he text, e.g. by stating "The Length is always 12"=C2=A0and the Figure 10 are c= lear that only one interface can be listed in the sub-TLV.
And th= e same is true for other sub-TLVs.
It isn't clear whether these are supposed to be the egress interface, t= he
ingress interface, or just any
interface
GIM>> In order for the process described i= n section 4.8 to work RTM node MUST use the same ID in RTM_SET sub-TLV as i= n RRO subobject.=C2=A0
- or why sending just a Router ID wouldn't be sufficient.
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one
to use.
GIM>> Selection should follow election o= f ID for corresponding subobject in RRO.=C2=A0


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.=C2=A0 While I understand that a normative reference isn&= #39;t
desirable - instead of "left for future study", it would be bette= r to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.=C2=A0 =C2= =A0This is
exactly how gaps are created for networks running only IPv6.=C2=A0 =C2=A0If=
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementati= ons
and had a clear time-frame for how and when to progress, this would also be a Discuss.
GIM>> I agree that your proposal n= arrows the gap for IPv6 extension for RTM capability advertisement. Will ap= ply the text you've suggested in the next version. Hope OSPF WG agrees = to this change.

--94eb2c0931da6088050549b9feab-- From nobody Thu Mar 2 00:30:42 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383081294AF; Thu, 2 Mar 2017 00:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGOTvJUgd6FU; Thu, 2 Mar 2017 00:30:39 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id EC6621294A7; Thu, 2 Mar 2017 00:30:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 41DDC2D00A; Thu, 2 Mar 2017 10:30:08 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LckWmSoSkBB0; Thu, 2 Mar 2017 10:30:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B8BC72D009; Thu, 2 Mar 2017 10:30:07 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0094C1B9-EEA1-47B1-9DE2-F51DBC3E92EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148822688424.13746.15775745274859586475.idtracker@ietfa.amsl.com> Date: Thu, 2 Mar 2017 10:30:08 +0200 Message-Id: <1E8F1C8B-35E2-4A95-94D7-E6E3966DADC9@piuha.net> References: <148822688424.13746.15775745274859586475.idtracker@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: mpls@ietf.org, gen-art@ietf.org, draft-ietf-mpls-residence-time.all@ietf.org, ietf@ietf.org Subject: Re: [mpls] [Gen-art] Review of draft-ietf-mpls-residence-time-14 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:30:40 -0000 --Apple-Mail=_0094C1B9-EEA1-47B1-9DE2-F51DBC3E92EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert: Thanks for the reviews and re-reviews. I have balloted no-objection for this document on tonight=92s IESG telechat. Jari --Apple-Mail=_0094C1B9-EEA1-47B1-9DE2-F51DBC3E92EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYt9gQAAoJEM80gCTQU46q37QQAIsSAjaZS7Fab98ZJD0j/Nus Dk7swIhn3OTE0cyIAHYKeoRh+kNz8wrxgbCkHoKlqOE0MM/jrBMRRGmUOnRMVPfl B+MfY5+nHBFMca7krFT6OT1lWMgJHVL64BKaSYqZT63YNIXXRJDxej3Zylc8W9wy uayF2lQW+5IsxUeip5gFstCVCOHMiMrvpZEsMjuJppErCf+6damFaPqPC307S2VP OULTaOmmSCu2s0UnQbALIJyGNN8ge/SAYdd7ZSol27M2e291t6yKSIkwA9wnyU0t 2tTkrvu07zcs2oCBS/MEAvhYMn4x9WeSnRhRNCYUUGkz8LcOgDvTeqCVcvcoHwRZ L1M/3AergjX7dyQi19G+bu4d6jK3m/C9uLRNzCHENs5xY4WVIqowCHAt8buem05S RBezVSWoKwQu97pslZ4EdmowC+7MiZHn+O5Qwv0RUqRVIx2kVpqMtpZYf5Oi3ze2 6WISOFI2Jg1t/ZnKGkFAQGV+3G9tgDbkDdD/z/m6P1mT2Vq12tTx3yRbFpQzjZmP jTvZ1hmcnPOwHLBSlu8Y2Q9MLmjMjrb5L1yljfgrQsOY1d5Pvoh372NputLirTC4 Pbw9rmPvh68+PFKZIvFOuCY2uff0vU2arxRdcK44VLFL2FhpITC5idxpLLKGxZLG er7O7wNWm9c08xwjds+v =/q3D -----END PGP SIGNATURE----- --Apple-Mail=_0094C1B9-EEA1-47B1-9DE2-F51DBC3E92EC-- From nobody Thu Mar 2 06:48:53 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E6212949B; Thu, 2 Mar 2017 06:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id numktoi2wryG; Thu, 2 Mar 2017 06:48:49 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A6B12949F; Thu, 2 Mar 2017 06:48:48 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id n11so26234007wma.1; Thu, 02 Mar 2017 06:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jAsmEN4m+RkG9ekOiEn/2UOKv51sO84IUPHvlLzoBYw=; b=kJZhKxfm5zTT5fLK8zt9gdKcEBYCUdjK1sthV/MiGpGVFvmMjYKJdWHHoh4NN84PhQ 6seTe6t+YLe1BS15Wq1PT/4VmBhqHpGr20pMYotQQs9P4Gee7kme4ukYcJ9FdbDmR4cs NHwxGayY8VS7lN12e25oqftPJ96wZh/SS+prho8awU0KUmaVDmJHmMvQo2+h9q8U9hvj JxMB3WmzJKq9r+KL6Shi8sEU6ezHWnVQtYoVYnW7w3OwUeWLfQuQYc+1ephILUCcnbqV +gEcap/ECMjKEfBQgQ7xJzCWH0giUoJQIMnOnFlPfOQ8j3PofXjoL4ZmqE+zOPwXCGoA eAdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jAsmEN4m+RkG9ekOiEn/2UOKv51sO84IUPHvlLzoBYw=; b=Vz/RNKmdO1lCYaX0OGJKxIT5AB47HYtGy59FUFoZeT780Xrl4QkO/ZacodRMVYS9yT /H1fTERMObT4HG22r02SAavqSU6jTBGLZYWGokaVpy4TuY8hyWHmQYyRah94szaHDYqi EGpDUpU30iWlQax6o4Pw/19TB//Yw33h+/V5yxXY4cTzQzqXvosws7ATNCEOzx2bko9l I7n1E5XNqtw8SV8emaW1MtgpEtXkEw2Ip2OqvS3s074+uxgSZfKH1I0+4m9GZcQBkcpB 98OWaRvjRZLqBdhWRx943gM7U5WzU6lMWsX0qkVdX68tV0d4Sis3ingnK91nFNG/p/2c L/9Q== X-Gm-Message-State: AMke39mmTvs+IkVfWrwQSdqpmrSXUf+NkJ1WpOHYM9Nju9UFdod5S038BInyj5GP35fhRNi2GvvkRd27BJe1qg== X-Received: by 10.28.207.7 with SMTP id f7mr8655320wmg.112.1488466126813; Thu, 02 Mar 2017 06:48:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.145.5 with HTTP; Thu, 2 Mar 2017 06:48:46 -0800 (PST) In-Reply-To: References: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Thu, 2 Mar 2017 09:48:46 -0500 Message-ID: To: Greg Mirsky Content-Type: multipart/alternative; boundary=94eb2c0d79ccbfbde30549c086a8 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:48:51 -0000 --94eb2c0d79ccbfbde30549c086a8 Content-Type: text/plain; charset=UTF-8 Hi Greg, On Thu, Mar 2, 2017 at 2:01 AM, Greg Mirsky wrote: > Hi Alia, > thank you for your thorough review and the comments. Please find my > responses in-line tagged GIM>>. > > Regards, > Greg > > On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas wrote: > >> Alia Atlas has entered the following ballot position for >> draft-ietf-mpls-residence-time-14: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thank you for a clear document. I think that this should be a >> straightforward Discuss to better clarify. >> >> In Section 4.8.1, it says "The RTM Set sub-object contains an ordered >> list, from egress node to >> ingress node, of the RTM capable nodes along the LSP's path." but the >> sub-TLVs (as most clearly >> indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant >> to be a list of interfaces. >> > GIM>> I think that the text, e.g. by stating "The Length is always 12" and > the Figure 10 are clear that only one interface can be listed in the > sub-TLV. > And the same is true for other sub-TLVs. > The draft says"Only a single RTM_SET sub-TLV with the given Value field MUST be present in the RTM_SET TLV. If more than one sub-TLV is found the LSP setup MUST fail" There is nothing there that clearly states that only one of the 3 sub-TLVs should be place in the RTM_SET TLV for a particular node. There is also the inaccuracy between putting in interface addresses versus the claim that it contains nodes. For instance, text could be added/changed to indicate: "The RTM_SET TLV is intended to include the subset of the RRO Object that represents those egress interfaces on the LSP that are RTM-capable. After a node chooses an egress interface to use in the RRO sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface sub-TLV. The address family chosen SHOULD match that of the RESV message and that used in the RRO; the unnumbered interface sub-TLV is used when the egress interface has no assigned IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress interfaces the LSP traverses that are under that node's control." It isn't clear whether these are supposed to be the egress interface, the >> ingress interface, or just any >> interface > > GIM>> In order for the process described in section 4.8 to work RTM node > MUST use the same ID in RTM_SET sub-TLV as in RRO subobject. > Right - but I don't see the draft saying that clearly. See my suggested text above. > - or why sending just a Router ID wouldn't be sufficient. >> There is no indication as to whether >> it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same >> node or how to select which one >> to use. >> > GIM>> Selection should follow election of ID for corresponding subobject > in RRO. > Agreed - see suggested text. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA >> isn't defined. While I understand that a normative reference isn't >> desirable - instead of "left for future study", it would be better to say >> that the sub-TLV should use the same format as in Sec 4.3 and that the >> type allocation and full details are left to a future document. This is >> exactly how gaps are created for networks running only IPv6. If >> draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementations >> and had a clear time-frame for how and when to progress, this would also >> be a Discuss. >> > GIM>> I agree that your proposal narrows the gap for IPv6 extension for > RTM capability advertisement. Will apply the text you've suggested in the > next version. Hope OSPF WG agrees to this change. > Thanks. Regards, Alia --94eb2c0d79ccbfbde30549c086a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,



On Thu, Mar 2, 2017 at 2:01 AM, Greg = Mirsky <gregimirsky@gmail.com> wrote:
Hi Alia,
thank you = for your thorough review and the comments. Please find my responses in-line= tagged GIM>>.

Regards,
Greg
=

On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas <akatlas@gmail.com>= ; wrote:
Alia A= tlas has entered the following ballot position for
draft-ietf-mpls-residence-time-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for a clear document.=C2=A0 I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered<= br> list, from egress node to
=C2=A0 =C2=A0ingress node, of the RTM capable nodes along the LSP's pat= h." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.=C2=A0 Unnumbered Interface Sub-TLV" are ac= tually meant
to be a list of interfaces.
GIM>> I think= that the text, e.g. by stating "The Length is always 12"=C2=A0and the Figure 1= 0 are clear that only one interface can be listed in the sub-TLV.
And the same is true for other sub-TLVs.

The draft says"Only a single RTM_SET=C2=A0 sub-= TLV with the given Value field MUST be present in the RTM_SET=C2=A0 =C2=A0T= LV.=C2=A0 If more than one sub-TLV is found the LSP setup MUST fail"

There is nothing there that clearly states that onl= y one of the 3 sub-TLVs should be place in the RTM_SET TLV for a particular= node.=C2=A0 There is also the inaccuracy between putting in interface addr= esses versus the claim that it contains nodes.

For= instance, text could be added/changed to indicate:

"The RTM_SET TLV is intended to include the subset of the RRO Object= that represents those egress interfaces on the LSP that are RTM-capable.= =C2=A0 After a node chooses an egress interface to use in the RRO sub-TLV, = that same egress interface, if RTM-capable, =C2=A0SHOULD be placed into the= RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Int= erface sub-TLV.=C2=A0 The address family chosen SHOULD match that of the RE= SV message and that used in the RRO; the unnumbered interface sub-TLV is us= ed when the egress interface has no assigned IP address.=C2=A0 A node MUST = NOT place more sub-TLVs in the RTM_SET TLV than the number of RTM-capable e= gress interfaces the LSP traverses that are under that node's control.&= quot;

It isn't clear whether these are supposed to be the egress interface, t= he
ingress interface, or just any
interface
GIM>> In order for the process desc= ribed in section 4.8 to work RTM node MUST use the same ID in RTM_SET sub-T= LV as in RRO subobject.=C2=A0

=
Right - but I don't see the draft saying that clearly.=C2=A0= See my suggested text above.
=C2=A0
- or why sending just a Router ID wouldn't be suf= ficient.
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one
to use.
GIM>> Selection should follow ele= ction of ID for corresponding subobject in RRO.=C2=A0

Agreed - see suggested text.=C2=A0
=

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.=C2=A0 While I understand that a normative reference isn&= #39;t
desirable - instead of "left for future study", it would be bette= r to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.=C2=A0 =C2= =A0This is
exactly how gaps are created for networks running only IPv6.=C2=A0 =C2=A0If=
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementati= ons
and had a clear time-frame for how and when to progress, this would also be a Discuss.
GIM>> I agree that your pro= posal narrows the gap for IPv6 extension for RTM capability advertisement. = Will apply the text you've suggested in the next version. Hope OSPF WG = agrees to this change.

=
Thanks.

Regards,
Alia<= /div>
--94eb2c0d79ccbfbde30549c086a8-- From nobody Thu Mar 2 08:37:43 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DE412956C; Thu, 2 Mar 2017 08:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rD0RNi8Njdn; Thu, 2 Mar 2017 08:37:34 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1273A1294C0; Thu, 2 Mar 2017 08:37:34 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id 2so42028938oif.0; Thu, 02 Mar 2017 08:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yjI0e3RTtb1k8czGDEteMaycxB//cHdcT/7bd0rj6Bk=; b=VH4C3dSiQ324CR9Tw9nWdDVWCL7crFao6aDaJscIgkT5VlaFBrm0nHkPF8UR4NG/3K k5GVytd5Pp9hUwCQd9nIBxFJw87yzbdElQnIoAyOzaXKDt6nVRkfqhWonqlUWQyBJRmR B9yXw+mu6BozBKw2JSDxQibHqgG3L7Ju6iw/3GB8brF+3a0Aovd4taBLYrr96ZPqHM7T qkOKpnMeKyzvnP8GMgGrHsA14AXTRoPHkSVAkEXcFuBcU9ppCwjtaeo1YWoQz3SKO46B hviNkAN9l0Jkzj0S0G/DVF1oIvcUdfSj0/dpkEJZI/rqrqEnU5D5nJomthvgwoXlzxi/ dTyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yjI0e3RTtb1k8czGDEteMaycxB//cHdcT/7bd0rj6Bk=; b=IfW+Lzf6Sru9AvxaLfDC5OTheLZTr3Ir/bdHGtOqW018EPyIzZFLQh1/tCwuGQAiEO qVp38fxPNmpq4UnX7MAAByn+5JWOz2ssX9ioIiLmtTuHphithdDPVyrr8UFIH0qUUmLX K//3uPz51hKBVP7h6VQn3OJcaQ8PLgHQXpYgwfb6q0+uh5L75ewpYQhkjo55lcvgzYfL oEqrXQB4FrMdB1Yy6MhgImvZuZC9Vuk4d/Ipg4QVDO1zqIwlIX6H9bUjWl3uDzypLKCR hWm3SDRNpsVY0o68QGz/LmObr3m4dhwbwWGH7/nMrSK8Kl/s9AFF3kzxtb2H7O0WdZAV ddZQ== X-Gm-Message-State: AMke39lT2FZASMHvm697sIbPOUmifMZEcWToiCmi0Z+H90dRAedrsf+4aOpdbrTH7cu8Sa55wRCPlCEAbseYOg== X-Received: by 10.202.236.140 with SMTP id k134mr6986797oih.123.1488472653426; Thu, 02 Mar 2017 08:37:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Thu, 2 Mar 2017 08:37:33 -0800 (PST) In-Reply-To: References: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 2 Mar 2017 08:37:33 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a1134fc3ec3ff110549c20bb0 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:37:37 -0000 --001a1134fc3ec3ff110549c20bb0 Content-Type: text/plain; charset=UTF-8 Hi Alia, thank you for the proposed text. Accepted. Please see the updated text below. Regards, Greg On Thu, Mar 2, 2017 at 6:48 AM, Alia Atlas wrote: > Hi Greg, > > > > On Thu, Mar 2, 2017 at 2:01 AM, Greg Mirsky wrote: > >> Hi Alia, >> thank you for your thorough review and the comments. Please find my >> responses in-line tagged GIM>>. >> >> Regards, >> Greg >> >> On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas wrote: >> >>> Alia Atlas has entered the following ballot position for >>> draft-ietf-mpls-residence-time-14: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/stat >>> ement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Thank you for a clear document. I think that this should be a >>> straightforward Discuss to better clarify. >>> >>> In Section 4.8.1, it says "The RTM Set sub-object contains an ordered >>> list, from egress node to >>> ingress node, of the RTM capable nodes along the LSP's path." but the >>> sub-TLVs (as most clearly >>> indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant >>> to be a list of interfaces. >>> >> GIM>> I think that the text, e.g. by stating "The Length is always 12" and >> the Figure 10 are clear that only one interface can be listed in the >> sub-TLV. >> And the same is true for other sub-TLVs. >> > > The draft says"Only a single RTM_SET sub-TLV with the given Value field > MUST be present in the RTM_SET TLV. If more than one sub-TLV is found > the LSP setup MUST fail" > > There is nothing there that clearly states that only one of the 3 sub-TLVs > should be place in the RTM_SET TLV for a particular node. There is also > the inaccuracy between putting in interface addresses versus the claim that > it contains nodes. > > For instance, text could be added/changed to indicate: > > "The RTM_SET TLV is intended to include the subset of the RRO Object that > represents those egress interfaces on the LSP that are RTM-capable. After > a node chooses an egress interface to use in the RRO sub-TLV, that same > egress interface, if RTM-capable, SHOULD be placed into the RTM_SET TLV > using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface > sub-TLV. The address family chosen SHOULD match that of the RESV message > and that used in the RRO; the unnumbered interface sub-TLV is used when the > egress interface has no assigned IP address. A node MUST NOT place more > sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress > interfaces the LSP traverses that are under that node's control." > > OLD TEXT: Sub-TLVs are organized as a last-in-first-out stack. The first -out sub-TLV relative to the beginning of RTM_SET TLV is considered the top. The last-out sub-TLV is considered the bottom. When a new sub- TLV is added, it is always added to the top. Only a single RTM_SET sub-TLV with the given Value field MUST be present in the RTM_SET TLV. If more than one sub-TLV is found the LSP setup MUST fail with the generation of a PathErr message with the Error Code "Duplicate sub-TLV" Section 8.9 and Error Value contains 16-bit value composed of (Type of TLV, Type of sub-TLV). NEW TEXT: Sub-TLVs are organized as a last-in-first-out stack. The first-out sub-TLV relative to the beginning of RTM_SET TLV is considered the top. The last-out sub-TLV is considered the bottom. When a new sub- TLV is added, it is always added to the top. The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs that represents those egress interfaces on the LSP that are RTM- capable. After a node chooses an egress interface to use in the RRO sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface sub-TLV. The address family chosen SHOULD match that of the RESV message and that used in the RRO; the unnumbered interface sub-TLV is used when the egress interface has no assigned IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress interfaces the LSP traverses that are under that node's control. Only a single RTM_SET sub-TLV with the given Value field MUST be present in the RTM_SET TLV. If more than one sub-TLV is found the LSP setup MUST fail with the generation of a ResvErr message with the Error Code "Duplicate sub- TLV" Section 7.9 and Error Value contains 16-bit value composed of (Type of TLV, Type of sub-TLV). > It isn't clear whether these are supposed to be the egress interface, the >>> ingress interface, or just any >>> interface >> >> GIM>> In order for the process described in section 4.8 to work RTM node >> MUST use the same ID in RTM_SET sub-TLV as in RRO subobject. >> > > Right - but I don't see the draft saying that clearly. See my suggested > text above. > > >> - or why sending just a Router ID wouldn't be sufficient. >>> There is no indication as to whether >>> it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same >>> node or how to select which one >>> to use. >>> >> GIM>> Selection should follow election of ID for corresponding subobject >> in RRO. >> > > Agreed - see suggested text. > >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA >>> isn't defined. While I understand that a normative reference isn't >>> desirable - instead of "left for future study", it would be better to say >>> that the sub-TLV should use the same format as in Sec 4.3 and that the >>> type allocation and full details are left to a future document. This is >>> exactly how gaps are created for networks running only IPv6. If >>> draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for >>> implementations >>> and had a clear time-frame for how and when to progress, this would also >>> be a Discuss. >>> >> GIM>> I agree that your proposal narrows the gap for IPv6 extension for >> RTM capability advertisement. Will apply the text you've suggested in the >> next version. Hope OSPF WG agrees to this change. >> > > OLD TEXT: The capability to support RTM on a particular link (interface) can be advertised in OSPFv3 using LSA extensions as described in [I-D.ietf-ospf-ospfv3-lsa-extend ]. Exact use of OSPFv3 LSA extensions is for further study. NEW TEXT: The capability to support RTM on a particular link (interface) can be advertised in OSPFv3 using LSA extensions as described in [I-D.ietf-ospf-ospfv3-lsa-extend]. The sub-TLV SHOULD use the same format as in Section 4.3. The type allocation and full details of exact use of OSPFv3 LSA extensions is for further study. > Thanks. > > Regards, > Alia > --001a1134fc3ec3ff110549c20bb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,
thank you for the proposed text. Accepted. Pl= ease see the updated text below.

Regards,
Greg

On Th= u, Mar 2, 2017 at 6:48 AM, Alia Atlas <akatlas@gmail.com> wr= ote:
= Hi Greg,



On Thu, Mar 2, 2017 at 2:= 01 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Alia,thank you for your thorough review and the comments. Please find my respo= nses in-line tagged GIM>>.

Regards,
Greg

On Wed, Mar 1, 2017 at 3:05 PM= , Alia Atlas <akatlas@gmail.com> wrote:
Alia Atlas has entered the following ballo= t position for
draft-ietf-mpls-residence-time-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for a clear document.=C2=A0 I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered<= br> list, from egress node to
=C2=A0 =C2=A0ingress node, of the RTM capable nodes along the LSP's pat= h." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.=C2=A0 Unnumbered Interface Sub-TLV" are ac= tually meant
to be a list of interfaces.
GIM>> I think= that the text, e.g. by stating "The Length is always 12"=C2=A0and the Figure 1= 0 are clear that only one interface can be listed in the sub-TLV.
And the same is true for other sub-TLVs.

The draft says"Only a single RTM_SE= T=C2=A0 sub-TLV with the given Value field MUST be present in the RTM_SET= =C2=A0 =C2=A0TLV.=C2=A0 If more than one sub-TLV is found the LSP setup MUS= T fail"

There is nothing there that clearly s= tates that only one of the 3 sub-TLVs should be place in the RTM_SET TLV fo= r a particular node.=C2=A0 There is also the inaccuracy between putting in = interface addresses versus the claim that it contains nodes.

=
For instance, text could be added/changed to indicate:

"The RTM_SET TLV is intended to include the subset of = the RRO Object that represents those egress interfaces on the LSP that are = RTM-capable.=C2=A0 After a node chooses an egress interface to use in the R= RO sub-TLV, that same egress interface, if RTM-capable, =C2=A0SHOULD be pla= ced into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Un= numbered Interface sub-TLV.=C2=A0 The address family chosen SHOULD match th= at of the RESV message and that used in the RRO; the unnumbered interface s= ub-TLV is used when the egress interface has no assigned IP address.=C2=A0 = A node MUST NOT place more sub-TLVs in the RTM_SET TLV than the number of R= TM-capable egress interfaces the LSP traverses that are under that node'= ;s control."

<= /div>
OLD TEXT:
   Sub-TLVs are organized as a last-in-first-out stack.  The first =
-out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.  Only a single RTM_SET
   sub-TLV with the given Value field MUST be present in the RTM_SET
   TLV.  If more than one sub-TLV is found the LSP setup MUST fail with
   the generation of a PathErr message with the Error Code "Duplicate
   sub-TLV" Section 8.9 and Error Value contains 16-bit=
 value composed
   of (Type of TLV, Type of sub-TLV).

NEW TEXT:
   Sub-TLVs are organized as =
a last-in-first-out stack.  The first-out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.

   The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs
   that represents those egress interfaces on the LSP that are RTM-
   capable.  After a node chooses an egress interface to use in the RRO
   sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed
   into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or
   Unnumbered Interface sub-TLV.  The address family chosen SHOULD match
   that of the RESV message and that used in the RRO; the unnumbered
   interface sub-TLV is used when the egress interface has no assigned
   IP address.  A node MUST NOT place more sub-TLVs in the RTM_SET TLV
   than the number of RTM-capable egress interfaces the LSP traverses
   that are under that node's control.  Only a single RTM_SET sub-TLV
   with the given Value field MUST be present in the RTM_SET TLV.  If
   more than one sub-TLV is found the LSP setup MUST fail with the
   generation of a ResvErr message with the Error Code "Duplicate sub-
   TLV" Section 7.9 and Error Value contains 16-bit value composed of
   (Type of TLV, Type of sub-TLV).
=C2=A0
<= span class=3D"gmail-m_1441921946818180727gmail-">
It isn't clear whether these are supposed to be the egress interface, t= he
ingress interface, or just any
interface
GIM>> In order for the process desc= ribed in section 4.8 to work RTM node MUST use the same ID in RTM_SET sub-T= LV as in RRO subobject.=C2=A0

=
Right - but I don't see the draft saying that clearly= .=C2=A0 See my suggested text above.
=C2= =A0
- or why sending just a Router ID wouldn't be sufficient.
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one
to use.
GIM>> Selection should follow ele= ction of ID for corresponding subobject in RRO.=C2=A0

Agreed - see suggested text.=C2= =A0

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.=C2=A0 While I understand that a normative reference isn&= #39;t
desirable - instead of "left for future study", it would be bette= r to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.=C2=A0 =C2= =A0This is
exactly how gaps are created for networks running only IPv6.=C2=A0 =C2=A0If=
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementati= ons
and had a clear time-frame for how and when to progress, this would also be a Discuss.
GIM>> I agree that your pro= posal narrows the gap for IPv6 extension for RTM capability advertisement. = Will apply the text you've suggested in the next version. Hope OSPF WG = agrees to this change.
OLD TEXT:
   The capability to support RTM on a particular link (interface) can =
be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend]=
.  Exact use of OSPFv3 LSA
   extensions is for further study.
NEW TEXT:
   The capability to support RTM on a particular l=
ink (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend].  The sub-TLV SHOULD use the same
   format as in Section 4.3.  The type allocation and full details of
   exact use of OSPFv3 LSA extensions is for further study.
=C2=A0
= Thanks.

Regards,
Alia

--001a1134fc3ec3ff110549c20bb0-- From nobody Thu Mar 2 08:41:05 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCC129515; Thu, 2 Mar 2017 08:40:58 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfFxCsN4Le63; Thu, 2 Mar 2017 08:40:55 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057A21294E3; Thu, 2 Mar 2017 08:40:55 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id g10so56567832wrg.2; Thu, 02 Mar 2017 08:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m5XmNsHb0fX0n9tENQKbiMC0Iz6tp4D/yGSmZF6oMIM=; b=foGgMMffRwJ24pRcSwdhQ3cM4PmxQ31ExeH/eJJNgTlvP+H6oJTrdFTC6Z0bl+jcnT v94THr2yy4nmcSOZcDvIlTq0GTnnIR4gIA/amimGJBjU9MjGrUFvLlBMU56fskxxjioZ kDw1HXiFz35UF+yqMsA8eVA57MRLkV97+ioqZL8CeubolUUjwiLirC9Yz89e4/DPUhuR 4EDnNynOsY9E3ce73P+K9wcuY3Hf23ia6i3x2d4Yptyurz33AD/LsttZ8BCwFzWmxAtA K1/0TCeI54EwbR6HYdqD3GMwBFJyS+pBHmWdrE336CsLxWrV8a7IElKYOEkQAXBw1VVY RkaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m5XmNsHb0fX0n9tENQKbiMC0Iz6tp4D/yGSmZF6oMIM=; b=cWwv9TguM3FN9oEDFjvaPoC7BkVli0eoMzhNeyi/3v2p5QnvPBKj+XT+n+du6DVjU0 KWNqdw7damGfrQjMEGm7+u7wORwGnOqXPEJ+a7ctlBDE9GLeekx7r+qWTtWZP0DORp5G tniOMkKEniqfRzwcMqaCDwLKSFFhitDtleNWDWfOCyRzthBFpuZr0Vqjsk9fm0hX5Grb d5bHXw9Zzd9qj116uMGyzvEyVHxrvMcYUz73BJSJ9VSInkIhqI9b4SfHrlD/idodE1Qt w5yQOIbZSUabK+X0NiSbClGTucaPoWXukor5kJUCy8AgkOz0ITn3UyDe6Ffmazu7Sc9x MnSw== X-Gm-Message-State: AMke39lY45lBbu2iwO/id8etynpItEXl/lSyWOEMPx1MfA6j+UnvGvJJFhC0gSvjSF5ZwqeTrt0JO7XaaIaHyA== X-Received: by 10.223.155.193 with SMTP id e1mr13106986wrc.86.1488472853125; Thu, 02 Mar 2017 08:40:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.145.5 with HTTP; Thu, 2 Mar 2017 08:40:52 -0800 (PST) In-Reply-To: References: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Thu, 2 Mar 2017 11:40:52 -0500 Message-ID: To: Greg Mirsky Content-Type: multipart/alternative; boundary=94eb2c1b31f2ab20ef0549c217f0 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:40:58 -0000 --94eb2c1b31f2ab20ef0549c217f0 Content-Type: text/plain; charset=UTF-8 LGTM - thanks! I'll clear now - assuming you will post the updated draft. Regards, Alia On Thu, Mar 2, 2017 at 11:37 AM, Greg Mirsky wrote: > Hi Alia, > thank you for the proposed text. Accepted. Please see the updated text > below. > > Regards, > Greg > > On Thu, Mar 2, 2017 at 6:48 AM, Alia Atlas wrote: > >> Hi Greg, >> >> >> >> On Thu, Mar 2, 2017 at 2:01 AM, Greg Mirsky >> wrote: >> >>> Hi Alia, >>> thank you for your thorough review and the comments. Please find my >>> responses in-line tagged GIM>>. >>> >>> Regards, >>> Greg >>> >>> On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas wrote: >>> >>>> Alia Atlas has entered the following ballot position for >>>> draft-ietf-mpls-residence-time-14: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/stat >>>> ement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> Thank you for a clear document. I think that this should be a >>>> straightforward Discuss to better clarify. >>>> >>>> In Section 4.8.1, it says "The RTM Set sub-object contains an ordered >>>> list, from egress node to >>>> ingress node, of the RTM capable nodes along the LSP's path." but the >>>> sub-TLVs (as most clearly >>>> indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant >>>> to be a list of interfaces. >>>> >>> GIM>> I think that the text, e.g. by stating "The Length is always 12" and >>> the Figure 10 are clear that only one interface can be listed in the >>> sub-TLV. >>> And the same is true for other sub-TLVs. >>> >> >> The draft says"Only a single RTM_SET sub-TLV with the given Value field >> MUST be present in the RTM_SET TLV. If more than one sub-TLV is found >> the LSP setup MUST fail" >> >> There is nothing there that clearly states that only one of the 3 >> sub-TLVs should be place in the RTM_SET TLV for a particular node. There >> is also the inaccuracy between putting in interface addresses versus the >> claim that it contains nodes. >> >> For instance, text could be added/changed to indicate: >> >> "The RTM_SET TLV is intended to include the subset of the RRO Object that >> represents those egress interfaces on the LSP that are RTM-capable. After >> a node chooses an egress interface to use in the RRO sub-TLV, that same >> egress interface, if RTM-capable, SHOULD be placed into the RTM_SET TLV >> using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface >> sub-TLV. The address family chosen SHOULD match that of the RESV message >> and that used in the RRO; the unnumbered interface sub-TLV is used when the >> egress interface has no assigned IP address. A node MUST NOT place more >> sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress >> interfaces the LSP traverses that are under that node's control." >> >> OLD TEXT: > > Sub-TLVs are organized as a last-in-first-out stack. The first -out > sub-TLV relative to the beginning of RTM_SET TLV is considered the > top. The last-out sub-TLV is considered the bottom. When a new sub- > TLV is added, it is always added to the top. Only a single RTM_SET > sub-TLV with the given Value field MUST be present in the RTM_SET > TLV. If more than one sub-TLV is found the LSP setup MUST fail with > the generation of a PathErr message with the Error Code "Duplicate > sub-TLV" Section 8.9 and Error Value contains 16-bit value composed > of (Type of TLV, Type of sub-TLV). > > > NEW TEXT: > > Sub-TLVs are organized as a last-in-first-out stack. The first-out > sub-TLV relative to the beginning of RTM_SET TLV is considered the > top. The last-out sub-TLV is considered the bottom. When a new sub- > TLV is added, it is always added to the top. > > The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs > that represents those egress interfaces on the LSP that are RTM- > capable. After a node chooses an egress interface to use in the RRO > sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed > into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or > Unnumbered Interface sub-TLV. The address family chosen SHOULD match > that of the RESV message and that used in the RRO; the unnumbered > interface sub-TLV is used when the egress interface has no assigned > IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV > than the number of RTM-capable egress interfaces the LSP traverses > that are under that node's control. Only a single RTM_SET sub-TLV > with the given Value field MUST be present in the RTM_SET TLV. If > more than one sub-TLV is found the LSP setup MUST fail with the > generation of a ResvErr message with the Error Code "Duplicate sub- > TLV" Section 7.9 and Error Value contains 16-bit value composed of > (Type of TLV, Type of sub-TLV). > > > >> It isn't clear whether these are supposed to be the egress interface, the >>>> ingress interface, or just any >>>> interface >>> >>> GIM>> In order for the process described in section 4.8 to work RTM node >>> MUST use the same ID in RTM_SET sub-TLV as in RRO subobject. >>> >> >> Right - but I don't see the draft saying that clearly. See my suggested >> text above. >> >> >>> - or why sending just a Router ID wouldn't be sufficient. >>>> There is no indication as to whether >>>> it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same >>>> node or how to select which one >>>> to use. >>>> >>> GIM>> Selection should follow election of ID for corresponding subobject >>> in RRO. >>> >> >> Agreed - see suggested text. >> >>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA >>>> isn't defined. While I understand that a normative reference isn't >>>> desirable - instead of "left for future study", it would be better to >>>> say >>>> that the sub-TLV should use the same format as in Sec 4.3 and that the >>>> type allocation and full details are left to a future document. This >>>> is >>>> exactly how gaps are created for networks running only IPv6. If >>>> draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for >>>> implementations >>>> and had a clear time-frame for how and when to progress, this would also >>>> be a Discuss. >>>> >>> GIM>> I agree that your proposal narrows the gap for IPv6 extension for >>> RTM capability advertisement. Will apply the text you've suggested in the >>> next version. Hope OSPF WG agrees to this change. >>> >> >> OLD TEXT: > > The capability to support RTM on a particular link (interface) can be > advertised in OSPFv3 using LSA extensions as described in > [I-D.ietf-ospf-ospfv3-lsa-extend ]. Exact use of OSPFv3 LSA > extensions is for further study. > > NEW TEXT: > > The capability to support RTM on a particular link (interface) can be > advertised in OSPFv3 using LSA extensions as described in > [I-D.ietf-ospf-ospfv3-lsa-extend]. The sub-TLV SHOULD use the same > format as in Section 4.3. The type allocation and full details of > exact use of OSPFv3 LSA extensions is for further study. > > > >> Thanks. >> >> Regards, >> Alia >> > > --94eb2c1b31f2ab20ef0549c217f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LGTM - thanks!

I'll clear now - ass= uming you will post the updated draft.

Regards,
Alia

On Thu, Mar 2, 2017 at 11:37 AM, Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com> wrote:
Hi Alia,
thank you for the proposed text. Accepted. Please see the u= pdated text below.

Regards,
Greg

On Thu, Mar 2, 2017 at 6:48 AM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
Hi Greg,


<= br>
On Thu, Mar 2, 2017 at 2:01 AM, Greg Mirsky <gregimirsky@gmail.c= om> wrote:
Hi Alia,
thank you for your thorough review and the= comments. Please find my responses in-line tagged GIM>>.
<= br>
Regards,
Greg

<= div class=3D"gmail_quote">On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas <akatlas= @gmail.com> wrote:
Alia Atlas has entered the following ballot position for
draft-ietf-mpls-residence-time-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for a clear document.=C2=A0 I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered<= br> list, from egress node to
=C2=A0 =C2=A0ingress node, of the RTM capable nodes along the LSP's pat= h." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.=C2=A0 Unnumbered Interface Sub-TLV" are ac= tually meant
to be a list of interfaces.
GIM>> I think= that the text, e.g. by stating "The Length is always 12"=C2=A0and the Figure 1= 0 are clear that only one interface can be listed in the sub-TLV.
And the same is true for other sub-TLVs.

The draft says"Only a single RTM_SE= T=C2=A0 sub-TLV with the given Value field MUST be present in the RTM_SET= =C2=A0 =C2=A0TLV.=C2=A0 If more than one sub-TLV is found the LSP setup MUS= T fail"

There is nothing there that clearly s= tates that only one of the 3 sub-TLVs should be place in the RTM_SET TLV fo= r a particular node.=C2=A0 There is also the inaccuracy between putting in = interface addresses versus the claim that it contains nodes.

=
For instance, text could be added/changed to indicate:

"The RTM_SET TLV is intended to include the subset of = the RRO Object that represents those egress interfaces on the LSP that are = RTM-capable.=C2=A0 After a node chooses an egress interface to use in the R= RO sub-TLV, that same egress interface, if RTM-capable, =C2=A0SHOULD be pla= ced into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Un= numbered Interface sub-TLV.=C2=A0 The address family chosen SHOULD match th= at of the RESV message and that used in the RRO; the unnumbered interface s= ub-TLV is used when the egress interface has no assigned IP address.=C2=A0 = A node MUST NOT place more sub-TLVs in the RTM_SET TLV than the number of R= TM-capable egress interfaces the LSP traverses that are under that node'= ;s control."
OLD TEXT:
   Sub-TLVs=
 are organized as a last-in-first-out stack.  The first -out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.  Only a single RTM_SET
   sub-TLV with the given Value field MUST be present in the RTM_SET
   TLV.  If more than one sub-TLV is found the LSP setup MUST fail with
   the generation of a PathErr message with the Error Code "Duplicate
   sub-TLV" Section 8.9 and Error Val=
ue contains 16-bit value composed
   of (Type of TLV, Type of sub-TLV).

NEW TEXT:
   Sub-TLVs are organized as =
a last-in-first-out stack.  The first-out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.

   The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs
   that represents those egress interfaces on the LSP that are RTM-
   capable.  After a node chooses an egress interface to use in the RRO
   sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed
   into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or
   Unnumbered Interface sub-TLV.  The address family chosen SHOULD match
   that of the RESV message and that used in the RRO; the unnumbered
   interface sub-TLV is used when the egress interface has no assigned
   IP address.  A node MUST NOT place more sub-TLVs in the RTM_SET TLV
   than the number of RTM-capable egress interfaces the LSP traverses
   that are under that node's control.  Only a single RTM_SET sub-TLV
   with the given Value field MUST be present in the RTM_SET TLV.  If
   more than one sub-TLV is found the LSP setup MUST fail with the
   generation of a ResvErr message with the Error Code "Duplicate sub-
   TLV" Section 7.9 and Error Value contains 16-bit value composed of
   (Type of TLV, Type of sub-TLV).
=C2=A0
It isn't clear whether these are supposed to be the egress interface, t= he
ingress interface, or just any
interface
GIM>> In order for the process desc= ribed in section 4.8 to work RTM node MUST use the same ID in RTM_SET sub-T= LV as in RRO subobject.=C2=A0

=
Right - but I don't see the draft saying that clearly= .=C2=A0 See my suggested text above.
=C2=A0
= - or why sending just a Rou= ter ID wouldn't be sufficient.
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one
to use.
GIM>> Selection should follow ele= ction of ID for corresponding subobject in RRO.=C2=A0

Agreed - see suggested text.=C2= =A0
-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.=C2=A0 While I understand that a normative reference isn&= #39;t
desirable - instead of "left for future study", it would be bette= r to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.=C2=A0 =C2= =A0This is
exactly how gaps are created for networks running only IPv6.=C2=A0 =C2=A0If=
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementati= ons
and had a clear time-frame for how and when to progress, this would also be a Discuss.
GIM>> I agree that your pro= posal narrows the gap for IPv6 extension for RTM capability advertisement. = Will apply the text you've suggested in the next version. Hope OSPF WG = agrees to this change.
OLD TEXT:
   The capability to support RTM on =
a particular link (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospf=
v3-lsa-extend].  Exact use of OSPFv3 LSA
   extensions is for further study.
NEW TEXT:
   The capability to support RTM on a particular l=
ink (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend].  The sub-TLV SHOULD use the same
   format as in Section 4.3.  The type allocation and full details of
   exact use of OSPFv3 LSA extensions is for further study.
=C2=A0
= Thanks.

Regards,
Alia


--94eb2c1b31f2ab20ef0549c217f0-- From nobody Thu Mar 2 08:43:27 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61C7129507; Thu, 2 Mar 2017 08:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIy6NpswXD0V; Thu, 2 Mar 2017 08:43:20 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F04129435; Thu, 2 Mar 2017 08:43:20 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id f192so42192408oic.3; Thu, 02 Mar 2017 08:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bV6HacbbaDiL+3bDs+S3IuTsIBP+bBkFrQ/A8UjF90M=; b=psZmuKUkEDQ9MBl3W4HZP0WKMH2K+LskfG4BevGxJ8/0JGGwOoXBxQAoEXNyjNM58z NMO66lrac3+gIi3Ys4wMsNEiVEPnuwTqiEPIqJMcrwnunsnBhAnXi3WwR/2TAaYvnt9q qWsgMvS7RWtcQ6WWWo1EGmRuLzN9ow0wNG1ZEw0c0XmAATxISSQsCMdVkQUO6D7Dag+n VY50l9yLsfunlrn5bOdKT+IyGWiH2p3Gj+uucCZ5xrRKnvmuXYTZlz1LozrIP9O+5VPo gO8k064yrfpZXN6ECF+cWJ1jDCDdPIdpMXQ/wda1Gl36K1Rx4GkIeGHUk081SbdGXIXf tlAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bV6HacbbaDiL+3bDs+S3IuTsIBP+bBkFrQ/A8UjF90M=; b=K83lYBA5X6X7io9KNd/tgnwuKkIP784sBcnz7J//x+PgrlSyoQ32r1sQt78mJ+a4Tp CSgjyYD/j1lrX+NsQU9fVukF35m3Po64cERuWZEr8KXbutzND8GauUOTxYo21q5UnzoM fjnuri0sjVACq/37uhwIKwWTi9IdNnKGXfzbfIeb0yHvIsODK0co5BvmhoBMAF+qSSF7 BsTkKpPHeTMvjJtjLme7Uj6xrjC850WwP8ixNuwtp4YZzLlf2L7QqAmXtwl7xNPsZfpt cU+aO7MaTVY2ODoZyTU/djHouseuBC4ihohleCJvbfVvRieB1tOnWdwfo4IDuu6EG4iL c22w== X-Gm-Message-State: AMke39n838esVY3ItT13hqSkg2kP5TtRj89xFyp/oIS+AdqR0K9oB99hIvu5tXPH2OvpBr62boXvCgw9MWWEqQ== X-Received: by 10.202.171.146 with SMTP id u140mr7815733oie.167.1488472999644; Thu, 02 Mar 2017 08:43:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Thu, 2 Mar 2017 08:43:19 -0800 (PST) In-Reply-To: References: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 2 Mar 2017 08:43:19 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113c32ea66d83f0549c220b6 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:43:23 -0000 --001a113c32ea66d83f0549c220b6 Content-Type: text/plain; charset=UTF-8 Thank you! Will work on other comments we've received and post the update then. Regards, Greg On Thu, Mar 2, 2017 at 8:40 AM, Alia Atlas wrote: > LGTM - thanks! > > I'll clear now - assuming you will post the updated draft. > > Regards, > Alia > > On Thu, Mar 2, 2017 at 11:37 AM, Greg Mirsky > wrote: > >> Hi Alia, >> thank you for the proposed text. Accepted. Please see the updated text >> below. >> >> Regards, >> Greg >> >> On Thu, Mar 2, 2017 at 6:48 AM, Alia Atlas wrote: >> >>> Hi Greg, >>> >>> >>> >>> On Thu, Mar 2, 2017 at 2:01 AM, Greg Mirsky >>> wrote: >>> >>>> Hi Alia, >>>> thank you for your thorough review and the comments. Please find my >>>> responses in-line tagged GIM>>. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas wrote: >>>> >>>>> Alia Atlas has entered the following ballot position for >>>>> draft-ietf-mpls-residence-time-14: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to https://www.ietf.org/iesg/stat >>>>> ement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Thank you for a clear document. I think that this should be a >>>>> straightforward Discuss to better clarify. >>>>> >>>>> In Section 4.8.1, it says "The RTM Set sub-object contains an ordered >>>>> list, from egress node to >>>>> ingress node, of the RTM capable nodes along the LSP's path." but >>>>> the >>>>> sub-TLVs (as most clearly >>>>> indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually >>>>> meant >>>>> to be a list of interfaces. >>>>> >>>> GIM>> I think that the text, e.g. by stating "The Length is always 12" and >>>> the Figure 10 are clear that only one interface can be listed in the >>>> sub-TLV. >>>> And the same is true for other sub-TLVs. >>>> >>> >>> The draft says"Only a single RTM_SET sub-TLV with the given Value field >>> MUST be present in the RTM_SET TLV. If more than one sub-TLV is found >>> the LSP setup MUST fail" >>> >>> There is nothing there that clearly states that only one of the 3 >>> sub-TLVs should be place in the RTM_SET TLV for a particular node. There >>> is also the inaccuracy between putting in interface addresses versus the >>> claim that it contains nodes. >>> >>> For instance, text could be added/changed to indicate: >>> >>> "The RTM_SET TLV is intended to include the subset of the RRO Object >>> that represents those egress interfaces on the LSP that are RTM-capable. >>> After a node chooses an egress interface to use in the RRO sub-TLV, that >>> same egress interface, if RTM-capable, SHOULD be placed into the RTM_SET >>> TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface >>> sub-TLV. The address family chosen SHOULD match that of the RESV message >>> and that used in the RRO; the unnumbered interface sub-TLV is used when the >>> egress interface has no assigned IP address. A node MUST NOT place more >>> sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress >>> interfaces the LSP traverses that are under that node's control." >>> >>> OLD TEXT: >> >> Sub-TLVs are organized as a last-in-first-out stack. The first -out >> sub-TLV relative to the beginning of RTM_SET TLV is considered the >> top. The last-out sub-TLV is considered the bottom. When a new sub- >> TLV is added, it is always added to the top. Only a single RTM_SET >> sub-TLV with the given Value field MUST be present in the RTM_SET >> TLV. If more than one sub-TLV is found the LSP setup MUST fail with >> the generation of a PathErr message with the Error Code "Duplicate >> sub-TLV" Section 8.9 and Error Value contains 16-bit value composed >> of (Type of TLV, Type of sub-TLV). >> >> >> NEW TEXT: >> >> Sub-TLVs are organized as a last-in-first-out stack. The first-out >> sub-TLV relative to the beginning of RTM_SET TLV is considered the >> top. The last-out sub-TLV is considered the bottom. When a new sub- >> TLV is added, it is always added to the top. >> >> The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs >> that represents those egress interfaces on the LSP that are RTM- >> capable. After a node chooses an egress interface to use in the RRO >> sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed >> into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or >> Unnumbered Interface sub-TLV. The address family chosen SHOULD match >> that of the RESV message and that used in the RRO; the unnumbered >> interface sub-TLV is used when the egress interface has no assigned >> IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV >> than the number of RTM-capable egress interfaces the LSP traverses >> that are under that node's control. Only a single RTM_SET sub-TLV >> with the given Value field MUST be present in the RTM_SET TLV. If >> more than one sub-TLV is found the LSP setup MUST fail with the >> generation of a ResvErr message with the Error Code "Duplicate sub- >> TLV" Section 7.9 and Error Value contains 16-bit value composed of >> (Type of TLV, Type of sub-TLV). >> >> >> >>> It isn't clear whether these are supposed to be the egress interface, the >>>>> ingress interface, or just any >>>>> interface >>>> >>>> GIM>> In order for the process described in section 4.8 to work RTM >>>> node MUST use the same ID in RTM_SET sub-TLV as in RRO subobject. >>>> >>> >>> Right - but I don't see the draft saying that clearly. See my suggested >>> text above. >>> >>> >>>> - or why sending just a Router ID wouldn't be sufficient. >>>>> There is no indication as to whether >>>>> it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the >>>>> same >>>>> node or how to select which one >>>>> to use. >>>>> >>>> GIM>> Selection should follow election of ID for corresponding >>>> subobject in RRO. >>>> >>> >>> Agreed - see suggested text. >>> >>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA >>>>> isn't defined. While I understand that a normative reference isn't >>>>> desirable - instead of "left for future study", it would be better to >>>>> say >>>>> that the sub-TLV should use the same format as in Sec 4.3 and that the >>>>> type allocation and full details are left to a future document. This >>>>> is >>>>> exactly how gaps are created for networks running only IPv6. If >>>>> draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for >>>>> implementations >>>>> and had a clear time-frame for how and when to progress, this would >>>>> also >>>>> be a Discuss. >>>>> >>>> GIM>> I agree that your proposal narrows the gap for IPv6 extension for >>>> RTM capability advertisement. Will apply the text you've suggested in the >>>> next version. Hope OSPF WG agrees to this change. >>>> >>> >>> OLD TEXT: >> >> The capability to support RTM on a particular link (interface) can be >> advertised in OSPFv3 using LSA extensions as described in >> [I-D.ietf-ospf-ospfv3-lsa-extend ]. Exact use of OSPFv3 LSA >> extensions is for further study. >> >> NEW TEXT: >> >> The capability to support RTM on a particular link (interface) can be >> advertised in OSPFv3 using LSA extensions as described in >> [I-D.ietf-ospf-ospfv3-lsa-extend]. The sub-TLV SHOULD use the same >> format as in Section 4.3. The type allocation and full details of >> exact use of OSPFv3 LSA extensions is for further study. >> >> >> >>> Thanks. >>> >>> Regards, >>> Alia >>> >> >> > --001a113c32ea66d83f0549c220b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you!
Will work on other comments we've recei= ved and post the update then.

Regards,
G= reg


On Thu, Mar 2, 2017 at 8:40 AM, Alia Atlas <akatlas@gmail= .com> wrote:
LGTM - thanks!

I'll clear now - assuming you will= post the updated draft.

Regards,
Alia

On Thu, Mar 2, 2017 at 11:37 AM, Greg Mirs= ky <gregimirsky@gmail.com> wrote:
Hi Alia,
thank you for the proposed text= . Accepted. Please see the updated text below.

Reg= ards,
Greg

On Thu, Mar 2, 2017 a= t 6:48 AM, Alia Atlas <akatlas@gmail.com> wrote:
Hi Greg,


On Thu, Mar 2, 2017 at 2:01 AM, Greg Mirsky <gregimirsky@gmail.com<= /a>> wrote:
=
Hi Alia,
thank you for your thorough review and the co= mments. Please find my responses in-line tagged GIM>>.

=
Regards,
Greg

On Wed, Mar 1, 2017 at 3:05 PM, A= lia Atlas <akatlas@gmail.com> wrote:
Alia Atlas has entered the following ballot p= osition for
draft-ietf-mpls-residence-time-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for a clear document.=C2=A0 I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered<= br> list, from egress node to
=C2=A0 =C2=A0ingress node, of the RTM capable nodes along the LSP's pat= h." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.=C2=A0 Unnumbered Interface Sub-TLV" are ac= tually meant
to be a list of interfaces.
GIM>> I think= that the text, e.g. by stating "The Length is always 12"=C2=A0and the Figure 1= 0 are clear that only one interface can be listed in the sub-TLV.
And the same is true for other sub-TLVs.

The draft says"Only a single RTM_SE= T=C2=A0 sub-TLV with the given Value field MUST be present in the RTM_SET= =C2=A0 =C2=A0TLV.=C2=A0 If more than one sub-TLV is found the LSP setup MUS= T fail"

There is nothing there that clearly s= tates that only one of the 3 sub-TLVs should be place in the RTM_SET TLV fo= r a particular node.=C2=A0 There is also the inaccuracy between putting in = interface addresses versus the claim that it contains nodes.

=
For instance, text could be added/changed to indicate:

"The RTM_SET TLV is intended to include the subset of = the RRO Object that represents those egress interfaces on the LSP that are = RTM-capable.=C2=A0 After a node chooses an egress interface to use in the R= RO sub-TLV, that same egress interface, if RTM-capable, =C2=A0SHOULD be pla= ced into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Un= numbered Interface sub-TLV.=C2=A0 The address family chosen SHOULD match th= at of the RESV message and that used in the RRO; the unnumbered interface s= ub-TLV is used when the egress interface has no assigned IP address.=C2=A0 = A node MUST NOT place more sub-TLVs in the RTM_SET TLV than the number of R= TM-capable egress interfaces the LSP traverses that are under that node'= ;s control."

<= /div>
OLD TEXT:
   Sub-TLVs are organized as a last-in-fir=
st-out stack.  The first -out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.  Only a single RTM_SET
   sub-TLV with the given Value field MUST be present in the RTM_SET
   TLV.  If more than one sub-TLV is found the LSP setup MUST fail with
   the generation of a PathErr message with the Error Code "Duplicate
   sub-TLV" Section 8.9 and Error Val=
ue contains 16-bit value composed
   of (Type of TLV, Type of sub-TLV).

NEW TEXT:
   Sub-TLVs are organized as =
a last-in-first-out stack.  The first-out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.

   The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs
   that represents those egress interfaces on the LSP that are RTM-
   capable.  After a node chooses an egress interface to use in the RRO
   sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed
   into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or
   Unnumbered Interface sub-TLV.  The address family chosen SHOULD match
   that of the RESV message and that used in the RRO; the unnumbered
   interface sub-TLV is used when the egress interface has no assigned
   IP address.  A node MUST NOT place more sub-TLVs in the RTM_SET TLV
   than the number of RTM-capable egress interfaces the LSP traverses
   that are under that node's control.  Only a single RTM_SET sub-TLV
   with the given Value field MUST be present in the RTM_SET TLV.  If
   more than one sub-TLV is found the LSP setup MUST fail with the
   generation of a ResvErr message with the Error Code "Duplicate sub-
   TLV" Section 7.9 and Error Value contains 16-bit value composed of
   (Type of TLV, Type of sub-TLV).
=C2=A0
It isn't clear whether these are supposed to be the egress interface, t= he
ingress interface, or just any
interface
GIM>> In order for the process desc= ribed in section 4.8 to work RTM node MUST use the same ID in RTM_SET sub-T= LV as in RRO subobject.=C2=A0

=
Right - but I don't see the draft saying that clearly= .=C2=A0 See my suggested text above.
=C2=A0
- or why sending just a Router ID wouldn't be sufficie= nt.
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one
to use.
GIM>> Selection should follow ele= ction of ID for corresponding subobject in RRO.=C2=A0

Agreed - see suggested text.=C2= =A0

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.=C2=A0 While I understand that a normative reference isn&= #39;t
desirable - instead of "left for future study", it would be bette= r to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.=C2=A0 =C2= =A0This is
exactly how gaps are created for networks running only IPv6.=C2=A0 =C2=A0If=
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementati= ons
and had a clear time-frame for how and when to progress, this would also be a Discuss.
GIM>> I agree that your pro= posal narrows the gap for IPv6 extension for RTM capability advertisement. = Will apply the text you've suggested in the next version. Hope OSPF WG = agrees to this change.
OLD TEXT:
   The capabil=
ity to support RTM on a particular link (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospf=
v3-lsa-extend].  Exact use of OSPFv3 LSA
   extensions is for further study.
NEW TEXT:
   The capability to support RTM on a particular l=
ink (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend].  The sub-TLV SHOULD use the same
   format as in Section 4.3.  The type allocation and full details of
   exact use of OSPFv3 LSA extensions is for further study.
=C2=A0
= Thanks.

Regards,
Alia



--001a113c32ea66d83f0549c220b6-- From nobody Thu Mar 2 08:57:25 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99C129507; Thu, 2 Mar 2017 08:57:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148847383926.19615.2189515047034076519.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 08:57:19 -0800 Archived-At: Cc: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Alia Atlas' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:57:19 -0000 Alia Atlas has entered the following ballot position for draft-ietf-mpls-residence-time-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the planned text to update the document to address my Discuss & comment. From nobody Thu Mar 2 09:21:49 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C20129579; Thu, 2 Mar 2017 09:21:48 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ7f4lN3XN4z; Thu, 2 Mar 2017 09:21:46 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFCE1294C0; Thu, 2 Mar 2017 09:21:46 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id i1so56907256ota.3; Thu, 02 Mar 2017 09:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eoP1gQ/J086lsZEm4Ac4IHT0h8wpscNJAgkCPNcQGvo=; b=IupLC2ML/bS5TsW9Yo7ukfkW/5mYoe8mXz6G/OxLSgf4l3stOaZI89b0n1keU39NNs tAHoFKnL6EyjnHx0LaxdLeTZ7G3fE4EixWuPAqC/78VfF/RHtttCFke7KaocVXFrebPD tXskN+evyVyroIm21mK+0c/haBM6m+fdIMpouLlnx04CUF04sENnjVDBLkKaLc8ncRFr 2zX4drvCbji/2oHhodShIxXEPcQHkfg9QbjiNLIJalO5hoyHHSzZ5G1UmcfJ8jEgpRPn GQFF514vYjYGBcze+cNj4Gys7YLVk55BH41SCSVRyDy/XgApntFiWyoORC/iXjbCbl1R kYVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eoP1gQ/J086lsZEm4Ac4IHT0h8wpscNJAgkCPNcQGvo=; b=POqVR0HYhGd1e7Q6oheH22+jEkADvM2SlXzRPFAwslD+gsCaTuwsJksNQtqDFwbVjK 0yGv8SggRqBScpOtTseq12Ha+SvxWVSG3iEOVMyOpl0SB76MSOn7TB/HznXoSWsGdh8b 3w63aZm9ekoELZZQSwuqMO5ssa+9MHcKs+2rAIwPCmjHlRUi0Zxrd7zwlWKPFcJ9xBar XIWa+JclxBwKVgHbmR4TaANET40A21TAW1ao//w4DHRau0u5uUfHwD+H3WQjtCHK0OQ0 bsPL/x1m8Yi+dabliZPugPHw5VgFXa6SowYkrjHJzNjy9WnlZxoAWaIf0Gx9nZqxte8T /3Gg== X-Gm-Message-State: AMke39msTMnAANvYor20vuDNhE+LHhLKwYDlJPFPqDAw3GmEVYjnNKe7UBz5Ej2RKT/yKeyay9bzPd4qfK5Ccg== X-Received: by 10.157.1.247 with SMTP id e110mr6531898ote.40.1488475305740; Thu, 02 Mar 2017 09:21:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Thu, 2 Mar 2017 09:21:45 -0800 (PST) In-Reply-To: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> References: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 2 Mar 2017 09:21:45 -0800 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c03b82adb11be0549c2a9c7 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 17:21:48 -0000 --94eb2c03b82adb11be0549c2a9c7 Content-Type: text/plain; charset=UTF-8 Hi Ben, thank you for your thorough review and comments. Please find my answers in-line tagged GIM>>. Regards, Greg On Wed, Mar 1, 2017 at 3:16 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-mpls-residence-time-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have no objection, but do have some a few minor comments: > > Substantive: > > -2.1, 4th paragraph from end: Can you offer guidance on what might > constitute a reasonably bound wait time?\ > GIM>> Section 7.7.2 Message transmission intervals in IEEE.1588.2008 defines algorithm to calculate intervals between PTP control messages that will, in turn, define the range for "the reasonably bound time". But specification of the precise values are deferred to the appropriate PTP profiles. > > -2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of > that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same > message? > GIM>> This is in reference to the node behavior in context of the same LSP. On the given LSP the RTM-capable node MUST NOT perform in one-step and two-step mode. > > Editorial: > - Abstract: The last paragraph is a single, long sentence. Please > consider breaking it into simpler sentences. > NEW TEXT Residence time is the variable part of propagation delay of timing and synchronization messages. Knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a Precision Time Protocol event message. > - 2.1, paragraph 9: "This bit, once it is set by a two- > step mode device, MUST stay set accordingly": Can that MUST be stated > in process terms? That is, MUST NOT unset this bit..." > OLD TEXT PTP messages also include a bit that indicates whether or not a follow-up message will be coming. This bit, once it is set by a two- step mode device, MUST stay set accordingly until the original and follow-up messages are combined by an end-point (such as a Boundary Clock). NEW TEXT PTP messages also include a bit that indicates whether or not a follow-up message will be coming. This bit MAY be set by a two-step mode PTP device. The value MUST NOT be unset until the original and follow-up messages are combined by an end-point (such as a Boundary Clock). > > -2.1, paragraph 11: "Without loss of generality should note > that handling of Sync event messages..." : I don't follow the > sentence; are words missing and/or out of order? > -- "Following outlines handling of PTP Sync event message by the two-step > RTM node.": I think there's a missing "the" at the start. It's absence > completely changes the meaning of "following outlines"-- as written it > seem like the verb is "following", but I think you mean it to be > "outlines". > GIM>> Agreed, Prepend with 'The'. > -- I have trouble matching some pronouns to their antecedents in the rest > of the paragraph. > > > --94eb2c03b82adb11be0549c2a9c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,
thank you for your thorough review and comment= s. Please find my answers in-line tagged GIM>>.

<= div>Regards,
Greg

On Wed, Mar 1, 2017 at 3:16 PM, Ben Campbell <ben@nostrum.c= om> wrote:
Ben Campbell has entered the following ballot position for
draft-ietf-mpls-residence-time-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I have no objection, but do have some a few minor comments:

Substantive:

-2.1, 4th paragraph from end: Can you offer guidance on what might
constitute a reasonably bound wait time?\
GIM>> = Section 7.7.2 Message transmission intervals in IEEE.1588.2008 defines algo= rithm to calculate intervals =C2=A0between PTP control messages that will, = in turn, define the range for "the reasonably bound time". But sp= ecification of the precise values are deferred to the appropriate PTP profi= les.

-2.1, 2nd paragraph from end: "... MUST NOT do both": What's = the scope of
that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same
message?
GIM>> This is in reference to the node = behavior in context of the same LSP. On the given LSP the RTM-capable node = MUST NOT perform in one-step and two-step mode.

Editorial:
- Abstract: The last paragraph is a single, long sentence. Please
consider breaking it into simpler sentences.
NEW TEXT<= /div>
   Residence time is the variable part of propagation delay of timing
   and synchronization messages.  Knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a Precision Time
   Protocol event message.=C2=A0

- 2.1, paragraph 9: "This bit, once it is set by a two-
=C2=A0 =C2=A0step mode device, MUST stay set accordingly": Can that MU= ST be stated
in process terms? That is, <actors>=C2=A0 MUST NOT unset this bit...&= quot;
OLD TEXT
   PTP messages also include a bit that indicates whe=
ther or not a
   follow-up message will be coming.  This bit, once it is set by a two-
   step mode device, MUST stay set accordingly until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).
NEW TEXT
   PTP messages also include a bit that indicates w=
hether or not a
   follow-up message will be coming.  This bit MAY be set by a two-step
   mode PTP device.  The value MUST NOT be unset until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).
=C2=A0

-2.1, paragraph 11:=C2=A0 "Without loss of generality should note
=C2=A0 =C2=A0that handling of Sync event messages..." : I don't fo= llow the
sentence; are words missing and/or out of order?
-- "Following outlines handling of PTP Sync event message by the two-s= tep
RTM node.": I think there's a missing "the" at the start= . It's absence
completely changes the meaning of "following outlines"-- as writt= en it
seem like the verb is "following", but I think you mean it to be<= br> "outlines".
GIM>> Agreed, Prepend with= 'The'.=C2=A0
, The IESG Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:47:21 -0000 --001a11407b327530de0549ca90e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, thank your for the review and the comments, most helpful. Please find my answers in-line tagged GIM>>. Regards, Greg On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-mpls-residence-time-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > High level comment: > Maybe extend the security section a bit and describe what can happen in > the worse case if the value has been modified to a too high or too low > value; and maybe even given some guidance on performing additional checks > to figure out if a given value is reasonable for a given path or not. > > Questions: > - Can you explain why PTPType, Port ID, and Sequence ID are needed in the > PTP Sub-TLV format if those values are already in the PTP packet itself > that follows? > GIM>> We propose to copy these values as they uniquely identify PTP control message as these are required for two-step mode and suggesting inspection of the PTP payload would cause layer violation. - Why is it necessary to define PTP sub-TLV (and have a registry for one > value only)? Are you expecting to see more values here? What would those > values be? > GIM>> We may have another protocols or applications to use RTM and these the most likely will have their specific set of parameters to uniquely identify control session for two-step mode. One obvious case would be NTP when on-path support is defined. But since we don't know which parameters will uniquely identify cotrol session we don't request code point allocation. > - Similar to Spencer's question: Why don't you also define a Sub-TLV > format for NTP? > GIM>>Hope that above answer addresses this question. > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > values > defined as follows: > * 0b001..." > Maybe I don't understand what a bit-map field is here but these are > more then 3 bits...? > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal format of notation. > - also sec 4.3.: "Value contains variable number of bit-map fields so > that overall > number of bits in the fields equals Length * 8." > However there is no field 'Value' in the figure... GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to add Value tag on the field immediately following RTM field. > Also the following > explanation about future bit-maps is really confusing to me; why don't > you just say that the rest as indicated by the length field must be > padded with zeros...? > - Should section 4.8 maybe be a subsection of 4.7? This part confused me > a bit because the example seems to be generic but the rest is RSVP-TE > specific, right? Maybe move the example as a separate section before or > after the whole section 4...? > > Nits: > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > network > - There are (still) some not spelled out abbreviations (LDP, PW); GIM>> Since both are used only once - expanded > in turn > others are extended twice (e.g. PTP)... > GIM>> Cleaned. > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > indicate it as optional in the figure: Sub-TLV (optional) > GIM>> Agree --001a11407b327530de0549ca90e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,
thank your for the review and the comments, = most helpful.
Please find my answers in-line tagged GIM>>.<= /div>

Regards,
Greg

On Wed, Mar 1, 2017 at 8:48 AM, Mirja = K=C3=BChlewind <ietf@kuehlewind.net> wrote:
Mirja K=C3=BChlewind has entered the following ballot p= osition for
draft-ietf-mpls-residence-time-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

High level comment:
Maybe extend the security section a bit and describe what can happen in
the worse case if the value has been modified to a too high or too low
value; and maybe even given some guidance on performing additional checks to figure out if a given value is reasonable for a given path or not.

Questions:
- Can you explain why PTPType, Port ID, and Sequence ID are needed in the PTP Sub-TLV format if those values are already in the PTP packet itself
that follows?
GIM>> We propose to copy these val= ues as they uniquely identify PTP control message as these are required for= two-step mode and suggesting inspection of the PTP payload would cause lay= er violation.

- Why is it necessary to define PTP sub-TLV (and have a registry for one value only)? Are you expecting to see more values here? What would those values be?
GIM>> We may have another protocols o= r applications to use RTM and these the most likely will have their specifi= c set of parameters to uniquely identify control session for two-step mode.= One obvious case would be NTP when on-path support is defined. But since w= e don't know which parameters will uniquely identify cotrol session we = don't request code point allocation.
- sec 4.3: "RTM (capability) - is a three-bit long bit-map field with<= br> values
=C2=A0 =C2=A0 =C2=A0 defined as follows:
=C2=A0 =C2=A0 =C2=A0 *=C2=A0 0b001..."
=C2=A0 Maybe I don't understand what a bit-map field is here but these = are
more then 3 bits...?
GIM>> '0b' identifi= es binary format as '0x' identifies hexadecimal format of notation.= =C2=A0
- also sec 4.3.: "Value contains variable number of bit-map fields so<= br> that overall
=C2=A0 =C2=A0 =C2=A0 number of bits in the fields equals Length * 8."<= br> =C2=A0 However there is no field 'Value' in the figure...
GIM>> Thank you for pointing. I'll update Figure 4 and F= igure 5 to add Value tag on the field immediately following RTM field.=C2= =A0
Also the following
explanation about future bit-maps is really confusing to me; why don't<= br> you just say that the rest as indicated by the length field must be
padded with zeros...?
- Should section 4.8 maybe be a subsection of 4.7? This part confused me a bit because the example seems to be generic but the rest is RSVP-TE
specific, right? Maybe move the example as a separate section before or
after the whole section 4...?

Nits:
- Maybe change to title to: Residence Time Measurement (RTM) in MPLS
network
- There are (still) some not spelled out abbreviations (LDP, PW);
GIM>> Since both are used only once - expanded=C2=A0
in turn
others are extended twice (e.g. PTP)...
GIM>> = =C2=A0Cleaned.
- In figure 1, I would rename 'Value' to 'Sub-TLV' and mayb= e also
indicate it as optional in the figure: Sub-TLV (optional)
<= div>GIM>> Agree=C2=A0

--001a11407b327530de0549ca90e6-- From nobody Thu Mar 2 20:12:11 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EFA1296DC for ; Thu, 2 Mar 2017 20:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.in Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX8q2BQXZKTe for ; Thu, 2 Mar 2017 20:12:04 -0800 (PST) Received: from nm40-vm8.bullet.mail.ne1.yahoo.com (nm40-vm8.bullet.mail.ne1.yahoo.com [98.138.229.184]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA011296DF for ; Thu, 2 Mar 2017 20:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.in; s=s2048; t=1488514323; bh=jC8uR9gPOz5/jGjThQ4qMR6YwG4q9XsL4TgTXbah+Tk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=bDLqUVE79bFuz4oClOt/ctJ/9imYI/eLx0qanqMnEeH4aW7438tqQ1D95g1IYsHwos+v4iS0NGdmMBf/U+Xy3WAt9tqnmknm8UwfW1/WgRNbAE1u9eAGziNr1ULjaLnGBFjy5XnndZo4fkTSg2w1ZR3t1lgJ5ZdeFVZwbEW066xoK+R+tY0qcMeH9IF98FRF5GP5dR7hqoErnlBf5ohXQBgLtVtPyA1rJZ0sJfBrG+m9taEI5ogqNjoTTFvJpccKu8w1uy5iWSGDSQSZGhar72YLv+pylfao8tisH1jSQDBvkCt+6bYvDU6j588NMGWefcstoItNK8eFrwTOOilfbA== Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 04:12:03 -0000 Received: from [98.138.100.111] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 04:09:08 -0000 Received: from [106.10.166.119] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 04:09:08 -0000 Received: from [106.10.151.15] by tm8.bullet.mail.sg3.yahoo.com with NNFMP; 03 Mar 2017 04:09:08 -0000 Received: from [127.0.0.1] by omp1020.mail.sg3.yahoo.com with NNFMP; 03 Mar 2017 04:09:08 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 256249.99440.bm@omp1020.mail.sg3.yahoo.com X-YMail-OSG: rohad8MVM1kPE6Vj_rAqd0GaP9O4iVn4D5O28DchQ2Vfel8TB0Svz_XA3NPevmw rm7Dyxk4VdqI7Eu5BSrVf4lvBWVT69z_S99fWqADIZIVklwybb6YIvoIwRKvOJdoXWnbxERKTCZg 9XyFtGVnlzz3WgLnm53drdLerbShZ40CJPOCw4o34hpJW2QglUxL.tQqdWrqKw4K18kPqXLjmtMb keMKOlLQodS3qh7O1GHO_9qJt8NQkL_ptd9xOb7VWUtnKh2nejgJgvPlSMh8uw0dbaKc3LaAkOP9 T4TQb_zeUs.T80grHAfHssdzG_4dSTxdv92o9DjIHVTOBZPhVcZ1TwIUDHTxsc_ie1kl6rymaNKf iSseC_.pF2WyVdlaazfQxm7CEFdpnLZJ2YdenlVGE3V2fSZQqZM1ROx_ikV5BAsFbZFi2v0u.59q tnbgLOfQLWhgCVr2q61Q4AC0RZdjYPiL2gjL9WCdrnOnRIF5d.uf7KhUGAV2mAbX7J3zM30Fe1L1 Ef.LXrZaLzjWlyyK7l6WlMT2B8ZgwkWT_oaqVEFcyUUTev1uw0T8.BleeYVIuJsMNuRaCeFFKEr3 r3Gr0MM1UvYeGhsCbJQ-- Received: from jws600008.mail.sg3.yahoo.com by sendmailws101b.mail.sg3.yahoo.com; Fri, 03 Mar 2017 04:09:07 +0000; 1488514147.889 Date: Fri, 3 Mar 2017 04:09:07 +0000 (UTC) From: Naveen T To: "adrian@olddog.co.uk" , 'Fatai Zhang' , "ccamp@ietf.org" , 'Mpls' Message-ID: <540463309.1044103.1488514147727@mail.yahoo.com> In-Reply-To: <067501d28dc1$25600520$70200f60$@olddog.co.uk> References: <1379399279.2996090.1487771407858.ref@mail.yahoo.com> <1379399279.2996090.1487771407858@mail.yahoo.com> <067501d28dc1$25600520$70200f60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1044102_893054666.1488514147721" Archived-At: Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBbQ0NBTVBdIFF1ZXN0aW9uIHJlZ2FyZGluZyBS?= =?utf-8?q?FC_7260?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Naveen T List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 04:12:06 -0000 ------=_Part_1044102_893054666.1488514147721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Adrian and Fatai.From what you say, it looks like I need to have an = implementation for=C2=A0RFC 6373before I go onto signal the OAM entities fo= r MPLS-TP paths.=C2=A0Thanks and Regards,Naveen T =20 On Thursday, 23 February 2017 4:10 PM, Adrian Farrel wrote: =20 #yiv2575976584 #yiv2575976584 -- _filtered #yiv2575976584 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv2575976584 {font-famil= y:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv2575976584 {font-fami= ly:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv2575976584 {font-fam= ily:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv2575976584 {font-= family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv2575976584 {pan= ose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv2575976584 {panose-1:2 11 6 0 7 2= 5 8 2 4;} _filtered #yiv2575976584 {panose-1:2 11 6 0 7 2 5 8 2 4;}#yiv257= 5976584 #yiv2575976584 p.yiv2575976584MsoNormal, #yiv2575976584 li.yiv25759= 76584MsoNormal, #yiv2575976584 div.yiv2575976584MsoNormal {margin:0cm;margi= n-bottom:.0001pt;font-size:12.0pt;font-family:SimSun;}#yiv2575976584 a:link= , #yiv2575976584 span.yiv2575976584MsoHyperlink {color:blue;text-decoration= :underline;}#yiv2575976584 a:visited, #yiv2575976584 span.yiv2575976584MsoH= yperlinkFollowed {color:purple;text-decoration:underline;}#yiv2575976584 sp= an.yiv2575976584EmailStyle17 {color:#1F497D;}#yiv2575976584 span.yiv2575976= 584EmailStyle18 {color:#1F497D;}#yiv2575976584 span.yiv2575976584SpellE {}#= yiv2575976584 .yiv2575976584MsoChpDefault {font-size:10.0pt;} _filtered #yi= v2575976584 {margin:72.0pt 90.0pt 72.0pt 90.0pt;}#yiv2575976584 div.yiv2575= 976584WordSection1 {}#yiv2575976584 _filtered #yiv2575976584 {} _filtered #= yiv2575976584 {} _filtered #yiv2575976584 {} _filtered #yiv2575976584 {} _f= iltered #yiv2575976584 {} _filtered #yiv2575976584 {} _filtered #yiv2575976= 584 {} _filtered #yiv2575976584 {} _filtered #yiv2575976584 {} _filtered #y= iv2575976584 {}#yiv2575976584 ol {margin-bottom:0cm;}#yiv2575976584 ul {mar= gin-bottom:0cm;}#yiv2575976584 Fatai is right, I think. =C2=A0If you want t= o operate "static" MPLS LSPs without using a control plane, then it would (= IMO) be peculiar to suddenly want to use a control plane to configure and m= anage OAM on that LSP. =C2=A0Why would you not use the same static provisio= ning tools? =C2=A0Of course, there is also RFC 7212 available to you. =C2= =A0Adrian =C2=A0 =C2=A0From: mpls [mailto:mpls-bounces@ietf.org] On Behalf = Of Fatai Zhang Sent: 23 February 2017 03:30 To: Naveen T; ccamp@ietf.org; Mpls Subject: [mpls] =E7=AD=94=E5=A4=8D: [CCAMP] Question regarding RFC 7260 =C2= =A0Hi Naveen, =C2=A0Per RFC 7487, =C2=A0I think there should be GMPLS contr= ol plane for OAM configuration purpose. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Thanks =C2=A0Fatai =C2=A0=E5=8F=91=E4=BB=B6=E4=BA=BA: CCAMP [mailto:ccamp-b= ounces@ietf.org] =E4=BB=A3=E8=A1=A8 Naveen T =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B42=E6=9C=8822=E6=97=A5 21= :50 =E6=94=B6=E4=BB=B6=E4=BA=BA: ccamp@ietf.org; Mpls =E4=B8=BB=E9=A2=98: [CCAMP] Question regarding RFC 7260 =C2=A0Dear Authors,= et al., =C2=A0RFC 7260=C2=A0describes the procedures for OAM configuration= and control via RSVP-TE.=C2=A0RFC 7467=C2=A0further extends this to provid= e procedures to configure pro-active OAMs like BFD, FMS etc.=C2=A0 =C2=A0I = have a query regarding the usage of RSVP-TE to carry the OAM configurations= from the MPLS-TP tunnel ingress to the tunnel egress.Considering that the = MPLS-TP bi-directional LSP has been established statically and the requirem= ent is to only signal the OAM entities, I have the following assumptions:1.= =C2=A0 An IGP path must be established between the MPLS-TP tunnel's ingress= and egress LERs.2.=C2=A0 The MPLS-TP node_id of and LER/LSR, defined=C2=A0= here, will also be configured as that LER's/LSR's loopback interface's addr= ess.3.=C2=A0 The IGP will ensure that each LER/LSR learns about all the LSR= s/LERs along the MPLS-TP transport path.4.=C2=A0 RSVP-TE will use this IGP = path to send/receive the PATH/RESV messages. =C2=A0Are these assumptions co= rrect?Or, should there be a GMPLS control-plane adjacency between LERs/LSRs= along the MPLS-TP path with the TE links on these nodes acting as the MPLS= -TP NNI interfaces? =C2=A0Thanks and Regards,Naveen T =C2=A0 =C2=A0 =C2=A0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------=_Part_1044102_893054666.1488514147721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Adrian and Fatai.=
<= span id=3D"yui_3_16_0_ym19_1_1488514039820_3003">From what you say, it look= s like I need to have an implementation for RFC 6373
before I go onto signal the OAM entiti= es for MPLS-TP paths.
 
Thanks and Regards,
Naveen T



On Thursday, 23 February 2017 4:1= 0 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Fatai is = right, I think.
 
If you want to operate "static" M= PLS LSPs without using a control plane, then it would (IMO) be peculiar to = suddenly want to use a control plane to configure and manage OAM on that LS= P.
 
Why would you not use the same static provisio= ning tools?
 
Of course, there is also RFC 7212 a= vailable to you.
 
Adrian
 
 
From: mpls [mailto:mpls-bounces@i= etf.org] On Behalf Of Fatai Zhang
Sent: 23 = February 2017 03:30
To: Naveen T; ccamp@ietf.org; = Mpls
Subject: [mpls] =E7=AD=94=E5=A4=8D: [CCAMP] Question regarding RFC 7260
 
Hi Naveen,
 
Per RFC 7487,  = I think there should be GMPLS control plane for OAM configuration purpose. =
 
 
 
 
 
Thanks
 
Fatai
=  
<= div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm;">
=E5=8F=91=E4=BB=B6=E4=BA=BA: CCAMP [mailto:ccamp-bounces@ietf.org] <= span lang=3D"ZH-CN" style=3D"font-size:10.0pt;">=E4=BB=A3=E8=A1=A8 <= /b>Naveen T
=E5=8F=91=E9= =80=81=E6=97=B6=E9=97=B4: 2= 017=E5=B9=B4= 2=E6=9C=8822=E6=97=A5 21:= 50
=E6=94=B6=E4=BB=B6=E4=BA=BA: ccamp@ietf.org; Mpls
=E4=B8=BB=E9=A2=98: [CCAMP] Question regarding RFC 7260
 
Dear Authors,= et al.,
 
<= /div>
RFC 7260 = describes the procedures for OAM configuration and control via RSVP-TE.&nbs= p;RFC 7467 further extends this to provide procedures to con= figure pro-active OAMs like BFD, FMS etc. 
 
= I have a query regarding the usage of RSVP-TE to carry the OAM configuratio= ns from the MPLS-TP tunnel ingress to the tunnel egress.
=
Considering that the MPLS-TP bi-directional LS= P has been established statically and the requirement is to only signal the= OAM entities, I have the following assumptions:
1.  An IGP path must be established between the MPLS-TP = tunnel's ingress and egress LERs.
2.  The MPLS-TP node_id of and LER/LSR, defined here= , will also be configured as that LER's/LSR's loopback interface's address.=
3.  The IGP will ensure that each L= ER/LSR learns about all the LSRs/LERs along the MPLS-TP transport path.
4.  RSVP-TE will use this IGP path to s= end/receive the PATH/RESV messages.
=  
Are these assumptions = correct?
Or, should there be a= GMPLS control-plane adjacency between LERs/LSRs along the MPLS-TP path wit= h the TE links on these nodes acting as the MPLS-TP NNI interfaces?<= /div>
<= div class=3D"yiv2575976584MsoNormal" style=3D"background:white;">  
Thanks and Regards,
Naveen T
&= nbsp;
&nb= sp;
 
=

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


------=_Part_1044102_893054666.1488514147721-- From nobody Thu Mar 2 21:39:44 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7CD12947C for ; Thu, 2 Mar 2017 21:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.in Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kha7ZDCwifyR for ; Thu, 2 Mar 2017 21:39:42 -0800 (PST) Received: from nm39-vm6.bullet.mail.ne1.yahoo.com (nm39-vm6.bullet.mail.ne1.yahoo.com [98.138.229.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AEF12944F for ; Thu, 2 Mar 2017 21:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.in; s=s2048; t=1488519581; bh=MNi3Lcn9j/9lJKeGXLWQ7jh0AT71PypbaaGgjjGmdws=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=oLxa1UT24TPm8ZbNLoXij0g9idiGjb8293Zs/zBWxOljO1XSmuYq+3noQsEPzOz4BZeeOi2FCnFFJESrwhst9DkwOzWmSH6REyU8L00ouvepv5gRxF+3cI64qHyn1u4iO6AsPQrr0NNIKD6NRNM9xhU2OLFfwZNg5Uo9U/HG8mnOiheDq3OQaZb7uUfdU2UER6GyArAZo4HhBXbapHMSikLw0pF1tpi3WFLieniP7WMKUnVtEwFadh4XQ9QzLs2m5bIQcSCBqU/I8m8Vfwkz3wSpngb8Zylux9pCKqr3HKlmviT9/8GwXImJdigtp79MyE54TWqZqX4FGfnOikosAg== Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 05:39:41 -0000 Received: from [98.138.101.131] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 05:36:52 -0000 Received: from [106.10.166.119] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 05:34:52 -0000 Received: from [106.10.151.253] by tm8.bullet.mail.sg3.yahoo.com with NNFMP; 03 Mar 2017 05:34:51 -0000 Received: from [127.0.0.1] by omp1002.mail.sg3.yahoo.com with NNFMP; 03 Mar 2017 05:34:51 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 849147.91265.bm@omp1002.mail.sg3.yahoo.com X-YMail-OSG: 6G77Re0VM1nzLfamlCIEQemC0XTMIeZOUqE.JmO0x6gPMF93.KipCcPy2v7BPUf nmYKYcT.DX_GpM.NQTC7TAFgt3kqKmVSdf9xY2rSgOYRJRNvC24yAZybydPD.4lUntYvIGIZhXEQ TTCg99mdNhDvvIqEK0kJCljNl4a4mKuYNqcCqs.QSUq4WiIZknaXYoe2PG2wGuENuaCp.fMwz8yP vMBZ01xs4Pe.UOm5pctVobsMeDaEC1TgmUGHJKe6B3t.0.6jwpKZQOUDlff0359MONz36xXMKYo8 736he7CkslwPHOqrN5QMfHnqYa1cyHE_SE1vUNiPLs4eaMA6f6JTUFv_PxRjOFkPOJybYsgZ4whT 3lmHPxjZjZ8vvhsoac4gycXsWeVIk460Gn9Zy.ujWrENwf_yPOnftnOFVyRFFb1VBXbTebTF5ePW Rq51WMCAHeHkTd2OmDNAItWHFyd1HsBDQHpO4EGSw8cjkgPECuBAQZTjMksqBRxjdR_XPx1ESw_2 bjwFoPxkKb6sAgg5jx6zqVX_LdjJ0ymEJBT7vHeGpOuLcB4CRWYcxTiJmTlRG4FW34tvtkXsW9B8 UsTR0dAunc1nkQBX8VDw- Received: from jws600024.mail.sg3.yahoo.com by sendmailws106.mail.sg3.yahoo.com; Fri, 03 Mar 2017 05:34:51 +0000; 1488519291.495 Date: Fri, 3 Mar 2017 05:34:51 +0000 (UTC) From: Naveen T To: "ccamp@ietf.org" , Mpls Message-ID: <1693389752.245372.1488519291327@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_245371_2064541237.1488519291326" References: <1693389752.245372.1488519291327.ref@mail.yahoo.com> Archived-At: Subject: [mpls] Questions regarding RFC-6373 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Naveen T List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 05:39:44 -0000 ------=_Part_245371_2064541237.1488519291326 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Authors, et al., The=C2=A0RFC 6737=C2=A0defines a control plane framework for MPLS-TP networ= ks and suggests the usage ofGMPLS to signal the MPLS-TP transport path. Further to this, we found an expired draft,=C2=A0https://tools.ietf.org/id/= draft-chen-ccamp-mpls-tp-oio-00.txt, that talksabout carrying the MPLS-TP i= ndentifiers in the RSVP-TE path message.However, since this draft has expir= ed, is there any other way to transport the MPLS-TP identifiers during the = pathestablishment?=C2=A0Thanks and Regards,Naveen T ------=_Part_245371_2064541237.1488519291326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div id=3D"yiv2219492964">
Dear Authors, et a= l.,

=
The RFC 6737 defines a c= ontrol plane framework for MPLS-TP networks and suggests the usage of
=
GMPLS to sign= al the MPLS-TP transport path.
Further to this, we found an expired= draft, https://tools.ietf.org/id/draft-chen-ccamp-mpl= s-tp-oio-00.txt, that talks
about carrying the MPLS-TP indentifiers= in the RSVP-TE path message.
However, since this draft has expired, is= there any other way to transport the MPLS-TP identifiers during the path
establishment?
 
Thanks and Regards,
Naveen T

------=_Part_245371_2064541237.1488519291326-- From nobody Fri Mar 3 01:46:14 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4191297CA for ; Fri, 3 Mar 2017 01:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lra6urMzKdMF for ; Fri, 3 Mar 2017 01:46:10 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719A01293F4 for ; Fri, 3 Mar 2017 01:46:10 -0800 (PST) Received: (qmail 16048 invoked from network); 3 Mar 2017 10:46:08 +0100 Received: from pd9e11f3d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.61) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Mar 2017 10:46:07 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 3 Mar 2017 10:46:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> To: Greg Mirsky X-Mailer: Apple Mail (2.3259) Archived-At: Cc: The IESG , draft-ietf-mpls-residence-time@ietf.org, mpls-chairs@ietf.org, "mpls@ietf.org" Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:46:12 -0000 Hi Greg, see inline. Mirja > Am 03.03.2017 um 03:47 schrieb Greg Mirsky : >=20 > Hi Mirja, > thank your for the review and the comments, most helpful. > Please find my answers in-line tagged GIM>>. >=20 > Regards, > Greg >=20 > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-mpls-residence-time-14: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > High level comment: > Maybe extend the security section a bit and describe what can happen = in > the worse case if the value has been modified to a too high or too low > value; and maybe even given some guidance on performing additional = checks > to figure out if a given value is reasonable for a given path or not. >=20 > Questions: > - Can you explain why PTPType, Port ID, and Sequence ID are needed in = the > PTP Sub-TLV format if those values are already in the PTP packet = itself > that follows? > GIM>> We propose to copy these values as they uniquely identify PTP = control message as these are required for two-step mode and suggesting = inspection of the PTP payload would cause layer violation. I see. Maybe add a sentence that these field are use to identify the = packet. However, when you copy them, you also have to inspect the = payload and that=E2=80=99s the same layer violation. Also not sure if = duplicating information in the packet is the best approach. Why don=E2=80=99= t use just add an own identifier to the packet instead? >=20 > - Why is it necessary to define PTP sub-TLV (and have a registry for = one > value only)? Are you expecting to see more values here? What would = those > values be? > GIM>> We may have another protocols or applications to use RTM and = these the most likely will have their specific set of parameters to = uniquely identify control session for two-step mode. One obvious case = would be NTP when on-path support is defined. But since we don't know = which parameters will uniquely identify cotrol session we don't request = code point allocation. My understanding was that a new protocol would be a different RTM TLV in = the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t = understand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and = registry in sec 7.3. > - Similar to Spencer's question: Why don't you also define a Sub-TLV > format for NTP? > GIM>>Hope that above answer addresses this question. Actually not really. Why don=E2=80=99t you know which parameters to use? > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > values > defined as follows: > * 0b001..." > Maybe I don't understand what a bit-map field is here but these are > more then 3 bits...? > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal = format of notation.=20 Ah sorry, fully overview that. > - also sec 4.3.: "Value contains variable number of bit-map fields so > that overall > number of bits in the fields equals Length * 8." > However there is no field 'Value' in the figure... > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to add = Value tag on the field immediately following RTM field.=20 There are more questions here: > Also the following > explanation about future bit-maps is really confusing to me; why don't > you just say that the rest as indicated by the length field must be > padded with zeros...? > - Should section 4.8 maybe be a subsection of 4.7? This part confused = me > a bit because the example seems to be generic but the rest is RSVP-TE > specific, right? Maybe move the example as a separate section before = or > after the whole section 4...? >=20 > Nits: > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > network > - There are (still) some not spelled out abbreviations (LDP, PW); > GIM>> Since both are used only once - expanded=20 > in turn > others are extended twice (e.g. PTP)... > GIM>> Cleaned. > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > indicate it as optional in the figure: Sub-TLV (optional) > GIM>> Agree=20 >=20 From nobody Fri Mar 3 11:10:22 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E98129997; Fri, 3 Mar 2017 11:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTJiLrIGDmD7; Fri, 3 Mar 2017 11:10:14 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B5D1295C0; Fri, 3 Mar 2017 11:10:14 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id 62so60620327oih.2; Fri, 03 Mar 2017 11:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IcUFdnRDZuVcqp9xGJEagNPWgCF8IF1TiQPAOL5ovy0=; b=BFLzbvssJGjXD4WTt7pfSLyeTz1awol+BF0+KjUdpzTsk4H3mqHzM3QKaaPGjfoUfy T49CLK62aHMFZvi9C3+GpgXh/lEXMjNG9E6Fny6zRhe8nz0z+tKRTX/NLiVlXYiSDvMm /vLx17bBoKpXffRLjAqhIX0WlZ6KZzi2J8CAJCf+VsANdXu7PkuyJvO8BVYLVXBUNDOs Kaz9nAteDvUWgytfQ/qgibHMo6a/k0PXlsF/PObwLWNRYz0wxNDyJA/ogyDy2gHQhrz+ L1l9ih9h9I0OqGgfhsPK8bu/tIHDmjayFh5CepG7ZHBZWXzAXHEQRW0lTxoM+ZgU+XJc YSFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IcUFdnRDZuVcqp9xGJEagNPWgCF8IF1TiQPAOL5ovy0=; b=djbekaNxtUDEldxSHNZvP7dklEIk22NP1r6X00UEMLxOCAIiox2x/kPabdbbN1eSsT cZdPknm0GQxvUlwyQEext6MCzc663VOpt7uLHDfJdeeAgHx41p+uxcpNExA5OrpgqitI 9V5uuD6pKkMGX7LGSpaTFsEkkNUWn2pemd6y35Ajb9JW8YM25+BHIfPQ/TJTCcSwEhyd 9OxytqYwtODoecVxnl7A4DxIqyq5dlXY5g7xgsdJ9Z97xTLufp3oDkuLo5duPO4kTnSC JLgQxKYxpeFVFz2tEPFnDlx/uelM+YCFCS1EeENeAQFjvTljvZuwcfj//spZE7ceyteT taRg== X-Gm-Message-State: AMke39mu/7XulreCDARq5GsR5YLFeKGFjrtSAkT36lmLD6igTclWjX6+JFjRmEVTHlsXItCz6rEFs7X/ywX30g== X-Received: by 10.202.239.2 with SMTP id n2mr2386898oih.157.1488568213432; Fri, 03 Mar 2017 11:10:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Fri, 3 Mar 2017 11:10:13 -0800 (PST) In-Reply-To: References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 3 Mar 2017 11:10:13 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=94eb2c0931da95efa10549d84b37 Archived-At: Cc: The IESG , draft-ietf-mpls-residence-time@ietf.org, mpls-chairs@ietf.org, "mpls@ietf.org" Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:10:16 -0000 --94eb2c0931da95efa10549d84b37 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, thank you for your comments and very helpful discussion. My notes in-lined and now tagged with GIM2>> Regards, Greg On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) wrote: > Hi Greg, > > see inline. > > Mirja > > > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky : > > > > Hi Mirja, > > thank your for the review and the comments, most helpful. > > Please find my answers in-line tagged GIM>>. > > > > Regards, > > Greg > > > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind > wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > > draft-ietf-mpls-residence-time-14: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > High level comment: > > Maybe extend the security section a bit and describe what can happen in > > the worse case if the value has been modified to a too high or too low > > value; and maybe even given some guidance on performing additional chec= ks > > to figure out if a given value is reasonable for a given path or not. > > > > Questions: > > - Can you explain why PTPType, Port ID, and Sequence ID are needed in t= he > > PTP Sub-TLV format if those values are already in the PTP packet itself > > that follows? > > GIM>> We propose to copy these values as they uniquely identify PTP > control message as these are required for two-step mode and suggesting > inspection of the PTP payload would cause layer violation. > > I see. Maybe add a sentence that these field are use to identify the > packet. However, when you copy them, you also have to inspect the payload > and that=E2=80=99s the same layer violation. Also not sure if duplicating > information in the packet is the best approach. Why don=E2=80=99t use jus= t add an > own identifier to the packet instead? > GIM2>> Will the following, when added at the very end of Section 3.1, work: Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP control packet encapsulated in RTM message and are used in two-step RTM mode Section 2.1.1. GIM2>> The RTM message created by egress or the first on the LSP two-step RTM node. Thus other RTM nodes don't need to look into PTP control message but use the PTP sub-TLV. Creating new identifier is certainly an alternative but I believe that will require more state coordination between LERs on the same RTM LSP. Re-using existing characteristic information, in my view, is simpler solution. > > > > > - Why is it necessary to define PTP sub-TLV (and have a registry for on= e > > value only)? Are you expecting to see more values here? What would thos= e > > values be? > > GIM>> We may have another protocols or applications to use RTM and thes= e > the most likely will have their specific set of parameters to uniquely > identify control session for two-step mode. One obvious case would be NTP > when on-path support is defined. But since we don't know which parameters > will uniquely identify cotrol session we don't request code point > allocation. > > My understanding was that a new protocol would be a different RTM TLV in > the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t underst= and why your PTP > sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec 7.3. > GIM2>> RTM TLV differentiates between different encapsulation types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this as a problem? > > > - Similar to Spencer's question: Why don't you also define a Sub-TLV > > format for NTP? > > GIM>>Hope that above answer addresses this question. > > Actually not really. Why don=E2=80=99t you know which parameters to use? > > > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > > values > > defined as follows: > > * 0b001..." > > Maybe I don't understand what a bit-map field is here but these are > > more then 3 bits...? > > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal > format of notation. > Ah sorry, fully overview that. > > > - also sec 4.3.: "Value contains variable number of bit-map fields so > > that overall > > number of bits in the fields equals Length * 8." > > However there is no field 'Value' in the figure... > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to add > Value tag on the field immediately following RTM field. > > There are more questions here: > > > Also the following > > explanation about future bit-maps is really confusing to me; why don't > > you just say that the rest as indicated by the length field must be > > padded with zeros...? > GIM2>> The description follows RFC 7794 Section 2.1 > > - Should section 4.8 maybe be a subsection of 4.7? This part confused m= e > > a bit because the example seems to be generic but the rest is RSVP-TE > > specific, right? Maybe move the example as a separate section before or > > after the whole section 4...? > GIM2>> Thank you, I agree it is more logical flow. With the change suggested by Ben it will look like this: 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 10 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 4.3. RTM Capability Advertisement in Routing Protocols . . . . 11 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 11 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 13 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 13 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 13 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . 14 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 15 > > > Nits: > > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > > network > > - There are (still) some not spelled out abbreviations (LDP, PW); > > GIM>> Since both are used only once - expanded > > in turn > > others are extended twice (e.g. PTP)... > > GIM>> Cleaned. > > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > > indicate it as optional in the figure: Sub-TLV (optional) > > GIM>> Agree > > > > --94eb2c0931da95efa10549d84b37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,
thank you for your comments and very helpful= discussion. My notes in-lined and now tagged with GIM2>>
<= br>
Regards,
Greg

<= div class=3D"gmail_quote">On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind = (IETF) <ietf@kuehlewind.net> wrote:
Hi Greg,

see inline.

Mirja


> Am 03.03.2017 um 03:47 schrieb Greg Mirsky <gregimirsky@gmail.com>:
>
> Hi Mirja,
> thank your for the review and the comments, most helpful.
> Please find my answers in-line tagged GIM>>.
>
> Regards,
> Greg
>
> On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
> Mirja K=C3=BChlewind has entered the following ballot position for
> draft-ietf-mpls-residence-time-14: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> High level comment:
> Maybe extend the security section a bit and describe what can happen i= n
> the worse case if the value has been modified to a too high or too low=
> value; and maybe even given some guidance on performing additional che= cks
> to figure out if a given value is reasonable for a given path or not.<= br> >
> Questions:
> - Can you explain why PTPType, Port ID, and Sequence ID are needed in = the
> PTP Sub-TLV format if those values are already in the PTP packet itsel= f
> that follows?
> GIM>> We propose to copy these values as they uniquely identify = PTP control message as these are required for two-step mode and suggesting = inspection of the PTP payload would cause layer violation.

I see. Maybe add a sentence that these field are use to identif= y the packet. However, when you copy them, you also have to inspect the pay= load and that=E2=80=99s the same layer violation. Also not sure if duplicat= ing information in the packet is the best approach. Why don=E2=80=99t use j= ust add an own identifier to the packet instead?
GIM2&= gt;> Will the following, when added at the very end of Section 3.1, work= :
   Tuple of PTPType, Port ID, and Sequence ID uniquely identifie=
s PTP
   control packet encapsulated in RTM message and are used in two-step
   RTM mode Section 2.1.1.
GIM2>> The RTM message created by egress or the firs= t on the LSP two-step RTM node. Thus other RTM nodes don't need to look= into PTP control message but use the PTP sub-TLV. Creating new identifier = is certainly an alternative but I believe that will require more state coor= dination between LERs on the same RTM LSP. Re-using existing characteristic= information, in my view, is simpler solution.

>
> - Why is it necessary to define PTP sub-TLV (and have a registry for o= ne
> value only)? Are you expecting to see more values here? What would tho= se
> values be?
> GIM>> We may have another protocols or applications to use RTM a= nd these the most likely will have their specific set of parameters to uniq= uely identify control session for two-step mode. One obvious case would be = NTP when on-path support is defined. But since we don't know which para= meters will uniquely identify cotrol session we don't request code poin= t allocation.

My understanding was that a new protocol would be a different RTM TL= V in the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t unde= rstand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and registry= in sec 7.3.
GIM2>> RTM TLV differentiates =C2= =A0between different encapsulation types, e.g. Ethernet, IPv4 or IPv6 but s= ub-TLV doesn't have to. Do you see this as a problem?

> - Similar to Spencer's question: Why don't you also define a S= ub-TLV
> format for NTP?
> GIM>>Hope that above answer addresses this question.

Actually not really. Why don=E2=80=99t you know which parameters to = use?

> - sec 4.3: "RTM (capability) - is a three-bit long bit-map field = with
> values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0defined as follows:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 0b001..."
>=C2=A0 =C2=A0Maybe I don't understand what a bit-map field is here = but these are
> more then 3 bits...?
> GIM>> '0b' identifies binary format as '0x' iden= tifies hexadecimal format of notation.
Ah sorry, fully overview that.

> - also sec 4.3.: "Value contains variable number of bit-map field= s so
> that overall
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number of bits in the fields equals Length *= 8."
>=C2=A0 =C2=A0However there is no field 'Value' in the figure...=
> GIM>> Thank you for pointing. I'll update Figure 4 and Figur= e 5 to add Value tag on the field immediately following RTM field.

There are more questions here:

> Also the following
> explanation about future bit-maps is really confusing to me; why don&#= 39;t
> you just say that the rest as indicated by the length field must be > padded with zeros...?
GIM2>> Th= e description follows RFC 7794 Section 2.1=C2=A0
> - Should section 4.8 maybe be a subsection of 4.7? This part confused = me
> a bit because the example seems to be generic but the rest is RSVP-TE<= br> > specific, right? Maybe move the example as a separate section before o= r
> after the whole section 4...?
GIM2>= ;> Thank you, I agree it is more logical flow. With the change suggested= by Ben it will look like this:
   4.  Control Plane Theory of Ope=
ration . . . . . . . . . . . . . .  10
     4.1.  RTM Capability  . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  RTM Capability Sub-TLV  . . . . . . . . . . . . . . . . .  11
     4.3.  RTM Capability Advertisement in Routing Protocols . . . .  11
       4.3.1.  RTM Capability Advertisement in OSPFv2  . . . . . . .  11
       4.3.2.  RTM Capability Advertisement in OSPFv3  . . . . . . .  13
       4.3.3.  RTM Capability Advertisement in IS-IS . . . . . . . .  13
       4.3.4.  RTM Capability Advertisement in BGP-LS  . . . . . . .  13
     4.4.  RSVP-TE Control Plane Operation to Support RTM  . . . . .  14
       4.4.1.  RTM_SET TLV . . . . . . . . . . . . . . . . . . . . .  15
>
> Nits:
> - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > network
> - There are (still) some not spelled out abbreviations (LDP, PW);
> GIM>> Since both are used only once - expanded
> in turn
> others are extended twice (e.g. PTP)...
> GIM>>=C2=A0 Cleaned.
> - In figure 1, I would rename 'Value' to 'Sub-TLV' and= maybe also
> indicate it as optional in the figure: Sub-TLV (optional)
> GIM>> Agree
>


--94eb2c0931da95efa10549d84b37-- From nobody Fri Mar 3 11:19:09 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4129D1295AF for ; Fri, 3 Mar 2017 11:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkVftyHg0NFK for ; Fri, 3 Mar 2017 11:19:06 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748C41294DF for ; Fri, 3 Mar 2017 11:19:05 -0800 (PST) Received: (qmail 14016 invoked from network); 3 Mar 2017 20:19:03 +0100 Received: from pd9e11f3d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.61) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Mar 2017 20:19:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 3 Mar 2017 20:19:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15C3695F-D11A-4F35-A405-CB71D914DC5F@kuehlewind.net> References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> To: Greg Mirsky X-Mailer: Apple Mail (2.3259) Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:19:07 -0000 Hi Greg, two quick replies below. Mirja > Am 03.03.2017 um 20:10 schrieb Greg Mirsky : >=20 > Hi Mirja, > thank you for your comments and very helpful discussion. My notes = in-lined and now tagged with GIM2>> >=20 > Regards, > Greg >=20 > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) = wrote: > Hi Greg, >=20 > see inline. >=20 > Mirja >=20 >=20 > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky : > > > > Hi Mirja, > > thank your for the review and the comments, most helpful. > > Please find my answers in-line tagged GIM>>. > > > > Regards, > > Greg > > > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind = wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > > draft-ietf-mpls-residence-time-14: No Objection > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > High level comment: > > Maybe extend the security section a bit and describe what can happen = in > > the worse case if the value has been modified to a too high or too = low > > value; and maybe even given some guidance on performing additional = checks > > to figure out if a given value is reasonable for a given path or = not. > > > > Questions: > > - Can you explain why PTPType, Port ID, and Sequence ID are needed = in the > > PTP Sub-TLV format if those values are already in the PTP packet = itself > > that follows? > > GIM>> We propose to copy these values as they uniquely identify PTP = control message as these are required for two-step mode and suggesting = inspection of the PTP payload would cause layer violation. >=20 > I see. Maybe add a sentence that these field are use to identify the = packet. However, when you copy them, you also have to inspect the = payload and that=E2=80=99s the same layer violation. Also not sure if = duplicating information in the packet is the best approach. Why don=E2=80=99= t use just add an own identifier to the packet instead? > GIM2>> Will the following, when added at the very end of Section 3.1, = work: > Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP > control packet encapsulated in RTM message and are used in two-step > RTM mode Section 2.1.1. >=20 > GIM2>> The RTM message created by egress or the first on the LSP = two-step RTM node. Thus other RTM nodes don't need to look into PTP = control message but use the PTP sub-TLV. Creating new identifier is = certainly an alternative but I believe that will require more state = coordination between LERs on the same RTM LSP. Re-using existing = characteristic information, in my view, is simpler solution. Yes the new text helps. I don=E2=80=99t see why there is any more = coordination needed if you use an identifier. If you are in two-step = mode, you simply remember the identifier of the packet that you use to = measurement together with your measurement and wait for the next packet = with the same identifier. I don=E2=80=99t think that=E2=80=99s any = different than using the PTP information as identifier. Anyway that=E2=80=99= s not an big issue. >=20 > > > > - Why is it necessary to define PTP sub-TLV (and have a registry for = one > > value only)? Are you expecting to see more values here? What would = those > > values be? > > GIM>> We may have another protocols or applications to use RTM and = these the most likely will have their specific set of parameters to = uniquely identify control session for two-step mode. One obvious case = would be NTP when on-path support is defined. But since we don't know = which parameters will uniquely identify cotrol session we don't request = code point allocation. >=20 > My understanding was that a new protocol would be a different RTM TLV = in the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t = understand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and = registry in sec 7.3. > GIM2>> RTM TLV differentiates between different encapsulation types, = e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this = as a problem? I still don=E2=80=99t fully understand this. You can use the same = sub-TLV even if that sub-TLV is not extensible. All I=E2=80=99m saying = is that I don=E2=80=99t understand why the sub-TLV in figure 2 has again = a type and a value. I don=E2=80=99t think those two field are needed. >=20 > > - Similar to Spencer's question: Why don't you also define a Sub-TLV > > format for NTP? > > GIM>>Hope that above answer addresses this question. >=20 > Actually not really. Why don=E2=80=99t you know which parameters to = use? >=20 > > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field = with > > values > > defined as follows: > > * 0b001..." > > Maybe I don't understand what a bit-map field is here but these = are > > more then 3 bits...? > > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal = format of notation. > Ah sorry, fully overview that. >=20 > > - also sec 4.3.: "Value contains variable number of bit-map fields = so > > that overall > > number of bits in the fields equals Length * 8." > > However there is no field 'Value' in the figure... > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to = add Value tag on the field immediately following RTM field. >=20 > There are more questions here: >=20 > > Also the following > > explanation about future bit-maps is really confusing to me; why = don't > > you just say that the rest as indicated by the length field must be > > padded with zeros...? > GIM2>> The description follows RFC 7794 Section 2.1=20 > > - Should section 4.8 maybe be a subsection of 4.7? This part = confused me > > a bit because the example seems to be generic but the rest is = RSVP-TE > > specific, right? Maybe move the example as a separate section before = or > > after the whole section 4...? > GIM2>> Thank you, I agree it is more logical flow. With the change = suggested by Ben it will look like this: > 4. Control Plane Theory of Operation . . . . . . . . . . . . . . = 10 > 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . = 10 > 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . = 11 > 4.3. RTM Capability Advertisement in Routing Protocols . . . . = 11 > 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . = 11 > 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . = 13 > 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . = 13 > 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . = 13 > 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . = 14 > 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . = 15 >=20 > > > > Nits: > > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > > network > > - There are (still) some not spelled out abbreviations (LDP, PW); > > GIM>> Since both are used only once - expanded > > in turn > > others are extended twice (e.g. PTP)... > > GIM>> Cleaned. > > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > > indicate it as optional in the figure: Sub-TLV (optional) > > GIM>> Agree > > >=20 >=20 From nobody Fri Mar 3 15:57:35 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE4129996; Fri, 3 Mar 2017 15:55:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532368.15846.9861435941051113498.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:23 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] mpls - Requested sessions have been scheduled for IETF 98 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:24 -0000 Dear Tarek Saad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mpls Session 1 (2:30:00) Tuesday, Morning Session I 0900-1130 Room Name: Vevey 1/2 size: 200 --------------------------------------------- mpls Session 2 (2:00:00) Friday, Morning Session I 0900-1130 Room Name: Zurich D size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Multiprotocol Label Switching Area Name: Routing Area Session Requester: Tarek Saad Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: teas ccamp pce bess bfd idr pals bier detnet Second Priority: nvo3 sfc spring i2rs rtgarea rtgwg Third Priority: ospf isis sidr People who must be present: George Swallow Loa Andersson Deborah Brungard Nicolai Leymann Tarek Saad Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sat Mar 4 16:46:54 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4631295F2; Sat, 4 Mar 2017 16:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z9iIpOhap4j; Sat, 4 Mar 2017 16:46:45 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D221295F0; Sat, 4 Mar 2017 16:46:45 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id x37so49735375ota.2; Sat, 04 Mar 2017 16:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zxFwoFkhAwQVY6WfI2++c7DlJZFdVpiyBCeeGpcN4hU=; b=QbXkC0uSL7wCKFyVJ7dV80pBvu0aefOE7ZfScSLK4tBMlTKati9WXsefXT+QtAIL2d VMYKl5sm1rZZ2IL32BCO40+Ko72T9FGFdD7yEBqVsmMVPUCUcF6JMkvHFpjxeSY4eDnU tucCf26WC7ebrbK44p3JBG2R15RG51foo4b1iwbvE6Jj4w+AlR1pRe3HiFfGtcN/ZiIJ BISxFpnz4AephRvAytWvhC9RMcQUs/kTQA5Ak6TDZITVNZE7adXke839nVlUEk3AQWN9 oDXI0ucdT8It3AU8RIG9zsvbyTz98cuiEuXGyF5eveDh3EzNmGFl8ly1ddLVmX3LQDVD paxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zxFwoFkhAwQVY6WfI2++c7DlJZFdVpiyBCeeGpcN4hU=; b=BQGWjkuvfpa5pjH53cxhVbO7WOoYjhFIxG+7TwRtJJrO0lUyBlkwFxEMOj1k21H/Ad M0w8Zejv/6kAFwhZ5T1fh8W0RAxxBuE+lUc2vGjVNdFJtJVZDanpmMnU17lpgM82xbmp OIVFaSLpFUI0bu1JwZVhWVp/5w4bZRsqXVgml7eSjJTbYoAz8IBI8mTYueef4IJr69tk qpgTTd8wtjt/zuUBGAfHkvBPLHlliF6+MbxWZNDbM9pmLONMfxOtEzxBd1M06aTSXEIr 6BVt4XsWprAI1fImNhWPsR5/VBXztt3tEJRgn5y7FfYFMoS0kUvuWiJzMzG9qJopVDKK +dHw== X-Gm-Message-State: AMke39nuIhfwa+RLK6r6FjL7kGeoC6CqUHZ1cdbBXUTPuNyPuURzMH5bEaePCmRokJeH8BfUaLEspByHeIpZ+w== X-Received: by 10.157.73.140 with SMTP id g12mr4583382otf.35.1488674804807; Sat, 04 Mar 2017 16:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Sat, 4 Mar 2017 16:46:44 -0800 (PST) In-Reply-To: References: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Sat, 4 Mar 2017 16:46:44 -0800 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=f40304379b20ed3ee20549f11c3a Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 00:46:47 -0000 --f40304379b20ed3ee20549f11c3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ben, Stefano provided more detailed information to our discussion regarding limiting wait for the follow-up: Profiles can have very different packet rate (between 1 and 128 packet per seconds). In G.8275.1 (telecom profile with full timing support) the packet rate is 16 packets per seconds. But for applications were timing support is not guaranteed, the packet rate might be higher (e.g. 64 or 128 packet per seconds). 8275.2 is a better reference for this case. One problem is that existing profiles have not defined time out ; extract from 8275.2: *=E2=80=9CPTSF-lossSync, lack of reception of PTP timing messages from a ma= ster (loss of the packet timing signal): if the slave no longer receives the timing messages sent by a master (i.e., Sync and subsequently Follow_up and Delay_Resp messages), then a PTSF-lossSync associated to this master must occur. A timeout period for reception of Sync messages or Delay_Resp messages (these are analogous to "syncReceiptTimeout" and "delayRespReceiptTimeout" in [ITU-T G.8265.1]) for these timing messages must be implemented in the slave before triggering the PTSF-lossSync (the range and default value of this timeout parameter are for further study).= =E2=80=9D* As an example, a time out of 5 Sync messages in case of 64 packets per seconds would mean 78 ms. I can add a sentence with reference to PTP profiles and G8275.2. Please advise. Regards, Greg On Thu, Mar 2, 2017 at 9:21 AM, Greg Mirsky wrote: > Hi Ben, > thank you for your thorough review and comments. Please find my answers > in-line tagged GIM>>. > > Regards, > Greg > > On Wed, Mar 1, 2017 at 3:16 PM, Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for >> draft-ietf-mpls-residence-time-14: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have no objection, but do have some a few minor comments: >> >> Substantive: >> >> -2.1, 4th paragraph from end: Can you offer guidance on what might >> constitute a reasonably bound wait time?\ >> > GIM>> Section 7.7.2 Message transmission intervals in IEEE.1588.2008 > defines algorithm to calculate intervals between PTP control messages th= at > will, in turn, define the range for "the reasonably bound time". But > specification of the precise values are deferred to the appropriate PTP > profiles. > >> >> -2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope o= f >> that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same >> message? >> > GIM>> This is in reference to the node behavior in context of the same > LSP. On the given LSP the RTM-capable node MUST NOT perform in one-step a= nd > two-step mode. > >> >> Editorial: >> - Abstract: The last paragraph is a single, long sentence. Please >> consider breaking it into simpler sentences. >> > NEW TEXT > > Residence time is the variable part of propagation delay of timing > and synchronization messages. Knowing what this delay is for each > message allows for a more accurate determination of the delay to be > taken into account in applying the value included in a Precision Time > Protocol event message. > > >> - 2.1, paragraph 9: "This bit, once it is set by a two- >> step mode device, MUST stay set accordingly": Can that MUST be stated >> in process terms? That is, MUST NOT unset this bit..." >> > OLD TEXT > > PTP messages also include a bit that indicates whether or not a > follow-up message will be coming. This bit, once it is set by a two- > step mode device, MUST stay set accordingly until the original and > follow-up messages are combined by an end-point (such as a Boundary > Clock). > > NEW TEXT > > PTP messages also include a bit that indicates whether or not a > follow-up message will be coming. This bit MAY be set by a two-step > mode PTP device. The value MUST NOT be unset until the original and > follow-up messages are combined by an end-point (such as a Boundary > Clock). > > > >> >> -2.1, paragraph 11: "Without loss of generality should note >> that handling of Sync event messages..." : I don't follow the >> sentence; are words missing and/or out of order? >> -- "Following outlines handling of PTP Sync event message by the two-ste= p >> RTM node.": I think there's a missing "the" at the start. It's absence >> completely changes the meaning of "following outlines"-- as written it >> seem like the verb is "following", but I think you mean it to be >> "outlines". >> > GIM>> Agreed, Prepend with 'The'. > >> -- I have trouble matching some pronouns to their antecedents in the res= t >> of the paragraph. >> >> >> > --f40304379b20ed3ee20549f11c3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,
Stefano provided more detailed information to = our discussion regarding limiting wait for the follow-up:

Profiles can have very different packet rate (between 1 and 1= 28 packet per seconds). In G.8275.1 (telecom profile with full timing suppo= rt) the packet rate is 16 packets per seconds.

But for applications were timing support is not guarante= ed, the packet rate might be higher (e.g. 64 or 128 packet per seconds). 82= 75.2 is a better reference for this case.

One problem is that existing profiles have not defined time o= ut ; extract from 8275.2:

=E2=80=9CPTSF-lossSync, lack= of reception of PTP timing messages from a master (loss of the packet timi= ng signal): if the slave no longer receives the timing messages sent by a m= aster (i.e., Sync and subsequently Follow_up and Delay_Resp messages), then= a PTSF-lossSync associated to this master must occur. A timeout period for= reception of Sync messages or Delay_Resp messages (these are analogous to = "syncReceiptTimeout" and "delayRespReceiptTimeout" in [= ITU-T G.8265.1]) for these timing messages must be implemented in the slave= before triggering the PTSF-lossSync (the range and default value of this t= imeout parameter=C2=A0are for further study).=E2=80=9D

=C2=A0

As an example, a time out of 5 Sync messages in case of 64= packets per seconds would mean 78 ms.

=C2=A0=C2=A0I = can add a sentence with reference to PTP profiles and G8275.2. Please advis= e.

Regards,
Greg

On Thu, Mar 2, 2017 at 9:21= AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Ben,
thank you for your t= horough review and comments. Please find my answers in-line tagged GIM>&= gt;.

Regards,
Greg

On Wed, Mar 1, 2= 017 at 3:16 PM, Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell has entered the f= ollowing ballot position for
draft-ietf-mpls-residence-time-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I have no objection, but do have some a few minor comments:

Substantive:

-2.1, 4th paragraph from end: Can you offer guidance on what might
constitute a reasonably bound wait time?\
GIM&g= t;> Section 7.7.2 Message transmission intervals in IEEE.1588.2008 defin= es algorithm to calculate intervals =C2=A0between PTP control messages that= will, in turn, define the range for "the reasonably bound time".= But specification of the precise values are deferred to the appropriate PT= P profiles.

-2.1, 2nd paragraph from end: "... MUST NOT do both": What's = the scope of
that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same
message?
GIM>> This is in reference to th= e node behavior in context of the same LSP. On the given LSP the RTM-capabl= e node MUST NOT perform in one-step and two-step mode.

Editorial:
- Abstract: The last paragraph is a single, long sentence. Please
consider breaking it into simpler sentences.
NE= W TEXT
   Residence time is the variable part of propagation delay of t=
iming
   and synchronization messages.  Knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a Precision Time
   Protocol event message.=C2=A0

- 2.1, paragraph 9: "This bit, once it is set by a two-
=C2=A0 =C2=A0step mode device, MUST stay set accordingly": Can that MU= ST be stated
in process terms? That is, <actors>=C2=A0 MUST NOT unset this bit...&= quot;
OLD TEXT
   PTP messages also inc=
lude a bit that indicates whether or not a
   follow-up message will be coming.  This bit, once it is set by a two-
   step mode device, MUST stay set accordingly until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).
NEW TEXT
   PTP messages also include a bit that indicates w=
hether or not a
   follow-up message will be coming.  This bit MAY be set by a two-step
   mode PTP device.  The value MUST NOT be unset until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).
=C2=A0

-2.1, paragraph 11:=C2=A0 "Without loss of generality should note
=C2=A0 =C2=A0that handling of Sync event messages..." : I don't fo= llow the
sentence; are words missing and/or out of order?
-- "Following outlines handling of PTP Sync event message by the two-s= tep
RTM node.": I think there's a missing "the" at the start= . It's absence
completely changes the meaning of "following outlines"-- as writt= en it
seem like the verb is "following", but I think you mean it to be<= br> "outlines".
GIM>> Agreed, Prepe= nd with 'The'.=C2=A0
-- I have trouble matching some pronouns to their antecedents in the rest of the paragraph.




--f40304379b20ed3ee20549f11c3a-- From nobody Sun Mar 5 01:59:35 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EA6129482; Sun, 5 Mar 2017 01:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzlC7JOwcOA5; Sun, 5 Mar 2017 01:59:27 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC52128AC9; Sun, 5 Mar 2017 01:59:27 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v259tDHY002063; Sun, 5 Mar 2017 01:59:25 -0800 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 28yutpbv9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 05 Mar 2017 01:59:25 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 5 Mar 2017 11:59:21 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Sun, 5 Mar 2017 11:59:21 +0200 From: Tal Mizrahi To: "'ippm@ietf.org'" , "mpls@ietf.org" Thread-Topic: Updated version of draft-mizrahi-ippm-multiplexed-alternate-marking-01.txt Thread-Index: AdKVllhO53n533LaTxio1Os1NzpebA== Date: Sun, 5 Mar 2017 09:59:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-04_19:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703050084 Archived-At: Subject: [mpls] Updated version of draft-mizrahi-ippm-multiplexed-alternate-marking-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 09:59:29 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1taXpy YWhpLWlwcG0tbXVsdGlwbGV4ZWQtYWx0ZXJuYXRlLW1hcmtpbmcuDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRpcGxleGVkLWFsdGVybmF0ZS1tYXJr aW5nLTAxDQoNClRoZSBtYWluIGNoYW5nZSBjb21wYXJlZCB0byB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyB0aGF0IHdlIGhhdmUgYWRkZWQgYSBzZWN0aW9uIHRoYXQgZXh0ZW5kcyB0aGUgYXBwcm9h Y2ggdG8gYSBtYXJraW5nIGZpZWxkIHRoYXQgaXMgbm90IG5lY2Vzc2FyaWx5IGEgc2luZ2xlIGJp dC4gDQpUaGUgbmV3IHNlY3Rpb24gbWVudGlvbnMgTVBMUyBTRkxzIGFzIGFuIGV4YW1wbGUgZm9y IG1hcmtpbmcgZmllbGRzIHRoYXQgYXJlIGxvbmdlciB0aGFuIG9uZSBiaXQgKGFzIGluIGRyYWZ0 LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsKSwgYW5kIGNhbiB0aHVzIHVzZSB0aGUgbXVsdGlwbGV4 aW5nIGFwcHJvYWNoLg0KDQpDb21tZW50cyB3aWxsIGJlIHdlbGNvbWUuDQoNClRoYW5rcywNClRh bC4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1p enJhaGktaXBwbS1tdWx0aXBsZXhlZC1hbHRlcm5hdGUtbWFya2luZy0wMS50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGFsIE1penJhaGkgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRpcGxleGVk LWFsdGVybmF0ZS1tYXJraW5nDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJUGFzc2l2ZSBQZXJmb3Jt YW5jZSBNb25pdG9yaW5nIHVzaW5nIGEgTXVsdGlwbGV4ZWQgTWFya2luZyBGaWVsZA0KRG9jdW1l bnQgZGF0ZToJMjAxNy0wMy0wNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMTANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRpcGxleGVkLWFsdGVybmF0ZS1tYXJraW5nLTAxLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW1penJhaGktaXBwbS1tdWx0aXBsZXhlZC1hbHRlcm5hdGUtbWFya2luZy8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRp cGxleGVkLWFsdGVybmF0ZS1tYXJraW5nLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1penJhaGktaXBwbS1tdWx0aXBsZXhlZC1hbHRl cm5hdGUtbWFya2luZy0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBpbnRyb2R1Y2VzIGEg bWFya2luZyBtZXRob2QgdGhhdCB1c2VzIGEgc2luZ2xlIG1hcmtpbmcgYml0LA0KICAgb3IgdHdv IG1hcmtpbmcgdmFsdWVzLCBhbmQgYWxsb3dzIGFjY3VyYXRlIGxvc3MgYW5kIGRlbGF5DQogICBt ZWFzdXJlbWVudC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Mar 6 14:52:38 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ECB129547 for ; Mon, 6 Mar 2017 14:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeWlH-c6MNOF for ; Mon, 6 Mar 2017 14:52:35 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0099.outbound.protection.outlook.com [104.47.33.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B446129493 for ; Mon, 6 Mar 2017 14:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wjW14VImHf9AAlEVKTOVCi69oQo4OTvTK3B3XFkq7N4=; b=AbYAw9rXXsNLvmKswzo8yMzaz2M26x3pF+XJFb0U62wQj6kKbwcr+ehqjnev/jyueCuKW8bZKKV9kwze+TAjHn4qjCRH1UZTENJsi/FjxNi9j/xB7s3u8xM09mR2JuO67n3p7dCQ+ryWpEpEy0yZ8ZMdtFkxl+rJgVVefQnjNao= Received: from CO2PR0501MB1077.namprd05.prod.outlook.com (10.160.7.22) by CO2PR0501MB1077.namprd05.prod.outlook.com (10.160.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 6 Mar 2017 22:52:33 +0000 Received: from CO2PR0501MB1077.namprd05.prod.outlook.com ([10.160.7.22]) by CO2PR0501MB1077.namprd05.prod.outlook.com ([10.160.7.22]) with mapi id 15.01.0947.011; Mon, 6 Mar 2017 22:52:33 +0000 From: Abhishek Deshmukh To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: draft-deshmukh-rsvp-rmr-extension Thread-Index: AQHSlsxXonFNfvGtMUu0sddk2NrX2Q== Date: Mon, 6 Mar 2017 22:52:33 +0000 Message-ID: <92C1A19A-0756-4AAD-A2B8-83F2739B6807@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: e341fdfb-ffe1-4650-1d26-08d464e37a57 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CO2PR0501MB1077; x-microsoft-exchange-diagnostics: 1; CO2PR0501MB1077; 7:AXTe1gCFZfZH8uEGyAQgs6xcSlvnn+qXXSkhPddKDQLjOM+4JP3pvWXcjLJcvLNmzLBC4x6IApdAaN9EHa8e4rfGv0kZOy2gEtqi1SmXScOJ4LHppmSco+DtErbv9UOPReOF9DtIlM2wczZ/dJ9+eWX9c5R1JZbAgwZxf2LU/w0AYTgwaPzyY5njANxqcPUXJKUeNJRLklmCq1Jzb1vOwA10Wo8WTvULu73hyFZUlgckjd0R6iP+eOoHTpdp3DNS/7pqkvyHpTOKnldWJmFIqF+4MIloBjbPQRDk7IB79nJ4bndsBQ1cGshFxWJF0+9Z1gWL9Km2uxhwTZcUHQ35GA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:CO2PR0501MB1077; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB1077; x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39840400002)(39860400002)(39850400002)(53754006)(50986999)(86362001)(3846002)(81166006)(33656002)(7736002)(2900100001)(102836003)(4326008)(7906003)(2501003)(236005)(66066001)(230783001)(36756003)(8676002)(6506006)(92566002)(77096006)(122556002)(189998001)(6116002)(606005)(6486002)(3660700001)(6436002)(9326002)(53936002)(6306002)(99286003)(106116001)(54356999)(54896002)(38730400002)(25786008)(5660300001)(3280700002)(2906002)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB1077; H:CO2PR0501MB1077.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_92C1A19A07564AADA2B883F2739B6807junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2017 22:52:33.8184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB1077 Archived-At: Cc: "draft-deshmukh-rsvp-rmr-extension@tools.ietf.org" Subject: [mpls] draft-deshmukh-rsvp-rmr-extension X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:52:37 -0000 --_000_92C1A19A07564AADA2B883F2739B6807junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpEdXJpbmcgSUVURjk2ICYgSUVURjk3LCB3ZSByZWNlaXZlZCBzb21lIGZlZWRi YWNrIG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC1kZXNobXVraC1yc3ZwLXJtci1leHRlbnNpb24tMDEudHh0DQpUaGUgcHVycG9zZSBvZiB0aGlz IGVtYWlsIGp1c3QgdG8gY2xhcmlmeSBvbiB0aGUgUEFUSCBzZW5kZXItdGVtcGxhdGUgbWVyZ2lu ZyBwcm9jZXNzIGFzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuDQoNCkV2ZXJ5IHJpbmcgbHNwIG9y aWdpbmF0ZXMgJiB0ZXJtaW5hdGVkIGF0IHRoZSBzYW1lIG5vZGUgaS5lLiB0aGUgaW5ncmVzcyAm IGVncmVzcyBmb3IgdGhlIHJpbmcgTFNQIGlzIHNhbWUuDQpBbHNvLCByaW5nIExTUHMgYXJlIE1Q MlAgaW4gbmF0dXJlLiBJdCBtZWFucyBldmVyeSBub24tZWdyZXNzIG5vZGUgaXMgYWxzbyBhbiBp bmdyZXNzIGFuZCBhIG1lcmdlLXBvaW50IGZvciB0aGUgTFNQLg0KUjAtLS0tPlIxLS0tLT5SMi0t LS0+UjMtLS0tPlI0LS0tLT5SMA0KDQpUbyBlc3RhYmxpc2ggYW4gTVAyUCBMU1AsIHdoZW4gbm9k ZSBSMiByZWNlaXZlcyBhIFBBVEggbWVzc2FnZSBmcm9tIFIwLCBSMiBhZGRzIGl04oCZcyBvd24g U0VOREVSX1RFTVBMQVRFIGluIHRoZSBvdXRnb2luZyBQQVRIIG1lc3NhZ2UuDQpUaGUgb3V0Z29p bmcgUEFUSCBtZXNzYWdlIGF0IFIwIHdpbGwgaGF2ZSB0aGUgZm9sbG93aW5nIFNFTkRFUl9URU1Q TEFURVM6DQogICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAg ICB8U0VOREVSX1RFTVBMQVRFXzAgOiBTRU5ERVJfQUREUkVTUyA9IFIwLCBMU1BfSUQgPSAxIHwN CiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgIHxTRU5E RVJfVEVNUExBVEVfMSA6IFNFTkRFUl9BRERSRVNTID0gUjEsIExTUF9JRCA9IDEgfA0KICAgICAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgfFNFTkRFUl9URU1Q TEFURV8yIDogU0VOREVSX0FERFJFU1MgPSBSMiwgTFNQX0lEID0gMSB8DQogICAgICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNpbWlsYXJseSwgZWFjaCBub2RlIGluIHRo ZSByaW5nIHdpbGwgaW5zZXJ0IGl04oCZcyBvd24gU0VOREVSX1RFTVBMQVRFLg0KVGhlIFJFU1Yg bWVzc2FnZSB3aWxsIGhhdmUgbXVsdGlwbGUgRklMVEVSX1NQRUMgb2JqZWN0cyBjb3JyZXNwb25k aW5nIHRvIHRoZSBTRU5ERVJfVEVNUExBVEVTLg0KDQpGdXJ0aGVyLCB0aGlzIHByb2Nlc3Mgb2Yg U0VOREVSX1RFTVBMQVRFIG1lcmdpbmcgY2FuIGFsc28gYmUgdXNlZCBmb3IgYmFuZHdpZHRoIG1h bmFnZW1lbnQgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNC41IG9mIHRoZSBkcmFmdC4NCkkgd2ls bCBiZSBwcmVzZW50aW5nIHRoaXMgZHJhZnQgYXQgdGhlIHVwY29taW5nIElFVEYgOTguIFBsZWFz ZSBsZXQgdXMga25vdywgaWYgdGhlcmUgYXJlIGFueSBhZGRpdGlvbmFsIHF1ZXN0aW9ucy9mZWVk YmFjayBvbiB0aGlzLg0KDQpUaGFua3MsDQpBYmhpc2hlayBhbmQgY28tYXV0aG9yKHMpDQoNCg== --_000_92C1A19A07564AADA2B883F2739B6807junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <0FB12220E57A184EB0EE0C970182C3A9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJp Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q291cmllcjt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5EdXJpbmcgSUVURjk2ICZhbXA7IElFVEY5Nywgd2UgcmVjZWl2ZWQg c29tZSBmZWVkYmFjayBvbiZuYnNwO3RoZSBmb2xsb3dpbmcgZHJhZnQ6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWRlc2htdWtoLXJzdnAt cm1yLWV4dGVuc2lvbi0wMS50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWRlc2ht dWtoLXJzdnAtcm1yLWV4dGVuc2lvbi0wMS50eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBw dXJwb3NlIG9mIHRoaXMgZW1haWwganVzdCB0byBjbGFyaWZ5IG9uIHRoZSBQQVRIIHNlbmRlci10 ZW1wbGF0ZSBtZXJnaW5nIHByb2Nlc3MgYXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkV2ZXJ5IHJpbmcgbHNwIG9yaWdp bmF0ZXMgJmFtcDsgdGVybWluYXRlZCBhdCB0aGUgc2FtZSBub2RlIGkuZS4gdGhlIGluZ3Jlc3Mg JmFtcDsgZWdyZXNzIGZvciB0aGUgcmluZyBMU1AgaXMgc2FtZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ QWxzbywgcmluZyBMU1BzIGFyZSBNUDJQIGluIG5hdHVyZS4gSXQgbWVhbnMgZXZlcnkgbm9uLWVn cmVzcyBub2RlIGlzIGFsc28gYW4gaW5ncmVzcyBhbmQgYSBtZXJnZS1wb2ludCBmb3IgdGhlIExT UC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UjAtLS0tJmd0O1IxLS0tLSZndDtSMi0tLS0mZ3Q7UjMtLS0t Jmd0O1I0LS0tLSZndDtSMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VG8gZXN0YWJsaXNoIGFuIE1QMlAgTFNQLCB3aGVuIG5vZGUgUjIgcmVjZWl2ZXMgYSBQQVRI IG1lc3NhZ2UgZnJvbSBSMCwgUjIgYWRkcyBpdOKAmXMgb3duIFNFTkRFUl9URU1QTEFURSBpbiB0 aGUgb3V0Z29pbmcgUEFUSCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgb3V0Z29pbmcg UEFUSCBtZXNzYWdlIGF0IFIwIHdpbGwgaGF2ZSB0aGUgZm9sbG93aW5nIFNFTkRFUl9URU1QTEFU RVM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 U0VOREVSX1RFTVBMQVRFXzAgOiBTRU5ERVJfQUREUkVTUyA9IFIwLCBMU1BfSUQgPSAxIHw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxTRU5ERVJf VEVNUExBVEVfMSA6IFNFTkRFUl9BRERSRVNTID0gUjEsIExTUF9JRCA9IDEgfDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFNFTkRFUl9URU1QTEFU RV8yIDogU0VOREVSX0FERFJFU1MgPSBSMiwgTFNQX0lEID0gMSB8PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5TaW1pbGFybHksIGVhY2ggbm9kZSBpbiB0aGUgcmluZyB3aWxsIGluc2VydCBp dOKAmXMgb3duIFNFTkRFUl9URU1QTEFURS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIFJFU1YgbWVz c2FnZSB3aWxsIGhhdmUgbXVsdGlwbGUgRklMVEVSX1NQRUMgb2JqZWN0cyBjb3JyZXNwb25kaW5n IHRvIHRoZSBTRU5ERVJfVEVNUExBVEVTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+RnVydGhlciwgdGhpcyBwcm9jZXNzIG9mIFNFTkRFUl9URU1QTEFURSBtZXJn aW5nIGNhbiBhbHNvIGJlIHVzZWQgZm9yIGJhbmR3aWR0aCBtYW5hZ2VtZW50IGFzIGRlc2NyaWJl ZCBpbiBzZWN0aW9uIDQuNSBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgd2lsbCBi ZSBwcmVzZW50aW5nIHRoaXMgZHJhZnQgYXQgdGhlIHVwY29taW5nIElFVEYgOTguIFBsZWFzZSBs ZXQgdXMga25vdywgaWYgdGhlcmUgYXJlIGFueSBhZGRpdGlvbmFsIHF1ZXN0aW9ucy9mZWVkYmFj ayBvbiB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhh bmtzLDxicj4NCkFiaGlzaGVrIGFuZCBjby1hdXRob3Iocyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_92C1A19A07564AADA2B883F2739B6807junipernet_-- From nobody Mon Mar 6 14:58:17 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350C3129545; Mon, 6 Mar 2017 14:58:11 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kNsTMKmyGaf; Mon, 6 Mar 2017 14:58:09 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE0312896F; Mon, 6 Mar 2017 14:58:09 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id i1so124054743ota.3; Mon, 06 Mar 2017 14:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0jMdUQIuNUwGBZ+h5yP2SmrTMn3JfK+ajjwmTDJcT44=; b=PHyhpLiJR7xR7PaK54gTa+vxLQr6pKgbZih9QeSpOdKI/S+OnCpMOoAxKMMZwWcWJX xRjivHzadrvUkqAbKBArOV0IEEwN4Kc98w4ZiYbWD9jtW9XNKDnaIYxLXYeqTJ0jyXYo 6wY4JOdX6B3vtk5YTon/DD6t/zVWjFY9U3dDAvPDQBtJIeCDhZMvuGjrUpXDsECppppj +1VbW0dbMG0g7I1VALJJOGmYwenCaNU9IZF6wKphd9oVUu9fpeEWnboB4e0qlTrONrRi k2f/jOM5Z33aJBvbDYCkeVzmgAQKXyrlYItP2WWEfFxkkfcntwu7ZjLA3i2A+KXyebGO wSpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0jMdUQIuNUwGBZ+h5yP2SmrTMn3JfK+ajjwmTDJcT44=; b=amS1RbL7gfOBU0GdwLyCMS1VMUYyWe/aKKu8JyxkD6C6gb2QL3DthDd4xc+aOTBkXh M69AyJOWITVkSB2a+UwQTM73wyCAXKEPlLpLL1rzX2TnUvntyoIV3IDKZJENXrvwAjUy FndvPZNYMG/Lmj2Y21W5oHz47wmxHrzc+cjJTyxXw9MOEDlRUY9fZdLmxcGUuz0Z824w G4sJUJtjSluY4jF6+yOGcPAFIqgZtpPqeBFGrE2l55hdO8NYzkY03seJf/PWzDOu8Aq+ iwegOzoZFxQ4ud3hhzEQUFOHnZplh1WLE5AZklOsQjcGYPbUV5/8+KRiNK41UR3sy5vF xzQg== X-Gm-Message-State: AMke39nruZZUjM0D+SoDKaziDljBE5+uQhf8BLLGdi5PM1/Og9vWPBEfuPXfWpUN2yGWQ1mPE91IYCRlrWn9+A== X-Received: by 10.157.25.18 with SMTP id j18mr9172914ota.128.1488841088469; Mon, 06 Mar 2017 14:58:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Mon, 6 Mar 2017 14:58:08 -0800 (PST) In-Reply-To: <15C3695F-D11A-4F35-A405-CB71D914DC5F@kuehlewind.net> References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> <15C3695F-D11A-4F35-A405-CB71D914DC5F@kuehlewind.net> From: Greg Mirsky Date: Mon, 6 Mar 2017 14:58:08 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=f4030435a804349cf9054a17d4ad Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:58:11 -0000 --f4030435a804349cf9054a17d4ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, we use sub-TLV in Figure 2 as future proofing approach in case someone may need to define different sub-TLV that MUST precede the PTP packet. Would you agree that it is reasonable design choice? Regards, Greg On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Greg, > > two quick replies below. > > Mirja > > > Am 03.03.2017 um 20:10 schrieb Greg Mirsky : > > > > Hi Mirja, > > thank you for your comments and very helpful discussion. My notes > in-lined and now tagged with GIM2>> > > > > Regards, > > Greg > > > > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > > Hi Greg, > > > > see inline. > > > > Mirja > > > > > > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky : > > > > > > Hi Mirja, > > > thank your for the review and the comments, most helpful. > > > Please find my answers in-line tagged GIM>>. > > > > > > Regards, > > > Greg > > > > > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind > wrote: > > > Mirja K=C3=BChlewind has entered the following ballot position for > > > draft-ietf-mpls-residence-time-14: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > High level comment: > > > Maybe extend the security section a bit and describe what can happen = in > > > the worse case if the value has been modified to a too high or too lo= w > > > value; and maybe even given some guidance on performing additional > checks > > > to figure out if a given value is reasonable for a given path or not. > > > > > > Questions: > > > - Can you explain why PTPType, Port ID, and Sequence ID are needed in > the > > > PTP Sub-TLV format if those values are already in the PTP packet itse= lf > > > that follows? > > > GIM>> We propose to copy these values as they uniquely identify PTP > control message as these are required for two-step mode and suggesting > inspection of the PTP payload would cause layer violation. > > > > I see. Maybe add a sentence that these field are use to identify the > packet. However, when you copy them, you also have to inspect the payload > and that=E2=80=99s the same layer violation. Also not sure if duplicating > information in the packet is the best approach. Why don=E2=80=99t use jus= t add an > own identifier to the packet instead? > > GIM2>> Will the following, when added at the very end of Section 3.1, > work: > > Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP > > control packet encapsulated in RTM message and are used in two-step > > RTM mode Section 2.1.1. > > > > GIM2>> The RTM message created by egress or the first on the LSP > two-step RTM node. Thus other RTM nodes don't need to look into PTP contr= ol > message but use the PTP sub-TLV. Creating new identifier is certainly an > alternative but I believe that will require more state coordination betwe= en > LERs on the same RTM LSP. Re-using existing characteristic information, i= n > my view, is simpler solution. > > Yes the new text helps. I don=E2=80=99t see why there is any more coordin= ation > needed if you use an identifier. If you are in two-step mode, you simply > remember the identifier of the packet that you use to measurement togethe= r > with your measurement and wait for the next packet with the same > identifier. I don=E2=80=99t think that=E2=80=99s any different than using= the PTP > information as identifier. Anyway that=E2=80=99s not an big issue. > > > > > > > > > - Why is it necessary to define PTP sub-TLV (and have a registry for > one > > > value only)? Are you expecting to see more values here? What would > those > > > values be? > > > GIM>> We may have another protocols or applications to use RTM and > these the most likely will have their specific set of parameters to > uniquely identify control session for two-step mode. One obvious case wou= ld > be NTP when on-path support is defined. But since we don't know which > parameters will uniquely identify cotrol session we don't request code > point allocation. > > > > My understanding was that a new protocol would be a different RTM TLV i= n > the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t underst= and why your PTP > sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec 7.3. > > GIM2>> RTM TLV differentiates between different encapsulation types, > e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this = as > a problem? > > I still don=E2=80=99t fully understand this. You can use the same sub-TLV= even if > that sub-TLV is not extensible. All I=E2=80=99m saying is that I don=E2= =80=99t understand > why the sub-TLV in figure 2 has again a type and a value. I don=E2=80=99t= think > those two field are needed. > > > > > > - Similar to Spencer's question: Why don't you also define a Sub-TLV > > > format for NTP? > > > GIM>>Hope that above answer addresses this question. > > > > Actually not really. Why don=E2=80=99t you know which parameters to use= ? > > > > > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > > > values > > > defined as follows: > > > * 0b001..." > > > Maybe I don't understand what a bit-map field is here but these are > > > more then 3 bits...? > > > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal > format of notation. > > Ah sorry, fully overview that. > > > > > - also sec 4.3.: "Value contains variable number of bit-map fields so > > > that overall > > > number of bits in the fields equals Length * 8." > > > However there is no field 'Value' in the figure... > > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to ad= d > Value tag on the field immediately following RTM field. > > > > There are more questions here: > > > > > Also the following > > > explanation about future bit-maps is really confusing to me; why don'= t > > > you just say that the rest as indicated by the length field must be > > > padded with zeros...? > > GIM2>> The description follows RFC 7794 Section 2.1 > > > - Should section 4.8 maybe be a subsection of 4.7? This part confused > me > > > a bit because the example seems to be generic but the rest is RSVP-TE > > > specific, right? Maybe move the example as a separate section before = or > > > after the whole section 4...? > > GIM2>> Thank you, I agree it is more logical flow. With the change > suggested by Ben it will look like this: > > 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 1= 0 > > 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 1= 0 > > 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 1= 1 > > 4.3. RTM Capability Advertisement in Routing Protocols . . . . 1= 1 > > 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 1= 1 > > 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 1= 3 > > 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 1= 3 > > 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 1= 3 > > 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . 1= 4 > > 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 1= 5 > > > > > > > > Nits: > > > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > > > network > > > - There are (still) some not spelled out abbreviations (LDP, PW); > > > GIM>> Since both are used only once - expanded > > > in turn > > > others are extended twice (e.g. PTP)... > > > GIM>> Cleaned. > > > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > > > indicate it as optional in the figure: Sub-TLV (optional) > > > GIM>> Agree > > > > > > > > > --f4030435a804349cf9054a17d4ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,
we use sub-TLV in Figure 2 as future proofin= g approach in case someone may need to define different sub-TLV that MUST p= recede the PTP packet.
Would you agree that it is reasonable desi= gn choice?

Regards,
Greg=C2=A0

On Fri, Mar 3, = 2017 at 11:19 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Greg,

two quick replies below.

Mirja

> Am 03.03.2017 um 20:10 schrieb Greg Mirsky <gregimirsky@gmail.com>:
>
> Hi Mirja,
> thank you for your comments and very helpful discussion. My notes in-l= ined and now tagged with GIM2>>
>
> Regards,
> Greg
>
> On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> Hi Greg,
>
> see inline.
>
> Mirja
>
>
> > Am 03.03.2017 um 03:47 schrieb Greg Mirsky <gregimirsky@gmail.com>:
> >
> > Hi Mirja,
> > thank your for the review and the comments, most helpful.
> > Please find my answers in-line tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
> > Mirja K=C3=BChlewind has entered the following ballot position fo= r
> > draft-ietf-mpls-residence-time-14: No Objection
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.o= rg/doc/draft-ietf-mpls-residence-time/
> >
> >
> >
> > ------------------------------------------------------------= ----------
> > COMMENT:
> > ------------------------------------------------------------= ----------
> >
> > High level comment:
> > Maybe extend the security section a bit and describe what can hap= pen in
> > the worse case if the value has been modified to a too high or to= o low
> > value; and maybe even given some guidance on performing additiona= l checks
> > to figure out if a given value is reasonable for a given path or = not.
> >
> > Questions:
> > - Can you explain why PTPType, Port ID, and Sequence ID are neede= d in the
> > PTP Sub-TLV format if those values are already in the PTP packet = itself
> > that follows?
> > GIM>> We propose to copy these values as they uniquely iden= tify PTP control message as these are required for two-step mode and sugges= ting inspection of the PTP payload would cause layer violation.
>
> I see. Maybe add a sentence that these field are use to identify the p= acket. However, when you copy them, you also have to inspect the payload an= d that=E2=80=99s the same layer violation. Also not sure if duplicating inf= ormation in the packet is the best approach. Why don=E2=80=99t use just add= an own identifier to the packet instead?
> GIM2>> Will the following, when added at the very end of Section= 3.1, work:
>=C2=A0 =C2=A0 Tuple of PTPType, Port ID, and Sequence ID uniquely ident= ifies PTP
>=C2=A0 =C2=A0 control packet encapsulated in RTM message and are used i= n two-step
>=C2=A0 =C2=A0 RTM mode Section 2.1.1.
>
> GIM2>> The RTM message created by egress or the first on the LSP= two-step RTM node. Thus other RTM nodes don't need to look into PTP co= ntrol message but use the PTP sub-TLV. Creating new identifier is certainly= an alternative but I believe that will require more state coordination bet= ween LERs on the same RTM LSP. Re-using existing characteristic information= , in my view, is simpler solution.

Yes the new text helps. I don=E2=80=99t see why there is any mo= re coordination needed if you use an identifier. If you are in two-step mod= e, you simply remember the identifier of the packet that you use to measure= ment together with your measurement and wait for the next packet with the s= ame identifier. I don=E2=80=99t think that=E2=80=99s any different than usi= ng the PTP information as identifier. Anyway that=E2=80=99s not an big issu= e.

>
> >
> > - Why is it necessary to define PTP sub-TLV (and have a registry = for one
> > value only)? Are you expecting to see more values here? What woul= d those
> > values be?
> > GIM>> We may have another protocols or applications to use = RTM and these the most likely will have their specific set of parameters to= uniquely identify control session for two-step mode. One obvious case woul= d be NTP when on-path support is defined. But since we don't know which= parameters will uniquely identify cotrol session we don't request code= point allocation.
>
> My understanding was that a new protocol would be a different RTM TLV = in the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t unders= tand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and registry i= n sec 7.3.
> GIM2>> RTM TLV differentiates=C2=A0 between different encapsulat= ion types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do = you see this as a problem?

I still don=E2=80=99t fully understand this. You can use the same su= b-TLV even if that sub-TLV is not extensible. All I=E2=80=99m saying is tha= t I don=E2=80=99t understand why the sub-TLV in figure 2 has again a type a= nd a value. I don=E2=80=99t think those two field are needed.

>
> > - Similar to Spencer's question: Why don't you also defin= e a Sub-TLV
> > format for NTP?
> > GIM>>Hope that above answer addresses this question.
>
> Actually not really. Why don=E2=80=99t you know which parameters to us= e?
>
> > - sec 4.3: "RTM (capability) - is a three-bit long bit-map f= ield with
> > values
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0defined as follows:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 0b001..."
> >=C2=A0 =C2=A0Maybe I don't understand what a bit-map field is = here but these are
> > more then 3 bits...?
> > GIM>> '0b' identifies binary format as '0x'= identifies hexadecimal format of notation.
> Ah sorry, fully overview that.
>
> > - also sec 4.3.: "Value contains variable number of bit-map = fields so
> > that overall
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0number of bits in the fields equals Len= gth * 8."
> >=C2=A0 =C2=A0However there is no field 'Value' in the figu= re...
> > GIM>> Thank you for pointing. I'll update Figure 4 and = Figure 5 to add Value tag on the field immediately following RTM field.
>
> There are more questions here:
>
> > Also the following
> > explanation about future bit-maps is really confusing to me; why = don't
> > you just say that the rest as indicated by the length field must = be
> > padded with zeros...?
> GIM2>> The description follows RFC 7794 Section 2.1
> > - Should section 4.8 maybe be a subsection of 4.7? This part conf= used me
> > a bit because the example seems to be generic but the rest is RSV= P-TE
> > specific, right? Maybe move the example as a separate section bef= ore or
> > after the whole section 4...?
> GIM2>> Thank you, I agree it is more logical flow. With the chan= ge suggested by Ben it will look like this:
>=C2=A0 =C2=A0 4.=C2=A0 Control Plane Theory of Operation . . . . . . . = . . . . . . .=C2=A0 10
>=C2=A0 =C2=A0 =C2=A0 4.1.=C2=A0 RTM Capability=C2=A0 . . . . . . . . . = . . . . . . . . . . . .=C2=A0 10
>=C2=A0 =C2=A0 =C2=A0 4.2.=C2=A0 RTM Capability Sub-TLV=C2=A0 . . . . . = . . . . . . . . . . . .=C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 4.3.=C2=A0 RTM Capability Advertisement in Routing= Protocols . . . .=C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.1.=C2=A0 RTM Capability Advertisement i= n OSPFv2=C2=A0 . . . . . . .=C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.2.=C2=A0 RTM Capability Advertisement i= n OSPFv3=C2=A0 . . . . . . .=C2=A0 13
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.3.=C2=A0 RTM Capability Advertisement i= n IS-IS . . . . . . . .=C2=A0 13
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.4.=C2=A0 RTM Capability Advertisement i= n BGP-LS=C2=A0 . . . . . . .=C2=A0 13
>=C2=A0 =C2=A0 =C2=A0 4.4.=C2=A0 RSVP-TE Control Plane Operation to Supp= ort RTM=C2=A0 . . . . .=C2=A0 14
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.4.1.=C2=A0 RTM_SET TLV . . . . . . . . . = . . . . . . . . . . . .=C2=A0 15
>
> >
> > Nits:
> > - Maybe change to title to: Residence Time Measurement (RTM) in M= PLS
> > network
> > - There are (still) some not spelled out abbreviations (LDP, PW);=
> > GIM>> Since both are used only once - expanded
> > in turn
> > others are extended twice (e.g. PTP)...
> > GIM>>=C2=A0 Cleaned.
> > - In figure 1, I would rename 'Value' to 'Sub-TLV'= ; and maybe also
> > indicate it as optional in the figure: Sub-TLV (optional)
> > GIM>> Agree
> >
>
>


--f4030435a804349cf9054a17d4ad-- From nobody Tue Mar 7 06:29:44 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40112965F for ; Tue, 7 Mar 2017 05:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb1HT9nuUUPh for ; Tue, 7 Mar 2017 05:32:50 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59387129B78 for ; Tue, 7 Mar 2017 05:32:47 -0800 (PST) Received: (qmail 32063 invoked from network); 7 Mar 2017 14:26:04 +0100 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 7 Mar 2017 14:26:04 +0100 To: Greg Mirsky References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> <15C3695F-D11A-4F35-A405-CB71D914DC5F@kuehlewind.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <6383944e-4453-c6c4-6e94-1e4a5e382fd3@kuehlewind.net> Date: Tue, 7 Mar 2017 14:26:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:32:52 -0000 Still not convinced because you can just use an new RTM TLV for this case. On 06.03.2017 23:58, Greg Mirsky wrote: > Hi Mirja, > we use sub-TLV in Figure 2 as future proofing approach in case someone may > need to define different sub-TLV that MUST precede the PTP packet. > Would you agree that it is reasonable design choice? > > Regards, > Greg > > On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) > wrote: > > Hi Greg, > > two quick replies below. > > Mirja > > > Am 03.03.2017 um 20:10 schrieb Greg Mirsky >: > > > > Hi Mirja, > > thank you for your comments and very helpful discussion. My notes > in-lined and now tagged with GIM2>> > > > > Regards, > > Greg > > > > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) > > wrote: > > Hi Greg, > > > > see inline. > > > > Mirja > > > > > > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky >: > > > > > > Hi Mirja, > > > thank your for the review and the comments, most helpful. > > > Please find my answers in-line tagged GIM>>. > > > > > > Regards, > > > Greg > > > > > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja Kühlewind > wrote: > > > Mirja Kühlewind has entered the following ballot position for > > > draft-ietf-mpls-residence-time-14: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > High level comment: > > > Maybe extend the security section a bit and describe what can happen in > > > the worse case if the value has been modified to a too high or too low > > > value; and maybe even given some guidance on performing additional checks > > > to figure out if a given value is reasonable for a given path or not. > > > > > > Questions: > > > - Can you explain why PTPType, Port ID, and Sequence ID are needed in the > > > PTP Sub-TLV format if those values are already in the PTP packet itself > > > that follows? > > > GIM>> We propose to copy these values as they uniquely identify PTP > control message as these are required for two-step mode and suggesting > inspection of the PTP payload would cause layer violation. > > > > I see. Maybe add a sentence that these field are use to identify the > packet. However, when you copy them, you also have to inspect the payload > and that’s the same layer violation. Also not sure if duplicating > information in the packet is the best approach. Why don’t use just add an > own identifier to the packet instead? > > GIM2>> Will the following, when added at the very end of Section 3.1, work: > > Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP > > control packet encapsulated in RTM message and are used in two-step > > RTM mode Section 2.1.1. > > > > GIM2>> The RTM message created by egress or the first on the LSP > two-step RTM node. Thus other RTM nodes don't need to look into PTP > control message but use the PTP sub-TLV. Creating new identifier is > certainly an alternative but I believe that will require more state > coordination between LERs on the same RTM LSP. Re-using existing > characteristic information, in my view, is simpler solution. > > Yes the new text helps. I don’t see why there is any more coordination > needed if you use an identifier. If you are in two-step mode, you simply > remember the identifier of the packet that you use to measurement > together with your measurement and wait for the next packet with the same > identifier. I don’t think that’s any different than using the PTP > information as identifier. Anyway that’s not an big issue. > > > > > > > > > - Why is it necessary to define PTP sub-TLV (and have a registry for one > > > value only)? Are you expecting to see more values here? What would those > > > values be? > > > GIM>> We may have another protocols or applications to use RTM and these the most likely will have their specific set of parameters to uniquely identify control session for two-step mode. One obvious case would be NTP when on-path support is defined. But since we don't know which parameters will uniquely identify cotrol session we don't request code point allocation. > > > > My understanding was that a new protocol would be a different RTM TLV in the registry in section 7.2. That’s fine. I don’t understand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec 7.3. > > GIM2>> RTM TLV differentiates between different encapsulation types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this as a problem? > > I still don’t fully understand this. You can use the same sub-TLV even if > that sub-TLV is not extensible. All I’m saying is that I don’t understand > why the sub-TLV in figure 2 has again a type and a value. I don’t think > those two field are needed. > > > > > > - Similar to Spencer's question: Why don't you also define a Sub-TLV > > > format for NTP? > > > GIM>>Hope that above answer addresses this question. > > > > Actually not really. Why don’t you know which parameters to use? > > > > > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > > > values > > > defined as follows: > > > * 0b001..." > > > Maybe I don't understand what a bit-map field is here but these are > > > more then 3 bits...? > > > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal > format of notation. > > Ah sorry, fully overview that. > > > > > - also sec 4.3.: "Value contains variable number of bit-map fields so > > > that overall > > > number of bits in the fields equals Length * 8." > > > However there is no field 'Value' in the figure... > > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to > add Value tag on the field immediately following RTM field. > > > > There are more questions here: > > > > > Also the following > > > explanation about future bit-maps is really confusing to me; why don't > > > you just say that the rest as indicated by the length field must be > > > padded with zeros...? > > GIM2>> The description follows RFC 7794 Section 2.1 > > > - Should section 4.8 maybe be a subsection of 4.7? This part confused me > > > a bit because the example seems to be generic but the rest is RSVP-TE > > > specific, right? Maybe move the example as a separate section before or > > > after the whole section 4...? > > GIM2>> Thank you, I agree it is more logical flow. With the change > suggested by Ben it will look like this: > > 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 10 > > 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 > > 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 > > 4.3. RTM Capability Advertisement in Routing Protocols . . . . 11 > > 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 11 > > 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 13 > > 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 13 > > 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 13 > > 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . 14 > > 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 15 > > > > > > > > Nits: > > > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > > > network > > > - There are (still) some not spelled out abbreviations (LDP, PW); > > > GIM>> Since both are used only once - expanded > > > in turn > > > others are extended twice (e.g. PTP)... > > > GIM>> Cleaned. > > > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > > > indicate it as optional in the figure: Sub-TLV (optional) > > > GIM>> Agree > > > > > > > > > From nobody Tue Mar 7 09:23:30 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF87129599; Tue, 7 Mar 2017 09:23:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148890740636.30331.8828124073163940642@ietfa.amsl.com> Date: Tue, 07 Mar 2017 09:23:26 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-15.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:23:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-15.txt Pages : 28 Date : 2017-03-07 Abstract: This document specifies a new Generic Associated Channel for Residence Time Measurement and describes how it can be used by time synchronization protocols within a MPLS domain. Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a Precision Time Protocol event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-15 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 nobody Tue Mar 7 09:29:48 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C9D1295B5; Tue, 7 Mar 2017 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atWeD58GQbOp; Tue, 7 Mar 2017 09:29:43 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEFC12959B; Tue, 7 Mar 2017 09:29:43 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id x37so10553904ota.2; Tue, 07 Mar 2017 09:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fFO+lwLlYckyYlz3v+hytAGMbd50GusulUiEzmdUHqc=; b=Q7gDnZeSt7eRJUTSNNLEr50SoRsu15QjH5enmsvf8HcqjLVF2k7b2UE58XHOX2stR4 lywW9b9BlN/GS1qqjDf5p4HKN3D9T5GFoQzGtntwak/OCZeEEOLFi11969IIMWd/UFVJ 94xa0FtsOV4UO4wxSPU+I6Myqm+uM5NLzu+GTIRL4+Y3rP6HDJNNOLI3t1k8aGXdZLLP XMidVnB/5jFDXGx5dkbTo4PrNBZnbTbt4IRWrNcV6NiUx2OCfgvURnYMvlS/ke2p29xb RcrZ3/l0vSNPdjA8kwqpo6QRQcaZnjuS5Rx3cMCsQdzmk+UqezXpk28DwdNR9kLJi2xF UwwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fFO+lwLlYckyYlz3v+hytAGMbd50GusulUiEzmdUHqc=; b=AED6rh0JH5z31/QeTXuuadA5M/ajdqoEuPNe0n0efBD+/enjxitZkOEbt9mN4IMBAn vswDNBo/HvYVvlY0A27q/zmcO6WYirDzhLjnel2GoLhHBgUtx90jPRlyOuvx+VXHElJN RplEXk9xJanGQzjjanS67p1VIpop+TppgaFxR97Lm7cMr3JIgCcXBVi5Smfo+2R5smXL WzqTgcfA9GZ9/IA0P6qbYyhu/b9TkwFba+iHGqiISS0LPfU7riLRZntPWsrdPpYlRkGh mP+18uAS5BujDWijdgXsmoyMMpZcH8DyrIW120hsBpQcxW3c/lwxCmGWusmVrmFWKFU2 X/Zg== X-Gm-Message-State: AFeK/H019jLHj/HFtvY97ZtoP6uHJQ6lJxe3fXHS183305gyVw2iscShIIPtgeBzH0U5LEqY+4hYY4exMwURew== X-Received: by 10.157.56.137 with SMTP id p9mr995001otc.68.1488907782813; Tue, 07 Mar 2017 09:29:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 7 Mar 2017 09:29:42 -0800 (PST) In-Reply-To: <6383944e-4453-c6c4-6e94-1e4a5e382fd3@kuehlewind.net> References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> <15C3695F-D11A-4F35-A405-CB71D914DC5F@kuehlewind.net> <6383944e-4453-c6c4-6e94-1e4a5e382fd3@kuehlewind.net> From: Greg Mirsky Date: Tue, 7 Mar 2017 09:29:42 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a11c10e5e7f8115054a275b66 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:29:47 -0000 --001a11c10e5e7f8115054a275b66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, et. al, I've uploaded the update to the draft. We've done our best to address your many comments. Kind regards, Greg On Tue, Mar 7, 2017 at 5:26 AM, Mirja K=C3=BChlewind = wrote: > Still not convinced because you can just use an new RTM TLV for this case= . > > On 06.03.2017 23:58, Greg Mirsky wrote: > >> Hi Mirja, >> we use sub-TLV in Figure 2 as future proofing approach in case someone m= ay >> need to define different sub-TLV that MUST precede the PTP packet. >> Would you agree that it is reasonable design choice? >> >> Regards, >> Greg >> >> On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) < >> ietf@kuehlewind.net >> > wrote: >> >> Hi Greg, >> >> two quick replies below. >> >> Mirja >> >> > Am 03.03.2017 um 20:10 schrieb Greg Mirsky > >: >> > >> > Hi Mirja, >> > thank you for your comments and very helpful discussion. My notes >> in-lined and now tagged with GIM2>> >> > >> > Regards, >> > Greg >> > >> > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) >> > wrote: >> > Hi Greg, >> > >> > see inline. >> > >> > Mirja >> > >> > >> > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky > >: >> > > >> > > Hi Mirja, >> > > thank your for the review and the comments, most helpful. >> > > Please find my answers in-line tagged GIM>>. >> > > >> > > Regards, >> > > Greg >> > > >> > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewind < >> ietf@kuehlewind.net >> > wrote: >> > > Mirja K=C3=BChlewind has entered the following ballot position f= or >> > > draft-ietf-mpls-residence-time-14: No Objection >> > > >> > > When responding, please keep the subject line intact and reply t= o >> all >> > > email addresses included in the To and CC lines. (Feel free to >> cut this >> > > introductory paragraph, however.) >> > > >> > > >> > > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> >> > > for more information about IESG DISCUSS and COMMENT positions. >> > > >> > > >> > > The document, along with other ballot positions, can be found >> here: >> > > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >> >> > > >> > > >> > > >> > > ------------------------------------------------------------ >> ---------- >> > > COMMENT: >> > > ------------------------------------------------------------ >> ---------- >> > > >> > > High level comment: >> > > Maybe extend the security section a bit and describe what can >> happen in >> > > the worse case if the value has been modified to a too high or >> too low >> > > value; and maybe even given some guidance on performing >> additional checks >> > > to figure out if a given value is reasonable for a given path or >> not. >> > > >> > > Questions: >> > > - Can you explain why PTPType, Port ID, and Sequence ID are >> needed in the >> > > PTP Sub-TLV format if those values are already in the PTP packet >> itself >> > > that follows? >> > > GIM>> We propose to copy these values as they uniquely identify >> PTP >> control message as these are required for two-step mode and suggesti= ng >> inspection of the PTP payload would cause layer violation. >> > >> > I see. Maybe add a sentence that these field are use to identify t= he >> packet. However, when you copy them, you also have to inspect the >> payload >> and that=E2=80=99s the same layer violation. Also not sure if duplic= ating >> information in the packet is the best approach. Why don=E2=80=99t us= e just >> add an >> own identifier to the packet instead? >> > GIM2>> Will the following, when added at the very end of Section >> 3.1, work: >> > Tuple of PTPType, Port ID, and Sequence ID uniquely identifies >> PTP >> > control packet encapsulated in RTM message and are used in >> two-step >> > RTM mode Section 2.1.1. >> > >> > GIM2>> The RTM message created by egress or the first on the LSP >> two-step RTM node. Thus other RTM nodes don't need to look into PTP >> control message but use the PTP sub-TLV. Creating new identifier is >> certainly an alternative but I believe that will require more state >> coordination between LERs on the same RTM LSP. Re-using existing >> characteristic information, in my view, is simpler solution. >> >> Yes the new text helps. I don=E2=80=99t see why there is any more co= ordination >> needed if you use an identifier. If you are in two-step mode, you >> simply >> remember the identifier of the packet that you use to measurement >> together with your measurement and wait for the next packet with the >> same >> identifier. I don=E2=80=99t think that=E2=80=99s any different than = using the PTP >> information as identifier. Anyway that=E2=80=99s not an big issue. >> >> > >> > > >> > > - Why is it necessary to define PTP sub-TLV (and have a registry >> for one >> > > value only)? Are you expecting to see more values here? What >> would those >> > > values be? >> > > GIM>> We may have another protocols or applications to use RTM >> and these the most likely will have their specific set of parameters to >> uniquely identify control session for two-step mode. One obvious case wo= uld >> be NTP when on-path support is defined. But since we don't know which >> parameters will uniquely identify cotrol session we don't request code >> point allocation. >> > >> > My understanding was that a new protocol would be a different RTM >> TLV in the registry in section 7.2. That=E2=80=99s fine. I don=E2=80=99t= understand why >> your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec = 7.3. >> > GIM2>> RTM TLV differentiates between different encapsulation >> types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you s= ee >> this as a problem? >> >> I still don=E2=80=99t fully understand this. You can use the same su= b-TLV >> even if >> that sub-TLV is not extensible. All I=E2=80=99m saying is that I don= =E2=80=99t >> understand >> why the sub-TLV in figure 2 has again a type and a value. I don=E2= =80=99t >> think >> those two field are needed. >> >> > >> > > - Similar to Spencer's question: Why don't you also define a >> Sub-TLV >> > > format for NTP? >> > > GIM>>Hope that above answer addresses this question. >> > >> > Actually not really. Why don=E2=80=99t you know which parameters t= o use? >> > >> > > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field >> with >> > > values >> > > defined as follows: >> > > * 0b001..." >> > > Maybe I don't understand what a bit-map field is here but thes= e >> are >> > > more then 3 bits...? >> > > GIM>> '0b' identifies binary format as '0x' identifies hexadecim= al >> format of notation. >> > Ah sorry, fully overview that. >> > >> > > - also sec 4.3.: "Value contains variable number of bit-map >> fields so >> > > that overall >> > > number of bits in the fields equals Length * 8." >> > > However there is no field 'Value' in the figure... >> > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 = to >> add Value tag on the field immediately following RTM field. >> > >> > There are more questions here: >> > >> > > Also the following >> > > explanation about future bit-maps is really confusing to me; why >> don't >> > > you just say that the rest as indicated by the length field must >> be >> > > padded with zeros...? >> > GIM2>> The description follows RFC 7794 Section 2.1 >> > > - Should section 4.8 maybe be a subsection of 4.7? This part >> confused me >> > > a bit because the example seems to be generic but the rest is >> RSVP-TE >> > > specific, right? Maybe move the example as a separate section >> before or >> > > after the whole section 4...? >> > GIM2>> Thank you, I agree it is more logical flow. With the change >> suggested by Ben it will look like this: >> > 4. Control Plane Theory of Operation . . . . . . . . . . . . . >> . 10 >> > 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . >> . 10 >> > 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . >> . 11 >> > 4.3. RTM Capability Advertisement in Routing Protocols . . . >> . 11 >> > 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . >> . 11 >> > 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . >> . 13 >> > 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . >> . 13 >> > 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . >> . 13 >> > 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . >> . 14 >> > 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . >> . 15 >> > >> > > >> > > Nits: >> > > - Maybe change to title to: Residence Time Measurement (RTM) in >> MPLS >> > > network >> > > - There are (still) some not spelled out abbreviations (LDP, PW)= ; >> > > GIM>> Since both are used only once - expanded >> > > in turn >> > > others are extended twice (e.g. PTP)... >> > > GIM>> Cleaned. >> > > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe als= o >> > > indicate it as optional in the figure: Sub-TLV (optional) >> > > GIM>> Agree >> > > >> > >> > >> >> >> --001a11c10e5e7f8115054a275b66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja, et. al,
I've uploaded the upd= ate to the draft. We've done our best to address your many comments.

Kind regards,
Greg

On Tue, Mar 7, 2017 at 5:26= AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
=
Still not convinced because you can just use= an new RTM TLV for this case.

On 06.03.2017 23:58, Greg Mirsky wrote:
Hi Mirja,
we use sub-TLV in Figure 2 as future proofing approach in case someone may<= br> need to define different sub-TLV that MUST precede the PTP packet.
Would you agree that it is reasonable design choice?

Regards,
Greg

On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net
<mailto:ietf@ku= ehlewind.net>> wrote:

=C2=A0 =C2=A0 Hi Greg,

=C2=A0 =C2=A0 two quick replies below.

=C2=A0 =C2=A0 Mirja

=C2=A0 =C2=A0 > Am 03.03.2017 um 20:10 schrieb Greg Mirsky <gregimirsky@gmail.com
 =C2=A0 =C2=A0 <mailto:gregimirsky@gmail.com>>:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Mirja,
=C2=A0 =C2=A0 > thank you for your comments and very helpful discussion.= My notes
=C2=A0 =C2=A0 in-lined and now tagged with GIM2>>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards,
=C2=A0 =C2=A0 > Greg
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF)<= br> =C2=A0 =C2=A0 <= ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
=C2=A0 =C2=A0 > Hi Greg,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > see inline.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Mirja
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky <gregimirsky@gmail.co= m
 =C2=A0 =C2=A0 <mailto:gregimirsky@gmail.com>>:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Hi Mirja,
=C2=A0 =C2=A0 > > thank your for the review and the comments, most he= lpful.
=C2=A0 =C2=A0 > > Please find my answers in-line tagged GIM>>.<= br> =C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Regards,
=C2=A0 =C2=A0 > > Greg
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja K=C3=BChlewin= d <ietf@kuehlew= ind.net
=C2=A0 =C2=A0 <mailto:ietf@kuehlewind.net>> wrote:
=C2=A0 =C2=A0 > > Mirja K=C3=BChlewind has entered the following ball= ot position for
=C2=A0 =C2=A0 > > draft-ietf-mpls-residence-time-14: No Objectio= n
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > When responding, please keep the subject line intac= t and reply to all
=C2=A0 =C2=A0 > > email addresses included in the To and CC lines. (F= eel free to cut this
=C2=A0 =C2=A0 > > introductory paragraph, however.)
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Please refer to
=C2=A0 =C2=A0 https://www.ietf.org/iesg/sta= tement/discuss-criteria.html
=C2=A0 =C2=A0 <https://www.ietf.org/iesg= /statement/discuss-criteria.html>
=C2=A0 =C2=A0 > > for more information about IESG DISCUSS and COMMENT= positions.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > The document, along with other ballot positions, ca= n be found here:
=C2=A0 =C2=A0 > > https://data= tracker.ietf.org/doc/draft-ietf-mpls-residence-time/
=C2=A0 =C2=A0 <https://datatracke= r.ietf.org/doc/draft-ietf-mpls-residence-time/>
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > ----------------------------------------------= ------------------------
=C2=A0 =C2=A0 > > COMMENT:
=C2=A0 =C2=A0 > > ----------------------------------------------= ------------------------
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > High level comment:
=C2=A0 =C2=A0 > > Maybe extend the security section a bit and describ= e what can happen in
=C2=A0 =C2=A0 > > the worse case if the value has been modified to a = too high or too low
=C2=A0 =C2=A0 > > value; and maybe even given some guidance on perfor= ming additional checks
=C2=A0 =C2=A0 > > to figure out if a given value is reasonable for a = given path or not.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Questions:
=C2=A0 =C2=A0 > > - Can you explain why PTPType, Port ID, and Sequenc= e ID are needed in the
=C2=A0 =C2=A0 > > PTP Sub-TLV format if those values are already in t= he PTP packet itself
=C2=A0 =C2=A0 > > that follows?
=C2=A0 =C2=A0 > > GIM>> We propose to copy these values as they= uniquely identify PTP
=C2=A0 =C2=A0 control message as these are required for two-step mode and s= uggesting
=C2=A0 =C2=A0 inspection of the PTP payload would cause layer violation. =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I see. Maybe add a sentence that these field are use to = identify the
=C2=A0 =C2=A0 packet. However, when you copy them, you also have to inspect= the payload
=C2=A0 =C2=A0 and that=E2=80=99s the same layer violation. Also not sure if= duplicating
=C2=A0 =C2=A0 information in the packet is the best approach. Why don=E2=80= =99t use just add an
=C2=A0 =C2=A0 own identifier to the packet instead?
=C2=A0 =C2=A0 > GIM2>> Will the following, when added at the very = end of Section 3.1, work:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Tuple of PTPType, Port ID, and Sequence ID = uniquely identifies PTP
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 control packet encapsulated in RTM message = and are used in two-step
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 RTM mode Section 2.1.1.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > GIM2>> The RTM message created by egress or the fi= rst on the LSP
=C2=A0 =C2=A0 two-step RTM node. Thus other RTM nodes don't need to loo= k into PTP
=C2=A0 =C2=A0 control message but use the PTP sub-TLV. Creating new identif= ier is
=C2=A0 =C2=A0 certainly an alternative but I believe that will require more= state
=C2=A0 =C2=A0 coordination between LERs on the same RTM LSP. Re-using exist= ing
=C2=A0 =C2=A0 characteristic information, in my view, is simpler solution.<= br>
=C2=A0 =C2=A0 Yes the new text helps. I don=E2=80=99t see why there is any = more coordination
=C2=A0 =C2=A0 needed if you use an identifier. If you are in two-step mode,= you simply
=C2=A0 =C2=A0 remember the identifier of the packet that you use to measure= ment
=C2=A0 =C2=A0 together with your measurement and wait for the next packet w= ith the same
=C2=A0 =C2=A0 identifier. I don=E2=80=99t think that=E2=80=99s any differen= t than using the PTP
=C2=A0 =C2=A0 information as identifier. Anyway that=E2=80=99s not an big i= ssue.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > - Why is it necessary to define PTP sub-TLV (and ha= ve a registry for one
=C2=A0 =C2=A0 > > value only)? Are you expecting to see more values h= ere? What would those
=C2=A0 =C2=A0 > > values be?
=C2=A0 =C2=A0 > > GIM>> We may have another protocols or applic= ations to use RTM and these the most likely will have their specific set of= parameters to uniquely identify control session for two-step mode. One obv= ious case would be NTP when on-path support is defined. But since we don= 9;t know which parameters will uniquely identify cotrol session we don'= t request code point allocation.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > My understanding was that a new protocol would be a diff= erent RTM TLV in the registry in section 7.2. That=E2=80=99s fine. I don=E2= =80=99t understand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 = and registry in sec 7.3.
=C2=A0 =C2=A0 > GIM2>> RTM TLV differentiates=C2=A0 between differ= ent encapsulation types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn'= t have to. Do you see this as a problem?

=C2=A0 =C2=A0 I still don=E2=80=99t fully understand this. You can use the = same sub-TLV even if
=C2=A0 =C2=A0 that sub-TLV is not extensible. All I=E2=80=99m saying is tha= t I don=E2=80=99t understand
=C2=A0 =C2=A0 why the sub-TLV in figure 2 has again a type and a value. I d= on=E2=80=99t think
=C2=A0 =C2=A0 those two field are needed.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > - Similar to Spencer's question: Why don't = you also define a Sub-TLV
=C2=A0 =C2=A0 > > format for NTP?
=C2=A0 =C2=A0 > > GIM>>Hope that above answer addresses this qu= estion.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Actually not really. Why don=E2=80=99t you know which pa= rameters to use?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > - sec 4.3: "RTM (capability) - is a three-bit = long bit-map field with
=C2=A0 =C2=A0 > > values
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0defined as follows:
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 0b001..." =C2=A0 =C2=A0 > >=C2=A0 =C2=A0Maybe I don't understand what a bit= -map field is here but these are
=C2=A0 =C2=A0 > > more then 3 bits...?
=C2=A0 =C2=A0 > > GIM>> '0b' identifies binary format a= s '0x' identifies hexadecimal
=C2=A0 =C2=A0 format of notation.
=C2=A0 =C2=A0 > Ah sorry, fully overview that.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > - also sec 4.3.: "Value contains variable numb= er of bit-map fields so
=C2=A0 =C2=A0 > > that overall
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0number of bits in the fie= lds equals Length * 8."
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0However there is no field 'Value= 9; in the figure...
=C2=A0 =C2=A0 > > GIM>> Thank you for pointing. I'll update= Figure 4 and Figure 5 to
=C2=A0 =C2=A0 add Value tag on the field immediately following RTM field. =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > There are more questions here:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > Also the following
=C2=A0 =C2=A0 > > explanation about future bit-maps is really confusi= ng to me; why don't
=C2=A0 =C2=A0 > > you just say that the rest as indicated by the leng= th field must be
=C2=A0 =C2=A0 > > padded with zeros...?
=C2=A0 =C2=A0 > GIM2>> The description follows RFC 7794 Section 2.= 1
=C2=A0 =C2=A0 > > - Should section 4.8 maybe be a subsection of 4.7? = This part confused me
=C2=A0 =C2=A0 > > a bit because the example seems to be generic but t= he rest is RSVP-TE
=C2=A0 =C2=A0 > > specific, right? Maybe move the example as a separa= te section before or
=C2=A0 =C2=A0 > > after the whole section 4...?
=C2=A0 =C2=A0 > GIM2>> Thank you, I agree it is more logical flow.= With the change
=C2=A0 =C2=A0 suggested by Ben it will look like this:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 4.=C2=A0 Control Plane Theory of Operation = . . . . . . . . . . . . . .=C2=A0 10
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 4.1.=C2=A0 RTM Capability=C2=A0 . . = . . . . . . . . . . . . . . . . . . .=C2=A0 10
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 4.2.=C2=A0 RTM Capability Sub-TLV=C2= =A0 . . . . . . . . . . . . . . . . .=C2=A0 11
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 4.3.=C2=A0 RTM Capability Advertisem= ent in Routing Protocols . . . .=C2=A0 11
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.1.=C2=A0 RTM Capability A= dvertisement in OSPFv2=C2=A0 . . . . . . .=C2=A0 11
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.2.=C2=A0 RTM Capability A= dvertisement in OSPFv3=C2=A0 . . . . . . .=C2=A0 13
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.3.=C2=A0 RTM Capability A= dvertisement in IS-IS . . . . . . . .=C2=A0 13
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.3.4.=C2=A0 RTM Capability A= dvertisement in BGP-LS=C2=A0 . . . . . . .=C2=A0 13
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 4.4.=C2=A0 RSVP-TE Control Plane Ope= ration to Support RTM=C2=A0 . . . . .=C2=A0 14
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.4.1.=C2=A0 RTM_SET TLV . . = . . . . . . . . . . . . . . . . . . .=C2=A0 15
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Nits:
=C2=A0 =C2=A0 > > - Maybe change to title to: Residence Time Measurem= ent (RTM) in MPLS
=C2=A0 =C2=A0 > > network
=C2=A0 =C2=A0 > > - There are (still) some not spelled out abbreviati= ons (LDP, PW);
=C2=A0 =C2=A0 > > GIM>> Since both are used only once - expande= d
=C2=A0 =C2=A0 > > in turn
=C2=A0 =C2=A0 > > others are extended twice (e.g. PTP)...
=C2=A0 =C2=A0 > > GIM>>=C2=A0 Cleaned.
=C2=A0 =C2=A0 > > - In figure 1, I would rename 'Value' to &#= 39;Sub-TLV' and maybe also
=C2=A0 =C2=A0 > > indicate it as optional in the figure: Sub-TLV (opt= ional)
=C2=A0 =C2=A0 > > GIM>> Agree
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >



--001a11c10e5e7f8115054a275b66-- From nobody Tue Mar 7 09:39:05 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B891295CD; Tue, 7 Mar 2017 09:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiINMGMQ4Yaf; Tue, 7 Mar 2017 09:38:57 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90E41295C6; Tue, 7 Mar 2017 09:38:57 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id 2so5529538oif.0; Tue, 07 Mar 2017 09:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BTggiW930pcdDymarh0DSBG4sa++XTgQKflMMFPcx5Q=; b=j06hqAYRtGw60JSAQ07tQUps7CSjHL91msPWniZAaoQfrnBK6sJmlPPgwYP418zWja BD+WwX03o7RLB2t7RXZa6TplVyodqLdzZkCOJUCNE/SEhLFOIBy8MN41FoLgvh+QNoad AQSam9Jau3ev6rdyZvp3235TC9wmYIMS3vXxx5i/L9Vhy8hTIsp/vbUxWv97/KrBiBOA 9UgYPYucU9OSZf3QioxM2yLN9gF8CtixswFNmw3GZvKK7+mnV60usrlIudtPxDPJ3sEX RynbzAq9IlKmLWOKVUW31B0AzOT8Dknfr4+Sst40kGIatw0gQljZQf6F7X9a+QQz0ik6 1xhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BTggiW930pcdDymarh0DSBG4sa++XTgQKflMMFPcx5Q=; b=PrrKlVfYVZ1T762YcmeYbLdq5QxRTKFqgXtuxvJ1D9TBMnMErAgr1FM/okWxmXJlpK 5E2jLNwUTapr/B3Lp3uf9/2u4lN92TUS4lDgV2ZSetllrBqTVo3A3n1Eo0rOKpk0jrcj 0wphqvzh/fJrGv5C5APvNrJsDhSbivq9bRc8qsVLuj+wDcBCy6rfrlB8S+jUBwly/gR/ G5XRO3M+lM0G7unbveWbfN27lM0azEsfwQQEOqE/kuheXUFm4Seq4zx7GNZUjZwLHsDz 65ttf8ZGLYPdSVP2izLXwaqLQFTA5/GNh2lE91bheHuBIj/8L/WcfVABop7Nh+LZOemL rtxQ== X-Gm-Message-State: AMke39mvOlXD53F/4z29QVSRYklFh9NvQSi1Y2I0FjgoLUoY3eUrx7ngx81vlzVMzQaQOnh7B1O5iJAQMCh1Bw== X-Received: by 10.202.181.135 with SMTP id e129mr945921oif.124.1488908337135; Tue, 07 Mar 2017 09:38:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 7 Mar 2017 09:38:56 -0800 (PST) In-Reply-To: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> References: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 7 Mar 2017 09:38:56 -0800 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a113cbe4c89caba054a277c7c Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:39:00 -0000 --001a113cbe4c89caba054a277c7c Content-Type: text/plain; charset=UTF-8 Hi Ben, et.al, we've published the new version of the draft. It includes changes to address your comments and many others. Hope I haven't missed any. Regards, Greg On Wed, Mar 1, 2017 at 3:16 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-mpls-residence-time-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have no objection, but do have some a few minor comments: > > Substantive: > > -2.1, 4th paragraph from end: Can you offer guidance on what might > constitute a reasonably bound wait time?\ > > -2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of > that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same > message? > > Editorial: > - Abstract: The last paragraph is a single, long sentence. Please > consider breaking it into simpler sentences. > > - 2.1, paragraph 9: "This bit, once it is set by a two- > step mode device, MUST stay set accordingly": Can that MUST be stated > in process terms? That is, MUST NOT unset this bit..." > > -2.1, paragraph 11: "Without loss of generality should note > that handling of Sync event messages..." : I don't follow the > sentence; are words missing and/or out of order? > -- "Following outlines handling of PTP Sync event message by the two-step > RTM node.": I think there's a missing "the" at the start. It's absence > completely changes the meaning of "following outlines"-- as written it > seem like the verb is "following", but I think you mean it to be > "outlines". > -- I have trouble matching some pronouns to their antecedents in the rest > of the paragraph. > > > --001a113cbe4c89caba054a277c7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben, et.al,
we've published the new version of the draft. It includes changes to a= ddress your comments and many others. Hope I haven't missed any.
<= div>
Regards,
Greg

On Wed, Mar 1, 2017 at 3:16 PM, Ben Ca= mpbell <ben@nostrum.com> wrote:
Ben Campbell has entered the following ballot position for
draft-ietf-mpls-residence-time-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I have no objection, but do have some a few minor comments:

Substantive:

-2.1, 4th paragraph from end: Can you offer guidance on what might
constitute a reasonably bound wait time?\

-2.1, 2nd paragraph from end: "... MUST NOT do both": What's = the scope of
that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same
message?

Editorial:
- Abstract: The last paragraph is a single, long sentence. Please
consider breaking it into simpler sentences.

- 2.1, paragraph 9: "This bit, once it is set by a two-
=C2=A0 =C2=A0step mode device, MUST stay set accordingly": Can that MU= ST be stated
in process terms? That is, <actors>=C2=A0 MUST NOT unset this bit...&= quot;

-2.1, paragraph 11:=C2=A0 "Without loss of generality should note
=C2=A0 =C2=A0that handling of Sync event messages..." : I don't fo= llow the
sentence; are words missing and/or out of order?
-- "Following outlines handling of PTP Sync event message by the two-s= tep
RTM node.": I think there's a missing "the" at the start= . It's absence
completely changes the meaning of "following outlines"-- as writt= en it
seem like the verb is "following", but I think you mean it to be<= br> "outlines".
-- I have trouble matching some pronouns to their antecedents in the rest of the paragraph.



--001a113cbe4c89caba054a277c7c-- From nobody Tue Mar 7 09:42:53 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440771295CD; Tue, 7 Mar 2017 09:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kuJv9yBue6s; Tue, 7 Mar 2017 09:42:48 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7421295C6; Tue, 7 Mar 2017 09:42:48 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id m124so5606211oig.1; Tue, 07 Mar 2017 09:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wC94ppULDsfS04M0UwgAn4d4fBDWK8Q5JysW/WTC9l8=; b=goxmemTqqUnYAXx3us9PV1MIWaYCIgSS53Kbz8KPYHTQco2FeYwisjrIZT7u+hbLEJ bFuKi7OKGG8K6DTGOPzHv08AdxAaCryErBkgEMGTouNyLl5tsKwwwmxnf001awKl08th SBNSvHvpY0UilXrrv4wltYkb6FsliUOunWuXq910fH5vnFo/jPx7efYdPBOh/Bzxow13 35ySkaqGhZUYYguzhZ1NkdwYrytZva3C66VcTnZwfjfq8j5jPVpcCjnIiQLdIg2x7Gf8 KBmMa2HXhek507SWWtI33KGOzqvbWyc96XJr8vdLtjXaJc52boODf7j/rJHsM0cbI+nC K+Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wC94ppULDsfS04M0UwgAn4d4fBDWK8Q5JysW/WTC9l8=; b=Tou5uYEabkzBL3u3OxluwA9wrasNXNO1f5pI2MHTjIXV1ny2L7UfKtgpZjiX5q4/RS /MIYMHQ/Nrywog6WP6mbXRe0DQmd8jpKRHcRr6p1bHHts7KbBwLdc2s959SDIphLlrmS 1C5kvZptrfecHwPDd/kFmam5vrX+U8zkQZTuxfDavdYa3Gjzxt0GX5FtR+U1uKMTsYi6 XMvpTitJm5xkYVSg8l8OwTWhZt5DiYGadCbrMoPlrpnl+r1uRzY5ypp30t49p10e7hr8 ipIurJyCMjb9KaJVIM2Nw/5vtOxGldST/PCBiyjFtaJGbvRJ65sQNm5yseY3sCkexJ51 F/Dw== X-Gm-Message-State: AMke39kSNk/5/Q+IBwOOqtSJJHLI03j8yV2Ln+5VQcbF/JH4wXNCzSpIHQwfakLA77jxf1bsxuNZFl6CsC/pdg== X-Received: by 10.202.236.140 with SMTP id k134mr828295oih.123.1488908567414; Tue, 07 Mar 2017 09:42:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 7 Mar 2017 09:42:46 -0800 (PST) In-Reply-To: References: <148814606376.2949.10868917655692470857.idtracker@ietfa.amsl.com> <48E1A67CB9CA044EADFEAB87D814BFF64A9FEEF5@eusaamb107.ericsson.se> From: Greg Mirsky Date: Tue, 7 Mar 2017 09:42:46 -0800 Message-ID: To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a1134fc3e439465054a278aee Archived-At: Cc: draft-ietf-mpls-residence-time@ietf.org, Alexander Vainshtein , mpls-chairs@ietf.org, "iesg@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:42:51 -0000 --001a1134fc3e439465054a278aee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Spencer, I've uploaded the new version of the draft. It includes changes we've discussed as well as to address comments from Alia, Mirja, Ben, and Benjamin. I hope that I haven't missed anything. Regards, Greg On Mon, Feb 27, 2017 at 1:36 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Keeping in mind that these are non-blocking comments (so, do the right > thing) ... > > > On Feb 27, 2017 14:53, "Alexander Vainshtein" > wrote: > > Spencer and all, > I concur with Eric. > > The RTM mechanism defined in this spec does not depend on the protocol - > NPT, PTP or something else - that is carried over an LSP. > > > Right, and the Introduction starts out that way, but the Abstract calls > out PTP specifically, and a quick string search turns up 4 "NTP" strings > and 70 "PTP" strings in the document (counting the table of contents but > you get the idea). That's probably what misled me. > > But the good news is that I'm not likely to be your typical reader ;-) > > Thanks, > > Spencer > > However, PTP by design can use the information about accummulated on-path > delay (the Correction field in its PDUs has been defined for just this > purpose), while NTP, in its present form, cannot do that. > > If/when the NTP spec is updated so that it can use measured on-path delay= , > it would be able to benefit from RTM as well - as I see it, without any > substantial changes to this spec. > > Hopefully this helps. > > My 2c, > Sasha > > On Feb 27, 2017 21:41, "Eric Gray" wrote: > > Spencer, > > > > While the reference to NTP is forward looking (as Greg > suggested) =E2=80=93 there is no strong reason to suspect that additional= work > relative to this specification will _*necessarily*_ be required. > > > > Transparent Clock (again as Greg mentioned) has not yet been defined for > NTP. > > > > The essential element of transparent clock is that there > needs to be a way to determine the amount of time a message spends at eac= h > hop (this is the variable component of delay for any given path) so that > this delay can be corrected for. The more hops for which you have this > information, the more accurate the corrected time values will be. > > > > If you can determine the variable delay experienced by a > time message, you can combine this information with the measurable fixed > delay (associated mostly with light-speed delays) to provide a very preci= se > corrected time value. > > > > Transparent Clock is quite elegant in that sense, as long > as it can be done without layer-violations. J > > > > -- > > Eric > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* Monday, February 27, 2017 12:47 PM > *To:* Greg Mirsky > *Cc:* iesg@ietf.org; draft-ietf-mpls-residence-time@ietf.org; Loa > Andersson ; mpls-chairs@ietf.org; mpls@ietf.org > *Subject:* Re: Spencer Dawkins' No Objection on > draft-ietf-mpls-residence-time-14: (with COMMENT) > > > > Hi, Greg, > > > > On Feb 27, 2017 11:13, "Greg Mirsky" wrote: > > Hi Spencer, > > yes, only PTP has defined operation of the transparent clock and how to > use the residence time to improve accuracy of distributed time. > > > > (Remembering that this is a no-blocking comment) > > > > I'd suggest removing the text reference to NTP in the Introduction, and > mentioning that you're allocating the value for NTP in Section 7.2, but > that NTP can't make use of this mechanism unless it adds support for > transparent clock. > > > > Does that make sense? > > > > Spencer > > > > Regards, > > Greg > > > > On Mon, Feb 27, 2017 at 9:06 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Greg, > > > > On Feb 27, 2017 09:55, "Greg Mirsky" wrote: > > Hi Spencer, > > thank you for your thorough review and the question. > > NTP yet doesn't use transparent clock paradigm but in section 3 G-ACh for > Residence Time Measurement we've noted that NTP may be one type of TLV an= d > have requested appropriate allocation by IANA in the new sub-registry MPL= S > RTM TLV Registry (section 7.2). Thus, if NTP will be enhanced to use > transparent clock, the RTM over MPLS will be capable to support it. > > We're open to your suggestions to make it clearer. > > > > So, is it correct to say that PTP is the only time protocol that uses the > transparent clock paradigm today? > > > > Spencer > > > > Kind regards, > > Greg > > > > On Sun, Feb 26, 2017 at 1:54 PM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > Spencer Dawkins has entered the following ballot position for > draft-ietf-mpls-residence-time-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a bit confused on one point. There's one reference to NTP in the > Introduction, everything else is about PTP, but the specification never > actually says if this mechanism is intended to be usable for NTP as well. > Could that be clearer? > > > > > > > > > > > > --001a1134fc3e439465054a278aee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Spencer,
I've uploaded the new versi= on of the draft. It includes changes we've discussed as well as to addr= ess comments from Alia, Mirja, Ben, and Benjamin. I hope that I haven't= missed anything.

Regards,
Greg

On Mon, Feb 27= , 2017 at 1:36 PM, Spencer Dawkins at IETF <spencerdawkins.iet= f@gmail.com> wrote:
Keeping in mind that these are non-blocking comments (so, do the= right thing) ...


On Feb 27, 2017 14:53, "Alexander Vainshtein" &l= t;vainshtein= .alex@gmail.com> wrote:
Spencer and all,
I concur with Eric.

The RTM mechanism defined in this spec does not depend on the protoco= l - NPT, PTP or something else - that is carried over an LSP.
<= /blockquote>

Right, and the Introduction starts out that way, but the Abstract= calls out PTP specifically, and a quick string search turns up 4 "NTP= " strings and 70 "PTP" strings in the document (counting the= table of contents but you get the idea). That's probably what misled m= e.

But the good news is = that I'm not likely to be your typical reader ;-)

Thanks,

Spencer

=
However, PTP by design can use the information about accummul= ated on-path delay (the Correction field in its PDUs has been defined for j= ust this purpose), while NTP, in its present form, cannot do that.

If/when the NTP spec is updated = so that it can use measured on-path delay, it would be able to benefit from= RTM as well - as I see it, without any substantial changes to this spec.

Hopefully this helps.=C2= =A0

My 2c,
Sasha

On Feb 27, 2017 21:41, "Eric Gray" <eric.gray@ericsson.com> wrote:<= br type=3D"attribution">

Spencer,

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 While the reference to NTP is forwa= rd looking (as Greg suggested) =E2=80=93 there is no strong reason to suspe= ct that additional work relative to this specification will _necessarily_ be required.=C2=A0

=C2=A0

Transparent Clock (again = as Greg mentioned) has not yet been defined for NTP.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The essential element of transparen= t clock is that there needs to be a way to determine the amount of time a m= essage spends at each hop (this is the variable component of delay for any given path) so that this delay can be corrected= for.=C2=A0 The more hops for which you have this information, the more acc= urate the corrected time values will be.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If you can determine the variable d= elay experienced by a time message, you can combine this information with t= he measurable fixed delay (associated mostly with light-speed delays) to provide a very precise corrected time value.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Transparent Clock is quite elegant = in that sense, as long as it can be done without layer-violations.=C2=A0 J<= u>

=C2=A0

--

Eric

=C2=A0

From: Spencer Dawkins at IETF [mailto:spencerdaw= kins.ietf@gmail.com]
Sent: Monday, February 27, 2017 12:47 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: iesg@ietf.org= ; draft-ietf-mpls-residence-time@ietf.org; Loa Andersson <= ;loa@pi.nu>; mpls-chairs@ietf.org= ; mpls@ietf.org
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-mpls-re= sidence-time-14: (with COMMENT)

=C2=A0

Hi, Greg,

=C2=A0

On Feb 27, 2017 11:13, "Greg Mirsky" <<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com> wrote:

Hi Spencer,

yes, only PTP has defined operation of the transpare= nt clock and how to use the residence time to improve accuracy of distribut= ed time.

=C2=A0

(Remembering that this is a no-blocking comment)<= /u>

=C2=A0

I'd suggest removing the text reference to NTP i= n the Introduction, and mentioning that you're allocating the value for= NTP in Section 7.2, but that NTP can't make use of this mechanism unle= ss it adds support for transparent clock.

=C2=A0

Does that make sense?

=C2=A0

Spencer

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 27, 2017 at 9:06 AM, Spencer Dawkins at = IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Greg,

=C2=A0

On Feb 27, 2017 09:55, "Greg Mirsky" <<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com> wrote:

Hi Spencer,

thank you for your thorough review and the question.=

NTP yet doesn't use transparent clock paradigm b= ut in section 3=C2=A0G-ACh for Residence Time Measure= ment we've noted that NTP may be one type of TLV and have requested appropriate allocation by IANA in the new sub-registry=C2=A0MPLS RTM TLV R= egistry (section 7.2). Thus, if NTP will be enhanced to use transparent clo= ck, the RTM over MPLS will be capable to support it.

We're open to your suggest= ions to make it clearer.

=C2=A0

So, is it correct to say that PTP is the only time p= rotocol that uses the transparent clock paradigm today?

=C2=A0=

Spencer

=C2=A0

Kind regards,

Greg

=C2=A0

On Sun, Feb 26, 2017 at 1:54 PM, Spencer Dawkins <= ;spencer= dawkins.ietf@gmail.com> wrote:

Spencer Dawkins has ent= ered the following ballot position for
draft-ietf-mpls-residence-time-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-r= esidence-time/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I'm a bit confused on one point. There's one reference to NTP in th= e
Introduction, everything else is about PTP, but the specification never
actually says if this mechanism is intended to be usable for NTP as well. Could that be clearer?

=C2=A0

=C2=A0

=C2=A0

=C2=A0




--001a1134fc3e439465054a278aee-- From nobody Tue Mar 7 09:49:45 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4DC1295FC; Tue, 7 Mar 2017 09:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOyH4FWoavKH; Tue, 7 Mar 2017 09:49:41 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC5F1295EE; Tue, 7 Mar 2017 09:49:41 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id 62so5779571oih.2; Tue, 07 Mar 2017 09:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VL9y1zkszBFDXhYmT1zz5L7+RhnQXsmpD791i2vGOQQ=; b=M0NB1WK4ZRBcVM5FAu5ztC5gqs9y8L8qWHJVpx5Y826o+0IFbN2x33g/eXzDyPSZI+ EcYIuBzllId4peJXywAuEWO2k3qiUIVDQjHZJP5OYoQnnReLHx4c8XDG8hJG4VNpkzGD bS6kSY6B/lc8QbipUQduXhHJB76aAPoVegPc1IlHKAiXzQt17ID8LqW248jdISG3vvZz Y6N4ZHrOIwYUARkDLT+oDcg3qq8iaTWvRuDlzSqox7DKUKhhnU0/6RYbhUD1TN0e8xJO 6nND+Ld2wut97d2rxBrLNmZggxEwfeJX7fDoEZHMwiHeINn6Y5swqZyhrj1Fj+THiU7Z ImmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VL9y1zkszBFDXhYmT1zz5L7+RhnQXsmpD791i2vGOQQ=; b=hNAXell5OUqzB5Lff8fdliRb2ffwEThE2oQYrlyp2u9saExBiYg4TPhj8Ihpi/sEa3 tX/gBXdDpXjuJoNZKWwdH3NmJOesz5QQJsakl/D4GV0C8Uvr5NLyCm+zh4o8ONiHTaCi pXmQCAdPnelKSQWZ4J/gJICwjvn5XcLyWP3/IF2ai/PqPBHXQKg+gjFs2VoW0J8CKqvh kEdbQNtjsvAVT9ecywdBUpuxlaQtpSA4jfTBPI6GT/xtY3roeD5EN5AFwKtcvCq8weUK 9qcc264YfL2PPjSQTwiwblbF+ogeo1awp3D2i7cUE1stL/8vwcNIG5YEc5gnxbWSuU4m FpOg== X-Gm-Message-State: AMke39lzQp/wc82XgjpFfuNrkh567Ly/5v24oiwCk3+VUYqxSPWff0gAwex17sHyA1Glea46PLgOGV+A/6/PxA== X-Received: by 10.202.232.210 with SMTP id f201mr842675oih.60.1488908980652; Tue, 07 Mar 2017 09:49:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 7 Mar 2017 09:49:40 -0800 (PST) In-Reply-To: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> References: <148840955223.7128.11294700301996460693.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 7 Mar 2017 09:49:40 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11407b32e51611054a27a237 Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" , The IESG Subject: Re: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:49:43 -0000 --001a11407b32e51611054a27a237 Content-Type: text/plain; charset=UTF-8 Hi Alia, et. al, the new version of the draft has been uploaded. It includes the changes we've discussed as well as addresses comments we've received from Mirja, Spencer, Ben, and Benjamin. Thank you for your help and patience. Regards, Greg On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-mpls-residence-time-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for a clear document. I think that this should be a > straightforward Discuss to better clarify. > > In Section 4.8.1, it says "The RTM Set sub-object contains an ordered > list, from egress node to > ingress node, of the RTM capable nodes along the LSP's path." but the > sub-TLVs (as most clearly > indicated by "4.8.1.3. Unnumbered Interface Sub-TLV" are actually meant > to be a list of interfaces. > It isn't clear whether these are supposed to be the egress interface, the > ingress interface, or just any > interface - or why sending just a Router ID wouldn't be sufficient. > There is no indication as to whether > it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same > node or how to select which one > to use. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA > isn't defined. While I understand that a normative reference isn't > desirable - instead of "left for future study", it would be better to say > that the sub-TLV should use the same format as in Sec 4.3 and that the > type allocation and full details are left to a future document. This is > exactly how gaps are created for networks running only IPv6. If > draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementations > and had a clear time-frame for how and when to progress, this would also > be a Discuss. > > > --001a11407b32e51611054a27a237 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia, et. al,
the new version of the dra= ft has been uploaded. It includes the changes we've discussed as well a= s addresses comments we've received from Mirja, Spencer, Ben, and Benja= min.
Thank you for your help and patience.

Regards,
Greg

On Wed, Mar 1, 2017 at 3:05 PM, Alia Atlas <akatlas= @gmail.com> wrote:
Alia Atl= as has entered the following ballot position for
draft-ietf-mpls-residence-time-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-mpls-residence-time/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for a clear document.=C2=A0 I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered<= br> list, from egress node to
=C2=A0 =C2=A0ingress node, of the RTM capable nodes along the LSP's pat= h." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.=C2=A0 Unnumbered Interface Sub-TLV" are ac= tually meant
to be a list of interfaces.
It isn't clear whether these are supposed to be the egress interface, t= he
ingress interface, or just any
interface - or why sending just a Router ID wouldn't be sufficient.
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same node or how to select which one
to use.


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.=C2=A0 While I understand that a normative reference isn&= #39;t
desirable - instead of "left for future study", it would be bette= r to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.=C2=A0 =C2= =A0This is
exactly how gaps are created for networks running only IPv6.=C2=A0 =C2=A0If=
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementati= ons
and had a clear time-frame for how and when to progress, this would also be a Discuss.



--001a11407b32e51611054a27a237-- From nobody Tue Mar 7 21:51:15 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B291293FD; Tue, 7 Mar 2017 21:51:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jon Mitchell To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148895226612.17662.7706011588102984090@ietfa.amsl.com> Date: Tue, 07 Mar 2017 21:51:06 -0800 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org, ietf@ietf.org Subject: [mpls] Review of draft-ietf-mpls-tp-temporal-hitless-psm-12 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 05:51:06 -0000 Reviewer: Jon Mitchell Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document is Ready with Nits. I share the concern that it's not totally clear upfront this is a requirements versus solution document. There is also not much in the way of requirements of notification or how to signal back to the operator that a fault has occurred, but this may be OK if whatever solution would meet the requirements of this draft will include such text or rely on existing mechanisms discussed in RFC6371. From nobody Wed Mar 8 00:21:16 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91557129468; Wed, 8 Mar 2017 00:21:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148896127057.26292.16175603386579709147@ietfa.amsl.com> Date: Wed, 08 Mar 2017 00:21:10 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-temporal-hitless-psm-13.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:21:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Requirements for hitless MPLS path segment monitoring Authors : Alessandro D'Alessandro Loa Andersson Satoshi Ueno Kaoru Arai Yoshinori Koike Filename : draft-ietf-mpls-tp-temporal-hitless-psm-13.txt Pages : 16 Date : 2017-03-08 Abstract: One of the most important OAM capabilities for transport network operation is fault localisation. An in-service, on-demand segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between end points. However, the current segment monitoring approach defined for MPLS (including the transport profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS- Based Transport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support a Hitless Path Segment Monitoring (HPSM). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-tp-temporal-hitless-psm-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-temporal-hitless-psm-13 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 nobody Wed Mar 8 08:45:21 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782481295B2 for ; Wed, 8 Mar 2017 08:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXvVf_nrc4Es for ; Wed, 8 Mar 2017 08:45:17 -0800 (PST) Received: from smtp28.msg.oleane.net (smtp28.msg.oleane.net [62.161.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A3129554 for ; Wed, 8 Mar 2017 08:45:16 -0800 (PST) Received: from MGosseDellM6800 (LMontsouris-656-1-5-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp28.msg.oleane.net (MSA) with ESMTP id v28GjDp2005927 for ; Wed, 8 Mar 2017 17:45:14 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: References: <001a01d29816$488c6a70$d9a53f50$@upperside.fr> <014b01d29817$0aaff860$200fe920$@upperside.fr> <003501d29817$7b941de0$72bc59a0$@upperside.fr> In-Reply-To: <003501d29817$7b941de0$72bc59a0$@upperside.fr> Date: Wed, 8 Mar 2017 17:45:12 +0100 Message-ID: <00b801d2982b$5b26f0a0$1174d1e0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01D29833.BCF03AA0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHcNVu6QaHS2dsFCqPmy6Hr9uFNpAGPsHldAhEO8ZehWr5SAA== Content-Language: fr X-Backend: vm-mx-sophos-mta67 X-PMX-Backend: PMX 6.3.1.2588712, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.3.8.163617 running on vm-mx-sophos-mta67 X-PMX-VirusScan: no virus found X-PFSI-Info: PMX 6.3.1.2588712, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.3.8.163617 (no virus found) X-PMX-Spam: Probability=11% X-PMX-SpamScan: NO 11% X X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: Subject: [mpls] MPLS + SDN + NFV World: SR Deployment Experience X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:45:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01D29833.BCF03AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One of the most important sessions of the Congress will deliver an update on the significant deployment experience across Web/OTT, SP and Large Enterprise, spanning DC, metro and WAN of Segment Routing. Hear testimonies from Bell Canada, Orange, Comcast and Microsoft. More info.: http://www.uppersideconferences.com/mpls-sdn-nfv/ ------=_NextPart_000_00B9_01D29833.BCF03AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One of the most important sessions = of the Congress will deliver an update on the significant deployment = experience across Web/OTT, SP and Large Enterprise, spanning DC, metro = and WAN of Segment Routing.

 

Hear testimonies from Bell = Canada, Orange, Comcast and Microsoft.

More info.: =  http://www.uppersideconferences.com/mpls-sdn-nfv/

------=_NextPart_000_00B9_01D29833.BCF03AA0-- From internet-drafts@ietf.org Thu Mar 9 14:30:43 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 831A3129588; Thu, 9 Mar 2017 14:30:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148909864349.5812.8705541689978006023@ietfa.amsl.com> Date: Thu, 09 Mar 2017 14:30:43 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-mtaillon-mpls-summary-frr-rsvpte-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 22:30:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels Authors : Mike Taillon Tarek Saad Rakesh Gandhi Abhishek Deshmukh Markus Jork Vishnu Pavan Beeram Filename : draft-mtaillon-mpls-summary-frr-rsvpte-05.txt Pages : 16 Date : 2017-03-09 Abstract: This document defines Resource Reservation Protocol (RSVP) Traffic- Engineering (TE) signaling extensions that reduce the amount of RSVP signaling required for Fast Reroute (FRR) procedures and subsequently improve the scalability of the RSVP-TE signaling when undergoing FRR convergence after a link or node failure. Such extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) to be independent of the number of protected Label Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mtaillon-mpls-summary-frr-rsvpte/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-mtaillon-mpls-summary-frr-rsvpte-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mtaillon-mpls-summary-frr-rsvpte-05 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 nobody Fri Mar 10 08:29:10 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 566F0129496; Fri, 10 Mar 2017 08:29:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916334631.6821.4396962017513554142@ietfa.amsl.com> Date: Fri, 10 Mar 2017 08:29:06 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-base-yang-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:29:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : A YANG Data Model for MPLS Base Authors : Tarek Saad Kamran Raza Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Himanshu Shah Igor Bryskin Xia Chen Raqib Jones Bin Wen Filename : draft-ietf-mpls-base-yang-02.txt Pages : 10 Date : 2017-03-10 Abstract: This document contains a specification of the the MPLS base YANG model. The MPLS base YANG module serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG models (e.g. MPLS LSP Static, LDP or RSVP-TE models) will augment the MPLS base YANG model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-base-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-base-yang-02 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 nobody Sat Mar 11 14:27:33 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D66E91295ED; Sat, 11 Mar 2017 14:27:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148927124886.2940.1603275986079038340@ietfa.amsl.com> Date: Sat, 11 Mar 2017 14:27:28 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rmr-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 22:27:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Resilient MPLS Rings Authors : Kireeti Kompella Luis M. Contreras Filename : draft-ietf-mpls-rmr-04.txt Pages : 14 Date : 2017-03-11 Abstract: This document describes the use of the MPLS control and data planes on ring topologies. It describes the special nature of rings, and proceeds to show how MPLS can be effectively used in such topologies. It describes how MPLS rings are configured, auto-discovered and signaled, as well as how the data plane works. Companion documents describe the details of discovery and signaling for specific protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rmr/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rmr-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rmr-04 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 nobody Sat Mar 11 20:19:48 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE976129975; Sat, 11 Mar 2017 20:19:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148929238669.2953.6429405687574394195@ietfa.amsl.com> Date: Sat, 11 Mar 2017 20:19:46 -0800 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-base-yang-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 04:19:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : A YANG Data Model for MPLS Base Authors : Tarek Saad Kamran Raza Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Himanshu Shah Igor Bryskin Xia Chen Raqib Jones Bin Wen Filename : draft-ietf-mpls-base-yang-03.txt Pages : 16 Date : 2017-03-11 Abstract: This document contains a specification of the the MPLS base YANG model. The MPLS base YANG module serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG models (e.g. MPLS LSP Static, LDP or RSVP-TE models) will augment the MPLS base YANG model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-base-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-base-yang-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 nobody Sun Mar 12 07:09:43 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9F61298B3; Sun, 12 Mar 2017 07:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM9Z7PixD1fM; Sun, 12 Mar 2017 07:09:41 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D45129A88; Sun, 12 Mar 2017 07:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=257; q=dns/txt; s=iport; t=1489327780; x=1490537380; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=oo26/39z3QrnNxd1CGeFAh2EoWJLpVvwZxGteUZKwUY=; b=Opj2qiGVjiSCdoQubYx7fNS35A7QpDyml4bbSGP1RXCy3HD0ZbmSgCP7 GhcP/+F5uNuPG8flQtuQi0sYkL09Tg2W61JcxpD8XiZpFrYKIGKOnAgNq YahLWYhZw+VJtumv+oKhPapRXvtiu66iV1y+sfviDsvWloyE0FVbP7K5C g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaBAARVsVY/xbLJq1cHAEBBAEBCgEBh?= =?us-ascii?q?DIqYINgig5zpAiCD4IOKoVuCoMCGAECAQEBAQEBAWsohT8VQTUCJgJsCAEBiXw?= =?us-ascii?q?OsUiCJopdAQEIKIELhUOCBYgKgjqCXwWcQZI5gWMBF4UlgzKGU4s1iA4fOIEEI?= =?us-ascii?q?xYIFxWHGT81AYcyK4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.36,152,1486425600"; d="scan'208";a="692934999" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2017 14:09:38 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2CE9cG7011335; Sun, 12 Mar 2017 14:09:38 GMT To: draft-ietf-mpls-base-yang@ietf.org From: Benoit Claise Message-ID: <1f8e1db6-0f76-1e9a-3b28-2b2e4a8ccdc6@cisco.com> Date: Sun, 12 Mar 2017 15:09:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Multiprotocol Label Switching Discussion List , Andy Bierman Subject: [mpls] YANG compilation issue in draft-ietf-mpls-base-yang X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 14:09:42 -0000 Dear authors, I see that you posted a new draft version. Be aware that there are some warnings regarding the validation of the YANG module. See http://www.claise.be/IETFYANGPageCompilation.html, and please correct the mistakes. Regards, Benoit From nobody Sun Mar 12 20:10:34 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C7C1294BC; Sun, 12 Mar 2017 20:10:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148937463335.24699.2581608402323494018@ietfa.amsl.com> Date: Sun, 12 Mar 2017 20:10:33 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-base-yang-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 03:10:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : A YANG Data Model for MPLS Base Authors : Tarek Saad Kamran Raza Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Himanshu Shah Igor Bryskin Xia Chen Raqib Jones Bin Wen Filename : draft-ietf-mpls-base-yang-04.txt Pages : 16 Date : 2017-03-12 Abstract: This document contains a specification of the the MPLS base YANG model. The MPLS base YANG module serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG models (e.g. MPLS LSP Static, LDP or RSVP-TE models) will augment the MPLS base YANG model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-base-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-base-yang-04 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 nobody Mon Mar 13 07:02:57 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B3B129659; Mon, 13 Mar 2017 07:02:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148941377244.16927.12669513368036397404@ietfa.amsl.com> Date: Mon, 13 Mar 2017 07:02:52 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc3107bis-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 14:02:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Using BGP to Bind MPLS Labels to Address Prefixes Author : Eric C. Rosen Filename : draft-ietf-mpls-rfc3107bis-01.txt Pages : 22 Date : 2017-03-13 Abstract: This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels, organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc3107bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc3107bis-01 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 nobody Mon Mar 13 09:28:30 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5C1293E9; Mon, 13 Mar 2017 09:28:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942250954.16860.645368470853864950@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:28:29 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-static-yang-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:28:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : A YANG Data Model for MPLS Static LSPs Authors : Tarek Saad Kamran Raza Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Himanshu Shah Igor Bryskin Xia Chen Raqib Jones Bin Wen Filename : draft-ietf-mpls-static-yang-03.txt Pages : 18 Date : 2017-03-13 Abstract: This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on LER(s) and LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-static-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-static-yang-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 nobody Mon Mar 13 15:35:42 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AE129B92; Mon, 13 Mar 2017 15:35:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944454059.20264.10310807010462154766@ietfa.amsl.com> Date: Mon, 13 Mar 2017 15:35:40 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-yang-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:35:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : YANG Data Model for MPLS LDP Authors : Kamran Raza Rajiv Asati Xufeng Liu Santosh Esale Xia Chen Himanshu Shah Filename : draft-ietf-mpls-ldp-yang-01.txt Pages : 88 Date : 2017-03-13 Abstract: This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). This model also serves as the base model that is augmented to define Multipoint LDP (mLDP) model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-ldp-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-yang-01 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 nobody Mon Mar 13 16:09:07 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DABF129BEB; Mon, 13 Mar 2017 16:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944654063.20397.1869763061385549021@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:09:00 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-yang-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:09:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : YANG Data Model for MPLS mLDP Authors : Kamran Raza Sowmya Krishnaswamy Xufeng Liu Santosh Esale Xia Chen Jeff Tantsura Filename : draft-ietf-mpls-mldp-yang-01.txt Pages : 57 Date : 2017-03-13 Abstract: This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP data model augments the LDP data model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-mldp-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-mldp-yang-01 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 nobody Mon Mar 13 19:31:33 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E1D129420 for ; Mon, 13 Mar 2017 19:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etAzmD-HOiMP for ; Mon, 13 Mar 2017 19:31:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789C3127A91 for ; Mon, 13 Mar 2017 19:31:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIV01618; Tue, 14 Mar 2017 02:31:26 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Mar 2017 02:31:25 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 14 Mar 2017 10:31:13 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-unified-source-routing-instruction-00.txt Thread-Index: AQHSm6X8X0exXChj1UuOWJwEGEIT0qGTnloQ Date: Tue, 14 Mar 2017 02:31:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB64094@NKGEML515-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.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58C755FF.0003, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d00073d569b61bf178ea3b3c4d36554f Archived-At: Subject: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-mpls-unified-source-routing-instruction-00=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 02:31:32 -0000 SGkgYWxsLA0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7 tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTflubQz5pyIMTPml6UgMTE6MDANCj4g5pS25Lu2 5Lq6OiBIYW1pZCBBc3NhcnBvdXI7IEx1aXMgTS4gQ29udHJlcmFzOyBSb2JlcnQgUmFzenVrOyBY dXhpYW9odTsgU3Rld2FydA0KPiBCcnlhbnQ7IEx1YXkgSmFsaWw7IFVtYSBDaHVuZHVyaTsgTHVp cyBDb250cmVyYXMNCj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRy YWZ0LXh1LW1wbHMtdW5pZmllZC1zb3VyY2Utcm91dGluZy1pbnN0cnVjdGlvbi0wMC50eHQNCj4g DQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtbXBscy11bmlmaWVkLXNvdXJj ZS1yb3V0aW5nLWluc3RydWN0aW9uLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+ IA0KPiBOYW1lOgkJZHJhZnQteHUtbXBscy11bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydWN0 aW9uDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVVuaWZpZWQgU291cmNlIFJvdXRpbmcgSW5z dHJ1Y3Rpb24gdXNpbmcgTVBMUyBMYWJlbCBTdGFjaw0KPiBEb2N1bWVudCBkYXRlOgkyMDE3LTAz LTA5DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTANCj4gVVJM Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtbXBscy11 bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydQ0KPiBjdGlvbi0wMC50eHQNCj4gU3RhdHVzOg0K PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1tcGxzLXVuaWZpZWQt c291cmNlLXJvdXRpbmctaW5zdHJ1Y3Rpb24NCj4gLw0KPiBIdG1saXplZDoNCj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtdW5pZmllZC1zb3VyY2Utcm91dGluZy1p bnN0cnVjdGlvbi0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBNUExTLVNQUklORyBpcyBh biBNUExTLWJhc2VkIHNvdXJjZSByb3V0aW5nIHBhcmFkaWdtIGluIHdoaWNoIGENCj4gICAgc2Vu ZGVyIG9mIGEgcGFja2V0IGlzIGFsbG93ZWQgdG8gcGFydGlhbGx5IG9yIGNvbXBsZXRlbHkgc3Bl Y2lmeSB0aGUNCj4gICAgcm91dGUgdGhlIHBhY2tldCB0YWtlcyB0aHJvdWdoIHRoZSBuZXR3b3Jr IGJ5IGltcG9zaW5nIHN0YWNrZWQgTVBMUw0KPiAgICBsYWJlbHMgdG8gdGhlIHBhY2tldC4gIFRo aXMgTVBMUyAtYmFzZWQgc291cmNlIHJvdXRpbmcgcGFyYWRpZ20gY291bGQNCj4gICAgYWN0dWFs bHkgYmUgbGV2ZXJhZ2VkIHRvIHJlYWxpemUgYSB1bmlmaWVkIHNvdXJjZSByb3V0aW5nIGluc3Ry dWN0aW9uDQo+ICAgIGZvciBib3RoIElQdjQgYW5kIElQdjYgdW5kZXJsYXlzLg0KPiANCj4gDQo+ IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Mar 13 19:42:49 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2BC129AAF for ; Mon, 13 Mar 2017 19:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMr4VB9_MezL for ; Mon, 13 Mar 2017 19:42:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CE4129420 for ; Mon, 13 Mar 2017 19:42:47 -0700 (PDT) Received: from [192.168.1.11] (unknown [112.204.187.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2452F18013D1 for ; Tue, 14 Mar 2017 03:42:44 +0100 (CET) To: mpls@ietf.org References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB64094@NKGEML515-MBS.china.huawei.com> From: Loa Andersson Message-ID: <0574c9db-9750-9c26-6fbc-17d3c0667099@pi.nu> Date: Tue, 14 Mar 2017 10:42:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB64094@NKGEML515-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-mpls-unified-source-routing-instruction-00=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 02:42:48 -0000 Xiaohu, Will you discuss this draft at the MPLS wg meeting in CHicago? /Loa On 2017-03-14 10:31, Xuxiaohu wrote: > Hi all, > > Any comments and suggestions are welcome. > > Best regards, > Xiaohu > >> -----邮件原件----- >> 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> 发送时间: 2017年3月13日 11:00 >> 收件人: Hamid Assarpour; Luis M. Contreras; Robert Raszuk; Xuxiaohu; Stewart >> Bryant; Luay Jalil; Uma Chunduri; Luis Contreras >> 主题: New Version Notification for >> draft-xu-mpls-unified-source-routing-instruction-00.txt >> >> >> A new version of I-D, draft-xu-mpls-unified-source-routing-instruction-00.txt >> has been successfully submitted by Xiaohu Xu and posted to the IETF repository. >> >> Name: draft-xu-mpls-unified-source-routing-instruction >> Revision: 00 >> Title: Unified Source Routing Instruction using MPLS Label Stack >> Document date: 2017-03-09 >> Group: Individual Submission >> Pages: 10 >> URL: >> https://www.ietf.org/internet-drafts/draft-xu-mpls-unified-source-routing-instru >> ction-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-xu-mpls-unified-source-routing-instruction >> / >> Htmlized: >> https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-00 >> >> >> Abstract: >> MPLS-SPRING is an MPLS-based source routing paradigm in which a >> sender of a packet is allowed to partially or completely specify the >> route the packet takes through the network by imposing stacked MPLS >> labels to the packet. This MPLS -based source routing paradigm could >> actually be leveraged to realize a unified source routing instruction >> for both IPv4 and IPv6 underlays. >> >> >> >> >> 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. >> >> The IETF Secretariat > > _______________________________________________ > 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 nobody Tue Mar 14 04:08:04 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1726C12954D; Tue, 14 Mar 2017 04:07:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148948967806.12630.17780798711864289686@ietfa.amsl.com> Date: Tue, 14 Mar 2017 04:07:58 -0700 Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org, ietf@ietf.org Subject: [mpls] Review of draft-ietf-mpls-tp-temporal-hitless-psm-13 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:07:58 -0000 Reviewer: Stewart Bryant Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-mpls-tp-temporal-hitless-psm-?? Reviewer: Stewart Bryant Review Date: 2017-03-14 IETF LC End Date: 2017-03-03 IESG Telechat date: 2017-03-16 Summary: Given that the implications for the MPLS architecture and the feasibility of a solution are currently unknown, the IESG needs to decide whether publication at this stage is appropriate, or whether a feasible solution should first be identified. Major issues: I previously raised the following two issues: "Whilst this text describes a list of issues with the existing IETF design, it should be remembered that the design was the best that could be accomplished at the time within the constraints of the MPLS architecture. So that leaves the reader with a question: do the authors now have an insight into how a solution can now be designed to meet the requirement, or do the authors intend to propose a change to the MPLS architecture, or is the intention to publish this to state the requirements in the hope that someone will eventually propose a solution?" and "The text around Figure 8 explains the deficiency in TTL based section of an OAM monitoring point in MPLS. However the authors give no indication of a feasible alternative." The authors responded by adding the following text: "Further works are required to evaluate how proposed requirements match with current MPLS architecture and to identify possibile solutions." When RFC6371 was written the problems cited in this text were known, and despite much work no one could identify a solution at the time. The key question for the IESG is whether it is appropriate to publish this requirements text when no one has any idea of the impact on the MPLS architecture or if there are any practical solutions to the problems raised. In response to the issue: "In particular, performance monitoring measurements (e.g. Delay Measurement and Packet Loss Measurement) are sensitive to these changes." Whilst technically true, I am not sure the impact on delay is significant in any engineering sense. We are talking four bytes per packet over a service that is going at 1 to 400 Gb/s. Again it is hard to imagine a significant impact on loss. If this is a key point it need some justification from an engineering perspective. The authors add text: As an example,increasing the packet lenght may impact on packet loss due to MTU settings, modifying the label stack may introduce packet loss or it may fix packet loss depending on the configuration status so modifying network conditions. Such changes influence packets delay too even if, from a practical point of view, it is likely that only a few services will experience a practical impact. Again it is for the IESG to decide whether in the light of the architectural and practical issues noted earlier, the problem is severe enough to warrant publication of this document at this stage. From nobody Tue Mar 14 09:45:34 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F191297B8; Tue, 14 Mar 2017 09:45:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, David Sinicrope , mpls-chairs@ietf.org, david.sinicrope@ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148950992865.30217.623852332846175032.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 09:45:28 -0700 Archived-At: Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-tp-temporal-hitless-psm-13=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.21 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:45:29 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-tp-temporal-hitless-psm-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't see a value in publishing this document in the RFC series. Btw. the shepherd write up still says this doc is standards track. Minor comments: - The classification into M(andatory) and O(ptional) is not consistent with the use of MUST and SHOULD. - The first sentence in the intro should use a lower case 'must'. - Sections 2.2 and 5. could be removed. From nobody Wed Mar 15 07:21:02 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 357F4131586; Wed, 15 Mar 2017 07:20:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, David Sinicrope , mpls-chairs@ietf.org, david.sinicrope@ericsson.com, mpls@ietf.org, Jon Mitchell X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148958764721.3940.6645107735827733493.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 07:20:47 -0700 Archived-At: Subject: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-tp-temporal-hitless-psm-13: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:20:47 -0000 Benoit Claise has entered the following ballot position for draft-ietf-mpls-tp-temporal-hitless-psm-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OPS DIR review from Jon Mitchell: Document is Ready with Nits. I share the concern that it's not totally clear upfront this is a requirements versus solution document. There is also not much in the way of requirements of notification or how to signal back to the operator that a fault has occurred, but this may be OK if whatever solution would meet the requirements of this draft will include such text or rely on existing mechanisms discussed in RFC6371. From nobody Wed Mar 15 15:00:22 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1E129C0E; Wed, 15 Mar 2017 15:00:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, David Sinicrope , mpls-chairs@ietf.org, david.sinicrope@ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148961521560.14213.1965727083109418701.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 15:00:15 -0700 Archived-At: Subject: [mpls] Alia Atlas' Abstain on draft-ietf-mpls-tp-temporal-hitless-psm-13: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:00:15 -0000 Alia Atlas has entered the following ballot position for draft-ietf-mpls-tp-temporal-hitless-psm-13: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do not see the value of this document as an RFC - particularly absent any work on a solution after 5 years. From nobody Wed Mar 15 18:08:51 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF67C129C68 for ; Wed, 15 Mar 2017 18:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b13k04bQXP-w for ; Wed, 15 Mar 2017 18:08:48 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B43129C4A for ; Wed, 15 Mar 2017 18:08:47 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Mar 2017 10:08:45 +0900 Received: from SMTP2.etri.info ([169.254.2.142]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.03.0319.002; Thu, 16 Mar 2017 10:08:45 +0900 From: "Ryoo, Jeong-dong " To: "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: [mpls] Building Agendas for the MPLS WG and Joint sessions - IETF 98 Chicago Thread-Index: AQHSkIPI1L/DZ3J+YUe1b7QvPRX9gKGWuzcT Date: Thu, 16 Mar 2017 01:08:44 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4@SMTP2.etri.info> References: <45C67F35-79A9-4EC9-9256-D91D6B0693D6@cisco.com> In-Reply-To: <45C67F35-79A9-4EC9-9256-D91D6B0693D6@cisco.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZyA= x-originating-ip: [129.254.28.42] Content-Type: multipart/mixed; boundary="_004_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: Subject: [mpls] =?utf-8?b?7ZqM7IugOiAgQnVpbGRpbmcgQWdlbmRhcyBmb3IgdGhlIE1Q?= =?utf-8?q?LS_WG_and_Joint_sessions_-_IETF=0998_Chicago?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 01:08:51 -0000 --_004_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_ Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_" --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBUYXJlaywNCg0KDQpUaGlzIGlzIGEgc3RhdHVzIHJlcG9ydCBvbiB0d28gTVBMUyBXRyBk cmFmdHMgdGhhdCBhcmUgbm90IGdvaW5nIHRvIGJlIHByZXNlbnRlZCBpbiBJRVRGOTguDQoNCg0K MS4gIGRyYWZ0LWlldGYtbXBscy10cC1hcHMtdXBkYXRlcy0wMzoNCg0KICAgLSBXRyBzdGF0ZTog U3VibWl0dGVkIHRvIElFU0cgZm9yIFB1YmxpY2F0aW9uDQoNCiAgIC0gSUVTRyBzdGF0ZTogRXhw ZXJ0IFJldmlldyAoRW50ZXJlZCBpbiBKYW51YXJ5IDEwLCAyMDE3Ow0KDQogICAgICAgICBSZXF1 ZXN0IGZvciBMYXN0IENhbGwgcmV2aWV3IGJ5IFJUR0RJUiBDb21wbGV0ZWQgaW4gSmFudWFyeSAy MzsNCg0KICAgICAgICAgTm8gb3V0c3RhbmRpbmcgaXNzdWVzIHJlbWFpbikNCg0KDQoyLiBkcmFm dC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tbWliLTEyOg0KDQogIC0gV0cgc3RhdGU6 IFN1Ym1pdHRlZCB0byBJRVNHIGZvciBQdWJsaWNhdGlvbg0KDQogIC0gSUVTRyBzdGF0ZTogUkZD IEVkIFF1ZXVlDQoNCg0KVGhhbmsgeW91Lg0KDQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQrrs7Trgrgg7IKs656MIDogIlRhcmVrIFNhYWQgKHRz YWFkKSIgPHRzYWFkQGNpc2NvLmNvbT4NCuuztOuCuCDrgqDsp5wgOiAyMDE3LTAyLTI3IDA3OjU4 OjIxICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYu b3JnPiwgVEVBUyBXRyAodGVhc0BpZXRmLm9yZykgPHRlYXNAaWV0Zi5vcmc+LCBwY2VAaWV0Zi5v cmcgPHBjZUBpZXRmLm9yZz4sIGNjYW1wQGlldGYub3JnIDxjY2FtcEBpZXRmLm9yZz4NCuywuOyh sCA6IGNjYW1wLWNoYWlyc0BpZXRmLm9yZyA8Y2NhbXAtY2hhaXJzQGlldGYub3JnPiwgdGVhcy1j aGFpcnNAaWV0Zi5vcmcgPHRlYXMtY2hhaXJzQGlldGYub3JnPiwgbXBscy1jaGFpcnNAaWV0Zi5v cmcgPG1wbHMtY2hhaXJzQGlldGYub3JnPiwgcGNlLWNoYWlyc0BpZXRmLm9yZyA8cGNlLWNoYWly c0BpZXRmLm9yZz4NCuygnOuqqSA6IFttcGxzXSBCdWlsZGluZyBBZ2VuZGFzIGZvciB0aGUgTVBM UyBXRyBhbmQgSm9pbnQgc2Vzc2lvbnMgLSBJRVRGIDk4IENoaWNhZ28NCg0KDQpIaSBhbGwsDQoN CldlIGFyZSBzdGFydGluZyB0byBidWlsZCB0aGUgTVBMUyBXRyBhbmQgdGhlIEpvaW50IFdHIHNl c3Npb25z4oCZIGFnZW5kYXMgZm9yIElFVEY5OCBpbiBDaGljYWdvLCBJTCwgVVNBLiBUaGUgcHJl bGltaW5hcnkgYWdlbmRhIGZvciBJRVRGOTgsIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OC9hZ2VuZGEuaHRtbA0KDQpUaGUgTVBMUyBXRyBz ZXNzaW9uIGlzIGN1cnJlbnRseSBzY2hlZHVsZWQgZm9yOg0KVHVlc2RheSwgTWFyY2ggMjgsIDIw MTcgKENEVCkgLSA5OjAwLTExOjMwIFR1ZXNkYXkgTW9ybmluZyBzZXNzaW9uIEkNClRoZXJlIHdp bGwgYWxzbyBiZSBhIGpvaW50IHNlc3Npb24gZm9yIE1QTFMvVEVBUy9QQ0UvQ0NBTVAgV0dzIGZv ciB0b3BpY3Mgb2YgY29tbW9uIGludGVyZXN0IChpbmNsdWRpbmcgWUFORyBtb2RlbHMpIHRoYXQg d2lsbCBob3N0ZWQgYnkgTVBMUyBXRyB0aGlzIHRpbWUgYW5kIGN1cnJlbnRseSBzY2hlZHVsZWQg Zm9yOg0KRnJpZGF5LCBNYXJjaCAzMSwgMjAxNyAoQ0RUKSAtIDk6MDAtMTE6MzAgRnJpZGF5IE1v cm5pbmcgc2Vzc2lvbiBJDQoNClBsZWFzZSBzZW5kIHNsb3QgcmVxdWVzdHMgZm9yIHRoZSBNUExT IGFuZCB0aGUgam9pbnQgc2Vzc2lvbnMgdG8gbXlzZWxmIGFuZCB0aGUgV0cgY2hhaXJzIGJ5IFR1 ZXNkYXkgTWFyY2ggMTR0aCAtIGluZGljYXRpbmcgZHJhZnQgbmFtZSwgc3BlYWtlciBhbmQgZGVz aXJlZCBkdXJhdGlvbi4gSWYgcHJlc2VudGluZywgeW91ciBzbGlkZXMgd2lsbCBiZSBkdWUgYnkg RnJpZGF5IE1hcmNoIDI0dGguIFBsZWFzZSBzZW5kIHNsaWRlcyB0byB0byBteXNlbGYgYW5kIHRo ZSBXRyBjaGFpcnMuDQpBIHJlbWluZGVyIHRvIGF1dGhvcnMvZWRpdG9ycyBvZiBNUExTIFdHIGRy YWZ0cyB0aGF0IHdpbGwgbm90IGJlIGRpc2N1c3NlZC9wcmVzZW50ZWQgYXQgSUVUOTggdG8gc2Vu ZCBhIHN0YXR1cyByZXBvcnQgdG8gdGhlIFdHIGxpc3QgYnkgRnJpZGF5IE1hcmNoIDI0dGggc28g aXQgY2FuIGJlIGluY2x1ZGVkIGluIHRoZSBNUExTIFdHIHByb2dyZXNzIHJlcG9ydC4NCg0KUmVn YXJkcywNClRhcmVrIGFuZCBNUExTIFdHIGNoYWlycw0KSW1wb3J0YW50IGRhdGVzOg0KMjAxNy0w My0xMyAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQgc3VibWlzc2lvbiBjdXQtb2ZmIChmb3IgYWxs IGRyYWZ0cywgaW5jbHVkaW5nIC0wMCkgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNpbmcgSUVURiBJ RCBTdWJtaXNzaW9uIFRvb2wuDQoyMDE3LTAzLTE1IChXZWRuZXNkYXkpOiBEcmFmdCBXb3JraW5n IEdyb3VwIGFnZW5kYXMgZHVlIGJ5IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGlu ZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0KMjAxNy0wMy0xNyAoRnJpZGF5KTogRWFybHkg QmlyZCByZWdpc3RyYXRpb24gYW5kIHBheW1lbnQgY3V0LW9mZiBhdCBVVEMgMjM6NTkuDQoyMDE3 LTAzLTIwIChNb25kYXkpOiBSZXZpc2VkIFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRD IDIzOjU5LCB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRv b2wuDQoyMDE3LTAzLTIwIChNb25kYXkpOiBSZWdpc3RyYXRpb24gY2FuY2VsbGF0aW9uIGN1dC1v ZmYgYXQgVVRDIDIzOjU5Lg0KMjAxNy0wMy0yNCAoRnJpZGF5KTogRmluYWwgUHJlLVJlZ2lzdHJh dGlvbiBhbmQgUHJlLVBheW1lbnQgY3V0LW9mZiBhdCAxNzowMCBsb2NhbCBtZWV0aW5nIHRpbWUu DQoyMDE3LTAzLTI2IC0gMjAxNy0wMy0zMTogSUVURiA5OCBpbiBDaGljYWdvLCBJTCwgVVNBDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij5EZWFy IFRhcmVrLDwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBw eCI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDog MHB4Ij5UaGlzIGlzIGEgc3RhdHVzIHJlcG9ydCBvbiB0d28gTVBMUyBXRyBkcmFmdHMgdGhhdCBh cmUgbm90IGdvaW5nIHRvIGJlIHByZXNlbnRlZCBpbiBJRVRGOTguPC9wPg0KPHAgc3R5bGU9Ik1B UkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0i TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjEuICZuYnNwO2RyYWZ0LWlldGYt bXBscy10cC1hcHMtdXBkYXRlcy0wMzombmJzcDsNCjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7Jm5ic3A7IC0gV0cgc3RhdGU6IFN1Ym1p dHRlZCB0byBJRVNHIGZvciBQdWJsaWNhdGlvbjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9N OiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7Jm5ic3A7IC0gSUVTRyBzdGF0ZTogRXhwZXJ0 IFJldmlldyAoRW50ZXJlZCBpbiBKYW51YXJ5IDEwLCAyMDE3Ow0KPC9wPg0KPHAgc3R5bGU9Ik1B UkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVxdWVzdCBmb3IgTGFzdCBDYWxsIHJldmlldyBi eSBSVEdESVIgQ29tcGxldGVkIGluIEphbnVhcnkgMjM7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1C T1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTm8gb3V0c3RhbmRpbmcgaXNzdWVzIHJlbWFpbik8L3A+DQo8 cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxicj4NCjwvcD4N CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Mi4mbmJzcDtk cmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tbWliLTEyOiZuYnNwOzwvcD4NCjxk aXYgaWQ9Ik1haWxTaWduU2VudCI+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPiZuYnNwOyAtIFdHIHN0YXRlOiBTdWJtaXR0ZWQgdG8gSUVTRyBmb3IgUHVi bGljYXRpb248L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAw cHgiPiZuYnNwOyAtIElFU0cgc3RhdGU6IFJGQyBFZCBRdWV1ZTwvcD4NCjxwIHN0eWxlPSJNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Ik1B UkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij5UaGFuayB5b3UuPC9wPg0KPHAgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48YnI+DQo8L3A+DQo8cCBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPkplb25nLWRvbmc8L3A+ DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PGJyPg0K PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJPUkdNQUlMX0NPTlRFTlQiPg0KPGhyIHRhYmluZGV4PSIt MSI+DQo8ZGl2PjxiPuuztOuCuCDsgqzrnowgOiA8L2I+JnF1b3Q7VGFyZWsgU2FhZCAodHNhYWQp JnF1b3Q7ICZsdDt0c2FhZEBjaXNjby5jb20mZ3Q7PC9kaXY+DQo8ZGl2PjxiPuuztOuCuCDrgqDs p5wgOiA8L2I+MjAxNy0wMi0yNyAwNzo1ODoyMSAoICYjNDM7MDk6MDAgKTwvZGl2Pg0KPGRpdj48 Yj7rsJvripQg7IKs656MIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7 LCBURUFTIFdHICh0ZWFzQGlldGYub3JnKSAmbHQ7dGVhc0BpZXRmLm9yZyZndDssIHBjZUBpZXRm Lm9yZyAmbHQ7cGNlQGlldGYub3JnJmd0OywgY2NhbXBAaWV0Zi5vcmcgJmx0O2NjYW1wQGlldGYu b3JnJmd0OzwvZGl2Pg0KPGRpdj48Yj7ssLjsobAgOiA8L2I+Y2NhbXAtY2hhaXJzQGlldGYub3Jn ICZsdDtjY2FtcC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCB0ZWFzLWNoYWlyc0BpZXRmLm9yZyAmbHQ7 dGVhcy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCBtcGxzLWNoYWlyc0BpZXRmLm9yZyAmbHQ7bXBscy1j aGFpcnNAaWV0Zi5vcmcmZ3Q7LCBwY2UtY2hhaXJzQGlldGYub3JnICZsdDtwY2UtY2hhaXJzQGll dGYub3JnJmd0OzwvZGl2Pg0KPGRpdj48Yj7soJzrqqkgOiA8L2I+W21wbHNdIEJ1aWxkaW5nIEFn ZW5kYXMgZm9yIHRoZSBNUExTIFdHIGFuZCBKb2ludCBzZXNzaW9ucyAtIElFVEYgOTggQ2hpY2Fn bzwvZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4m bmJzcDs8L3A+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48c3BhbiBzdHls ZT0iRk9OVC1TSVpFOiAxMy41cHQ7IENPTE9SOiBibGFjayI+SGkgYWxsLDwhLS0/eG1sOm5hbWVz cGFjZSBwcmVmaXggPSAibyIgbnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIiAvLS0+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJH SU4tQk9UVE9NOiAwcHg7IFdPUkQtU1BBQ0lORzogMHB4OyBNQVJHSU4tVE9QOiAwcHg7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij4NCjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEz LjVwdDsgQ09MT1I6IGJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgV09SRC1TUEFDSU5HOiAwcHg7IE1BUkdJTi1U T1A6IDBweDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiPg0KPHNwYW4gc3R5bGU9 IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPldlIGFyZSBzdGFydGluZyB0byBidWls ZCB0aGUgTVBMUyBXRyBhbmQgdGhlIEpvaW50IFdHIHNlc3Npb25z4oCZIGFnZW5kYXMgZm9yIElF VEY5OCBpbiBDaGljYWdvLCBJTCwgVVNBLiBUaGUgcHJlbGltaW5hcnkgYWdlbmRhIGZvciBJRVRG OTgsIGlzIGF2YWlsYWJsZSBhdDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48c3BhbiBzdHlsZT0iRk9O VC1TSVpFOiAxMy41cHQ7IENPTE9SOiBibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzk4L2FnZW5kYS5odG1sIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL21lZXRpbmcvOTgvYWdlbmRhLmh0bWw8L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PHNw YW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPiZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBXT1JE LVNQQUNJTkc6IDBweDsgTUFSR0lOLVRPUDogMHB4OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMy41cHQ7IENPTE9SOiBibGFjayI+ VGhlIE1QTFMgV0cgc2Vzc2lvbiBpcyBjdXJyZW50bHkgc2NoZWR1bGVkIGZvcjo8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgV09SRC1T UEFDSU5HOiAwcHg7IE1BUkdJTi1UT1A6IDBweDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHgiPg0KPHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPlR1 ZXNkYXksIE1hcmNoIDI4LCAyMDE3IChDRFQpIC0gOTowMC0xMTozMCBUdWVzZGF5IE1vcm5pbmcg c2Vzc2lvbiBJPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48c3BhbiBzdHlsZT0i Rk9OVC1TSVpFOiAxMy41cHQ7IENPTE9SOiBibGFjayI+VGhlcmUgd2lsbCBhbHNvIGJlIGENCjxi Pjx1PmpvaW50IHNlc3Npb248L3U+PC9iPiBmb3IgTVBMUy9URUFTL1BDRS9DQ0FNUCBXR3MgZm9y IHRvcGljcyBvZiBjb21tb24gaW50ZXJlc3QgKGluY2x1ZGluZyBZQU5HIG1vZGVscykgdGhhdCB3 aWxsIGhvc3RlZCBieSBNUExTIFdHIHRoaXMgdGltZSBhbmQgY3VycmVudGx5IHNjaGVkdWxlZCBm b3I6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9N OiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBD T0xPUjogYmxhY2siPkZyaWRheSwgTWFyY2ggMzEsIDIwMTcgKENEVCkgLSA5OjAwLTExOjMwIEZy aWRheSBNb3JuaW5nIHNlc3Npb24gSTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxzcGFuIHN0eWxlPSJG T05ULVNJWkU6IDEzLjVwdDsgQ09MT1I6IGJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgV09SRC1TUEFDSU5HOiAw cHg7IE1BUkdJTi1UT1A6IDBweDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiPg0K PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPlBsZWFzZSBzZW5k IHNsb3QgcmVxdWVzdHMgZm9yIHRoZSBNUExTIGFuZCB0aGUgam9pbnQgc2Vzc2lvbnMgdG8gbXlz ZWxmIGFuZCB0aGUgV0cgY2hhaXJzIGJ5IFR1ZXNkYXkgTWFyY2ggMTQ8c3VwPnRoPC9zdXA+IC0g aW5kaWNhdGluZyBkcmFmdCBuYW1lLCBzcGVha2VyIGFuZCBkZXNpcmVkIGR1cmF0aW9uLiBJZiBw cmVzZW50aW5nLCB5b3VyIHNsaWRlcyB3aWxsIGJlDQogZHVlIGJ5Jm5ic3A7RnJpZGF5IE1hcmNo IDI0dGguIFBsZWFzZSBzZW5kIHNsaWRlcyB0byB0byBteXNlbGYgYW5kIHRoZSBXRyBjaGFpcnMu PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1B UkdJTi1CT1RUT006IDBweDsgV09SRC1TUEFDSU5HOiAwcHg7IE1BUkdJTi1UT1A6IDBweDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiPg0KPHNwYW4gc3R5bGU9IkZPTlQtU0laRTog MTMuNXB0OyBDT0xPUjogYmxhY2siPkEgcmVtaW5kZXIgdG8gYXV0aG9ycy9lZGl0b3JzIG9mIE1Q TFMgV0cgZHJhZnRzIHRoYXQgd2lsbCBub3QgYmUgZGlzY3Vzc2VkL3ByZXNlbnRlZCBhdCBJRVQ5 OCB0byBzZW5kIGENCjxiPjx1PnN0YXR1cyByZXBvcnQ8L3U+PC9iPiB0byB0aGUgV0cgbGlzdCBi eSBGcmlkYXkgTWFyY2ggMjR0aDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5zbyBpdCBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIE1QTFMgV0cgcHJvZ3Jlc3Mg cmVwb3J0Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBXT1JELVNQQUNJTkc6IDBweDsgTUFSR0lOLVRPUDogMHB4OyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMy41cHQ7 IENPTE9SOiBibGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IFdPUkQtU1BBQ0lORzogMHB4OyBNQVJHSU4tVE9QOiAw cHg7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij4NCjxzcGFuIHN0eWxlPSJGT05U LVNJWkU6IDEzLjVwdDsgQ09MT1I6IGJsYWNrIj5SZWdhcmRzLDwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBXT1JELVNQQUNJTkc6IDBw eDsgTUFSR0lOLVRPUDogMHB4OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyAtd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCI+DQo8 c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMy41cHQ7IENPTE9SOiBibGFjayI+VGFyZWsgYW5kIE1Q TFMgV0cgY2hhaXJzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJH SU4tQk9UVE9NOiAwcHg7IFdPUkQtU1BBQ0lORzogMHB4OyBNQVJHSU4tVE9QOiAwcHg7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PHNwYW4gc3R5bGU9 IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPkltcG9ydGFudCBkYXRlczo8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMy41cHQ7IENPTE9SOiBibGFj ayI+MjAxNy0wMy0xMyAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQgc3VibWlzc2lvbiBjdXQtb2Zm IChmb3IgYWxsIGRyYWZ0cywgaW5jbHVkaW5nIC0wMCkgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNp bmcgSUVURiBJRCBTdWJtaXNzaW9uIFRvb2wuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PHNwYW4gc3R5 bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPjIwMTctMDMtMTUgKFdlZG5lc2Rh eSk6IERyYWZ0IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1cGxvYWQg dXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPjIw MTctMDMtMTcgKEZyaWRheSk6IEVhcmx5IEJpcmQgcmVnaXN0cmF0aW9uIGFuZCBwYXltZW50IGN1 dC1vZmYgYXQgVVRDIDIzOjU5Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxzcGFuIHN0eWxlPSJGT05U LVNJWkU6IDEzLjVwdDsgQ09MT1I6IGJsYWNrIj4yMDE3LTAzLTIwIChNb25kYXkpOiBSZXZpc2Vk IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNpbmcgSUVU RiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xPUjogYmxhY2siPjIwMTctMDMtMjAg KE1vbmRheSk6IFJlZ2lzdHJhdGlvbiBjYW5jZWxsYXRpb24gY3V0LW9mZiBhdCBVVEMgMjM6NTku PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTMuNXB0OyBDT0xP UjogYmxhY2siPjIwMTctMDMtMjQgKEZyaWRheSk6IEZpbmFsIFByZS1SZWdpc3RyYXRpb24gYW5k IFByZS1QYXltZW50IGN1dC1vZmYgYXQgMTc6MDAgbG9jYWwgbWVldGluZyB0aW1lLjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEzLjVwdDsgQ09MT1I6IGJsYWNr Ij4yMDE3LTAzLTI2IC0gMjAxNy0wMy0zMTogSUVURiA5OCBpbiBDaGljYWdvLCBJTCwgVVNBPC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_-- --_004_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Thu, 02 Mar 2017 06:53:12 GMT"; modification-date="Thu, 02 Mar 2017 06:53:12 GMT" Content-ID: <984278D066DB3C45BA1EF9CD4CCED665@etri.re.kr> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFp bGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg== --_004_5B4A6CBE3924BB41A3BEE462A8E0B75A292BA9E4SMTP2etriinfo_-- From nobody Thu Mar 16 07:04:20 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466721294E5; Thu, 16 Mar 2017 07:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HEyOWOoOUAP; Thu, 16 Mar 2017 07:04:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id D2791129516; Thu, 16 Mar 2017 07:04:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 268CF2CFD8; Thu, 16 Mar 2017 16:04:00 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU9zqfSEx29X; Thu, 16 Mar 2017 16:03:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ACFE62CC5E; Thu, 16 Mar 2017 16:03:57 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0801213D-FB08-47E9-A3F7-8480FFA07C95"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148948967806.12630.17780798711864289686@ietfa.amsl.com> Date: Thu, 16 Mar 2017 23:03:56 +0900 Cc: gen-art@ietf.org, mpls@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org, ietf@ietf.org Message-Id: References: <148948967806.12630.17780798711864289686@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [mpls] Review of draft-ietf-mpls-tp-temporal-hitless-psm-13 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:04:07 -0000 --Apple-Mail=_0801213D-FB08-47E9-A3F7-8480FFA07C95 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for your substantial comments, Stewart. Are there any comments from the authors or the WG otherwise? Jari --Apple-Mail=_0801213D-FB08-47E9-A3F7-8480FFA07C95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYyptNAAoJEM80gCTQU46q8CgP/18jqzXBxbL51u4E+lErjdsO VHQYS99AlNMKpDYlkBRmzBaotRA1YelJwrGz7rXWuNTPQkCrRyPEJUEOcUsFD8id Nj4SuefNTwAzYnYW+aftuBSZjtlkxQzynNrEpp/Bi6BNv9AfLb+GkF+XeaEi9XXD KWjCfA63xt0lLsCpWxJcEL9P1AowdlDaxRpWR4GHoaA8A5U8HnvK8+cLnwFBYlg9 /SVVHblhM3Qv3ynIrWcNM/kFL+RJi/WskYVPHzkFyYpSEbJ5mwadh4f288uwlk1L ZdY+kkFjNOqNe6unOWevjmfABOsowOjaiAlyd5mSStpuvTxwUzBD7tjy+zmoQPBn bOg/emWufEdo9gNqEFjM6bSX7C7PkFaxehHK0fkm5Fa34Mo4I9l1JhYNIAMQzd/k Ky1pwT9EnqouVShP9IFs9Ps5QRbymlijTwJw+8AXERSmbrW+pAMZRmyzzmiKJDpm cAgtFUoA7WGGCJ60hY6w0OmXGhtsh+QvZeq/BKrRNpG2uU2UEY7e9hVQREabyf+a s+NnvJXjIFgCklNZr/zLukzq3fPf44qaLXP6zV8oatl2Pkf43pTrz/kn11QkueNZ dzkdGFPWad+PXBrm4FSGMk5f/InNpTxGysA9h+1AfO1tgPCto9RsykO8xZ0oNXiH GppM5JCsSRNYYoV2Oo6w =pzmG -----END PGP SIGNATURE----- --Apple-Mail=_0801213D-FB08-47E9-A3F7-8480FFA07C95-- From nobody Thu Mar 16 07:08:36 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29B1294FF; Thu, 16 Mar 2017 07:08:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jari Arkko To: "The IESG" Cc: draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org, David Sinicrope , mpls-chairs@ietf.org, david.sinicrope@ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148967331347.14253.6887549974851914610.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 07:08:33 -0700 Archived-At: Subject: [mpls] Jari Arkko's Discuss on draft-ietf-mpls-tp-temporal-hitless-psm-13: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:08:33 -0000 Jari Arkko has entered the following ballot position for draft-ietf-mpls-tp-temporal-hitless-psm-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Stewart Bryant's Gen-ART review comments deserve more discussion, in my opinion. Perhaps that response is in the way of showing that Stewart is wrong, or that the working group has knowingly chosen a particular path, or that some clarification or changes are needed in the document. But substantial comments need to be addressed in some fashion, and I don't feel we're quite there yet. But I also didn't see much discussion on my e-mail search, it is possible of course that discussion happened without me seeing it (I'm not on the MPLS WG list). All that being said, this Discuss position is a request for discussion, but I do not plan to hold on to it beyond this telechat. From nobody Thu Mar 16 19:31:49 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB58129BC7; Thu, 16 Mar 2017 19:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X20HMRwxjN8; Thu, 16 Mar 2017 19:31:39 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A788129BB7; Thu, 16 Mar 2017 19:31:38 -0700 (PDT) Received: from [192.168.1.11] (unknown [112.204.187.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A81ED18013D1; Fri, 17 Mar 2017 03:31:35 +0100 (CET) To: Fatai Zhang , "ccamp@ietf.org" , "mpls@ietf.org" References: <943b685f-1403-09e4-fba2-b0d9d1ad64eb@pi.nu> From: Loa Andersson Message-ID: <9e65927f-6ab1-c143-e6e2-e9b4c5b1cd86@pi.nu> Date: Fri, 17 Mar 2017 10:31:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBbVGVhc10gRmxleEUgc2lkZSBtZWV0aW5n?= =?utf-8?q?_on_Monday_17=2C_at_18=2E30_-_20=2E00?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 02:31:41 -0000 Fatai, Your are right, tnx! The address expansion in THunderbird played me at trick, it was not only CCAMP I missed, but MPLS also :(. Copied now. /Loa On 2017-03-17 09:28, Fatai Zhang wrote: > Hi Loa, > > Thanks for your effort. > > I think you missed the leading actor: CCAMP WG, :-). > > Forwarded to CCAMP as well. > > > > > Thanks > > Fatai > > > -----ʼԭ----- > : Teas [mailto:teas-bounces@ietf.org] Loa Andersson > ʱ: 2017317 9:17 > ռ: draft-izh-ccamp-flexe-fwk@ietf.org; mpls-chairs@ietf.org; pce@ietf.org; TEAS WG; routing-discussion@ietf.org > : Ignas Bagdonas; ccamp-chairs@tools.ietf.org; Deborah A Brungard; Andrew G. Malis; n.leymann@telekom.de; draft-izh-ccamp-flexe-fwk@ietf.org; Stewart Bryant > : [Teas] FlexE side meeting on Monday 17, at 18.30 - 20.00 > > Folks, > > On Monday March 27 in Zurich B , there will be a FlexE side meeting from 18:30-20:00. The meeting will be chaired bt Daniele Ceccarelli and Nic Leyman. The initiative for this meeting were taken within the group that works on a FlexE Framework document (draft-izh-ccamp- flexe-fwk), and has been sponsored by Deborah Brungard and the ccamp working group co-chairs. > > The intent is to bring people up to speed on the FlexE technology and try to understand what work will be appropriate to do in the IETF. > > The agenda will be: > > 1. FlexE background and origins: Haomian Zheng > 2. FlexE Technology Deep Dive: Iftekhar Hussain > 3. FlexE in the IETF: Mach Chen > 4. Open Mic > > Each presentation is panned to last 20 min, and the Open Mic 30 min. > > > /Daniele, Fatai and Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Mar 17 01:34:40 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2F126BF6; Fri, 17 Mar 2017 01:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZXmjQGZ4Wpt; Fri, 17 Mar 2017 01:34:35 -0700 (PDT) Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9418124D68; Fri, 17 Mar 2017 01:34:34 -0700 (PDT) Content-Type: multipart/mixed; boundary="_e07cfd4f-aff1-4e7e-a351-bd5af7ccf7d0_" Received: from TELMBXB05RM001.telecomitalia.local (10.14.252.33) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 17 Mar 2017 09:34:32 +0100 Received: from TELMBXA05RM001.telecomitalia.local (10.14.252.32) by TELMBXB05RM001.telecomitalia.local (10.14.252.33) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Mar 2017 09:34:31 +0100 Received: from TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376]) by TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376%19]) with mapi id 15.00.1263.000; Fri, 17 Mar 2017 09:34:31 +0100 From: D'Alessandro Alessandro Gerardo To: Jari Arkko , The IESG CC: "draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org" , "draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org" , David Sinicrope , "mpls-chairs@ietf.org" , "david.sinicrope@ericsson.com" , "mpls@ietf.org" Thread-Topic: Jari Arkko's Discuss on draft-ietf-mpls-tp-temporal-hitless-psm-13: (with DISCUSS) Thread-Index: AQHSnl7Ob2H3kJUjL0WwGw9FeG8O6qGYq2EQ Date: Fri, 17 Mar 2017 08:34:31 +0000 Message-ID: <2494b7e2831c423982e8e9113d2989cd@TELMBXA05RM001.telecomitalia.local> References: <148967331347.14253.6887549974851914610.idtracker@ietfa.amsl.com> In-Reply-To: <148967331347.14253.6887549974851914610.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.244] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Archived-At: Subject: [mpls] R: Jari Arkko's Discuss on draft-ietf-mpls-tp-temporal-hitless-psm-13: (with DISCUSS) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 08:34:39 -0000 --_e07cfd4f-aff1-4e7e-a351-bd5af7ccf7d0_ Content-Type: multipart/alternative; boundary="_000_2494b7e2831c423982e8e9113d2989cdTELMBXA05RM001telecomit_" --_000_2494b7e2831c423982e8e9113d2989cdTELMBXA05RM001telecomit_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGFyZSBleHRyZW1lbHkgaW50ZXJlc3RlZCBpbiB0aGUgZnVuY3Rpb25h bGl0eSBkZXNjcmliZWQgaW4gdGhpcyAgUkZDLiBXZSB3aWxsIHN0YXJ0IGRpc2N1c3Npbmcgd2l0 aCBvdXIgdmVuZG9ycyBhcyBzb29uIGFzIHRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gYXBwcm92ZWQu DQoNCg0KDQpBcyBmYXIgYXMgU3Rld2FydCBCcnlhbnQncyBHZW4tQVJUIHJldmlldyBjb21tZW50 cywgaXQgc2VlbXMgdGhhdCAiVGhlIGtleSBxdWVzdGlvbiBmb3IgdGhlIElFU0cgaXMgd2hldGhl ciBpdCBpcyBhcHByb3ByaWF0ZSB0byBwdWJsaXNoIHRoaXMgcmVxdWlyZW1lbnRzIHRleHQgd2hl biAgbm8gb25lIGhhcyBhbnkgaWRlYSBvZiB0aGUgaW1wYWN0IG9uIHRoZSBNUExTIGFyY2hpdGVj dHVyZSBvciBpZiB0aGVyZSBhcmUgYW55IHByYWN0aWNhbCBzb2x1dGlvbnMgdG8gdGhlIHByb2Js ZW1zIHJhaXNlZC4iICBUbyB0aGF0IHF1ZXN0aW9uIEkgY2FuIHNheSB0aGF0IGEgcG90ZW50aWFs IHNvbHV0aW9uIHRoYXQgd2FzIGNvbmNlaXZlZCBhdCB0aGUgdGltZSB0aGUgZHJhZnQgd2FzIHdy aXR0ZW4gaXMgYmFzZWQgb24gY29tYmluaW5nIFRUTCBhbmQgbm9kZS9pbnRlcmZhY2UgSUQuICBJ IGhvcGUgdGhpcyBjYW4gYnJpZ2h0ZW4gdXAgYSBsaXR0bGUgYml0Lg0KDQoNCg0KQWdhaW4gZnJv bSBTdGV3YXJ0IEJyeWFudCdzIEdlbi1BUlQgcmV2aWV3IGNvbW1lbnRzICJTbyB0aGF0IGxlYXZl cyB0aGUgcmVhZGVyIHdpdGggYSBxdWVzdGlvbjogZG8gdGhlIGF1dGhvcnMgbm93IGhhdmUgYW4g aW5zaWdodCBpbnRvIGhvdyBhIHNvbHV0aW9uIGNhbiBub3cgYmUgZGVzaWduZWQgdG8gbWVldCB0 aGUgcmVxdWlyZW1lbnQsICBvciBkbyB0aGUgYXV0aG9ycyBpbnRlbmQgdG8gcHJvcG9zZSBhIGNo YW5nZSB0byB0aGUgTVBMUyBhcmNoaXRlY3R1cmUsIG9yIGlzIHRoZSBpbnRlbnRpb24gdG8gcHVi bGlzaCB0aGlzIHRvIHN0YXRlIHRoZSByZXF1aXJlbWVudHMgaW4gdGhlIGhvcGUgdGhhdCBzb21l b25lIHdpbGwgZXZlbnR1YWxseSBwcm9wb3NlIGEgc29sdXRpb24/IiBJIGJlbGlldmUgdGhhdCB3 aGF0IEkgc2FpZCBhYm92ZSBwcm92aWRlIGFuIGFuc3dlciB0byB0aGlzIGRvdWJ0LiBQZXJzb25h bGx5IEkgZG8gbm90IGJlbGlldmUgaXQgaXMgYXBwcm9wcmlhdGUgdG8gZWl0aGVyIGluY2x1ZGUg Y29tbWVudHMgYWJvdXQgc29sdXRpb25zIG5vciB0byBhbnRpY2lwYXRlIHNvbHV0aW9ucyBpbiBh IHJlcXVpcmVtZW50IGRvY3VtZW50IGJ1dCBpZiB5b3UgYmVsaWV2ZSB0aGlzIGlzIGEgd2F5IHRv IGltcHJvdmUgdGhlIGRvY3VtZW50IEkgY2FuIGFkZCBzb21lIGRldGFpbHMuDQoNCg0KDQpGaW5h bGx5LCBmcm9tIFN0ZXdhcnQgQnJ5YW50J3MgR2VuLUFSVCByZXZpZXcgY29tbWVudHMgIlRoZSB0 ZXh0IGFyb3VuZCBGaWd1cmUgOCBleHBsYWlucyB0aGUgZGVmaWNpZW5jeSBpbiBUVEwgYmFzZWQg c2VjdGlvbiBvZiBhbiBPQU0gbW9uaXRvcmluZyBwb2ludCBpbiBNUExTLiBIb3dldmVyIHRoZSBh dXRob3JzIGdpdmUgbm8gaW5kaWNhdGlvbiBvZiBhIGZlYXNpYmxlIGFsdGVybmF0aXZlLiIgVGhh dCBhcHBlYXJzIHRvIGJlIHRoZSBjb25jcmV0ZSBJRVNHIGNvbmNlcm4gYW5kIEkgZG8gdW5kZXJz dGFuZCB0aGF0Lg0KDQpEcmFmdCBkcmFmdC1pZXRmLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1w c20tMTMgc2F5czogIkFzc3VtaW5nIHRoYXQgT0FNIHBhY2tldCB0ZXJtaW5hdGlvbiBkZXBlbmRz IG9ubHkgb24gIHRoZSBUVEwgdmFsdWUgb2YgdGhlIE1QTFMgbGFiZWwgaGVhZGVyLCB0aGUgdGFy Z2V0IG5vZGUgb2YgdGhlIEhQU00gIGNoYW5nZXMgZnJvbSBFIHRvIEQgLi4uLi48c25pcHBlZD4u Li4uICBBcyBhIHJlc3VsdCByZXF1aXJlbWVudCAoTTkpIGlzIG5vdCBzYXRpc2ZpZWQu4oCdIC4g VGV4dCBpcyBOT1Qgc2F5aW5nIHRoYXQgTVBMUyBhcmNoaXRlY3R1cmUgaXMgbm90IGFkZXF1YXRl IHRvIHNhdGlzZnkgcmVxdWlyZW1lbnQgKE05KS4gSXQgc2ltcGx5IHNheXMgdGhhdCB1c2luZyBP TkxZIFRUTCBpcyBub3QgYWRlcXVhdGUgdG8gc2F0aXNmeSByZXF1aXJlbWVudCAoTTkpLiBBIHBv c3NpYmxlIHNvbHV0aW9uIGhhcyBiZWVuIGRlc2NyaWJlZCBhYm92ZS4NCg0KDQoNCkkgaG9wZSB0 aGlzIGNsYXJpZmllcyBhbmQgbGV0IHRoZSBkb2N1bWVudCB0byBiZSBmaW5hbGl6ZWQgc28gc3Rh cnRpbmcgYSBzZWNvbmQgcGhhc2Ugd2hlcmUgcGVvcGxlIGNhbiBiZSBjb21taXR0ZWQgdG8gd29y ayBvbiB0aGUgc29sdXRpb24uDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkFsZXNzYW5kcm8NCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCg0KDQoNCkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8N Cg0KVHJhbnNwb3J0IElubm92YXRpb24NCg0KVHJhbnNwb3J0IGFuZCBJUCBJbm5vdmF0aW9uDQoN ClZpYSBSZWlzcyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubw0KDQpwaG9uZTogICszOSAwMTEg MjI4IDU4ODcNCg0KbW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQoNCmZheDogKzM5IDA2IDQxOCA2 MzkgMDcNCg0KVGltIE9mZmljaWFsOiBGYWNlYm9vayAtIFR3aXR0ZXINCg0Kd3d3LnRpbS5pdA0K DQoNCg0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogSmFyaSBBcmtrbyBb bWFpbHRvOmphcmkuYXJra29AcGl1aGEubmV0XQ0KSW52aWF0bzogZ2lvdmVkw6wgMTYgbWFyem8g MjAxNyAxNTowOQ0KQTogVGhlIElFU0cNCkNjOiBkcmFmdC1pZXRmLW1wbHMtdHAtdGVtcG9yYWwt aGl0bGVzcy1wc21AaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10cC10ZW1wb3JhbC1oaXRsZXNz LXBzbUBpZXRmLm9yZzsgRGF2aWQgU2luaWNyb3BlOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgZGF2 aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbTsgbXBsc0BpZXRmLm9yZw0KT2dnZXR0bzogSmFyaSBB cmtrbydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNt LTEzOiAod2l0aCBESVNDVVNTKQ0KDQoNCg0KSmFyaSBBcmtrbyBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXRlbXBvcmFs LWhpdGxlc3MtcHNtLTEzOiBEaXNjdXNzDQoNCg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCg0KZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXMNCg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KDQoNCg0KUGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbA0KDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1Mg YW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXRwLXRlbXBvcmFsLWhpdGxl c3MtcHNtLw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkRJU0NVU1M6DQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KDQoNClN0ZXdhcnQgQnJ5YW50J3MgR2VuLUFSVCByZXZpZXcgY29tbWVudHMg ZGVzZXJ2ZSBtb3JlIGRpc2N1c3Npb24sIGluIG15DQoNCm9waW5pb24uIFBlcmhhcHMgdGhhdCBy ZXNwb25zZSBpcyBpbiB0aGUgd2F5IG9mIHNob3dpbmcgdGhhdCBTdGV3YXJ0IGlzDQoNCndyb25n LCBvciB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBrbm93aW5nbHkgY2hvc2VuIGEgcGFydGlj dWxhciBwYXRoLA0KDQpvciB0aGF0IHNvbWUgY2xhcmlmaWNhdGlvbiBvciBjaGFuZ2VzIGFyZSBu ZWVkZWQgaW4gdGhlIGRvY3VtZW50LiBCdXQNCg0Kc3Vic3RhbnRpYWwgY29tbWVudHMgbmVlZCB0 byBiZSBhZGRyZXNzZWQgaW4gc29tZSBmYXNoaW9uLCBhbmQgSSBkb24ndA0KDQpmZWVsIHdlJ3Jl IHF1aXRlIHRoZXJlIHlldC4gQnV0IEkgYWxzbyBkaWRuJ3Qgc2VlIG11Y2ggZGlzY3Vzc2lvbiBv biBteQ0KDQplLW1haWwgc2VhcmNoLCBpdCBpcyBwb3NzaWJsZSBvZiBjb3Vyc2UgdGhhdCBkaXNj dXNzaW9uIGhhcHBlbmVkIHdpdGhvdXQNCg0KbWUgc2VlaW5nIGl0IChJJ20gbm90IG9uIHRoZSBN UExTIFdHIGxpc3QpLg0KDQoNCg0KQWxsIHRoYXQgYmVpbmcgc2FpZCwgdGhpcyBEaXNjdXNzIHBv c2l0aW9uIGlzIGEgcmVxdWVzdCBmb3IgZGlzY3Vzc2lvbiwNCg0KYnV0IEkgZG8gbm90IHBsYW4g dG8gaG9sZCBvbiB0byBpdCBiZXlvbmQgdGhpcyB0ZWxlY2hhdC4NCg0KDQoNCg0KDQoNCg0KDQoN ClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2Ns dXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8g cXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVz dGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlh dGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50 ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUg ZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBE aXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlz IHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRo ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbcmlzcGV0dGEgbCdhbWJpZW50 ZV1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOo IG5lY2Vzc2FyaW8uDQoNCg== --_000_2494b7e2831c423982e8e9113d2989cdTELMBXA05RM001telecomit_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDI5RjAxLkFEQTcxRTQwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6R3JhbW1hclN0YXRlPkNsZWFuPC93OkdyYW1tYXJTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0K PHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlB1bmN0dWF0aW9uS2Vy bmluZy8+DQo8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJZlhNTEludmFsaWQ+ ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwv dzpJZ25vcmVNaXhlZENvbnRlbnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0PmZhbHNl PC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21vdGVRRi8+DQo8dzpM aWRUaGVtZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRUaGVtZUFzaWFuPlgt Tk9ORTwvdzpMaWRUaGVtZUFzaWFuPg0KPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwv dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+DQo8dzpDb21wYXRpYmlsaXR5Pg0KPHc6QnJlYWtXcmFw cGVkVGFibGVzLz4NCjx3OlNuYXBUb0dyaWRJbkNlbGwvPg0KPHc6V3JhcFRleHRXaXRoUHVuY3Qv Pg0KPHc6VXNlQXNpYW5CcmVha1J1bGVzLz4NCjx3OkRvbnRHcm93QXV0b2ZpdC8+DQo8dzpTcGxp dFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPHc6RG9u dEZsaXBNaXJyb3JJbmRlbnRzLz4NCjx3Ok92ZXJyaWRlVGFibGVTdHlsZUhwcy8+DQo8L3c6Q29t cGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgi Lz4NCjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7 LSIvPg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdp biBtOnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNl bnRlckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2 YWw9InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwv dzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJp b3JpdHk9Ijk5IiBMYXRlbnRTdHlsZUNvdW50PSIyNjciPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9j IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9 InRvYyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBO YW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgTmFtZT0idG9jIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIE5hbWU9IkRlZmF1bHQg UGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMTEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjIyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNp bmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iUmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhh c2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJJbnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjMxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRs ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgTmFtZT0i QmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPC93OkxhdGVudFN0eWxl cz4NCjwveG1sPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJBcmlhbCBSb3VuZGVkIE1UIEJvbGQiOw0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA5MjkyOSAxMDcz Nzg2MTExIDkgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJ bXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3MzgwNjU5MSA5IDAgNDE1IDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJ bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5k ZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmds ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVzdG8gbm9ybWFsZSBD YXJhdHRlcmUiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1w YWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZv bnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNv bnNvbGFzO30NCnNwYW4uVGVzdG9ub3JtYWxlQ2FyYXR0ZXJlDQoJe21zby1zdHlsZS1uYW1lOiJU ZXN0byBub3JtYWxlIENhcmF0dGVyZSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6 IlRlc3RvIG5vcm1hbGUiOw0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3Bs LWU6eWVzO30NCnNwYW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5 ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gMi4wY20gMi4wY207DQoJ bXNvLWhlYWRlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjM2LjBwdDsNCglt c28tcGFwZXItc291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmlu aXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFiZWxs YSBub3JtYWxlIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29s YmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAw Y20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0eWxlPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRh Yi1pbnRlcnZhbDozNi4wcHQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V2UgYXJlIGV4dHJlbWVseSBpbnRlcmVzdGVkIGluIHRoZSBmdW5jdGlvbmFsaXR5 IGRlc2NyaWJlZCBpbg0KPHNwYW4gY2xhc3M9IkdyYW1FIj50aGlzIDxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46eWVzIj4mbmJzcDs8L3NwYW4+UkZDPC9zcGFuPi4gV2Ugd2lsbCBzdGFydCBkaXNj dXNzaW5nIHdpdGggb3VyIHZlbmRvcnMgYXMgc29vbiBhcyB0aGlzIGRvY3VtZW50IGhhcyBiZWVu IGFwcHJvdmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcyBmYXIgYXMgU3Rld2Fy dCBCcnlhbnQncyBHZW4tQVJUIHJldmlldyBjb21tZW50cywgaXQgc2VlbXMgdGhhdCAmcXVvdDs8 aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPlRoZSBrZXkgcXVlc3Rpb24gZm9y IHRoZSBJRVNHIGlzIHdoZXRoZXIgaXQgaXMgYXBwcm9wcmlhdGUgdG8gcHVibGlzaCB0aGlzIHJl cXVpcmVtZW50cyB0ZXh0DQo8c3BhbiBjbGFzcz0iR3JhbUUiPndoZW48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOnllcyI+Jm5ic3A7IDwvc3Bhbj5ubzwvc3Bhbj4gb25lIGhhcyBhbnkgaWRlYSBv ZiB0aGUgaW1wYWN0IG9uIHRoZSBNUExTIGFyY2hpdGVjdHVyZSBvciBpZiB0aGVyZSBhcmUgYW55 IHByYWN0aWNhbCBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW1zIHJhaXNlZC4mcXVvdDs8L2k+PHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPlRvIHRoYXQgcXVlc3Rp b24gSSBjYW4gc2F5IHRoYXQgYSBwb3RlbnRpYWwgc29sdXRpb24gdGhhdCB3YXMgY29uY2VpdmVk IGF0IHRoZSB0aW1lIHRoZSBkcmFmdCB3YXMgd3JpdHRlbiBpcyBiYXNlZCBvbiBjb21iaW5pbmcg VFRMIGFuZCBub2RlL2ludGVyZmFjZSBJRC4NCjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVz Ij4mbmJzcDs8L3NwYW4+SSBob3BlIHRoaXMgY2FuIGJyaWdodGVuIHVwIGEgbGl0dGxlIGJpdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWdhaW4gZnJvbSBTdGV3YXJ0IEJyeWFudCdz IEdlbi1BUlQgcmV2aWV3IGNvbW1lbnRzICZxdW90OzxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0 eWxlOm5vcm1hbCI+U28gdGhhdCBsZWF2ZXMgdGhlIHJlYWRlciB3aXRoIGEgcXVlc3Rpb246IGRv IHRoZSBhdXRob3JzIG5vdyBoYXZlIGFuIGluc2lnaHQgaW50byBob3cgYSBzb2x1dGlvbiBjYW4g bm93IGJlIGRlc2lnbmVkIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50PHNwYW4gY2xhc3M9IkdyYW1F Ij4sPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPm9yPC9zcGFu PiBkbyB0aGUgYXV0aG9ycyBpbnRlbmQgdG8gcHJvcG9zZSBhIGNoYW5nZSB0byB0aGUgTVBMUyBh cmNoaXRlY3R1cmUsIG9yIGlzIHRoZSBpbnRlbnRpb24gdG8gcHVibGlzaCB0aGlzIHRvIHN0YXRl IHRoZSByZXF1aXJlbWVudHMgaW4gdGhlIGhvcGUgdGhhdCBzb21lb25lIHdpbGwgZXZlbnR1YWxs eSBwcm9wb3NlIGEgc29sdXRpb248L2k+PyZxdW90OyBJIGJlbGlldmUgdGhhdCB3aGF0IEkgc2Fp ZCBhYm92ZSBwcm92aWRlIGFuDQogYW5zd2VyIHRvIHRoaXMgZG91YnQuIFBlcnNvbmFsbHkgSSBk byBub3QgYmVsaWV2ZSBpdCBpcyBhcHByb3ByaWF0ZSB0byBlaXRoZXIgaW5jbHVkZSBjb21tZW50 cyBhYm91dCBzb2x1dGlvbnMgbm9yIHRvIGFudGljaXBhdGUgc29sdXRpb25zIGluIGEgcmVxdWly ZW1lbnQgZG9jdW1lbnQgYnV0IGlmIHlvdSBiZWxpZXZlIHRoaXMgaXMgYSB3YXkgdG8gaW1wcm92 ZSB0aGUgZG9jdW1lbnQgSSBjYW4gYWRkIHNvbWUgZGV0YWlscy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+RmluYWxseSwgZnJvbSBTdGV3YXJ0IEJyeWFudCdzIEdlbi1BUlQgcmV2aWV3 IGNvbW1lbnRzICZxdW90OzxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+VGhl IHRleHQgYXJvdW5kIEZpZ3VyZSA4IGV4cGxhaW5zIHRoZSBkZWZpY2llbmN5IGluIFRUTCBiYXNl ZCBzZWN0aW9uIG9mIGFuIE9BTSBtb25pdG9yaW5nIHBvaW50IGluIE1QTFMuIEhvd2V2ZXIgdGhl IGF1dGhvcnMgZ2l2ZSBubyBpbmRpY2F0aW9uDQogb2YgYSBmZWFzaWJsZSBhbHRlcm5hdGl2ZS48 L2k+JnF1b3Q7IFRoYXQgYXBwZWFycyB0byBiZSB0aGUgY29uY3JldGUgSUVTRyBjb25jZXJuIGFu ZCBJIGRvIHVuZGVyc3RhbmQgdGhhdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+RHJhZnQgZHJhZnQtaWV0Zi1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtLTEz IHNheXM6ICZxdW90OzxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+QXNzdW1p bmcgdGhhdCBPQU0gcGFja2V0IHRlcm1pbmF0aW9uIGRlcGVuZHMNCjxiIHN0eWxlPSJtc28tYmlk aS1mb250LXdlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPm9ubHk8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPg0KPC9zcGFuPjxzcGFuIGNsYXNzPSJHcmFtRSI+ b24gPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOzwvc3Bhbj50aGU8L3NwYW4+ IFRUTCB2YWx1ZSBvZiB0aGUgTVBMUyBsYWJlbCBoZWFkZXIsIHRoZSB0YXJnZXQgbm9kZSBvZiB0 aGUgSFBTTQ0KPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOzwvc3Bhbj5jaGFu Z2VzIGZyb20gRSB0byBEIC4uLi4uJmx0OzxzcGFuIGNsYXNzPSJHcmFtRSI+c25pcHBlZDwvc3Bh bj4mZ3Q7Li4uLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj5B cyBhIHJlc3VsdCByZXF1aXJlbWVudCAoTTkpIGlzIG5vdCBzYXRpc2ZpZWQ8L2k+LjxzcGFuIGNs YXNzPSJHcmFtRSI+4oCdIC48L3NwYW4+IFRleHQgaXMgTk9UIHNheWluZyB0aGF0IE1QTFMgYXJj aGl0ZWN0dXJlIGlzIG5vdCBhZGVxdWF0ZSB0byBzYXRpc2Z5IHJlcXVpcmVtZW50IChNOSkuIEl0 IHNpbXBseSBzYXlzIHRoYXQgdXNpbmcgT05MWSBUVEwgaXMgbm90IGFkZXF1YXRlIHRvIHNhdGlz ZnkgcmVxdWlyZW1lbnQgKE05KS4gQQ0KIHBvc3NpYmxlIHNvbHV0aW9uIGhhcyBiZWVuIGRlc2Ny aWJlZCBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBob3BlIHRoaXMgY2xh cmlmaWVzIGFuZCBsZXQgdGhlIGRvY3VtZW50IHRvIGJlIGZpbmFsaXplZCBzbyBzdGFydGluZyBh IHNlY29uZCBwaGFzZSB3aGVyZSBwZW9wbGUgY2FuIGJlIGNvbW1pdHRlZCB0byB3b3JrIG9uIHRo ZSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVzdCByZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWxlc3NhbmRybzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJJVCIgc3R5bGU9Im1zby1hbnNpLWxh bmd1YWdlOklUO21zby1uby1wcm9vZjp5ZXMiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0ibXNvLWFu c2ktbGFuZ3VhZ2U6SVQ7bXNvLW5vLXByb29mOnllcyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJtc28t YW5zaS1sYW5ndWFnZTpJVDttc28tbm8tcHJvb2Y6eWVzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJJVCIgc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOklUO21zby1uby1wcm9vZjp5ZXMiPkFsZXNzYW5kcm8gR2VyYXJkbyBE J0FsZXNzYW5kcm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJJVCIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOklUO21zby1uby1wcm9v Zjp5ZXMiPlRyPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tbm8tcHJvb2Y6eWVzIj5hbnNwb3J0IElu bm92YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0ibXNvLW5vLXByb29mOnllcyI+VHJhPC9zcGFuPjxzcGFuIGxhbmc9IklUIiBz dHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6SVQ7bXNvLW5vLXByb29mOnllcyI+bnNwb3J0IGFuZCBJ UCBJbm5vdmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpJVDttc28tbm8tcHJv b2Y6eWVzIj5WaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLW5vLXBy b29mOnllcyI+cGhvbmU6Jm5ic3A7ICYjNDM7MzkgMDExIDIyOCA1ODg3PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1uby1wcm9v Zjp5ZXMiPm1vYmlsZTogJiM0MzszOSAzMzUgNzY2IDk2MDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLW5vLXByb29mOnllcyI+ ZmF4OiAmIzQzOzM5IDA2IDQxOCA2MzkgMDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLW5vLXByb29mOnllcyI+VGltIE9mZmlj aWFsOiBGYWNlYm9vayAtIFR3aXR0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLW5vLXByb29mOnllcyI+d3d3LnRpbS5pdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0ibXNvLW5vLXByb29mOnllcyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJJVCIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOklUIj4tLS0t LU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLTxicj4NCkRhOiBKYXJpIEFya2tvIFttYWlsdG86amFy aS5hcmtrb0BwaXVoYS5uZXRdIDxicj4NCkludmlhdG86IGdpb3ZlZMOsIDE2IG1hcnpvIDIwMTcg MTU6MDk8YnI+DQpBOiBUaGUgSUVTRzxicj4NCkNjOiBkcmFmdC1pZXRmLW1wbHMtdHAtdGVtcG9y YWwtaGl0bGVzcy1wc21AaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10cC10ZW1wb3JhbC1oaXRs ZXNzLXBzbUBpZXRmLm9yZzsgRGF2aWQgU2luaWNyb3BlOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsg ZGF2aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbTsgbXBsc0BpZXRmLm9yZzxicj4NCk9nZ2V0dG86 IEphcmkgQXJra28ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbXBscy10cC10ZW1wb3JhbC1oaXRs ZXNzLXBzbS0xMzogKHdpdGggRElTQ1VTUyk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5KYXJp IEFya2tvIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZHJhZnQtaWV0Zi1tcGxzLXRwLXRl bXBvcmFsLWhpdGxlc3MtcHNtLTEzOiBEaXNjdXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3Qg YW5kIHJlcGx5IHRvIGFsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFz ZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9k aXNjdXNzLWNyaXRlcmlhLmh0bWwiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXRw LXRlbXBvcmFsLWhpdGxlc3MtcHNtLyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtLzwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5ESVNDVVNTOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGV3 YXJ0IEJyeWFudCdzIEdlbi1BUlQgcmV2aWV3IGNvbW1lbnRzIGRlc2VydmUgbW9yZSBkaXNjdXNz aW9uLCBpbiBteTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+b3Bpbmlv bi4gUGVyaGFwcyB0aGF0IHJlc3BvbnNlIGlzIGluIHRoZSB3YXkgb2Ygc2hvd2luZyB0aGF0IFN0 ZXdhcnQgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPndyb25nLCBv ciB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBrbm93aW5nbHkgY2hvc2VuIGEgcGFydGljdWxh ciBwYXRoLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+b3IgdGhhdCBz b21lIGNsYXJpZmljYXRpb24gb3IgY2hhbmdlcyBhcmUgbmVlZGVkIGluIHRoZSBkb2N1bWVudC4g QnV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zdWJzdGFudGlhbCBj b21tZW50cyBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiBzb21lIGZhc2hpb24sIGFuZCBJIGRvbid0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5mZWVsIHdlJ3JlIHF1aXRl IHRoZXJlIHlldC4gQnV0IEkgYWxzbyBkaWRuJ3Qgc2VlIG11Y2ggZGlzY3Vzc2lvbiBvbiBteTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZS1tYWlsIHNlYXJjaCwgaXQg aXMgcG9zc2libGUgb2YgY291cnNlIHRoYXQgZGlzY3Vzc2lvbiBoYXBwZW5lZCB3aXRob3V0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5tZSBzZWVpbmcgaXQgKEknbSBu b3Qgb24gdGhlIE1QTFMgV0cgbGlzdCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFs bCB0aGF0IGJlaW5nIHNhaWQsIHRoaXMgRGlzY3VzcyBwb3NpdGlvbiBpcyBhIHJlcXVlc3QgZm9y IGRpc2N1c3Npb24sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5idXQg SSBkbyBub3QgcGxhbiB0byBob2xkIG9uIHRvIGl0IGJleW9uZCB0aGlzIHRlbGVjaGF0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2Nz cyI+DQo8IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnll czt9DQotLT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJp YWw7IGZvbnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0 aD0iMzk1Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8gbWVzc2FnZ2lvIGUg aSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJz b25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaQ0KIGFsdHJhIGF6 aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNv bm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3Rv IGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5l IGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxh IHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxwIGFsaWdu PSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0Ii PlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzxz cGFuIGNsYXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48aT48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtt c28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1heSBjb250YWluIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4g RGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBp cyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0 aGUgc2VuZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8L3NwYW4+PC9zcGFu PjwvcD4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5OlZl cmRhbmEiPjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEku RGlzY2xhaW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0iMjYiIGhlaWdodD0i NDAiPlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24g w6ggbmVjZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2494b7e2831c423982e8e9113d2989cdTELMBXA05RM001telecomit_-- --_e07cfd4f-aff1-4e7e-a351-bd5af7ccf7d0_ 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= --_e07cfd4f-aff1-4e7e-a351-bd5af7ccf7d0_-- From nobody Fri Mar 17 16:10:00 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E60312964F; Fri, 17 Mar 2017 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_ZiLn6eFgCV; Fri, 17 Mar 2017 16:09:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBCA12952D; Fri, 17 Mar 2017 16:09:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 07876B80D87; Fri, 17 Mar 2017 16:09:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, mpls@ietf.org Message-Id: <20170317230940.07876B80D87@rfc-editor.org> Date: Fri, 17 Mar 2017 16:09:40 -0700 (PDT) Archived-At: Subject: [mpls] RFC 8029 on Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 23:09:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8029 Title: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures Author: K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen Status: Standards Track Stream: IETF Date: March 2017 Mailbox: kireeti.kompella@gmail.com, swallow.ietf@gmail.com, cpignata@cisco.com, naikumar@cisco.com, aldrin.ietf@gmail.com, mach.chen@huawei.com Pages: 78 Characters: 174158 Obsoletes: RFC 4379, RFC 6424, RFC 6829, RFC 7537 Updates: RFC 1122 I-D Tag: draft-ietf-mpls-rfc4379bis-09.txt URL: https://www.rfc-editor.org/info/rfc8029 DOI: 10.17487/RFC8029 This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 nobody Fri Mar 17 20:48:04 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CAE129630; Fri, 17 Mar 2017 20:47:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Cc: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-residence-time@ietf.org, mpls-chairs@ietf.org, "Loa Andersson" , "The IESG" , rfc-editor@rfc-editor.org, loa@pi.nu MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148980887040.21320.15560310484304262081.idtracker@ietfa.amsl.com> Date: Fri, 17 Mar 2017 20:47:50 -0700 Archived-At: Subject: [mpls] Protocol Action: 'Residence Time Measurement in MPLS network' to Proposed Standard (draft-ietf-mpls-residence-time-15.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 03:47:50 -0000 The IESG has approved the following document: - 'Residence Time Measurement in MPLS network' (draft-ietf-mpls-residence-time-15.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ Technical Summary This document specifies a new Generic Associated Channel for Residence Time Measurement and describes how it can be used by time synchronization protocols within a MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a Precision Time Protocol event message. Working Group Summary The working group processing of this group was fairly smooth, experts in the area have ben chiming in and very much improved the document. There has been a high degree of collaboration between members of the MPLS, TICTOC and BMWG Working Groups. There are currently 6 co- authors listed on the front page. This was discussed (chairs, shepherd, AD and authors), we said that considering the level of contribution from different sources, we agreed that it is motivated to have all 6 authors listed on the front page. Document Quality We are aware of intentions to implement this specification, an Implementation Poll has been started and the Write-Up will be added as new information is available. Personnel Who is the Document Shepherd for this document? Loa Andersson Who is the Responsible Area Director? Deborah Brungard From nobody Wed Mar 22 03:25:16 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EEE128CDB; Wed, 22 Mar 2017 03:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UthRdlJU1Ap; Wed, 22 Mar 2017 03:25:09 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36A2129480; Wed, 22 Mar 2017 03:25:08 -0700 (PDT) Received: from [172.20.9.46] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 03F6C18013DA; Wed, 22 Mar 2017 11:25:06 +0100 (CET) To: "draft-izh-ccamp-flexe-fwk@ietf.org" , "mpls-chairs@ietf.org" , pce@ietf.org, TEAS WG , "routing-discussion@ietf.org" References: <943b685f-1403-09e4-fba2-b0d9d1ad64eb@pi.nu> Cc: "ccamp-chairs@tools.ietf.org" , "Andrew G. Malis" , Ignas Bagdonas , "n.leymann@telekom.de" , Stewart Bryant , Deborah A Brungard , "ccamp@ietf.org" , "mpls@ietf.org" From: Loa Andersson Message-ID: <3906fe87-3871-ce18-3fa1-235dc4fadbbf@pi.nu> Date: Wed, 22 Mar 2017 18:25:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <943b685f-1403-09e4-fba2-b0d9d1ad64eb@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Change of date and time: Re: FlexE side meeting at a new time -- Tuesday at 18:45 in Zurich B X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:25:15 -0000 Folks, The FlexE side meeting (see below) has been rescheduled the new time is Tuesday March 22 at 18:45 in Zurich B. Sorry for ant inconveniences. /Loa On 2017-03-17 09:17, Loa Andersson wrote: > Folks, > > On Monday March 27 in Zurich B , there will be a FlexE side meeting > from 18:30-20:00. The meeting will be chaired bt Daniele Ceccarelli > and Nic Leyman. The initiative for this meeting were taken within the > group that works on a FlexE Framework document (draft-izh-ccamp- > flexe-fwk), and has been sponsored by Deborah Brungard and the ccamp > working group co-chairs. > > The intent is to bring people up to speed on the FlexE technology and > try to understand what work will be appropriate to do in the IETF. > > The agenda will be: > > 1. FlexE background and origins: Haomian Zheng > 2. FlexE Technology Deep Dive: Iftekhar Hussain > 3. FlexE in the IETF: Mach Chen > 4. Open Mic > > Each presentation is panned to last 20 min, and the Open Mic 30 min. > > > /Daniele, Fatai and Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Mar 22 06:04:29 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF951297CB for ; Wed, 22 Mar 2017 06:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1qb_NvEG1Gc for ; Wed, 22 Mar 2017 06:04:19 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDAF1297D0 for ; Wed, 22 Mar 2017 06:04:00 -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 v2MC1pXr016729; Wed, 22 Mar 2017 12:01:51 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2MC1kII016632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2017 12:01:50 GMT Reply-To: From: "Adrian Farrel" To: Date: Wed, 22 Mar 2017 12:01:48 -0000 Message-ID: <092401d2a304$18a021f0$49e065d0$@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: AdKjAfuXdnt08d4ZROKPFkUNmMwj0g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22956.006 X-TM-AS-Result: No--1.985-10.0-31-10 X-imss-scan-details: No--1.985-10.0-31-10 X-TMASE-MatchedRID: iv01+ZwXeFIMeUy96gk4BAPZZctd3P4Bq8zyGnyMiHQm1kf23NRabg+Y 03vjORO0MX/2wRtF20QpklIgnYODOJNPnS9GFVSg6RQpiPVHMpzXO6omeezMleznxfqv/qRmtTD LZLR3mBESMR49tQQx5JGTpe1iiCJqtD9qpBlNF8o7qnMAZEGUXNmzcdRxL+xwKrauXd3MZDVBQF 3Hv1FCuWIfDca1AsWU5A6yIf3WB/J8enoJqFzznze87kOzyj6VKtQkmqFIiivhTo4H4x6+rY2TP MdDwkLrxVUqph8xfT3fm+4tYxS2QafItuohgjfnw/3NmPJsa4pNWfnUnboMLyBJEZlhLWrQQwym txuJ6y0= Archived-At: Subject: [mpls] Status of X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 13:04:22 -0000 Hi, Here is the status of this WG draft... - Not on the agenda in Chicago - Target is Experimental - 02 version - Posted 9/20/17 - Minor nits of spelling, grammar, and style. - Added Section 1.2 "Existing Security Tools for MPLS Data". - Small changes for clarification. - Update references. - Current revision about to expire - Plan to refresh as keep-alive - Implementation status - Several attempts to achieve academic implementations failed - Students' life plans not consistent with writing code - Excellent candidate for OpenSource project Adrian From nobody Thu Mar 23 01:07:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D9112E76A; Thu, 23 Mar 2017 01:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ii-PIai-Kc1; Thu, 23 Mar 2017 01:07:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B331317DD; Thu, 23 Mar 2017 01:07:26 -0700 (PDT) Received: from [172.20.9.46] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5D8F91802A16; Thu, 23 Mar 2017 09:07:24 +0100 (CET) To: "draft-izh-ccamp-flexe-fwk@ietf.org" , "mpls-chairs@ietf.org" , pce@ietf.org, TEAS WG , "routing-discussion@ietf.org" References: <943b685f-1403-09e4-fba2-b0d9d1ad64eb@pi.nu> <3906fe87-3871-ce18-3fa1-235dc4fadbbf@pi.nu> Cc: Ignas Bagdonas , "mpls@ietf.org" , "ccamp-chairs@tools.ietf.org" , Deborah A Brungard , "ccamp@ietf.org" , "n.leymann@telekom.de" From: Loa Andersson Message-ID: <2cb8e8e6-0412-f8aa-311a-bc2ae84364b1@pi.nu> Date: Thu, 23 Mar 2017 16:07:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3906fe87-3871-ce18-3fa1-235dc4fadbbf@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] Change of date and time: Re: FlexE side meeting at a new time -- Tuesday at 18:45 in Zurich B X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 08:07:29 -0000 All, Sorry to clog your in inboxes, but there is an error in the changes message. The meeting will take place: Tuesday March 28 at 18:45 in Zurich B ^^ /Loa On 2017-03-22 18:25, Loa Andersson wrote: > Folks, > > The FlexE side meeting (see below) has been rescheduled the new time > is Tuesday March 22 at 18:45 in Zurich B. > > Sorry for ant inconveniences. > > /Loa > > On 2017-03-17 09:17, Loa Andersson wrote: >> Folks, >> >> On Monday March 27 in Zurich B , there will be a FlexE side meeting >> from 18:30-20:00. The meeting will be chaired bt Daniele Ceccarelli >> and Nic Leyman. The initiative for this meeting were taken within the >> group that works on a FlexE Framework document (draft-izh-ccamp- >> flexe-fwk), and has been sponsored by Deborah Brungard and the ccamp >> working group co-chairs. >> >> The intent is to bring people up to speed on the FlexE technology and >> try to understand what work will be appropriate to do in the IETF. >> >> The agenda will be: >> >> 1. FlexE background and origins: Haomian Zheng >> 2. FlexE Technology Deep Dive: Iftekhar Hussain >> 3. FlexE in the IETF: Mach Chen >> 4. Open Mic >> >> Each presentation is panned to last 20 min, and the Open Mic 30 min. >> >> >> /Daniele, Fatai and Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Mar 23 08:11:29 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E342E129476; Thu, 23 Mar 2017 08:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgDDZMkXbzSr; Thu, 23 Mar 2017 08:11:25 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50862129481; Thu, 23 Mar 2017 08:11:25 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id r137so28582958pfr.3; Thu, 23 Mar 2017 08:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding:content-disposition; bh=0avt/n5sspto2XYaby1H4GcE75YXqgkllTUc0ybyrjY=; b=jgD2ekB448RzRZihge672QsbiHV5D1HLvUZR52kCxNLkdGuEvVx9Jo8w2o4Yvsq4vo 3DzRK78qYgaYlPZwAXx08l3a561cHnk2hyWwa9NcpybSRHfIcYGEIz7Z0On3HXhJoapt hj0UZyvieKa8qk/okaHTFRnUe03EkPnvxYKoN91ef3LCkLhJFkFFHumLQ2vKfMDElLlK UU4t63xLHtmFZpF+58sGMKh1lqFNN3ebhqelVxuDz7/qPABid+pb19RFqmiVoJX2WaCz BMKZbhPyJ604XtlV7rb6ka61r4AZUjA94eWNRn3YAceNqBasA4pP9AxsElyD/MqoKiGa x+Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding :content-disposition; bh=0avt/n5sspto2XYaby1H4GcE75YXqgkllTUc0ybyrjY=; b=nOtfXP6ddUZTC16K9Q9lge5XZeDA/SnfhGPD74gWxgIT7DV+rnJHf2Hrz96NtmYTba owfhp1dJyULWvbaHoYVbyw4a/wNRgaBUSjqyEWLpU0TydO5o4nokTyEaS0+vFzK5EQlB WffelRJm2R9SiCsb6FAFLlWAoJOkZYgXTe3NedJ6mDSTsNdu0i1oM5E6W4eAyXxOq1an Ec3oSfVh4pZRZGuPtiClJc+hD4yt1CypI1LNYv9sk6t8MkZTiJJRpoDjIYtQS+g4K5rS 9nQAI+nLdR4UUSwTTLmMx5dYNvE5iPtRVKXtzGHbOPAXDR1IXshts1Ts8f0Yef/M6w7S 0abw== X-Gm-Message-State: AFeK/H2RgJAE8DZD6365WXW3pdgQzJ7uukDS7Ql+h8PPm7DP3TqGYVDsXQ8DI2GXHGMrdA== X-Received: by 10.99.175.66 with SMTP id s2mr3590275pgo.30.1490281884836; Thu, 23 Mar 2017 08:11:24 -0700 (PDT) Received: from LLIOK4RX6E0B076 ([103.251.128.66]) by smtp.gmail.com with ESMTPSA id n15sm10984707pfj.18.2017.03.23.08.11.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 08:11:23 -0700 (PDT) Date: Thu, 23 Mar 2017 23:14:05 +0800 From: "lizho.jin" To: Loa Andersson , draft-bryant-mpls-rfc6374-sfl Cc: huubatwork , "Andrew G. Malis" , Vishwas Manral , mpls-chairs , mpls Message-ID: <20653DE4-B6BE-4915-AB22-0574891CD225@gmail.com> In-Reply-To: <3492a077-bc52-dd35-aed7-17fc6c749a8b@pi.nu> References: <3492a077-bc52-dd35-aed7-17fc6c749a8b@pi.nu> X-Mailer: PC MailMaster/3.3.1.1013 (Windows 7) MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:11:27 -0000
Hi,
I review this draft, and also the t= wo related S=46L draft. Overall, this document is useful and technically = sound. And I have some non-blocking comments listed below. Regarding the = adoption, I suggest to consider adopting draft-bryant-mpls-sf= l-framework-03 first, then this draft which is highly relied on the conce= pt of S=46L.

Section 3
  &nb= sp;The data service packets of the flow being instrumented are grouped
   into batches, and all the packets within a batch are= marked with the
   S=46L =5BI-D.ietf-mpls-flow-ident= =5D
=5BLizhong=5D more suitable to refer =5Bdraft-bryant-mpls-s= fl-framework=5D, not =5BI-D.ietf-mpls-flow-ident=5D

<= /div>
Section 4
   Such a pack= et may not need to be carried over an S=46L since the delay
&nb= sp;  over a particular LSP should be a function of the TC bits.
=5BLizhong=5D not understand here, adding S=46L does not change the= LSE and TC, why not possible to carry over S=46L=3F
 
Section 7
7.  Multiple Packet Delay Characteri= stics
=5BLizhong=5D is it= assumed here that all packets belong to one flow will go through the sam= e path=3F Some network equipment may not be the case. E.g., case in R=46C= 7424.

Section 7.1
   There will be a n= umber of Interval/Number pairs depending on the
   nu= mber of buckets being specified by the Querier.  If an R=46C6374
   message is being used to configure the buckets, the R= esponder MUST
   respond with 0 packets in each bucke= t until it has been configured
   for a full measurem= ent period (i.e. it was configured at the time of
   = the last response message).  Out of band configuration is permitted<= /div>
   by this mode of operation.
=5BLizhong=5D= need detail process of Query and Reponse. E.g., does the query need =22Number pkts in Bucket=22 field,= and if not, please specify.

7= .3.1.  R=46C6374 Multi-Packet Delay Measurement Message =46ormat
=5BLizhong=5D this is only for Classic Standard Deviation, right=3F= why it is not section 7.2.1=3F

7.4
<= div>
   This R=46C6374 message is carried over an LSP in th= e way described in
   =5BR=46C6374=5D and over an LSP= with an S=46L as described in Section 9
=5BLizhong=5D what's the format of query message, will it= include =22Time of =46irst Packet=22, =22Time of =46irst Packet=22, and = other fields=3F

13.1.  Al= location of PW Associated Channel Type
   As per the IANA considerations in =5BR=46C5586= =5D, IANA is requested to
   allocate the foll= owing Channel Type in the =22PW Associated Channel
   = ;Type=22 registry:

   Value  Desc= ription                   &n= bsp;TLV =46ollows  Reference
   -----  ----= -------------------------  -----------  ---------
&nb= sp;  TBD    Description MPLS Multi-Packet  No   =         This
        &n= bsp; Delay Measurement
=5BLizhong=5D there is other two message= type need to be defined here. E.g., Bucket Jitter Measurement Message =46ormat, Average Delay Measurement Message =46ormat


Regards
Lizhong

On 03/= 9/2017 11:09=EF=BC=8CLoa Ander= sson<loa=40pi.nu> wrote=EF=BC=9A
Huub, Andy, Vishwas and Lizhong,

You have been selected as MPLS-RT revie= wers for 
draft-bryant-mpls-rfc6374-sfl-03.

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

Reviews should comment on whether the d= ocument is coherent, is it
useful (ie, is it likely to be act= ually useful in operational networks), 
nd is the document technically sound=3F

We are interested in knowing whether th= e document is ready to be
considered for WG adoption (ie, it does= n't have to be perfect at this
point, but should be a good start).&nbs= p;Please remember that it often is
easier to progress the document when it=  has become a working group
document. All comments in the MPLS-RT r= eview needs to be addressed,
but please think carefully about whether&nbs= p;a comment is gating the
adoption or could just as easily be&nbs= p;addressed after the adoption.

Reviews should be sent to the document&= nbsp;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.

If you have technical comments you shou= ld try to be explicit about what
needs to be resolved before adopting it=  as a working group document, and
what can wait until the document is&nbs= p;a working group document and the
working group has the revision control.

Are you able to review this draft = by March 23, 2017=3F Please respond
whether you are available to do the&nbs= p;review in a timely fashion.


Thanks, Loa
(as MPLS WG co-chair)
-- 


Loa Andersson        &nb= sp;           &nbs= p;   email: loa=40mail01.huawei.com
Senior MPLS Expert       = ;            =        loa=40pi.nu
Huawei Technologies (consultant)    &nb= sp;phone: +46 739 81 21 64
<=21--=F0=9F=98=80-->
From nobody Sat Mar 25 01:55:45 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2AE124281; Sat, 25 Mar 2017 01:55:43 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngvu_4ad6dqs; Sat, 25 Mar 2017 01:55:40 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 96CA61293FB; Sat, 25 Mar 2017 01:55:37 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee258d63082635-0b645; Sat, 25 Mar 2017 16:55:30 +0800 (CST) X-RM-TRANSID: 2ee258d63082635-0b645 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[183.240.196.121]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee558d630812c5-1ea35; Sat, 25 Mar 2017 16:55:30 +0800 (CST) X-RM-TRANSID: 2ee558d630812c5-1ea35 From: "Weiqiang Cheng" To: "'Mach Chen'" , Cc: , , References: In-Reply-To: Date: Sat, 25 Mar 2017 16:55:29 +0800 Message-ID: <008501d2a545$8e3f3840$aabda8c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHSjcZujP4pQeKD5EC3MI1pw61Qg6GlbAVw Content-Language: zh-cn Archived-At: Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 08:55:43 -0000 Hi Mach, Thanks a lot for your comments. An updated version of = draft-ietf-mpls-tp-shared-ring-protection which solves your comments = will be submitted when the submission is open again.=20 And please see some replies inline: > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Monday, February 27, 2017 6:05 PM > To: 'rtg-ads@ietf.org' > Cc: 'rtg-dir@ietf.org' ;=20 > 'draft-ietf-mpls-tp-shared-ring-protection@ietf.org' > ; mpls@ietf.org > Subject: [mpls] RtgDir review:=20 > draft-ietf-mpls-tp-shared-ring-protection-04.txt >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this=20 > draft. The Routing Directorate seeks to review all routing or=20 > routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. > The purpose of the review is to provide assistance to the Routing ADs. = > For more information about the Routing Directorate, please see=20 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs,=20 > it would be helpful if you could consider them along with any other=20 > IETF Last Call comments that you receive, and strive to resolve them=20 > through discussion or by updating the draft. >=20 > Document: draft-ietf-mpls-tp-shared-ring-protection-04.txt > Reviewer: Mach Chen > Review Date: 2017/2/23 > IETF LC End Date: > Intended Status: Standards Track >=20 > Summary: > I have some minor concerns about this document that I think should be=20 > resolved before publication. >=20 > Comments: > This document may need some paragraph restructuration or adjustment to = > make it more readable, for example , before jumping into the detail of = > some processes, it's better to give some introduction to the scenarios = > and relevant conditions, and the used terms need to be defined before = being used. >=20 > Major Issues: > No major issues found. >=20 > Minor Issues: >=20 > 1. > The implicit fundamental pre-condition of the proposed MSRP is that,=20 > for each protected LSP, the egress and the ingress LSR have to=20 > negotiate (or through NMS, or static configurations) the LSP label = that will be pushed by the ingress. > The label has to be a label that the egress must know how to handle=20 > it, otherwise, when the packet exits the ring tunnel, the packet will=20 > be mis-forwarded to non-intended node or dropped. This condition and=20 > probably the relevant mechanisms should be explicitly pointed out and = > described in the document. [Authors] Some description about LSP label allocation will be added in = the new version. >=20 > 2. > Section 4.1 > The Figure of "the logical layers of the ring" shows the innermost=20 > service is PW, is this document only applies to PW or other=20 > applications will be included. If it's later, some modifications are=20 > needed, and you need to check the whole document to make the relevant = descriptions and usages consistent. > Figure 2 has the same problem. [Authors] Yes, other services can also be supported. In the latest = version =E2=80=9CPW=E2=80=9D is replaced by "service". >=20 > 3. > Section 4.1.3 > s/The clockwise working ring tunnel label RcW_D/ The clockwise working = > ring tunnel label of RcW_D And since RcW_D identifies a ring tunnel,=20 > not a label, and the author seems intend to use RcW_D(X) to identify a = > ring tunnel label, I'd suggest to add some clarification text to this = notation. [Authors] The sentence will be rephrased to make it clearer.=20 > 4. > Section 4.4.1 > Suggest to move Figure 11 to under "Bullet 1. Single-node=20 > interconnected rings." [Authors] Done.=20 >=20 > 5. > Section 4.4.4, the penultimate paragraph=20 > "...LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LS > P1.", what's reason to add "R1cW_F&A(D)" into the switching path?=20 > Seems it's redundant. [Authors] Agree, the redundant part will be removed.=20 > 6. > Section 4.4.3, > In my understanding, the ring tunnels to virtual interconnected group=20 > are shared by all LSPs that needed to be forwarded to other rings,=20 > right? If so, it's better to add some text to explicitly state this. [Authors] Yes, some description will be added to reflect this.=20 > 7. > Section 5.1 > " When the failure has cleared and the Wait-to-Restore (WTR) timer = has > expired, the nodes sourcing RPS requests MUST drop their respective > switches (tail end) and MUST source an RPS request carrying the NR > code. The node receiving from both directions such an RPS request > (head end) MUST drop its protection switches." >=20 > Above text introduces the "tail end" and "Head end" tems, but the=20 > document does not have detail definition and introduction to these=20 > terms. Suggest to give the definition of these term in the terminology = and notation section. [Authors] The "tail end" and "head end" will be replaced with detailed = description. > 8. > Section 5.1 > "A destination node is a node that is adjacent to a node that > identified a failed link." >=20 > Based on the above text, the "destination node" cannot be uniquely=20 > determined, since a node in a ring has two adjacent nodes. Some=20 > clarification or more accurate description is needed. [Authors] The sentence has been rephrased to make it clear. > 9. > Section 5.1.2 > s/sane ring/same ring Done. > 10. > Section 5.1.3. Ring Node RPS States >=20 > Are those RPS states per node or per ring tunnel or per egress? =20 > Whatever for either case, the document should state it explicitly. >=20 > And according to the explanation of each state, seems that the states=20 > are mutex each other. Considering the steering mode, seems that a node = > may be at both switching and pass-through state, right? >=20 > BTW, for those RPS codes, it's better to add a reference to the=20 > section (Section > 5.2.1.1) to give a hint to the reader that there will be detailed=20 > explanation in the following sections. [Authors] As indicated by the title of 5.1.3, the RPS state is per node.=20 In steering mode, a node can be in either switching or pass-through = state, but cannot be both.=20 > 11. > Section 5.1.3.2 >=20 > "A node in the switching state MUST terminate RPS requests flow in > both directions." >=20 > If a node in the switching state terminates RPS requests, how does the = > steering switching mode work? [Authors] In steering mode, upon receiving the RPS request, ring nodes = which are not the destination node would enter the pass-through state, = and the RPS request is relayed along the ring to the next node until it = reaches the destination node of the RPS request. > 12. > Section 5.1. RPS Protocol > "The described RPS protocol uses the short- > wrapping mechanism described in section 4.3.2 as an example." > Are there any differences when the RPS protocol used for wrapping and=20 > steering, if no, it should be stated clearly. Otherwise, it needs to=20 > specify the differences, or for each switching mode, define its=20 > procedures and state machine. [Authors] A sentence will be added to this section: "The RPS protocol = is applicable to all the three protection modes." >=20 > 13. > Section 5.1.3.2. Switching State, >=20 > The third paragraph describes the rules in case of unidirectional=20 > failure, but reader can not recognized this only when read the next=20 > paragraph. This section needs some restructure to make it more=20 > readable. BTW, since there are differences between unidirectional=20 > failure and bidirectional failure, there need some text to describe=20 > the rules and procedures for the bidirectional case IMHO [Authors] This section has been restructured to describe the procedures = of bidirectional failure and unidirectional failure. > 14. > Section 5.2.2. Initial States > a) > It just lists a table and let the reader to guess the meaning, it's=20 > better to add some clarification text to help the reader understand=20 > the meaning and intention. >=20 > b) > In addition: >=20 > | B | Pass-through | N/A | > | | Working: no switch | | > | | Protection: pass through | | > For pass-through state, why the working and protection tunnel states=20 > are different? [Authors] When a node is in pass-through state, it allows traffic to be forwarded = on either the working tunnel or the protection tunnel. As described in section 5.1.3, For working ring tunnel, "no switch" means traffic is carried on this = tunnel. For protection ring tunnel, "no switch" means traffic is blocked on the = protection tunnel, and "pass-through" means traffic can be forwarded on = the protection tunnel. > c) > | D | Idle - LW | NR | >=20 > What is the LW? I guess it means "Lock of Working", but it needs to=20 > be expanded it when first use. [Authors] LW means Lockout of Working, it has been expanded when first use, and = the acronym "LW" is added right after the full name. Best regards, Mach From nobody Sat Mar 25 02:59:17 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E12124281; Sat, 25 Mar 2017 02:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM6uoIZcXLe6; Sat, 25 Mar 2017 02:59:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D740B120726; Sat, 25 Mar 2017 02:59:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDL79189; Sat, 25 Mar 2017 09:59:02 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 25 Mar 2017 09:59:01 +0000 Received: from SZXEMA510-MBS.china.huawei.com ([169.254.4.102]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Sat, 25 Mar 2017 17:58:58 +0800 From: Mach Chen To: Weiqiang Cheng , "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls@ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt Thread-Index: AQHSjcZujP4pQeKD5EC3MI1pw61Qg6GlbAVwgAAEPjA= Date: Sat, 25 Mar 2017 09:58:57 +0000 Message-ID: References: <008501d2a545$8e3f3840$aabda8c0$@com> In-Reply-To: <008501d2a545$8e3f3840$aabda8c0$@com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58D63F67.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 750c85b75acbfbd84119d2f99f908fb6 Archived-At: Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 09:59:09 -0000 SGkgV2VpcWlhbmcsDQoNClRoYW5rcyBmb3IgYWRkcmVzc2luZyB0aGUgY29tbWVudHMsIEkgaGF2 ZSByZXZpZXdlZCB0aGUgdXBkYXRlIGRyYWZ0LCBJJ20gZmluZSB3aXRoIGl0Lg0KDQpCZXN0IHJl Z2FyZHMsDQpNYWNoDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2Vp cWlhbmcgQ2hlbmcgW21haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbV0NCj4gU2Vu dDogU2F0dXJkYXksIE1hcmNoIDI1LCAyMDE3IDQ6NTUgUE0NCj4gVG86IE1hY2ggQ2hlbiA8bWFj aC5jaGVuQGh1YXdlaS5jb20+OyBydGctYWRzQGlldGYub3JnDQo+IENjOiBydGctZGlyQGlldGYu b3JnOyBkcmFmdC1pZXRmLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbkBpZXRmLm9yZzsN Cj4gbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi1tcGxzLXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb24tMDQudHh0DQo+IA0KPiBIaSBNYWNoLA0K PiANCj4gVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBBbiB1cGRhdGVkIHZlcnNpb24g b2YgZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPiBzaGFyZWQtcmluZy1wcm90ZWN0aW9uIHdoaWNoIHNv bHZlcyB5b3VyIGNvbW1lbnRzIHdpbGwgYmUgc3VibWl0dGVkIHdoZW4NCj4gdGhlIHN1Ym1pc3Np b24gaXMgb3BlbiBhZ2Fpbi4NCj4gDQo+IEFuZCBwbGVhc2Ugc2VlIHNvbWUgcmVwbGllcyBpbmxp bmU6DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbXBscyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hY2ggQ2hlbg0KPiA+ IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjcsIDIwMTcgNjowNSBQTQ0KPiA+IFRvOiAncnRnLWFk c0BpZXRmLm9yZycgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ID4gQ2M6ICdydGctZGlyQGlldGYub3Jn JyA8cnRnLWRpckBpZXRmLm9yZz47DQo+ID4gJ2RyYWZ0LWlldGYtbXBscy10cC1zaGFyZWQtcmlu Zy1wcm90ZWN0aW9uQGlldGYub3JnJw0KPiA+IDxkcmFmdC1pZXRmLW1wbHMtdHAtc2hhcmVkLXJp bmctcHJvdGVjdGlvbkBpZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbbXBs c10gUnRnRGlyIHJldmlldzoNCj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJv dGVjdGlvbi0wNC50eHQNCj4gPg0KPiA+IEhlbGxvLA0KPiA+DQo+ID4gSSBoYXZlIGJlZW4gc2Vs ZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCj4gPiBk cmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5n IG9yDQo+ID4gcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRG IGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsDQo+IGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCBy ZXF1ZXN0Lg0KPiA+IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4NCj4gPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPiA+IGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gPg0KPiA+IEFsdGhvdWdo IHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcg QURzLA0KPiA+IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0g YWxvbmcgd2l0aCBhbnkgb3RoZXINCj4gPiBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlv dSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbQ0KPiA+IHRocm91Z2ggZGlzY3Vz c2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4NCj4gPiBEb2N1bWVudDogZHJhZnQt aWV0Zi1tcGxzLXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb24tMDQudHh0DQo+ID4gIFJldmlld2Vy OiBNYWNoIENoZW4NCj4gPiAgUmV2aWV3IERhdGU6IDIwMTcvMi8yMw0KPiA+ICBJRVRGIExDIEVu ZCBEYXRlOg0KPiA+ICBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiA+DQo+ID4g U3VtbWFyeToNCj4gPiBJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRvY3Vt ZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUNCj4gPiByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRp b24uDQo+ID4NCj4gPiBDb21tZW50czoNCj4gPiBUaGlzIGRvY3VtZW50IG1heSBuZWVkIHNvbWUg cGFyYWdyYXBoIHJlc3RydWN0dXJhdGlvbiBvciBhZGp1c3RtZW50IHRvDQo+ID4gbWFrZSBpdCBt b3JlIHJlYWRhYmxlLCBmb3IgZXhhbXBsZSAsIGJlZm9yZSBqdW1waW5nIGludG8gdGhlIGRldGFp bCBvZg0KPiA+IHNvbWUgcHJvY2Vzc2VzLCBpdCdzIGJldHRlciB0byBnaXZlIHNvbWUgaW50cm9k dWN0aW9uIHRvIHRoZSBzY2VuYXJpb3MNCj4gPiBhbmQgcmVsZXZhbnQgY29uZGl0aW9ucywgYW5k IHRoZSB1c2VkIHRlcm1zIG5lZWQgdG8gYmUgZGVmaW5lZCBiZWZvcmUNCj4gYmVpbmcgdXNlZC4N Cj4gPg0KPiA+IE1ham9yIElzc3VlczoNCj4gPiBObyBtYWpvciBpc3N1ZXMgZm91bmQuDQo+ID4N Cj4gPiBNaW5vciBJc3N1ZXM6DQo+ID4NCj4gPiAxLg0KPiA+IFRoZSBpbXBsaWNpdCBmdW5kYW1l bnRhbCBwcmUtY29uZGl0aW9uIG9mIHRoZSBwcm9wb3NlZCBNU1JQIGlzIHRoYXQsDQo+ID4gZm9y IGVhY2ggcHJvdGVjdGVkIExTUCwgdGhlIGVncmVzcyBhbmQgdGhlICBpbmdyZXNzIExTUiBoYXZl IHRvDQo+ID4gbmVnb3RpYXRlIChvciB0aHJvdWdoIE5NUywgb3Igc3RhdGljIGNvbmZpZ3VyYXRp b25zKSB0aGUgTFNQIGxhYmVsIHRoYXQgd2lsbA0KPiBiZSBwdXNoZWQgYnkgdGhlIGluZ3Jlc3Mu DQo+ID4gVGhlIGxhYmVsIGhhcyB0byBiZSBhIGxhYmVsIHRoYXQgdGhlIGVncmVzcyBtdXN0IGtu b3cgaG93IHRvIGhhbmRsZQ0KPiA+IGl0LCBvdGhlcndpc2UsIHdoZW4gdGhlIHBhY2tldCBleGl0 cyB0aGUgcmluZyB0dW5uZWwsIHRoZSBwYWNrZXQgd2lsbA0KPiA+IGJlIG1pcy1mb3J3YXJkZWQg dG8gbm9uLWludGVuZGVkIG5vZGUgb3IgZHJvcHBlZC4gVGhpcyBjb25kaXRpb24gYW5kDQo+ID4g cHJvYmFibHkgdGhlIHJlbGV2YW50IG1lY2hhbmlzbXMgIHNob3VsZCBiZSBleHBsaWNpdGx5IHBv aW50ZWQgb3V0IGFuZA0KPiA+IGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuDQo+IA0KPiBbQXV0 aG9yc10gU29tZSBkZXNjcmlwdGlvbiBhYm91dCBMU1AgbGFiZWwgYWxsb2NhdGlvbiB3aWxsIGJl IGFkZGVkIGluIHRoZQ0KPiBuZXcgdmVyc2lvbi4NCj4gDQo+ID4NCj4gPiAyLg0KPiA+IFNlY3Rp b24gNC4xDQo+ID4gVGhlIEZpZ3VyZSBvZiAidGhlIGxvZ2ljYWwgbGF5ZXJzIG9mIHRoZSByaW5n IiBzaG93cyB0aGUgaW5uZXJtb3N0DQo+ID4gc2VydmljZSBpcyBQVywgaXMgdGhpcyBkb2N1bWVu dCBvbmx5IGFwcGxpZXMgdG8gUFcgb3Igb3RoZXINCj4gPiBhcHBsaWNhdGlvbnMgd2lsbCBiZSBp bmNsdWRlZC4gSWYgaXQncyBsYXRlciwgc29tZSBtb2RpZmljYXRpb25zIGFyZQ0KPiA+IG5lZWRl ZCwgYW5kIHlvdSBuZWVkIHRvIGNoZWNrIHRoZSB3aG9sZSBkb2N1bWVudCB0byBtYWtlIHRoZSBy ZWxldmFudA0KPiBkZXNjcmlwdGlvbnMgYW5kIHVzYWdlcyBjb25zaXN0ZW50Lg0KPiA+IEZpZ3Vy ZSAyIGhhcyB0aGUgc2FtZSBwcm9ibGVtLg0KPiANCj4gW0F1dGhvcnNdIFllcywgb3RoZXIgc2Vy dmljZXMgY2FuIGFsc28gYmUgc3VwcG9ydGVkLiBJbiB0aGUgbGF0ZXN0IHZlcnNpb24NCj4g4oCc UFfigJ0gaXMgcmVwbGFjZWQgYnkgInNlcnZpY2UiLg0KPiANCj4gPg0KPiA+IDMuDQo+ID4gU2Vj dGlvbiA0LjEuMw0KPiA+IHMvVGhlIGNsb2Nrd2lzZSB3b3JraW5nIHJpbmcgdHVubmVsIGxhYmVs IFJjV19ELyBUaGUgY2xvY2t3aXNlIHdvcmtpbmcNCj4gPiByaW5nIHR1bm5lbCBsYWJlbCBvZiBS Y1dfRCBBbmQgc2luY2UgUmNXX0QgaWRlbnRpZmllcyBhIHJpbmcgdHVubmVsLA0KPiA+IG5vdCBh IGxhYmVsLCBhbmQgdGhlIGF1dGhvciBzZWVtcyBpbnRlbmQgdG8gdXNlIFJjV19EKFgpIHRvIGlk ZW50aWZ5IGENCj4gPiByaW5nIHR1bm5lbCBsYWJlbCwgSSdkIHN1Z2dlc3QgdG8gYWRkIHNvbWUg Y2xhcmlmaWNhdGlvbiB0ZXh0IHRvIHRoaXMgbm90YXRpb24uDQo+IA0KPiBbQXV0aG9yc10gVGhl IHNlbnRlbmNlIHdpbGwgYmUgcmVwaHJhc2VkIHRvIG1ha2UgaXQgY2xlYXJlci4NCj4gDQo+ID4g NC4NCj4gPiBTZWN0aW9uIDQuNC4xDQo+ID4gU3VnZ2VzdCB0byBtb3ZlIEZpZ3VyZSAxMSB0byB1 bmRlciAiQnVsbGV0ICAxLiAgU2luZ2xlLW5vZGUNCj4gPiBpbnRlcmNvbm5lY3RlZCByaW5ncy4i DQo+IA0KPiBbQXV0aG9yc10gIERvbmUuDQo+IA0KPiA+DQo+ID4gNS4NCj4gPiBTZWN0aW9uIDQu NC40LCB0aGUgcGVudWx0aW1hdGUgcGFyYWdyYXBoDQo+ID4gIi4uLkxTUDEtPlIxY1dfRiZBKEQp LT5SMWFQX0YmQShELT5DLT5CLT5BKS0+UjJjV19JKEEtPkYtPkctPkgtDQo+ID5JKS0+TFMNCj4g PiBQMS4iLCB3aGF0J3MgcmVhc29uIHRvIGFkZCAiUjFjV19GJkEoRCkiIGludG8gdGhlIHN3aXRj aGluZyBwYXRoPw0KPiA+IFNlZW1zIGl0J3MgcmVkdW5kYW50Lg0KPiANCj4gW0F1dGhvcnNdICBB Z3JlZSwgdGhlIHJlZHVuZGFudCBwYXJ0IHdpbGwgYmUgcmVtb3ZlZC4NCj4gDQo+ID4gNi4NCj4g PiBTZWN0aW9uIDQuNC4zLA0KPiA+IEluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSByaW5nIHR1bm5l bHMgdG8gdmlydHVhbCBpbnRlcmNvbm5lY3RlZCBncm91cA0KPiA+IGFyZSBzaGFyZWQgYnkgYWxs IExTUHMgdGhhdCBuZWVkZWQgdG8gYmUgZm9yd2FyZGVkIHRvIG90aGVyIHJpbmdzLA0KPiA+IHJp Z2h0PyBJZiBzbywgaXQncyBiZXR0ZXIgdG8gYWRkIHNvbWUgdGV4dCB0byBleHBsaWNpdGx5IHN0 YXRlIHRoaXMuDQo+IA0KPiBbQXV0aG9yc10gWWVzLCBzb21lIGRlc2NyaXB0aW9uIHdpbGwgYmUg YWRkZWQgdG8gcmVmbGVjdCB0aGlzLg0KPiANCj4gPiA3Lg0KPiA+IFNlY3Rpb24gNS4xDQo+ID4g IiAgIFdoZW4gdGhlIGZhaWx1cmUgaGFzIGNsZWFyZWQgYW5kIHRoZSBXYWl0LXRvLVJlc3RvcmUg KFdUUikgdGltZXIgaGFzDQo+ID4gICAgZXhwaXJlZCwgdGhlIG5vZGVzIHNvdXJjaW5nIFJQUyBy ZXF1ZXN0cyBNVVNUIGRyb3AgdGhlaXIgcmVzcGVjdGl2ZQ0KPiA+ICAgIHN3aXRjaGVzICh0YWls IGVuZCkgYW5kIE1VU1Qgc291cmNlIGFuIFJQUyByZXF1ZXN0IGNhcnJ5aW5nIHRoZSBOUg0KPiA+ ICAgIGNvZGUuICBUaGUgbm9kZSByZWNlaXZpbmcgZnJvbSBib3RoIGRpcmVjdGlvbnMgc3VjaCBh biBSUFMgcmVxdWVzdA0KPiA+ICAgIChoZWFkIGVuZCkgTVVTVCBkcm9wIGl0cyBwcm90ZWN0aW9u IHN3aXRjaGVzLiINCj4gPg0KPiA+IEFib3ZlIHRleHQgaW50cm9kdWNlcyB0aGUgInRhaWwgZW5k IiBhbmQgIkhlYWQgZW5kIiB0ZW1zLCBidXQgdGhlDQo+ID4gZG9jdW1lbnQgZG9lcyBub3QgaGF2 ZSBkZXRhaWwgZGVmaW5pdGlvbiBhbmQgaW50cm9kdWN0aW9uIHRvIHRoZXNlDQo+ID4gdGVybXMu IFN1Z2dlc3QgdG8gZ2l2ZSB0aGUgZGVmaW5pdGlvbiBvZiB0aGVzZSB0ZXJtIGluIHRoZSB0ZXJt aW5vbG9neSBhbmQNCj4gbm90YXRpb24gc2VjdGlvbi4NCj4gDQo+IFtBdXRob3JzXSAgVGhlICJ0 YWlsIGVuZCIgYW5kICJoZWFkIGVuZCIgd2lsbCBiZSByZXBsYWNlZCB3aXRoIGRldGFpbGVkDQo+ IGRlc2NyaXB0aW9uLg0KPiANCj4gPiA4Lg0KPiA+IFNlY3Rpb24gNS4xDQo+ID4gIkEgZGVzdGlu YXRpb24gbm9kZSBpcyBhIG5vZGUgdGhhdCBpcyBhZGphY2VudCB0byBhIG5vZGUgdGhhdA0KPiA+ ICAgIGlkZW50aWZpZWQgYSBmYWlsZWQgbGluay4iDQo+ID4NCj4gPiBCYXNlZCBvbiB0aGUgYWJv dmUgdGV4dCwgdGhlICJkZXN0aW5hdGlvbiBub2RlIiBjYW5ub3QgYmUgdW5pcXVlbHkNCj4gPiBk ZXRlcm1pbmVkLCBzaW5jZSBhIG5vZGUgaW4gYSByaW5nIGhhcyB0d28gYWRqYWNlbnQgbm9kZXMu IFNvbWUNCj4gPiBjbGFyaWZpY2F0aW9uIG9yIG1vcmUgYWNjdXJhdGUgZGVzY3JpcHRpb24gaXMg bmVlZGVkLg0KPiANCj4gW0F1dGhvcnNdIFRoZSBzZW50ZW5jZSBoYXMgYmVlbiByZXBocmFzZWQg dG8gbWFrZSBpdCBjbGVhci4NCj4gDQo+ID4gOS4NCj4gPiBTZWN0aW9uIDUuMS4yDQo+ID4gcy9z YW5lIHJpbmcvc2FtZSByaW5nDQo+IA0KPiBEb25lLg0KPiANCj4gPiAxMC4NCj4gPiBTZWN0aW9u IDUuMS4zLiAgUmluZyBOb2RlIFJQUyBTdGF0ZXMNCj4gPg0KPiA+IEFyZSB0aG9zZSBSUFMgc3Rh dGVzIHBlciBub2RlIG9yIHBlciByaW5nIHR1bm5lbCBvciBwZXIgZWdyZXNzPw0KPiA+IFdoYXRl dmVyIGZvciBlaXRoZXIgY2FzZSwgdGhlIGRvY3VtZW50IHNob3VsZCBzdGF0ZSBpdCBleHBsaWNp dGx5Lg0KPiA+DQo+ID4gQW5kIGFjY29yZGluZyB0byB0aGUgZXhwbGFuYXRpb24gb2YgZWFjaCBz dGF0ZSwgc2VlbXMgdGhhdCB0aGUgc3RhdGVzDQo+ID4gYXJlIG11dGV4IGVhY2ggb3RoZXIuIENv bnNpZGVyaW5nIHRoZSBzdGVlcmluZyBtb2RlLCBzZWVtcyB0aGF0IGEgbm9kZQ0KPiA+IG1heSBi ZSBhdCBib3RoIHN3aXRjaGluZyBhbmQgcGFzcy10aHJvdWdoIHN0YXRlLCByaWdodD8NCj4gPg0K PiA+IEJUVywgZm9yIHRob3NlIFJQUyBjb2RlcywgaXQncyBiZXR0ZXIgdG8gYWRkIGEgcmVmZXJl bmNlIHRvIHRoZQ0KPiA+IHNlY3Rpb24gKFNlY3Rpb24NCj4gPiA1LjIuMS4xKSB0byBnaXZlIGEg aGludCB0byB0aGUgcmVhZGVyIHRoYXQgdGhlcmUgd2lsbCBiZSBkZXRhaWxlZA0KPiA+IGV4cGxh bmF0aW9uIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuDQo+IA0KPiBbQXV0aG9yc10NCj4gQXMg aW5kaWNhdGVkIGJ5IHRoZSB0aXRsZSBvZiA1LjEuMywgdGhlIFJQUyBzdGF0ZSBpcyBwZXIgbm9k ZS4NCj4gDQo+IEluIHN0ZWVyaW5nIG1vZGUsIGEgbm9kZSBjYW4gYmUgaW4gZWl0aGVyIHN3aXRj aGluZyBvciBwYXNzLXRocm91Z2ggc3RhdGUsDQo+IGJ1dCBjYW5ub3QgYmUgYm90aC4NCj4gDQo+ ID4gMTEuDQo+ID4gU2VjdGlvbiA1LjEuMy4yDQo+ID4NCj4gPiAiQSBub2RlIGluIHRoZSBzd2l0 Y2hpbmcgc3RhdGUgTVVTVCB0ZXJtaW5hdGUgUlBTIHJlcXVlc3RzIGZsb3cgaW4NCj4gPiAgICBi b3RoIGRpcmVjdGlvbnMuIg0KPiA+DQo+ID4gSWYgYSBub2RlIGluIHRoZSBzd2l0Y2hpbmcgc3Rh dGUgdGVybWluYXRlcyBSUFMgcmVxdWVzdHMsIGhvdyBkb2VzIHRoZQ0KPiA+IHN0ZWVyaW5nIHN3 aXRjaGluZyBtb2RlIHdvcms/DQo+IA0KPiBbQXV0aG9yc10gSW4gc3RlZXJpbmcgbW9kZSwgdXBv biByZWNlaXZpbmcgdGhlIFJQUyByZXF1ZXN0LCByaW5nIG5vZGVzDQo+IHdoaWNoIGFyZSBub3Qg dGhlIGRlc3RpbmF0aW9uIG5vZGUgd291bGQgZW50ZXIgdGhlIHBhc3MtdGhyb3VnaCBzdGF0ZSwg YW5kDQo+IHRoZSBSUFMgcmVxdWVzdCBpcyByZWxheWVkIGFsb25nIHRoZSByaW5nIHRvIHRoZSBu ZXh0IG5vZGUgdW50aWwgaXQgcmVhY2hlcyB0aGUNCj4gZGVzdGluYXRpb24gbm9kZSBvZiB0aGUg UlBTIHJlcXVlc3QuDQo+IA0KPiA+IDEyLg0KPiA+IFNlY3Rpb24gNS4xLiAgUlBTIFByb3RvY29s DQo+ID4gIlRoZSBkZXNjcmliZWQgUlBTIHByb3RvY29sIHVzZXMgdGhlIHNob3J0LQ0KPiA+ICAg IHdyYXBwaW5nIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjMuMiBhcyBhbiBleGFt cGxlLiINCj4gPiBBcmUgdGhlcmUgYW55IGRpZmZlcmVuY2VzIHdoZW4gdGhlIFJQUyBwcm90b2Nv bCB1c2VkIGZvciB3cmFwcGluZyBhbmQNCj4gPiBzdGVlcmluZywgaWYgbm8sIGl0IHNob3VsZCBi ZSBzdGF0ZWQgY2xlYXJseS4gT3RoZXJ3aXNlLCBpdCBuZWVkcyB0bw0KPiA+IHNwZWNpZnkgdGhl IGRpZmZlcmVuY2VzLCBvciBmb3IgZWFjaCBzd2l0Y2hpbmcgbW9kZSwgZGVmaW5lIGl0cw0KPiA+ IHByb2NlZHVyZXMgYW5kIHN0YXRlIG1hY2hpbmUuDQo+IA0KPiBbQXV0aG9yc10gIEEgc2VudGVu Y2Ugd2lsbCBiZSBhZGRlZCB0byB0aGlzIHNlY3Rpb246ICJUaGUgUlBTIHByb3RvY29sIGlzDQo+ IGFwcGxpY2FibGUgdG8gYWxsIHRoZSB0aHJlZSBwcm90ZWN0aW9uIG1vZGVzLiINCj4gDQo+ID4N Cj4gPiAxMy4NCj4gPiBTZWN0aW9uIDUuMS4zLjIuICBTd2l0Y2hpbmcgU3RhdGUsDQo+ID4NCj4g PiBUaGUgdGhpcmQgcGFyYWdyYXBoIGRlc2NyaWJlcyB0aGUgcnVsZXMgaW4gY2FzZSBvZiB1bmlk aXJlY3Rpb25hbA0KPiA+IGZhaWx1cmUsIGJ1dCByZWFkZXIgY2FuIG5vdCByZWNvZ25pemVkIHRo aXMgb25seSB3aGVuIHJlYWQgdGhlIG5leHQNCj4gPiBwYXJhZ3JhcGguIFRoaXMgc2VjdGlvbiBu ZWVkcyBzb21lIHJlc3RydWN0dXJlIHRvIG1ha2UgaXQgbW9yZQ0KPiA+IHJlYWRhYmxlLiBCVFcs IHNpbmNlIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHVuaWRpcmVjdGlvbmFsDQo+ID4g ZmFpbHVyZSBhbmQgYmlkaXJlY3Rpb25hbCBmYWlsdXJlLCB0aGVyZSBuZWVkIHNvbWUgdGV4dCB0 byBkZXNjcmliZQ0KPiA+IHRoZSBydWxlcyBhbmQgcHJvY2VkdXJlcyBmb3IgdGhlIGJpZGlyZWN0 aW9uYWwgY2FzZSBJTUhPDQo+IA0KPiBbQXV0aG9yc10gVGhpcyBzZWN0aW9uIGhhcyBiZWVuIHJl c3RydWN0dXJlZCB0byBkZXNjcmliZSB0aGUgcHJvY2VkdXJlcyBvZg0KPiBiaWRpcmVjdGlvbmFs IGZhaWx1cmUgYW5kIHVuaWRpcmVjdGlvbmFsIGZhaWx1cmUuDQo+IA0KPiA+IDE0Lg0KPiA+IFNl Y3Rpb24gNS4yLjIuICBJbml0aWFsIFN0YXRlcw0KPiA+IGEpDQo+ID4gSXQganVzdCBsaXN0cyBh IHRhYmxlIGFuZCBsZXQgdGhlIHJlYWRlciB0byBndWVzcyB0aGUgbWVhbmluZywgaXQncw0KPiA+ IGJldHRlciB0byBhZGQgc29tZSBjbGFyaWZpY2F0aW9uIHRleHQgdG8gaGVscCB0aGUgcmVhZGVy IHVuZGVyc3RhbmQNCj4gPiB0aGUgbWVhbmluZyBhbmQgaW50ZW50aW9uLg0KPiA+DQo+ID4gYikN Cj4gPiBJbiBhZGRpdGlvbjoNCj4gPg0KPiA+ICAgICAgICAgICAgfCAgQiAgfCAgUGFzcy10aHJv dWdoICAgICAgICAgICAgICAgfCAgTi9BICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgfCAg ICAgfCAgIFdvcmtpbmc6IG5vIHN3aXRjaCAgICAgICAgfCAgICAgICAgICAgICAgICB8DQo+ID4g ICAgICAgICAgICAgfCAgICAgfCAgIFByb3RlY3Rpb246IHBhc3MgdGhyb3VnaCAgfCAgICAgICAg ICAgICAgICB8DQo+ID4gRm9yIHBhc3MtdGhyb3VnaCBzdGF0ZSwgd2h5IHRoZSB3b3JraW5nIGFu ZCBwcm90ZWN0aW9uIHR1bm5lbCBzdGF0ZXMNCj4gPiBhcmUgZGlmZmVyZW50Pw0KPiBbQXV0aG9y c10NCj4gV2hlbiBhIG5vZGUgaXMgaW4gcGFzcy10aHJvdWdoIHN0YXRlLCBpdCBhbGxvd3MgdHJh ZmZpYyB0byBiZSBmb3J3YXJkZWQgb24NCj4gZWl0aGVyIHRoZSB3b3JraW5nIHR1bm5lbCBvciB0 aGUgcHJvdGVjdGlvbiB0dW5uZWwuDQo+IA0KPiBBcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjEu MywNCj4gRm9yIHdvcmtpbmcgcmluZyB0dW5uZWwsICJubyBzd2l0Y2giIG1lYW5zIHRyYWZmaWMg aXMgY2FycmllZCBvbiB0aGlzIHR1bm5lbC4NCj4gRm9yIHByb3RlY3Rpb24gcmluZyB0dW5uZWws ICJubyBzd2l0Y2giIG1lYW5zIHRyYWZmaWMgaXMgYmxvY2tlZCBvbiB0aGUNCj4gcHJvdGVjdGlv biB0dW5uZWwsIGFuZCAicGFzcy10aHJvdWdoIiBtZWFucyB0cmFmZmljIGNhbiBiZSBmb3J3YXJk ZWQgb24gdGhlDQo+IHByb3RlY3Rpb24gdHVubmVsLg0KPiANCj4gPiBjKQ0KPiA+IHwgIEQgIHwg IElkbGUgLSBMVyAgICAgICAgICAgICAgICAgIHwgIE5SICAgICAgICAgICAgfA0KPiA+DQo+ID4g V2hhdCBpcyB0aGUgTFc/ICBJIGd1ZXNzIGl0IG1lYW5zICJMb2NrIG9mIFdvcmtpbmciLCBidXQg aXQgbmVlZHMgdG8NCj4gPiBiZSBleHBhbmRlZCBpdCB3aGVuIGZpcnN0IHVzZS4NCj4gW0F1dGhv cnNdDQo+IA0KPiBMVyBtZWFucyBMb2Nrb3V0IG9mIFdvcmtpbmcsIGl0IGhhcyBiZWVuIGV4cGFu ZGVkIHdoZW4gZmlyc3QgdXNlLCBhbmQgdGhlDQo+IGFjcm9ueW0gIkxXIiBpcyBhZGRlZCByaWdo dCBhZnRlciB0aGUgZnVsbCBuYW1lLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBNYWNoDQo+IA0K PiANCg0K From nobody Mon Mar 27 19:55:17 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCC91204DA; Mon, 27 Mar 2017 19:55:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149066971586.30521.5141437997659483201@ietfa.amsl.com> Date: Mon, 27 Mar 2017 19:55:15 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-tp-shared-ring-protection-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 02:55:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Shared-Ring protection (MSRP) mechanism for ring topology Authors : Weiqiang Cheng Lei Wang Han Li Huub van Helvoort Jie Dong Filename : draft-ietf-mpls-tp-shared-ring-protection-05.txt Pages : 48 Date : 2017-03-27 Abstract: This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection-05 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-tp-shared-ring-protection-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-shared-ring-protection-05 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 nobody Tue Mar 28 04:46:12 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EE91294FD; Tue, 28 Mar 2017 04:46:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149070156510.30545.18390576225108822459@ietfa.amsl.com> Date: Tue, 28 Mar 2017 04:46:05 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-mib-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 11:46:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Authors : Kishore Tiruveedhula Uwe Joorde Arvind Venkateswaran Filename : draft-ietf-mpls-mldp-mib-02.txt Pages : 37 Date : 2017-03-28 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing multicast LDP point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths. The MIB module defined in this document is extension of LDP MIB defined in RFC3815 which supports only for LDP point-to-point LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-mldp-mib-02 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mldp-mib-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-mldp-mib-02 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 nobody Tue Mar 28 10:00:29 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B95128708; Tue, 28 Mar 2017 10:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebEDny6nM0UR; Tue, 28 Mar 2017 10:00:17 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A341C129405; Tue, 28 Mar 2017 10:00:16 -0700 (PDT) X-AuditID: c1b4fb25-ce3ff70000002d78-49-58da969b6e42 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 2C.38.11640.B969AD85; Tue, 28 Mar 2017 19:00:15 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 28 Mar 2017 19:00:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BkeafmJXJc1be3jdcSN4QBnWzU0OKj5rPZ/jVV2k7lA=; b=GXDCoQ55gS5K+sLVEwHuQ9l3iPW94uPPInZDBLBbrfJr3bQ/CX7yHT2/b9ec1ku/HsE7a238Tog7SjC8J6xageD507mKbIk78VYlCYw9IPvpath86LtZh78lHKxU8hS/wkZwUWkVu1EKtkEUd6lvo+EwXZyel4RU7UDp2r/Lvz4= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1008.eurprd07.prod.outlook.com (10.161.111.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 17:00:10 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) with mapi id 15.01.1005.006; Tue, 28 Mar 2017 17:00:10 +0000 From: Daniele Ceccarelli To: "pce@ietf.org" , TEAS WG , "routing-discussion@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" CC: Loa Andersson , "N.Leymann@telekom.de" , "draft-izh-ccamp-flexe-fwk@ietf.org" , Deborah A Brungard , Ignas Bagdonas Thread-Topic: FlexE side meeting Thread-Index: AdKn49pNj71q7aJYRYuZInhREbEccw== Date: Tue, 28 Mar 2017 17:00:09 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:67c:370:128:d9ca:5ff5:e144:7b3a] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1008; 7:jUSh0AY/Cty8fWUQg1MYb6jB28P4NttGv1XPPLfLdL1zM6WfWBIsi17kiGbhtIzW1nvfF7Xhop+kRAl1DETIEQREfDFFhkZP9DYn7+H3L2eIpjTfmxef26pqSkPC5FjPhmjfS3R+HSRxQq9CpNpaYpusCuZSgNZuufhXbRX5hlusnAy7/5z2KAcrH0YGYs5W4iBAKaoWx0tQx4hrtl8MJVWcWQTl91VpCNEdp/MN+ThwMdA0A1pmSCyvnvw25V5HoSvUkE76tcsD+subIGBd9X/jFRIeN/OjPqbz9bHOP/2fbMGRG5L0Al+Y4juYZqV+pwW9n9gaK0IJRdOpalthTQ== x-ms-office365-filtering-correlation-id: 794bebe6-1f4b-44b2-a7a7-08d475fbe4c6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423063)(201703031133069); SRVR:VI1PR07MB1008; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040438)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(201703131423063)(201702281528063)(201703061421063)(201703061406063)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:VI1PR07MB1008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1008; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39450400003)(39850400002)(39860400002)(39410400002)(39840400002)(53754006)(7116003)(7736002)(2501003)(5660300001)(7906003)(7416002)(3280700002)(50986999)(54356999)(606005)(3480700004)(74316002)(86362001)(6116002)(790700001)(102836003)(2906002)(2201001)(7696004)(54896002)(15380165006)(53936002)(8936002)(81166006)(6306002)(99286003)(2900100001)(966004)(55016002)(236005)(6506006)(77096006)(9686003)(54906002)(6436002)(8676002)(33656002)(39060400002)(189998001)(38730400002)(3660700001)(4326008)(558084003)(122556002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1008; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB10054D43730534EB63F29DE6F0320VI1PR07MB1005eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 17:00:09.8295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1008 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe96709WjWZ1WkQ4mlWVlfniJKK0PjSiSPsSIIpe+qWjTNrtK ZUKms8u6rVxecwqKNhre8pK2Ii8ECXbTsrJtlaUpJZFplq/vBL/9zv9/znnOHx6O9OujFVy8 LkXQ67SJSkZG5Whq16wqMPdo1jyuonlX7muK7zJms/zdT1v5n2ezKH4iL5fke0rKaP5q0XWC T3//muXbrNUMf+53HRUuU/dfzkXq+5ZeVm21jhJqy80MRp3RHxBJ75FtiBES448K+tUbo2Rx dTeGiOT0hcfd9RNsGqqcb0ReHOAw+HhhiDIiGeeHbQgacppYqWhDMD5YQogFhS+ScH28CUmO mYC0X/m0VDxBcKXRyhgRxzF4Pbgc20XdHzcjqKk1kmJBYjeCitFBQnxxLl4Mt3rLKJH9cSBY 3bmExCFgLnJPMYVVcKPYzogsx3uhuOQzKzLCS8DUcAeJTOIF0OMqIKQUGKyNz0iJ50G/c2Lq OoSzEQznv/Q08VD94hUjGoAvkPCmo5gWzwa8A5zGZVLPabD11noWJYBtrN0zux4yr7TS0uw7 Auo7nB5jMZQ8yvMs7aahw9ZHSzEV0Ps8C01H/vK2iZbOToLP5mukFM0X2nNclAkFWWYkssxo s8xok/SVUNjwg5E4GEqLvpHT/LTFSczUCxFbjuYZBMOBQ7Gh60IEfXy0wZCkC9EJKXY0+fEe Vo2p6lDXQIQDYQ4pfeQfFN0aP1p71HDikAMBRyr95b+8JyV5jPbESUGftF9/JFEwONAijlIu kEc86NT44VhtipAgCMmCftolOC9FGmIHtthXbFJtjC4uCDo3emx3c3kLBw3PjrhPnXWG1c8u 1TFsZMzIqr8jSd9dAaEaXeOuzFlkanT+5lZz3LbDyP4vYuJBW0Xn15PU+ZvDK+f4Vibeq3Ec DEwoilU1K9/vi43SBF9b7p3fvNTHa2lqZOixnb6qzMPht02Xzqj/mJ70ZSkpQ5x27QpSb9D+ B1HP7gl0AwAA Archived-At: Subject: [mpls] FlexE side meeting X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:00:20 -0000 --_000_VI1PR07MB10054D43730534EB63F29DE6F0320VI1PR07MB1005eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, a reminder for the FlexE side meeting and the link to Meetecho: When: Tuesday 18:45-20:15 Room: Zurich B Remote participation - Meetecho: http://www.meetecho.com/ietf98/CCAMP-FlexE BR Daniele, Nic, Loa --_000_VI1PR07MB10054D43730534EB63F29DE6F0320VI1PR07MB1005eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

a reminder for the FlexE side m= eeting and the link to Meetecho:

 

When: Tuesday 18:45-20:15<= /o:p>

Room: Zurich B

Remote participation - Meetecho= : http://www.meetecho.com/ietf98/CCAMP-FlexE

 

BR
Daniele, Nic, Loa

--_000_VI1PR07MB10054D43730534EB63F29DE6F0320VI1PR07MB1005eurp_-- From nobody Tue Mar 28 10:10:37 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF211294AA; Tue, 28 Mar 2017 10:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8HKJVQJ1udz; Tue, 28 Mar 2017 10:10:33 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9EA129454; Tue, 28 Mar 2017 10:10:32 -0700 (PDT) X-AuditID: c1b4fb25-ce3ff70000002d78-ba-58da9906f5c0 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 55.89.11640.6099AD85; Tue, 28 Mar 2017 19:10:30 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 28 Mar 2017 19:10:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W3KBmLDQTWqkY8YDZQgbWZdmAihZG1H3ziOLyMqbLnI=; b=b7i3hVAS4PXoFoEU6RIO8dELbLGmBaJt/1vt+BsvEJDnlHI4P8MUPrxdGnaR8HbWt2h+jW54Urbvzd+XxNTmfTJw0ZSmL0Yy94i6r0k7yS9H11fxVbnmSWglVY//JbfzGO6S6XZo8Km/WjoG1Nz3LSqr1YL/ZMv42Qk3dES+5Dk= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 17:10:27 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) with mapi id 15.01.1005.006; Tue, 28 Mar 2017 17:10:27 +0000 From: Daniele Ceccarelli To: Daniele Ceccarelli , "pce@ietf.org" , TEAS WG , "routing-discussion@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" CC: Ignas Bagdonas , "draft-izh-ccamp-flexe-fwk@ietf.org" , "N.Leymann@telekom.de" Thread-Topic: [CCAMP] FlexE side meeting Thread-Index: AdKn49pNj71q7aJYRYuZInhREbEccwAAkarA Date: Tue, 28 Mar 2017 17:10:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:67c:370:128:d9ca:5ff5:e144:7b3a] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1005; 7:3Fa4MxRQ+FgJ89IS+6yRvAWTPdgqQtOs1TiwHrulHlRPyIM+SIt6z1gq9CmP9T8mNEERFEfV0c+l3Yg0fu+SSeQWYG8GmgmaVTDLBODBYiex6k7fi+tY1GCTfRwna8hKFXHuwmJdG126OBwgxiKRvOLOYLhiTLu0R9uM/hUrLzewcV76mUpkBBGHU/YPt3OjA/nIcTKfwv33eXzMJQhKizOb/GxUSwDqOwHwOv/YI8AXIsYnR8+aGzzQtp1MgaROkdHHG4foL6v2UtV8OuMv0hh9JGFd41n+nBW6iNJ5e2T/1x9lhb4+doP4dGDYl/1MMVp4Xw6cJzjd4PMW8us7Vw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39850400002)(39400400002)(39840400002)(39450400003)(39410400002)(53754006)(38730400002)(3280700002)(2501003)(5660300001)(229853002)(74316002)(2906002)(189998001)(76176999)(39060400002)(6246003)(54356999)(15380165006)(3660700001)(122556002)(50986999)(7736002)(4326008)(2900100001)(7906003)(7696004)(2950100002)(8936002)(33656002)(77096006)(6436002)(6506006)(8676002)(54896002)(81166006)(53546009)(99286003)(236005)(54906002)(25786009)(9686003)(2201001)(6306002)(55016002)(102836003)(86362001)(606005)(790700001)(966004)(53936002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1005; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 71e1fb18-bea5-4ef8-35e2-08d475fd548d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423063)(201703031133069); SRVR:VI1PR07MB1005; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040438)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(201703131423063)(201702281528063)(201703061421063)(201703061406063)(20161123560025)(6072148); SRVR:VI1PR07MB1005; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1005; x-forefront-prvs: 0260457E99 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1005A7B83B7605A5E10053BCF0320VI1PR07MB1005eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 17:10:26.5083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1005 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGObt3917N1Wkp/pkFMRNN07KMLpGhRLgPFfWhGFnkzJtJc8au WvYhrEhTlPKlUktta1NmL45IKnKW6229aWLS2rSyNLOCsKIUY+bdKfDb73ke/m+Hw1HKZ3IV l2XIFYwGnV7NBNK12hvRsUytR7vs4tdYfui8m+avfkzhfxwpoXmP1SbnK03VMv7oWzfLuyxt DH98/CadxGlu1Q2wGotlQqYpGl24mdoeuCZD0GflC8ala9MC93bWupj9V+IPPjG10oVoNKYU BXCAE8DuOSYvRYGcErciKH3WTRPhQmA3W/2CxuUUmJ/eRiQ5IwOv1yIj4iEC58jEtOA4Bq+G IecGyQ/GvxE89E5SkqCwFUFDz3OZNHEejoSOwQuUxME4Chw/pekSL4eJiX5WakTjCPCUzJFs Bd4B7spmVmLlNLdftvtLA/BO6G15gCRGeAGcum32M4VDwTPUKCPHYbC0d1OEQ2D0g89/KMJV CE62NzAk4KGt7xUjBYDLKPCN3WVJMCyH0vFVhDfCoLnnX8Fh+H2j+d+EfVDh6UWEV8OJikdy 0uiNDC613KFJMB+s9+oZcr0KBl6WIMLz4VO/Q34KRdXN2JxwDrTV9LF1/heYC49rh2jix4H7 dDVDOAaaTF8owrFQ43PSM/0LiG1BIaIgpmdnLl8RJxizdotijiHOIOReQ9N/rPP6ZMRN1Ps1 2Ykwh9RBineq11qlXJcvFmQ7EXCUOljxa9a0pcjQFRwSjDm7jHl6QXSiMI5WhyqSO15olThT lyvsE4T9gvF/KuMCVIVodubY5I4lNQcS/7jykrzlxT8aF6d0bSqyp0WatphGwtwxaVNlbeln newC5k/Vd1u8rWE8Y16Wsn5RRfW6z7sS68vOhatD7hrMv6IbHzv2LG6Vp+q/fBP3DFwMC1Ld dySk2k5MsUGdXdQqzbaK3d0JK0J975uwt39lQX7x1uHw9T41Le7VxUdTRlH3F3N5GVJfAwAA Archived-At: Subject: Re: [mpls] [CCAMP] FlexE side meeting X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:10:36 -0000 --_000_VI1PR07MB1005A7B83B7605A5E10053BCF0320VI1PR07MB1005eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ...and the agenda >> The agenda will be: >> >> 1. FlexE background and origins: Haomian Zheng >> 2. FlexE Technology Deep Dive: Iftekhar Hussain >> 3. FlexE in the IETF: Mach Chen >> 4. Open Mic From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: marted=EC 28 marzo 2017 12:00 To: pce@ietf.org; TEAS WG ; routing-discussion@ietf.org; mpl= s@ietf.org; ccamp@ietf.org Cc: Ignas Bagdonas ; draft-izh-ccamp-flexe-fwk@ietf.org= ; N.Leymann@telekom.de Subject: [CCAMP] FlexE side meeting Hi everyone, a reminder for the FlexE side meeting and the link to Meetecho: When: Tuesday 18:45-20:15 Room: Zurich B Remote participation - Meetecho: http://www.meetecho.com/ietf98/CCAMP-FlexE BR Daniele, Nic, Loa --_000_VI1PR07MB1005A7B83B7605A5E10053BCF0320VI1PR07MB1005eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

…and the agenda

 

>> The agenda will be:=

>> 

>> 1. FlexE background= and origins: Haomian Zheng

>> 2. FlexE Technology= Deep Dive:   Iftekhar Hussain

>> 3. FlexE in the IET= F:            Mach C= hen

>> 4. Open Mic

 

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: marted=EC 28 marzo 2017 12:00
To: pce@ietf.org; TEAS WG <teas@ietf.org>; routing-discussion@= ietf.org; mpls@ietf.org; ccamp@ietf.org
Cc: Ignas Bagdonas <ibagdona@gmail.com>; draft-izh-ccamp-flexe= -fwk@ietf.org; N.Leymann@telekom.de
Subject: [CCAMP] FlexE side meeting

 

Hi everyone,=

 

a = reminder for the FlexE side meeting and the link to Meetecho:

 

Wh= en: Tuesday 18:45-20:15

Ro= om: Zurich B

Re= mote participation - Meetecho: http://www.meetecho.= com/ietf98/CCAMP-FlexE

 

BR=
Daniele, Nic, Loa

--_000_VI1PR07MB1005A7B83B7605A5E10053BCF0320VI1PR07MB1005eurp_-- From nobody Tue Mar 28 11:23:06 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 497741299B8; Tue, 28 Mar 2017 11:22:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149072537825.1283.10211341750934588513@ietfa.amsl.com> Date: Tue, 28 Mar 2017 11:22:58 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:22:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Opportunistic Security in MPLS Networks Authors : Adrian Farrel Stephen Farrell Filename : draft-ietf-mpls-opportunistic-encrypt-03.txt Pages : 38 Date : 2017-03-28 Abstract: This document describes a way to apply opportunistic security between adjacent nodes on an MPLS Label Switched Path (LSP) or between end points of an LSP. It explains how keys may be agreed to enable encryption, and how key identifiers are exchanged in encrypted MPLS packets. Finally, this document describes the applicability of this approach to opportunistic security in MPLS networks with an indication of the level of improved security as well as the continued vulnerabilities. This document does not describe security for MPLS control plane protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-opportunistic-encrypt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-03 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-opportunistic-encrypt-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-opportunistic-encrypt-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 nobody Tue Mar 28 11:25:16 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D111296FF for ; Tue, 28 Mar 2017 11:25:15 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lbtlwU5pEeO for ; Tue, 28 Mar 2017 11:25:13 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C701297ED for ; Tue, 28 Mar 2017 11:25:08 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2SIP6vu016952 for ; Tue, 28 Mar 2017 19:25:06 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2SIP3xJ016858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Mar 2017 19:25:05 +0100 Reply-To: From: "Adrian Farrel" To: References: <149072537825.1283.10211341750934588513@ietfa.amsl.com> In-Reply-To: <149072537825.1283.10211341750934588513@ietfa.amsl.com> Date: Tue, 28 Mar 2017 19:25:04 +0100 Message-ID: <023501d2a7f0$a0af5340$e20df9c0$@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: AQGBVJ7mis3WWXGsFL8MrWIy1alkr6JNN8lw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22970.007 X-TM-AS-Result: No--11.252-10.0-31-10 X-imss-scan-details: No--11.252-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvjlMOLj7fx09vHkpkyUphL9Ud7Bjfo+5jQkj7nyXxwWM8Ki gQM2uK1bIWzmoUykPQiISleZ//blDfeCv1PcqE/eCLNfGU4dffgZKp0SZ4P+dWsxtqQk3w550IS bJBSoCMNhJ5Zyqn1oSxG02jfbek+OKtoNRlFqVkeBbn8pczfpvpnaxzJFBx6vBMjYv8ffQVUVL/ X4YHmrBvOqUDFnyCMFBjJOMVCX9gqOGtq4RwLbmbxygpRxo469IZm2INWXDp5k2J2ef3Nd3/TrP 5e8ec7BsBb3Q0HEUXwFnwbZRaSvqQzyMxeMEX6wOX/V8P8ail3InWAWA4yE6foA9r2LThYYKrau Xd3MZDXt+7WsvSOmiyKSHG4L+9vVAefvkJx+Zrs1HEHY8JLAvWgDeG6O1rXK Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-opportunistic-encrypt-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:25:15 -0000 As mentioned in today's meeting, this is just a keep-alive. Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 28 March 2017 19:23 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-opportunistic-encrypt-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching of the IETF. > > Title : Opportunistic Security in MPLS Networks > Authors : Adrian Farrel > Stephen Farrell > Filename : draft-ietf-mpls-opportunistic-encrypt-03.txt > Pages : 38 > Date : 2017-03-28 > > Abstract: > This document describes a way to apply opportunistic security between > adjacent nodes on an MPLS Label Switched Path (LSP) or between end > points of an LSP. It explains how keys may be agreed to enable > encryption, and how key identifiers are exchanged in encrypted MPLS > packets. Finally, this document describes the applicability of this > approach to opportunistic security in MPLS networks with an > indication of the level of improved security as well as the continued > vulnerabilities. > > This document does not describe security for MPLS control plane > protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-opportunistic-encrypt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-opportunistic-encrypt-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-opportunistic-encrypt-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/ > > _______________________________________________ > 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 nobody Tue Mar 28 14:20:58 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB19126C23; Tue, 28 Mar 2017 14:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUdZHXiZcvGc; Tue, 28 Mar 2017 14:20:53 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2207C129611; Tue, 28 Mar 2017 14:20:53 -0700 (PDT) X-AuditID: c6180641-0291898000000a06-fc-58da8d5c65fe Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id E3.65.02566.C5D8AD85; Tue, 28 Mar 2017 18:20:44 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Tue, 28 Mar 2017 17:20:51 -0400 From: David Sinicrope To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: The IESG , "draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc20tMTM6ICh3aXRoIENPTU1F?= =?utf-8?Q?NT)?= Thread-Index: AQHSnOJlkqAVO57tpEa/quwYa3zKFaGrG6IA Date: Tue, 28 Mar 2017 21:20:51 +0000 Message-ID: <58A94BC3-856A-428C-BCB1-062982878F1F@ericsson.com> References: <148950992865.30217.623852332846175032.idtracker@ietfa.amsl.com> In-Reply-To: <148950992865.30217.623852332846175032.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-CA60051F-3396-402E-B654-F6D5A2D04764"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyuXRPiG5M760Ig575ihZnXx1hsZjxZyKz xYvrH5kt1l0+xWZxa+lKVgdWjyVLfjJ5tHxcyBrAFMVlk5Kak1mWWqRvl8CVMX3HLLaCb94V WzcvYmlgfOTZxcjBISFgInG8Ob6LkYtDSGADo8SqPeuZIJzljBKvX99l62Lk5GADKlq3cQ8L iC0iYCdxadlJZpAiZoGbjBKL/24E6xAW2MQoMelLL5gjIrCZUWJu20tWiBYjiUeTnoO1swio Sry+8I8ZxOYVsJd43/qZHcQWEvCRaG+5xQhicwr4Skz7fYcJxGYUEJP4fmoNmM0sIC5x68l8 MFtCQETi4cXTbBC2qMTLx/9YIU6azChx7sJXVogFghInZz5hmcAoPAtJ/yxkdbOQ1EEUaUrs 714OZStKTOl+yA5hW0vM+HWQDcI2lXh99CMjspoFjByrGDlKiwtyctONDDcxAqPsmASb4w7G vb2ehxgFOBiVeHgVTG5FCLEmlhVX5h5iVAFqfbRh9QVGKZa8/LxUJRHe+cuA0rwpiZVVqUX5 8UWlOanFhxilOViUxHnflV+IEBJITyxJzU5NLUgtgskycXBKNTDyrXVkiJDd9mAvc+DklwpW 1/oKfu8vm2zDVTyhUdXmzenvT/5psTG0qIfd0FsUnj15OcPiPc5fWEzrd1b89fTcw3PDtel4 o8NalZBZZRLXtyZKmGuwNkzqCtdeo3Q2ROjozUXGB+4F/m2/Z/DgpuC73DPFSSatba0LX5nf VA1V+/tEZk7QPQ4lluKMREMt5qLiRADgLliFugIAAA== Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-tp-temporal-hitless-psm-13=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 21:20:56 -0000 --Apple-Mail-CA60051F-3396-402E-B654-F6D5A2D04764 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB1cGRhdGVkIHRoZSBTaGVwaGVyZCdzIHdyaXRlIHVwIHRoaXMgbW9ybmluZy4NCi0gaXQncyBu b3cgbGlzdGVkIGFzIEluZm9ybWF0aW9uYWwNCi0gYWxsIGVkaXRvcnMgbGlzdGVkIGhhdmUgY29u ZmlybWVkIHRvIG1lIHRoZXkga25vdyBvZiBubyB1bmRpc2Nsb3NlZCBJUFIgb24gdGhlIGRyYWZ0 DQpTb3JyeSBmb3IgdGhlIGRlbGF5IGFuZCBhbnkgY29uZnVzaW9uLg0KRGF2ZQ0KDQo+IE9uIE1h ciAxNCwgMjAxNywgYXQgMTE6NDUsIE1pcmphIEvDvGhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5u ZXQ+IHdyb3RlOg0KPiANCj4gTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLXRlbXBvcmFsLWhp dGxlc3MtcHNtLTEzOiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpcw0KPiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtdGVtcG9yYWwtaGl0 bGVzcy1wc20vDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gSSBkb24ndCBzZWUgYSB2YWx1ZSBpbiBwdWJsaXNoaW5nIHRoaXMg ZG9jdW1lbnQgaW4gdGhlIFJGQyBzZXJpZXMuIEJ0dy4NCj4gdGhlIHNoZXBoZXJkIHdyaXRlIHVw IHN0aWxsIHNheXMgdGhpcyBkb2MgaXMgc3RhbmRhcmRzIHRyYWNrLg0KPiANCj4gTWlub3IgY29t bWVudHM6DQo+IC0gVGhlIGNsYXNzaWZpY2F0aW9uIGludG8gTShhbmRhdG9yeSkgYW5kIE8ocHRp b25hbCkgaXMgbm90IGNvbnNpc3RlbnQNCj4gd2l0aCB0aGUgdXNlIG9mIE1VU1QgYW5kIFNIT1VM RC4NCj4gLSBUaGUgZmlyc3Qgc2VudGVuY2UgaW4gdGhlIGludHJvIHNob3VsZCB1c2UgYSBsb3dl ciBjYXNlICdtdXN0Jy4NCj4gLSBTZWN0aW9ucyAyLjIgYW5kIDUuIGNvdWxkIGJlIHJlbW92ZWQu DQo+IA0KPiANCg== --Apple-Mail-CA60051F-3396-402E-B654-F6D5A2D04764 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR7zCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF9TCCA92gAwIBAgIRALxlYliaGlVBVIzdf0JdrVww DQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMTcyNjU5WhcNMTcxMjAzMTcyNjU4WjBsMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPRGF2aWQgU2luaWNyb3BlMSswKQYJKoZIhvcNAQkBFhxk YXZpZC5zaW5pY3JvcGVAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdFVUREQVNJMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuLSip8vAw047E4kqOvaSr8JiZv7osqpEc8b3YlpWh72Ultla sLTTNu0dglUgUBTsTaJc9MsShWoNZQ33ovV7nFNK0/tlmaPGF5vkyiJlx2FbwQKDgXYPnWz8ygbN yuUngRRO2QQgbk9HdXbsaZV0P/bqOZcyCIjiA8R7gGFMihA6aaYQqc/kkaOvA7KC1NLA1LcrMs5b XU4EwLvMmrV8pqEiJhyHF7+3R+0Enn0f0vcQyufycv3ryV8Ew8IfcYEOMSi1YRyd8U9yw2zTbNjw RzzLw+9BGlsHg2xtL8pfDRarlbgdFIp+aX41FpJ4IyK33O72IsOzW1LUTYskPOu4dQIDAQABo4IB wjCCAb4wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRw Oi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVs aWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwJwYDVR0RBCAwHoEcZGF2 aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFHN5kln74TY7ros9qkuGK5Ep w6ZkMB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkq hkiG9w0BAQUFAAOCAgEAvivBzaZgYr3huLaEMwV6QA0QcQwF4i+5zvbg/iAgfBKkPAvr/MWGSkI5 RyT/ognomX1ttqdqvz+adnHbtV4lOQapbcZZeWrmyh9xHeRqrkbEeB0FMC/HJFXcRP51IcTa2Pzx s3rb4nIs7YIONPGBXth/Dn9UYjYXQy5V8MkYGlf4kT5AbUQiyJwmABxWrUDLrJd4Q6nDR5YV+wGW VVW0SWN9adVzSnIF0cqbX4YoRAXUzbwP4eFGpXqfrqd2njMCMU9r3RKP66EsFpbzQW2yMNydUA8m ZrxDTB8BhCtvXxopMy3Ye/5pjkMk+nl74WsnMwc2pRqWbyu/BCjD6DNnEdxy8BAKoi/fKwsMpNAy GvMyf2t1hm5VWFMhfUD4P/5YNM8L9qjkx0uBMYuXhyuDCYk7NQFHfelc8j2Tl91wqF+/9u8CjaDT 8lVPsfPzmNaU6W7fbn4kYSXOoj+EIioPI9pXgVzCiSgGzhFm/6UWnmYRiDxn1XXvz4vJ8d2RhXiG vvNDB5CLM7RoF/Sfzr2Ertc3hHQfT/AfroWqs4g/6NTOLnSocPjahJoGdU6DjhQnaIsjJ8qb+bhj qiI/4no7zMQYAJX9E+Xfr4MAaC2767wm5S1osZzHMxPVu7nSWyWp2UlgaTvWZuGvbct819D0dSY1 tLRMekyVV1g5KKW7wDAwgga2MIIEnqADAgECAhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0B AQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEF AAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/ q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkN fF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Y d4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tB Gsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGe KudmaURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6 PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry5 0dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJv Z5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/ dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGG IWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIG A1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcC ARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQw QjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEG MB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr +nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QY dz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mP fLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7n uvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAI rzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgr OB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A +zj4+r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt 9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcM uFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNq yvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKZMIIClQIBATBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAvGViWJoaVUFUjN1/ Ql2tXDAJBgUrDgMCGgUAoIIBHzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNzAzMjgyMTIwNTBaMCMGCSqGSIb3DQEJBDEWBBTldz8nfQmgzjCRbgYx2RbW2XEC0TBe BgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYyAhEAvGViWJoaVUFUjN1/Ql2tXDBgBgsqhkiG9w0BCRACCzFRoE8w OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg djICEQC8ZWJYmhpVQVSM3X9CXa1cMA0GCSqGSIb3DQEBAQUABIIBACH7KDsv3J9vw8A+n2b6H4wh 9/0uAZWhbCTJA43iwlXHRcLMzs6jaZTdTo9pGY2y1xxbuBogzMrLB3pgJNBS+tINIsFEKhayOh2J xxzK615Nr+Bf6heRzmw10tYj0Vw/dDhW+OMgwfFj5u88ivbY9cYhe38SMw748mRQP7aU7iq90Beh 7vyqHCqkP3NSFEeLiyNQTax8TLyWpUgwGSknhcZOWaCpFsQT7k10qsUWx9EewIv8+Utt+JwsjVHu X4z8dCVjgGCaKyywqyDEbGLjs3ipqPPRvtQtMNoRH8d9NFaj04mCT0WnBwf2r3mpSHNXHY/G268g 10LWsCVF2THm/PcAAAAAAAA= --Apple-Mail-CA60051F-3396-402E-B654-F6D5A2D04764-- From nobody Wed Mar 29 08:30:17 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37AB1296F5; Wed, 29 Mar 2017 08:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6YGIIB7oxEk; Wed, 29 Mar 2017 08:30:13 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324D31296E7; Wed, 29 Mar 2017 08:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N23FFoY2Vl9CWmf2sb/cOyVhZpbHfVux+NX1wxo0yCk=; b=MvLeorVpib8jo+7DXcGc+25tulPUD1L05lqW4FDeIWelPdcYoIai6ORWRTEtQ8+ZZxS0JxIHJCPIg0C7epgFUMlAP67itz317ZQ6SMksnpIL3d3qyEIiCFxaaiJt0x3VEtcztq3lK1Sjj+ukAfWhzAshJV6Q4Dabv9HZbY+SyWc= Received: from BL2PR02MB2066.namprd02.prod.outlook.com (10.167.96.150) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 15:30:09 +0000 Received: from BL2PR02MB2066.namprd02.prod.outlook.com ([10.167.96.150]) by BL2PR02MB2066.namprd02.prod.outlook.com ([10.167.96.150]) with mapi id 15.01.0977.021; Wed, 29 Mar 2017 15:30:07 +0000 From: Aidan Copeland To: "draft-ietf-mpls-static-yang@ietf.org" , "mpls@ietf.org" Thread-Topic: Use of leaf-lists in draft-ietf-mpls-static-yang Thread-Index: AdKol+KJ/4b/UbzHSOirBqv9oxg+hg== Date: Wed, 29 Mar 2017 15:30:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [2620:104:4000:7064:ec31:f1ec:1fac:4e94] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:oL9NH16r6pDggV/oyDNEXIZY3UK4EaXEgyyKn93kmvXlZxIuMH2ECaKd7nPfR1Jsic40yqCS11GR8Oy8Xz5QLoWY9SVCv+vjEcrVW9vR6RPPZpPPvDqo3dYyXrAUQPlb41ptqSOGTj3sWAuRKv8AEhT88KutMDccZHHu9jE3Gfx1oQhlcID+yXnePGiTQM9/S16jXzI/PKKzoKlLzMLltNAtW1luAdDJr7SlfLAfbuyGwGpa8qSP+DIcSDl4g6NhaH8MGsulaRh7tpT29Wm7L2iBmBIU18ZauWl+5w9WuhKbzyOeXzMALV3GCGpXSN21g96NdPs71Cvp8aN9wbmIOQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39450400003)(39410400002)(51444003)(8676002)(3280700002)(25786009)(77096006)(230783001)(81166006)(189998001)(6506006)(6436002)(5660300001)(450100002)(3660700001)(55016002)(7696004)(2900100001)(6306002)(99286003)(54896002)(50986999)(54356999)(33656002)(122556002)(74316002)(38730400002)(9686003)(2906002)(53936002)(102836003)(6116002)(790700001)(2501003)(7736002)(86362001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BL2PR02MB2066.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: fb65be3d-27e7-4a26-e31a-08d476b87b07 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1911; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; x-forefront-prvs: 0261CCEEDF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR02MB20660E93F80140BFF1FDA2E0E9350BL2PR02MB2066namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 15:30:07.3913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911 Archived-At: Subject: [mpls] Use of leaf-lists in draft-ietf-mpls-static-yang X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:30:16 -0000 --_000_BL2PR02MB20660E93F80140BFF1FDA2E0E9350BL2PR02MB2066namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tarek, all, I think that there is an error in the use of a leaf-list to represent the s= et of outgoing MPLS labels to impose for an outgoing path. RFC7950, section 7.7, states In configuration data, the values in a leaf-list MUST be unique. This means that a leaf-list is not suitable to represent a label stack, whe= re the same label value may be used more than once. I think the best solution is instead to specify the set of outgoing labels = as a list of outgoing label containers, keyed by label index and containing= the outgoing label value. Do you agree with this, or do you think a different mechanism would be bett= er? Regards Aidan --_000_BL2PR02MB20660E93F80140BFF1FDA2E0E9350BL2PR02MB2066namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tarek, all,

 

I think that there is an error in the use of a leaf-= list to represent the set of outgoing MPLS labels to impose for an outgoing= path. 

 

RFC7950, section 7.7, states

 

In configuration data, the values in a leaf-list MUST be unique.

 

This means that a leaf-list is not suitable to repre= sent a label stack, where the same label value may be used more than once.

 

I think the best solution is instead to specify the = set of outgoing labels as a list of outgoing label containers, keyed by lab= el index and containing the outgoing label value. 

 

Do you agree with this, or do you think a different = mechanism would be better?

 

Regards

 

Aidan

 

 

--_000_BL2PR02MB20660E93F80140BFF1FDA2E0E9350BL2PR02MB2066namp_-- From nobody Wed Mar 29 09:27:53 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E8E128792; Wed, 29 Mar 2017 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsSK0RdWRQwR; Wed, 29 Mar 2017 09:27:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800D3128C83; Wed, 29 Mar 2017 09:27:33 -0700 (PDT) X-AuditID: c1b4fb3a-0dfff70000003958-05-58dbe0737983 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 80.0B.14680.370EBD85; Wed, 29 Mar 2017 18:27:31 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 29 Mar 2017 18:27:28 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VYomq9EpXPunfBt/ZNlbCRaYQ7kc0jib61/HP9s0ddk=; b=RrPQweMg8FqlKld7tUyyrCvk4H9pT8PKei0DqjM9MMQgtDv7HyWeXTqcEh2L/U0vqmMDzP+2yhDuBDjzGREIVuuU12cw3ILZiehvsujDK51ld52v+65x8UPdWsJXSv66VqQxbOzYyP1q4RxQRkrXhyOvbpew1HxXBC/2IrMbq+0= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0995.eurprd07.prod.outlook.com (10.162.37.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 29 Mar 2017 16:27:27 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 16:27:27 +0000 From: Daniele Ceccarelli To: "pce@ietf.org" , TEAS WG , "mpls@ietf.org" , "ccamp@ietf.org" Thread-Topic: FlexE side meeting Thread-Index: AdKoplJL5NQ9uV3wSTaOLYmobfrRrQ== Date: Wed, 29 Mar 2017 16:27:26 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [31.133.148.42] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 7:HsOmhbqNtAThmzRzG9fkeYwwW8b5+MaZ9ArOp0uwLEepqTUx7b3tq75nOgZZRflWQpbHbfZfnXO04E/PVysH4GgfMwIVM7ORGsvMQVM3QOYJ+cX5F+/TjwW34L8fQTzxgl+MAe1+Qee/GiPBufrdfC7RShFkOHvJXK4Q+lAR2wlR03/72pjBPlCvnU2qUZ9Yqwg3Pv9I+dFfbKo/DekPUTFh5jYLWMfZlGNOSDjnFEPmTwuNtCKUYlvo5GSnkWr/r+Tt5sMfYvArHApaaILeMr3aArAfo1dgm5ibzvpt+08AG38H//mtd2FmHRulsRBPmTWBiIQ5Q09X/aez8iHxwg== x-ms-office365-filtering-correlation-id: 0dcf1911-e9c5-46b5-4fff-08d476c07d1f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM2PR07MB0995; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006041)(93001041)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123562025)(20161123560025)(6072148); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39860400002)(39450400003)(39840400002)(39400400002)(39850400002)(51914003)(53754006)(77096006)(6506006)(4326008)(966004)(81166006)(6306002)(99286003)(55016002)(50986999)(54356999)(606005)(5660300001)(3480700004)(54896002)(53936002)(236005)(9686003)(2501003)(6436002)(74316002)(66066001)(8676002)(3846002)(102836003)(7906003)(6116002)(790700001)(7736002)(15380165006)(8936002)(33656002)(7696004)(3660700001)(7116003)(2906002)(3280700002)(38730400002)(25786009)(53546009)(2201001)(2900100001)(189998001)(122556002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09940C2242BF984060E67A2AF0350AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 16:27:26.9522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH+97z3D0P69Y3P/IJbbpVf9RciHYzFbZkk60f/rC06eIZNxzd c4nWIkM7lxJHXOVX57ZTqkUiv+aS6J8oZGjEKdbiWJryY3k82vz3+r7f7+/7+/lsX5qwqxc6 0wqlmlEp5fESkS1ZEr5yzZ0dGw73mMv0lFkeDJKyoSqTUJZfoRPIMkYHKVnWYgPpLww2GP4I grOn3U4Jztn6RTPximRGdfDoBdtYTYaJSuo9mzL3JDgdlYXkIJoG7A36DmkOsqHt8HME45Oh Och2jbsQ5PfOIO5A4lwCGgs0iHd0AqjuH6X4QyeC7IVSiqsSYV+wmE9yugNOR/DwYy7B9RLY E+qN39Yz9tgFLJNenOyA3eBpZhbFsxSyM+fXmcR7odl6V8SxGJ+Hmcm+dR3hXZDXVIn4SicY spQJOAaMwdD8geDZEaYnVoXcDAhrEVhLBzZCu6FltUfEGYBvETB78zfFG6FgejUs4vk6vLaO buhxML9s3GiNgJ6lCYq/PC+At43aDcMV7mTkE7zRJoTF2sL15+yxM3zp0yCeXWFqpEXIz50I 2sUVkt9tO3SXWMg8tE+/aSX9pph+U4zXpTBYqBPxfACMFT8Int2heNVMbtbLEVWNHFmGZRNi vLykjEoRxbKJSqmSUb9Aa7+pvW7JtwG1fw8wI0wjyVbxWMtwuJ1QnsymJpgR0ITEQdxtWpPE 0fLUq4wqMVJ1OZ5hzciFJiVOYv/WnnA7HCNXM3EMk8So/rsC2sY5HRlcgxoOF5uO+Fh720rv 2Zff17gUFcRW9vvM1lklF5d/PpoyXqn9etzyqSvohq5mW6DflvEzv5JShpqq0mpzP4dFmGXL hqUeddTOIvdntw2tOwYGNIEjHpbIsHTtCUe/aa1rwMtDk3GdwnfU4mPF+8q/6NiCd8jpS4El NW9y9nR1pElINlbuuZ9QsfJ/XH9RvEkDAAA= Archived-At: Subject: [mpls] FlexE side meeting X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:27:37 -0000 --_000_AM2PR07MB09940C2242BF984060E67A2AF0350AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, thanks for the useful and productive meeting. I've uploaded the slides in the CCAMP page as well as the minutes (thanks t= o Andy for putting them together) https://datatracker.ietf.org/meeting/98/session/ccamp The recordings can be found at the following link http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF98_CCAMP_Fl= exE&chapter=3Dchapter_1 Thanks Daniele & Nic From: Daniele Ceccarelli Sent: marted=EC 28 marzo 2017 12:10 To: Daniele Ceccarelli ; pce@ietf.org; TEA= S WG ; routing-discussion@ietf.org; mpls@ietf.org; ccamp@iet= f.org Cc: Ignas Bagdonas ; draft-izh-ccamp-flexe-fwk@ietf.org= ; N.Leymann@telekom.de Subject: RE: [CCAMP] FlexE side meeting ...and the agenda >> The agenda will be: >> >> 1. FlexE background and origins: Haomian Zheng >> 2. FlexE Technology Deep Dive: Iftekhar Hussain >> 3. FlexE in the IETF: Mach Chen >> 4. Open Mic From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: marted=EC 28 marzo 2017 12:00 To: pce@ietf.org; TEAS WG >; routing-discussion@ietf.org;= mpls@ietf.org; ccamp@ietf.org Cc: Ignas Bagdonas >; draft-i= zh-ccamp-flexe-fwk@ietf.org; N.L= eymann@telekom.de Subject: [CCAMP] FlexE side meeting Hi everyone, a reminder for the FlexE side meeting and the link to Meetecho: When: Tuesday 18:45-20:15 Room: Zurich B Remote participation - Meetecho: http://www.meetecho.com/ietf98/CCAMP-FlexE BR Daniele, Nic, Loa --_000_AM2PR07MB09940C2242BF984060E67A2AF0350AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

thanks for the useful and produ= ctive meeting.

 

I’ve uploaded the slides = in the CCAMP page as well as the minutes (thanks to Andy for putting them t= ogether)

https://datatracker.ietf.org/meeting/98/= session/ccamp

 

The recordings can be found at = the following link

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF98= _CCAMP_FlexE&chapter=3Dchapter_1

 

Thanks

Daniele & Nic

 

From: Daniele Ceccarelli
Sent: marted=EC 28 marzo 2017 12:10
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; pce@= ietf.org; TEAS WG <teas@ietf.org>; routing-discussion@ietf.org; mpls@= ietf.org; ccamp@ietf.org
Cc: Ignas Bagdonas <ibagdona@gmail.com>; draft-izh-ccamp-flexe= -fwk@ietf.org; N.Leymann@telekom.de
Subject: RE: [CCAMP] FlexE side meeting

 

…and the agenda

 

>> The agenda will be:

>> 

>> 1. FlexE background and origins: Haomian Zheng<= /p>

>> 2. FlexE Technology Deep Dive:   Iftekhar Hussain<= /o:p>

>> 3. FlexE in the IETF:       &n= bsp;    Mach Chen

>> 4. Open Mic=

 

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: marted=EC 28 marzo 2017 12:00
To: pce@ietf.org; TEAS WG <teas@ietf.org>; routing-discussion@ietf.org<= /a>; mpls@ietf.org; ccamp@ietf.org
Cc: Ignas Bagdonas <ibagdon= a@gmail.com>; draft-izh-ccamp-flexe= -fwk@ietf.org; N.Leymann@telekom.de
Subject: [CCAMP] FlexE side meeting

 

Hi everyone,=

 

a = reminder for the FlexE side meeting and the link to Meetecho:

 

Wh= en: Tuesday 18:45-20:15

Ro= om: Zurich B

Re= mote participation - Meetecho: http://www.meetecho.= com/ietf98/CCAMP-FlexE

 

BR=
Daniele, Nic, Loa

--_000_AM2PR07MB09940C2242BF984060E67A2AF0350AM2PR07MB0994eurp_-- From nobody Fri Mar 31 06:53:56 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF66120326; Fri, 31 Mar 2017 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue0MqryQ3Xnf; Fri, 31 Mar 2017 06:53:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F4C1296B3; Fri, 31 Mar 2017 06:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7976; q=dns/txt; s=iport; t=1490968432; x=1492178032; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LpAB46OBpVXkabxc+H6WTFnG0d+PQ2KNxjuC4WBmNuU=; b=TYvavURAVoL0clSqofYpODmW7zlMkwKwGFuu+HHLv0+sXBbZz1tr1w5O vg64h6HYiPcS9tY8hCeA4QThleH2/ZHvqxn4v9lIw5KyAKXn+jgrKjRI9 FoRv7nczgpTnsK+kZxq9QfnbEcnVk6ogEXaAnTCjbDFv2s769uKeIb3ue 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAgA0Xt5Y/4sNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgm5mYYELB4NbihKhdIUxgg6GIgIagyw/GAECAQEBAQEBAWsohRYGI2YCAQg?= =?us-ascii?q?/AwICAjAUEQEBBAESG4lyrgaCJiuKMAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GT?= =?us-ascii?q?oIFgWGBCYRrgm8ugjEFlhiGUgGST4F9jz2IXIsUAR84gQVbFUERAYZHdYhOgQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208,217";a="227162176" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2017 13:53:52 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2VDrp6t022684 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 13:53:51 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 09:53:50 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 09:53:50 -0400 From: "Tarek Saad (tsaad)" To: Aidan Copeland , "draft-ietf-mpls-static-yang@ietf.org" , "mpls@ietf.org" Thread-Topic: Use of leaf-lists in draft-ietf-mpls-static-yang Thread-Index: AdKol+KJ/4b/UbzHSOirBqv9oxg+hgBhe9kA Date: Fri, 31 Mar 2017 13:53:50 +0000 Message-ID: <6B5BFBDF-39BE-4EEA-AE11-4FB035907920@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.240.109] Content-Type: multipart/alternative; boundary="_000_6B5BFBDF39BE4EEAAE114FB035907920ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Use of leaf-lists in draft-ietf-mpls-static-yang X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 13:53:55 -0000 --_000_6B5BFBDF39BE4EEAAE114FB035907920ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWlkYW4sDQoNCllvdSBhcmUgcmlnaHQuIEluZGVlZCwgaXQgaXMgcGVybWlzc2libGUgdGhl IHNhbWUgbGFiZWxzIHZhbHVlcyBjYW4gcmVwZWF0IGluIHRoZSBsYWJlbCBzdGFjayBhbmQgdGh1 cyB0aGUgbGVhZi1saXN0IGlzIG5vdCBzdWl0YWJsZS4gSeKAmWxsIGxvb2sgaW50byB0aGlzIGFu ZCB3ZeKAmWxsIHVwZGF0ZSBpdCB0aGUgbW9kZWwuDQpUaGFua3MgZm9yIHJlcG9ydGluZyBpdC4N Cg0KUmVnYXJkcywNClRhcmVrDQoNCk9uIDIwMTctMDMtMjksIDEwOjMwIEFNLCAiQWlkYW4gQ29w ZWxhbmQiIDxhaWRhbi5jb3BlbGFuZEBtZXRhc3dpdGNoLmNvbTxtYWlsdG86YWlkYW4uY29wZWxh bmRAbWV0YXN3aXRjaC5jb20+PiB3cm90ZToNCg0KSGkgVGFyZWssIGFsbCwNCg0KSSB0aGluayB0 aGF0IHRoZXJlIGlzIGFuIGVycm9yIGluIHRoZSB1c2Ugb2YgYSBsZWFmLWxpc3QgdG8gcmVwcmVz ZW50IHRoZSBzZXQgb2Ygb3V0Z29pbmcgTVBMUyBsYWJlbHMgdG8gaW1wb3NlIGZvciBhbiBvdXRn b2luZyBwYXRoLg0KDQpSRkM3OTUwLCBzZWN0aW9uIDcuNywgc3RhdGVzDQoNCkluIGNvbmZpZ3Vy YXRpb24gZGF0YSwgdGhlIHZhbHVlcyBpbiBhIGxlYWYtbGlzdCBNVVNUIGJlIHVuaXF1ZS4NCg0K VGhpcyBtZWFucyB0aGF0IGEgbGVhZi1saXN0IGlzIG5vdCBzdWl0YWJsZSB0byByZXByZXNlbnQg YSBsYWJlbCBzdGFjaywgd2hlcmUgdGhlIHNhbWUgbGFiZWwgdmFsdWUgbWF5IGJlIHVzZWQgbW9y ZSB0aGFuIG9uY2UuDQoNCkkgdGhpbmsgdGhlIGJlc3Qgc29sdXRpb24gaXMgaW5zdGVhZCB0byBz cGVjaWZ5IHRoZSBzZXQgb2Ygb3V0Z29pbmcgbGFiZWxzIGFzIGEgbGlzdCBvZiBvdXRnb2luZyBs YWJlbCBjb250YWluZXJzLCBrZXllZCBieSBsYWJlbCBpbmRleCBhbmQgY29udGFpbmluZyB0aGUg b3V0Z29pbmcgbGFiZWwgdmFsdWUuDQoNCkRvIHlvdSBhZ3JlZSB3aXRoIHRoaXMsIG9yIGRvIHlv dSB0aGluayBhIGRpZmZlcmVudCBtZWNoYW5pc20gd291bGQgYmUgYmV0dGVyPw0KDQpSZWdhcmRz DQoNCkFpZGFuDQoNCg0K --_000_6B5BFBDF39BE4EEAAE114FB035907920ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8D0262DF0F69774BB24F5695C7588008@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCW1zby1jb250ZXh0dWFsLWFsdGVybmF0ZXM6 bm87DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5IaSBBaWRhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPllvdSBhcmUgcmlnaHQuIEluZGVlZCwgaXQgaXMgcGVybWlzc2libGUgdGhlIHNhbWUgbGFi ZWxzIHZhbHVlcyBjYW4gcmVwZWF0IGluIHRoZSBsYWJlbCBzdGFjayBhbmQgdGh1cyB0aGUgbGVh Zi1saXN0IGlzIG5vdCBzdWl0YWJsZS4gSeKAmWxsIGxvb2sgaW50byB0aGlzIGFuZCB3ZeKAmWxs IHVwZGF0ZSBpdCB0aGUgbW9kZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoYW5rcyBmb3IgcmVwb3J0 aW5nIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+VGFyZWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAy MDE3LTAzLTI5LCAxMDozMCBBTSwgJnF1b3Q7QWlkYW4gQ29wZWxhbmQmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzphaWRhbi5jb3BlbGFuZEBtZXRhc3dpdGNoLmNvbSI+YWlkYW4uY29wZWxhbmRA bWV0YXN3aXRjaC5jb208L2E+Jmd0OyB3cm90ZTo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgVGFyZWssIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0 aGF0IHRoZXJlIGlzIGFuIGVycm9yIGluIHRoZSB1c2Ugb2YgYSBsZWFmLWxpc3QgdG8gcmVwcmVz ZW50IHRoZSBzZXQgb2Ygb3V0Z29pbmcgTVBMUyBsYWJlbHMgdG8gaW1wb3NlIGZvciBhbiBvdXRn b2luZyBwYXRoLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQzc5NTAsIHNlY3Rp b24gNy43LCBzdGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkluIGNvbmZpZ3Vy YXRpb24gZGF0YSwgdGhlIHZhbHVlcyBpbiBhIGxlYWYtbGlzdCBNVVNUIGJlIHVuaXF1ZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgbWVhbnMgdGhhdCBhIGxlYWYtbGlzdCBpcyBub3Qgc3VpdGFibGUgdG8gcmVwcmVzZW50IGEg bGFiZWwgc3RhY2ssIHdoZXJlIHRoZSBzYW1lIGxhYmVsIHZhbHVlIG1heSBiZSB1c2VkIG1vcmUg dGhhbiBvbmNlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGJlc3Qgc29s dXRpb24gaXMgaW5zdGVhZCB0byBzcGVjaWZ5IHRoZSBzZXQgb2Ygb3V0Z29pbmcgbGFiZWxzIGFz IGEgbGlzdCBvZiBvdXRnb2luZyBsYWJlbCBjb250YWluZXJzLCBrZXllZCBieSBsYWJlbCBpbmRl eCBhbmQgY29udGFpbmluZyB0aGUgb3V0Z29pbmcgbGFiZWwgdmFsdWUuJm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IGFncmVlIHdpdGggdGhpcywgb3IgZG8geW91IHRoaW5r IGEgZGlmZmVyZW50IG1lY2hhbmlzbSB3b3VsZCBiZSBiZXR0ZXI/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWlkYW48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_6B5BFBDF39BE4EEAAE114FB035907920ciscocom_-- From nobody Fri Mar 31 09:22:19 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1027012998B; Fri, 31 Mar 2017 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvIQGKhVoW9E; Fri, 31 Mar 2017 09:22:09 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0122.outbound.protection.outlook.com [104.47.1.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303A0129A1A; Fri, 31 Mar 2017 09:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AQ7DOz+AvW++NXoPg5zUF9xLP1uCpTFehRuqfmAzTvI=; b=fbhfOpG1Ohqd04MX5f+LOup+6S+52cb2u7kKDBhRM3JOWEMbdsKKiw9PBHX7hKwOgIBEn5hQNSsBZlgUJBjkf+D8EmMvrqr2iQkPlG3Oe3pKFbbHwYRrr6uzYxusvF6pbScZdBKxbUcaDBP5NSCf8Cv05GbdcPv4X8C1dttu04E= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Fri, 31 Mar 2017 16:22:06 +0000 Message-ID: <015001d2aa3a$af400840$4001a8c0@gateway.2wire.net> From: t.petch To: "Tarek Saad (tsaad)" , Aidan Copeland , , References: <6B5BFBDF-39BE-4EEA-AE11-4FB035907920@cisco.com> Date: Fri, 31 Mar 2017 17:11:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6PR0202CA0036.eurprd02.prod.outlook.com (10.171.70.22) To AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) X-MS-Office365-Filtering-Correlation-Id: 8e77b058-c7d9-4910-2a3c-08d478521322 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 3:s3lATST9lA6r5lYeyDegv8CMwSyOLxsaratp8zsPcMCvY4rLi4SKRZ0CMaax3qccGhXOkRuMYzZo4rLlfjhFzCKp6iDNT8OQ37+8bkhfyC8XlhRBbMsUMKq6YjxFzro25n2bMp4edvpVxLnrrUwm5ii/hIGlYFiTSI+V3l7PhJsKqhot8yFSFz7W+t+KbK4SGYgoWUVCDnrHfRHN5dDcUzZZE2K6posqqUOSjGMtkJVK7omYWRJCCaMw4hbJJZKwvg9g6BIguaClxXg4Zm49yQVxEZaVtuVPS4Cbjz6NtBNbDGAw7eTwC6+D+WEKINADOKYwQYxKTTGEp3q/Zh26Xg==; 25:r0VH+x5MyTxvNyM765RTGdTskfcy0pWOpmUJjAHAPMcoPzzEr6UfQE00sgP+MOXGphzCvrkssJifjuAu8+Y5NIfae/B4FyqHq8AZLxqPwBlqTwo5PO1nrRFlZZUJmfsbIYuSX7899+/tEVOPwXnhsD/MtpjIecTa8yr+V8HH8Wipu8cHytuLqkk2W8aDIcBhCtrAHdblulZufdL0SmOrVrgF5TRbs0sgJFeAVuReughQlKJXf4jUYhyQTkMzeJZQYkJr45tT3mXYSYnhMMp5EcwrJ5q6BAvNOvciiJ6iadK8eXI3mA5isEc6R60EyA0A9Vt3t0Qn8Os/64GeDlxLYwHyT1DlkccCzRxelH/4sepP/aeFN5NhGtLfinglDJHK3JzZsKRPvbxcJCWkFll1YXy1m8tV9RqlEFABUahPFpxjsfu4ed9JqDqCPe2lvoDo28zeRPFS4Pk3hDswqyJv+g== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 31:VK/C2K6D0pTnQSZrcWEnDK5hJZp9IIm9DTn7XHP4ePVZEQBeOoxe4Y9dhD7ZBsFOyQ6TXkQg8gbAzu6WjzXYT9Qs+I3SaBZ6d7uqNZz2GZha+nrRyy7XCfWsIa8f9uVxKDvKdgZmeskP6rkZHRU1b/UlTESVCyjei5ZFm0Ww/kbdMjkkncKhgKzz/yvQptxCeCJX4xBUoFyc/ZWF/rVfmp3vthJTABZ79NbwBRBPoZEy30gH/O+evJ/vheAplJuMpcAIVYbWCjZDR3Id8v+ypw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014)(211171220733660); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(6072148); SRVR:AM5PR0701MB2994; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 4:ZCXB/4BrFFvfUsDnlqyBcGnMf45yOpikZcsS709VSVA1mRd74myxLfMcP87d4zWpbHnKs/c0/gsCaRzPT/Odbld2riJ8XoVOzNGdWC7uABQ+Plj+nkLZKyJKfdZzaxZ3zEYI0gB2hq9ANkxzk99XZc/u5rtCSwl1+GLlfTasxCyQzSrlHAtpE3jWnCUt4rFxUxy5V4P52pik3Up5ByoXZI7bYW0E7yLNfXajsehC1puVr8pabNH+hXYy2uqN4L/prVY67PA7k7hMUsbjGb7ZPkqnVQDneV+8Sc6/C7fTYx5lFSY3zbIHe3iu8NDJadx+XT0ZLqnWpLQ5G3gu0XkGoJRWsHaYwT7fc2EBOqekc613seh0cXPpOYt78Z1epGsdsH+cbZ8nnodQgfhMGrLGM7aUEWtX0qXXOtcKmSdvEq0bYvWHT0GpU1iofL0NJKvb/CvyWKvhFpWcurzlEPuOLcUi7VrKyssXvou/K4kOxjuOS+REBJ+vAv/l3juN4cMNEZaSaFXoFIkSukq/c9i7kR6F/4885tvDKrdZDZ3xdvosy85H2SI+oqIB3w75b5LV1hWc51ds6I1vDWfIQx56f0FRH6/36e7EyJj7sGZnauMXYulGlqsMLrz9jia1COtlVsqARKDymBwRId3+jP/0nw+QrbhtM3GvhScDLthR8zZMq/ggOv5Z424L0+QwiEFAMEkPk+10E3bbFywEKjLHw3ox/o9vFmBxbgdpXvJ7n0cog5spEhS79s0gmnfE0KsGMqouPu87gP3riqW1eaD/f0ZYeF9elgr6DBsKDeL0VZI= X-Forefront-PRVS: 02638D901B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39410400002)(39450400003)(39840400002)(39860400002)(39400400002)(39850400002)(13464003)(377454003)(51444003)(377424004)(24454002)(9686003)(4720700003)(53936002)(6496005)(6246003)(6486002)(50466002)(6306002)(5820100001)(25786009)(5660300001)(229853002)(23676002)(38730400002)(3846002)(6116002)(50226002)(47776003)(2201001)(84392002)(2906002)(61296003)(42186005)(33646002)(50986999)(81686999)(2870700001)(305945005)(81166006)(8676002)(44736005)(189998001)(86362001)(66066001)(76176999)(62236002)(44716002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2994; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTQ7MjM6TUNpYUplZ2MzQmEzd3oya1NBSUJoRlB0?= =?utf-8?B?RVJhWUdGNVNLMmFFdWV4d3ZMTVJhQ2EwWDJnbW4wcHZMek9FVlR4alhqaG11?= =?utf-8?B?S3Vlc3loYVU4R3J5U3BwN3FWaVRrYU10R0xzWlJIU1NGOUhNRUpWWlhmcDh2?= =?utf-8?B?ZnBrT0lXRDdCN3J2NUp4aDdDdkJPZ3czZitoQ3dtZUpFSHpiZDk3NmRRWjcv?= =?utf-8?B?Z2FRK3JRZkdwYVo2SFNFd083Q3EwVk9ETGFVNGY3eGQ1Wk00eThHY3FNdUNU?= =?utf-8?B?Y05QOElRdk9XRmtWRm1wL2Y1dFpVd1dpbU1uWk1VTHZ4cFczSGMvaEZPRWMv?= =?utf-8?B?bHZUMmtzY0t5US8ySS9QNUxKUFVVU2VmUEU5ZFNJY1B1bkNycmdFc2tBUlhs?= =?utf-8?B?NHVWbUUvajMzdENOOUxJY3lNS29sUzl4VWJ6a1gxQm5jd2xjbk5rTkF0cEVY?= =?utf-8?B?VXR2TDRZQjdiTUtvZno2cWdrQUl4eVl0NXBiT2R3ek5NL3Zwa2xwVnVLU3FV?= =?utf-8?B?c2s1UTN6RXN5d0lUMWdyYTRubkpNdHBXM1lNSSs4N0pLUFVLS2VBdDZUbmpE?= =?utf-8?B?Z2psUFYzeXRUelJueFcwMzU3K0M5akp4UmdzNUZZbm5aS3JRVkp3WWtSMzlF?= =?utf-8?B?NjlOc2p4SVo5WHFjQ0FQSWlMV0pOcHNuZ0RBSHBaNFFFL3FRM2lueTR3RzR3?= =?utf-8?B?UHRzODIrdVNqdVY0ZHFEbWlrSmxBQ2Q0UlZBaWM3elN3Rk4weEhnMzJUVXJO?= =?utf-8?B?K0dhditmTWY3aXdyeXVKTFpDMVA0NDI0SEoxZXMxTDRlWW1rR2dabkwrR0Vi?= =?utf-8?B?aUxMUU5NcU1MdXVwSnBQM252WUpYS3pXL1ZhZDQxQWxHbWxSQm54SUFSc1po?= =?utf-8?B?aDUzWG9HQ0dEUEFRV21TVjVJamNyT3VGdlBMVlc2K3BDbURWOG82am1Zdnpr?= =?utf-8?B?WFM4WThqYWhQWFNXN2xqZmJGb3FGcVhLRXAxS2JFcUpSZXRWSDdGQ1lZWDR5?= =?utf-8?B?NENtMUpQLzZFdEs5QWxQU1M0WUxVc0FyTzkrZ256VHhPWEl1c1Nyd3lLdkdS?= =?utf-8?B?WkJSaE82bldxNzRXeVlCQUh0bGl1NDJXeDNORkhtMXVsK2haMGRuOE9lelJG?= =?utf-8?B?dnZDTXBRc08vcWNJV0o5c09OcmVMZmV1WW0yZ3RIbjFKQUhrdUVyMk9CV0VB?= =?utf-8?B?NjB6a2kyczBQQTJ1VG8yRWJaMGRlMjJteTIzdzVqK2crL2syOUJYU2tLMWpQ?= =?utf-8?B?alIyb1ZDeldVTlk1ejVjcmdhdkpqWkNiQ3d3T211OGRvWFVRQ3RsMmh4NXR4?= =?utf-8?B?SVoyOFFjVFMyREhZTlhrMnhvSG8wN044cnY1SDJoM2VzRWhYUm0yc09JbG5y?= =?utf-8?B?OEQzcUs4OGtBZFlSb2pEaHJuN3V5dTBqYmJNY29ZdTczY2hqa2djWnZpUDVV?= =?utf-8?B?UDc0aThtMWlpVHg5c1dhdUJ0eXFWQmEzRk1Ed2MzQmd3dC9HS0JHS3V2eEI1?= =?utf-8?B?Q1ZWNjBJTndSOVFGUFJRZFBCc1dQcDNRaUxWcG9mdk5Qa0pBSnZFL3RyR0di?= =?utf-8?B?WVp3N1Fuc21zZ05IbTJWNGpBSWdWTTZydGQwRjdTcUtWdkwwWlJkdUtFYzJv?= =?utf-8?B?N0JQUDRlRm5QRGR5UE9XbEZ2azhSc1BQemFHY2JRTGQ1dVhIb0NhenIxNW9Y?= =?utf-8?Q?dv41BbJWbPEtR2dvX/r8r8zoYR6L4Z4vmSjoMN9ok?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 6:5amVj0tzlIocufIJ2syIy1WHT40zI4R39E1Rjy6Y3D+8IA9Nh2EXfX/axeHOcEfI2BvxlQ3mAfaXB5G8DylmeTLVa9wv4jOXoLGjjuJhbeMSQH02NuSEPQIOdQ+ags0rYJVkZ0bxDj8mKxohnozNPDCyUhkkOXjy/ybOOToXwBPvYjDu1x6qF2BqJUIKx8fzAGAB1sXvN2TUDZC2Cha6sPoSKbSRc9Pch512qZsBF0aWCkqmX9SNIuhGkhSbsMrRFXPvXUwyNirgSc/OcQ+Ijegp6okQTWLqE4kIsZOYWENsSyhDducZZCAjqfCbqZk6jgJ2BJ8R/lAH8YxAnYiGKySyzvsoSOyUT0N48pcjyR4x/LUKMS9y5AS02wvtnU0EFQT0P17o6X4VPivaazY1Vw==; 5:ZXxILNYmlIUU41SmXUq27aGEDCkYKN4YiHp/TmdCwIBYokAcq6MJRrxd9v5yEfgJrMSziU82TWiZQTHRu+6tuHXqmtGpkiPkW+Ul8JE+pLErSSQHySSD9jsTkukxqBw/laKUHrfu51E7x+M3V0CWxCfigKqKLQfwzlaQXVQBgHE=; 24:u8nTV2NUSo99C6XP6L6n4tYKmoqybgcR1xqLnR0Hv1UOZcvzNZZHUJIgoTdg3Qs9Qvv901lG/bzT8oIUiElpIdYjLoAohhjhjZAzdLeuefE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 7:L92r+stLeUkpqGeX70x6IqQvbroEkpyyfNwqGpfv73/vFFRGEBNGkwLA1fdyTmfQqIV9mVKzG01Ttl9rX/C2MPL0t2E780StiJtw2/2souxXIeIaVTobhfLnReQPlEOHQkU4KXSW1IQfdjuEKJKEtbAJHm0s5y25ARjkqylFzhbPvDzBL+o6Viq/zMYD0KMi56rHP9fIQ3c5UwXjNgEcJkcwhAsMygdDMd6HDuq9J+0rCdXNWScrJdRvm+1HOF1HHb4zb20cMasGd62gIudfbSd/M6bPxftDh5qNrZlYchs00Hm9E0nQMC+TOCohs8C/PWkp0w7B/uWBdN6/st9bhQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2017 16:22:06.5156 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2994 Archived-At: Subject: Re: [mpls] Use of leaf-lists in draft-ietf-mpls-static-yang X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 16:22:14 -0000 ---- Original Message ----- From: "Tarek Saad (tsaad)" To: "Aidan Copeland" ; ; Sent: Friday, March 31, 2017 2:53 PM > Hi Aidan, > > You are right. Indeed, it is permissible the same labels values can repeat in the label stack and thus the leaf-list is not suitable. I’ll look into this and we’ll update it the model. > Thanks for reporting it. The logic is that individual entries in a list can be separately edited -which being 'configuration' implies that they may be - and so must have a unique identifier for NETCONF to use. The usual solution to this, in a database, is to introduce an additional 'column' purely to provide that unique identifier, often an integer. Incidentally, your reference for YANG is to V1.0 which always makes me wonder if it will work with YANG V1.1:-) Tom Petch > Regards, > Tarek > > On 2017-03-29, 10:30 AM, "Aidan Copeland" > wrote: > > Hi Tarek, all, > > I think that there is an error in the use of a leaf-list to represent the set of outgoing MPLS labels to impose for an outgoing path. > > RFC7950, section 7.7, states > > In configuration data, the values in a leaf-list MUST be unique. > > This means that a leaf-list is not suitable to represent a label stack, where the same label value may be used more than once. > > I think the best solution is instead to specify the set of outgoing labels as a list of outgoing label containers, keyed by label index and containing the outgoing label value. > > Do you agree with this, or do you think a different mechanism would be better? > > Regards > > Aidan > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >